实战指南：如何将个人经验转化为高效的AI Skills

在AI技术飞速发展的今天，如何让AI真正融入日常工作而非停留在概念演示阶段，已成为众多企业和技术从业者关注的核心议题。 Skills作为AI能力的重要载体，其价值不仅在于执行任务，更在于承载和复用个人的专业经验与判断标准。许多人在初次接触Skills时会产生疑问：既然AI已经如此强大，为什么还需要将个人经验“喂”给它？答案在于，AI虽然能够给出完整且看似专业的答案，但这些输出往往缺乏针对特定业务场景的适配性。真正高效的Skills，需要我们将积累的经验、方法论和判断标准转化为明确的边界与约束，让AI的输出能够真正服务于具体的工作需求。

第一轮调试：一个Skill承担过多职责

本文以SaaS产品经理每周都需要面对的客户定制需求工作量评估为例，详细分享将个人经验转化为Skills的完整过程。作为产品经理，评估客户定制需求是一项高频且耗时的工作——少则每周1至2家，多则5至10家，每次评估耗时从1小时到一整天不等。如果不认真评估，仅给出笼统的人天数据，客户往往会追问评估依据；而如果认真分析，又要投入大量时间，最终真正付费的客户可能不足5%。这正是Skills可以发挥价值的典型场景。

第二轮调试：拆分职责但仅给出要求

在初次调试时，作者犯了一个常见的错误：希望一个Skill能够一次性完成所有工作。输入一个需求后，期待它同时输出解决方案、用户故事、流程图以及工作量评估。这种“一步到位”的思路看似高效，实际上却带来了严重问题。首先，评估结果的偏差极大——原本经验判断约为15人天的需求，AI给出的方案一可能是30人天，方案二甚至高达59人天。其次，输出内容过于技术化，将大量研发内部的实现细节直接暴露给客户，反而增加了沟通难度。反思这一轮失败的原因，关键在于一个Skill同时承担了“方案设计“和”工作量评估“两种职责——前者偏发散，后者偏收敛，本质上不应混为一谈。

第三轮调试：注入方法论而非仅给规则

基于第一轮的教训，作者开始将职责拆分。新的问题浮现：虽然给出了很多要求，却未能将背后的经验和方法论一并传递。第二轮调试中，作者将工作拆分为至少两个Skill，一个负责设计方案，另一个专门负责评估工作量。这次作者明确给出了一些经验判断规则：测试工作量通常是后端的三分之一到二分之一，前端一般是后端的一半，产品和设计工作量最小，简单需求1天，最复杂不超过5天。然而测试结果却令人哭笑不得：同样一个经验判断约15人天的需求，AI直接给出了44人天的评估，而且数字呈现方式极为“规整“——后端18天、前端9天、测试9天，看起来逻辑自洽但结果明显偏离实际。这一轮让作者深刻意识到：只给比例、不给方法，危害更大。AI会非常认真地执行约束，却未必理解这些约束背后的逻辑——这与新人员工记住所有规则却仍做不好工作的道理相同。

判断Skills是否真正可用的标准

经过前两轮调试，作者意识到核心问题在于对AI的期待不切实际。与其期待AI能够“肚子里的蛔虫“般自动理解需求和业务，不如将其视为一位能力很强但刚入职的同事——需要明确的指导和方法论。第三轮调试采用了完全不同的策略：首先，明确“需求是1，方案是1“的原则，在需求未搞清楚之前不评估工作量，方案未确定之前不给时数；其次，建立明确的拆解路径，采用“需求→场景→模块→功能→原子任务“的链路，并遵循一个功能点只做一件事、链路要闭环等原则；再者，将工作量评估定义为“五步法”，按顺序逐层展开而非直接按角色拍脑袋报数；最后，将经验作为参考系而非铁律，允许小功能点评估为0.2或0.4天。经过多轮微调，最终输出的结果终于符合预期：按场景组织输出，每个场景下聚合功能点，分别展示后端、前端、产品、测试的工作量，最后汇总总人天，既便于客户理解，又保留了必要的细节支撑。

如有侵权，请联系删除。