06
第六章 · 从会写到写好
工程化：从需求到上线
设计四招与测试四步
写技能不是灵感活，是工程活：需求、设计、实现、测试、上线，一段都不能省。本章的底层信念是演进式架构——先跑通，再演进；把复杂度锁在技能文件里，而不是转嫁给用的人。
本页末附 · 读书会：对我们的启发 ↓
框架详解
很多人以为写技能的门槛在"写"，其实门槛在"流程"。本章给出一条完整的生产线，管理者可以把它理解成一个微型项目的立项到验收。
全流程五段：需求 → 设计 → 实现 → 测试 → 上线起点是真实痛点——好技能不是想出来的，是从反复出现的麻烦里长出来的，书中建议用 5 分钟先把需求定义清楚。中间的实现环节讲人机协作：你负责决策，智能体负责执行，逐步构建、不求一步到位。这套顺序对管理者并不陌生，它就是把"做项目"的纪律搬到了写技能上：先想清楚为谁解决什么，再动手，最后用测试证明它真的有用，才谈得上交付。
设计四招：让技能更靠谱
第一招 · 记录踩坑点把反复犯的错记下来，写进技能。这一招最朴素也最值钱：技能的可靠性不是靠一次写对，而是靠把每次翻车的教训沉淀成约束。团队里"老带新"的口口相传，在这里变成了可以固化的文字。
第二招 · 可容错假定一定会出意外，然后为意外预留位置：开头先做检查、关键动作前留人工确认、中间设检查点。这和管理里的风控思路一致——不是祈祷不出事，而是出了事能被拦住、能被发现。
第三招 · 可扩展让技能支持组合或外挂配置，将来加新需求时不用改原文件。一开始就留好这个口，技能才有"长大"的空间；否则每次改动都要动正文，改一处塌一片，没人敢碰。
第四招 · 跨对话记忆让技能记住上次做了什么。对反复执行的工作来说，这一招决定了它是"每次从零开始的工具"还是"越用越懂你的助手"。四招走完，书中还提醒用一份设计检查清单收尾过一遍，别凭感觉交卷。
把踩坑点写进 SKILL.md，失败案例存入独立测试题库——千万别把测试用例写进 SKILL.md。
测试四步：证明技能真有增益
第一步 · 构建测试用例一个用例由指令 + 输入 + 期望结果三件套构成。指令要像真人说话，覆盖正式与口语、长与短等多种情况，并且别忘反例——那些沾边但不该触发技能的请求，比正例难写，也更有价值。
第二步 · 写客观检查项在看到任何输出之前，先把"什么算过、什么算不过"写成客观标准。这是整套方法里最反直觉、也最像管理者本能的一步：先定验收标准，再看交付物。
第三步 · 有/无技能对比跑测同样的任务，开着技能跑一遍、关掉技能跑一遍，对照检查项打分。这是最硬的验收：它回答的不是"输出好不好看"，而是"这个技能到底带来了多少增益"。
第四步 · 根据丢分项改技能丢分的地方就是改进的方向。改完再用整套题库复测，形成闭环。测试不是上线前的仪式，而是技能迭代的发动机。
上线三层与 EXTEND
个人自用 → 团队分享 → 社区发布上线不是一个动作，是三个台阶。个人自用门槛最低；到了团队分享这一层，书中给出关键机制 EXTEND 文件——团队共用一份原版技能，每个人的个性化偏好写在自己的外挂文件里，不改原 SKILL.md。原件保持干净，个性各归各家，升级原版时谁也不受伤。再往上是社区发布，让技能走出团队接受更大范围的检验。
关键概念
| 概念 | 一句话理解 |
|---|
| 演进式架构 | 技能从简单长到复杂，体现在文件夹结构的演进——比如从 20 行单文件长成 641 行主文件加 26 个参考文档。原则是先跑通，再演进。 |
| 测试用例三件套 | 指令 + 输入 + 期望结果。指令要像真人说话，覆盖多种情况，别忘反例。 |
| 踩坑点 vs 测试用例 | 铁律：踩坑点写进 SKILL.md（教智能体做事），失败案例存入独立测试题库（留案发现场），两者绝不混放。 |
| EXTEND | 团队分发时的个性化外挂文件，各人写各人的偏好，不动原 SKILL.md。 |
| 有/无技能对比 | 开关技能各跑一遍、对照客观检查项打分，用增益说话的验收方法。 |
心智模型
本章其实只有一个心智模型：把技能当软件做。软件行业用几十年学费换来的纪律——需求先行、为失败设计、测试驱动、版本演进——在技能这件事上照单全收。对非程序员来说，好消息是这些纪律不需要你会写代码，只需要你会做管理。
其中最值得单独记住的是"先定考题，再测考生"。人看到一份输出，判断力就会被第一印象锚住，就像考试先看了答案再出题，出的题必然偏向那份答案。先写客观检查项、再看输出，是给自己的判断力上的保险。
书中案例
WORKED EXAMPLE · 会议纪要技能的测试题库
书中用一个会议纪要技能演示测试用例怎么写。用例一：指令是"帮我整理一下昨天产品评审会的纪要"，输入是 30 分钟会议转录稿，期望按模板输出纪要，含决议事项和待办清单。用例二：指令是"这个讨论记录太长了，帮我提炼重点"，输入是 90 分钟头脑风暴转录稿，期望提炼核心讨论点和结论，过滤闲聊。
三个要求贯穿其中：指令像真人说话（带文件路径、口语缩写）；覆盖多种情况（正式与口语、长与短、边界）；别忘反例——翻译技能的好反例不是"写个斐波那契函数"（太明显不相干），而是"帮我把这段话改得更通顺"（沾边，但其实要的是润色）。
遇到失败案例要做两个动作：一是提炼成"踩坑点"约束写进 SKILL.md，教智能体做事；二是固化成"测试用例"存入独立题库，留下案发现场。此后每次改技能都用整套题库复测，杜绝旧问题复现。
反模式
ANTI-PATTERNS · 这些坑别踩
- 先看输出再定标准——判断力被第一印象锚住，等于考试先看答案再出题。永远先定考题，再测考生。
- 把测试用例写进 SKILL.md——污染技能正文，干扰智能体正常运行。测试用例的家在独立题库。
- 求一步到位——技能是逐步构建、逐版演进出来的，不是一次写成的。
- 只写正例不写反例——不该触发、容易混淆的反例比正例难写，也更有价值，缺了它测试形同虚设。
本章要点
- 技能当软件做：需求 → 设计 → 实现 → 测试 → 上线，走演进式架构，先跑通再演进。
- 设计四招：记录踩坑点、可容错、可扩展、跨对话记忆，收尾过一遍设计检查清单。
- 先定考题再测考生——客观检查项写在看到输出之前，避免被第一印象锚定。
- 测试四步必含"有/无技能对比"，用增益证明技能真的有用。
- 踩坑点进 SKILL.md，测试用例进独立题库，两者别混。
- 上线分三层：个人自用、团队分享（用 EXTEND 做个性化，不改原件）、社区发布。
原文摘读 · 三段
原书 145 页
测试用例和检查项都准备好了，关键操作来了：同一个测试用例跑两遍——一遍用技能，一遍不用技能。
为什么？因为评测技能的价值，不在于看它的绝对输出有多好，而在于看它相比“裸跑”，把下限提升了多少。如果不用技能也能拿 80 分，用了技能拿到 85 分，那么这个技能可能不值得维护。如果不用技能只能拿 30 分，用了技能拿到 90 分，技能的价值便一目了然。
原书 144 页
不要把测试用例写进 SKILL.md，这里面只存技能流程、规则与踩坑经验，建议将测试用例单独建档，形成专属题库。
日常使用一旦出现问题，就把当时的指令与输入固化为新测试用例补充进题库；同时把对应的整改规则（踩坑点）写进 SKILL.md。后续每次修改技能，都用整套题库复测，杜绝旧问题复现。
面对同一次失败案例，我们需要做两个动作。一、提炼“踩坑点”：将具体的约束（如“遇到术语必须用行业惯用语”）写进 SKILL.md，用来教智能体做事。二、固化“测试用例”（留案发现场）：把引发问题的原始对话和文件存入独立的测试用例文件。千万别把考题也写进 SKILL.md，那会干扰智能体的正常运行。一句话总结：把踩坑点写进 SKILL.md，失败案例存入测试题库。
原书 137–138 页
对于团队共享的技能，在实现可扩展设计时，还有一个进阶做法：扩展文件机制。以我开源的 baoyu-skills 项目为例，所有技能都支持通过扩展文件（EXTEND.md）进行自定义，无须修改原技能。
比如你想给封面图生成技能加一套企业品牌配色，不用改原技能的 SKILL.md，只需要在项目目录下创建一个扩展文件……智能体执行技能时会先读取扩展文件，用其中的配置覆盖默认值。团队里每个人可以有自己的扩展配置，互不干扰。
注意扩展文件要放在项目目录或用户目录下，不要放在技能安装目录下——技能升级时，安装目录会被覆盖，你自定义的部分就丢了。
读书会 · 对我们的启发
吴总的角度 · 销售管理
- 「踩坑点进 SKILL.md、测试用例存独立题库」——团队沉淀经验最容易犯的错就是把两者混在一起
- EXTEND 机制值得留意：团队共用一份技能，每人有自己的个性化层，不改原件——正适合团队里每个人风格不同的现实
Vera 的角度 · 市场部
- 「有/无技能对比」是最硬的验收法：一直在用，先定考题再测考生，防第一印象锚定
- 设计四招里「可扩展（外挂配置不改原文件）」是技能能长大的前提，一开始就要留口