如何把经验装到Skills¶

Ch03.067 如何把经验装到Skills¶

📊 Level ⭐⭐ | 12.2KB | entities/how-to-encode-experience-into-skills.md

核心内容¶

调试背景¶

SaaS 产品经理每周评估 1-10 家客户定制需求工作量，少则 1 小时，多则一整天。既重复又高频还费时间，但认真做完后真正付费的客户可能不到 5%。这是一个典型适合用 Skills 解决的场景。

第一轮调试：Skill 干太多事¶

做法：一个 Skill 同时输出解决方案、用户故事、流程图 + 工作量评估。问题：

评估基准飘了：经验判断约 15 人天的需求，Skill 给出 30-59 人天
拆得太细太技术化，研发内部内容直接暴露给客户根因：一个 Skill 同时承担"方案设计"和"工作量评估"两种不同职责，一个偏发散，一个偏收敛，不该混在一起。

第二轮调试：只给约束，不给方法¶

做法：拆成两个 Skill，测试 Skill 专门负责评估工作量。给出硬性比例约束（测试工作量是后端 1/3-1/2、前端是后端 1/2 等）。问题：Skill 非常"听话"地照着比例套用，结果教条——15 人天的经验判断， Skill 套出来 44 人天（后端 18+前端 9+测试 9 天），数字规整但结果不对。根因：只给比例不给判断框架 = 告诉新人很多规则但没让他建立判断框架。AI 会认真执行约束，但不理解为什么这样约束。

第三轮调试：给经验，更给判断逻辑¶

核心改变：不再给死规则，而是把真正的方法论讲清楚。四条关键原则： 1. 需求是 1，方案是 1：需求没搞清楚之前不能评估工作量；方案没定下来之前不能给时数 2. 明确的拆解路径："需求 → 场景 → 模块 → 功能 → 原子任务"链路，一个功能点只做一件事，链路要闭环 3. 五步法：按需求→场景→业务→最小功能点→任务的顺序逐层展开，不按角色拍脑袋 4. 给经验参考系，不给铁律：测试工作量通常是后端的一半；产品按需求复杂度浮动（小需求 0.5 天，复杂需求 3-5 天） 后续微调：输出形式从"按角色评估"改为"按场景组织"（一行一个用户场景，客户更易读）；产品/测试改为场景级汇总而非逐功能点细拆。

最终判断标准¶

标准	说明
颗粒度合适	不能粗到只剩总人天，也不能细到全是不懂的技术项
结果符合经验	经验判断 10 人天 → 上下 20% 波动可接受，翻倍或离谱则无意义

核心结论¶

Skills 不是替你"发明"工作经验，而是帮你把已有经验稳定地复用出来。 Skill 的价值 = 你讲清楚多少判断标准和方法论，而非给出多长的提示词。

深度分析¶

第一性原理：Skill 的本质是经验的压缩格式¶

这篇文章最核心的认知贡献是揭示了 Skill 和 Prompt 的本质区别：Prompt 是指令，Skill 是经验的结构化载体。 Prompt 的逻辑是"告诉 AI 怎么做"——给出规则、给出示例、给出约束，AI 按照指令执行。Skill 的逻辑是"把人的经验固化下来"——这个人是怎么判断的？他的判断标准是什么？他遇到矛盾时怎么权衡？这两种逻辑产出的 AI 行为有本质差异：Prompt 给出的 AI 输出依赖模型自身的推理能力，Skill 给出的 AI 输出复制的是这个人的判断框架。第三轮调试的核心改变——从"给约束"到"给判断逻辑"——正好说明了这一点。比例约束是浅层规则，AI 执行时并不理解这个比例背后的业务逻辑。判断逻辑（需求没搞清楚不给时数、按场景链路拆解而不是按角色拍脑袋）才是真正的经验内核。AI 学会了这个逻辑，才能在面对新场景时做出合理判断，而不是机械套用比例。

三轮调试揭示的 Skill 开发范式¶

第一轮失败（Skill 承担多种职责）是 Skill 开发中最常见的错误。当一个 Skill 试图同时做"方案设计"和"工作量评估"时，它实际上试图让 AI 同时做两种推理模式：发散性推理（探索可能的方案）和收敛性推理（评估每个方案的成本）。这对应大脑的两种不同认知模式，让一个 Skill 同时运行两种模式会导致输出不稳定。教训：每个 Skill 应该对应一个判断模式。如果要同时覆盖多个模式，应该拆成多个 Skill，通过编排组合它们。 第二轮失败（给规则不给框架）是第二常见的错误。规则告诉 AI"是什么"（测试是后端的 1/3-1/2），框架告诉 AI"为什么"（为什么这个比例是合理的，什么时候这个比例不适用）。没有框架的规则是脆弱的——AI 在遇到边界情况时既不知道规则为什么存在，也无法灵活调整。更深层的问题是：AI 执行规则的能力远强于理解规则的能力。这就是为什么"听话"的 AI 给出了更教条的结果——AI 忠实地执行了每条规则，但每条规则在单独执行时都没有考虑相互作用的语境，最终结果反而离经验值更远。

"按场景组织" vs "按角色评估"的设计演进¶

输出形式从"按角色评估"改为"按场景组织"这个微调揭示了一个重要的 Skill 设计原则：Skill 的输出格式应该服务于使用者的认知模型，而不是 AI 的推理便利性。 "按角色评估"（前端多少天、后端多少天）是 AI 推理最自然的输出结构——它直接映射到软件工程的角色分工。但客户（产品经理的使用场景）需要的是"这个功能能不能做，什么时候能做好"这种场景级答案。把 AI 的推理结构（按角色）翻译成用户的需求结构（按场景）是 Skill 设计后期的重要工作。这也说明 Skill 开发不是一次性的"写好 prompt"过程，而是需要通过用户反馈循环持续优化的。第一轮和第二轮的问题都是通过实际使用才发现的，不是写的时候就预见的。

实践启示¶

Skill 开发的第一步：经验提取，而不是 Prompt 写作¶

在动手写 Skill 之前，应该先完成一个独立的"经验提取"步骤。具体做法： 1. 画出你的判断路径：当遇到这个任务时，你实际上是怎么思考的？先画流程图（不是写 prompt） 2. 识别判断节点：在哪些节点你做了权衡？权衡的标准是什么？ 3. 标注边界：什么情况下你的判断标准会变化？有没有例外情况？ 4. 找测试 case：挑 5 个你已经处理过的案例，用这些判断路径重新走一遍，验证是否和实际结果一致只有完成这 4 步，才进入 Skill 写作阶段。经验提取的质量直接决定 Skill 的质量——"给不出好 Skill"通常是因为"还没想清楚自己的经验"。

多轮调试的最小可行节奏¶

这篇文章的价值在于展示了完整的调试过程。但在实际操作中，可以更高效： 第一轮写 Skill 时故意做减法：不要试图一开始就写出"完整"的 Skill。先只写一个最核心的功能（只做工作量评估，不做方案设计），跑通后用真实 case 测试。根据测试结果扩展，而不是一开始就穷举所有场景。 每个测试 case 记录三个东西：①输入是什么（用户的原始需求）②Skill 输出是什么 ③你的经验判断是什么。三个东西放在一起对比，才能发现 Skill 输出偏差的模式。 当发现偏差时，先定位根因：

输出稳定但偏大 → 通常是 Skill 在发散阶段过于自由，需要加约束
输出稳定但偏小 → 通常是 Skill 过于保守，需要放宽边界
输出不稳定 → 通常是 Skill 的判断框架不清晰，需要明确决策节点

"给经验参考系，不给铁律"的具体操作¶

第三轮调试的第四条原则（给经验参考系，不给铁律）是最有操作价值的洞察。具体怎么操作： 把比例变成锚点：不要说"测试是后端的一半"，而说"测试工作量通常是后端的一半，但如果有以下情况应该增加：①测试环境搭建复杂 ②涉及第三方系统集成 ③功能涉及事务一致性验证。也可以减少：如果功能是纯展示型、已经有过类似测试经验"。这样AI获得了：①基准值（后端的一半）②调整方向（在什么情况下加减）③调整的原因（和环境复杂度、集成复杂度、经验覆盖相关）。这比单纯给比例多了一个可以在新场景下推理的框架。 输出"建议值 ± 合理波动范围"而不是精确数字：说"后端 15-18 天"比说"后端 16 天"更诚实，因为它传递了不确定性区间，让用户在使用输出时知道如何处理这个数字。

评估 Skill 质量的两个维度¶

轴1：输出稳定性——同样的输入多次运行，输出是否一致？波动太大说明判断框架不清晰。 轴2：输出符合度——Skill 输出和专家判断的一致性有多高？可以用经验判断作为 ground truth，计算偏差率。最好的 Skill 是高稳定性 + 高符合度的。如果低稳定性 + 高符合度（输出波动大但都接近专家值），问题可能在推理过程有随机性，需要减少采样温度或明确更多决策节点。如果高稳定性 + 低符合度（输出稳定但远离专家值），说明 Skill 学到的是规则而不是判断框架，需要重建底层逻辑。 → 原文存档