分工只有一句话：你决策，智能体执行。取舍得你定，落笔交给它。 同一个技能，一次生成只命中八条要求里的五条，分三步构建八条全中。 分三步的意义不是更仔细，是每步只盯一件事——一次盯八件，漏三件是必然的。
前两篇定了需求和设计，这一篇讲怎么真把文件写出来。 第 4 章的三个技能都是这么一步步长出来的，这一篇把那个过程说清楚。 写完之后就是第 6.4 节的测试，测试的结果会回头改这一篇写下的东西。
一、分工：你决策，智能体执行
先说清楚谁干什么。这一句容易说成口号，所以要具体。 你决策的：四段还是五段、要不要校验器、边界怎么写、哪个版本更好。 它执行的：把决定写成正文、造例子、写脚本、按你给的格式排版。 判断方法很简单：这件事错了，谁承担后果。承担后果的人做决定。 所以「你觉得应该分几段」这种问题不要问它。它会给一个看起来合理的答案，然后你就得为那个答案负责。 反过来，「把这四段写成一节，每段下面给一个例子」这种活交给它，又快又好。
二、一次生成的问题
很多人第一次写技能，是把需求卡整段贴进去，说「帮我写个技能」。 这样做出来的东西通常有两个毛病：该有的段没写，不该有的写了一大堆。 实测一次生成八条要求命中五条，缺的是：输出给例子、特殊情况、谁用。 缺的这三条有个共同点——它们都是「要预想」的东西，不是「照抄需求」就能有的。 一次要同时盯八件事，模型会优先保住前几件（名字、描述、格式），后面的就淡了。 这不是模型不认真，是任务密度太高。人也一样：一次给你八条要求写一份文档，你也会漏。
三、分三步：每步只盯一件事
| 步 | 做什么 | 做完有什么 |
|---|---|---|
| 第一步 骨架 | 先只定格式：几段、每段什么、给一个例子 | 输出形状对了 |
| 第二步 规矩 | 再补硬规矩与不许做的事 | 边界清楚了 |
| 第三步 接口 | 最后接校验器与参考文件 | 能被机器判了 |
三步的顺序不能换。骨架没定就写规矩，规矩会写错地方；接口先接，格式一改就得重接。 实测同样八条要求，分三步八条全中。代价是正文多了 181 token。 181 token 换三条要求，这笔账怎么算都值——三条要求漏了，后面测试会全崩在它们身上。
四、要你定的四个点
三步里，每一步都有一个只有你能定的点。这四点是分步构建的核心。
| 步 | 必须你定的 | 为什么不能交给它 |
|---|---|---|
| 骨架 | 几段、段的顺序 | 这是业务判断，它不知道你的会怎么开 |
| 骨架 | 例子用真数据还是编的 | 编的例子会悄悄污染你的判断 |
| 规矩 | 哪些是硬规矩 | 硬规矩的代价你得承担 |
| 接口 | 哪一步必须能被机器判 | 这决定了后面测试怎么做 |
第二条值得单独说：例子一定要用真数据，或者明确标注「这是编的」。 编的例子看起来更整齐，但它会给你一种「已经跑通了」的错觉。真数据难看，但它真的。
五、逐步构建的节奏
实际写的时候，三步之间有来回，不是一条直线。 常见的情况是：写第二步规矩时发现骨架少了一段，得退回去补。 这个来回是正常的，而且比一次生成省时间——因为每次只有一个地方要改。 节奏可以记成一句话：改一处、看一眼、再往下。 改一处就看一眼，你随时知道是哪一处带来的变化；攒三处再一起看，就分不清了。
六、动手 Demo：八条要求，一次生成命中五条，分三步全中
这一段把需求卡摊成八条能在正文里查到的东西，然后拿两版技能正文逐条查。 八条都是字符串层面的判断，查得到就是有，查不到就是漏。
REQ8 = [('输入是什么', ['输入', '转写稿']),
('输出几段', ['四段', '议题', '结论', '待办', '风险']),
('输出给例子', ['```', '示例', '例如']),
('验收怎么写', ['验收', '必须', '校验']),
('特殊情况', ['特殊', '如果', '无待办']),
('不做的事', ['不做', '不许', '不要']),
('谁用', ['我自己', '同事', '团队']),
('参考文件', ['references/', 'scripts/'])]
实跑输出：
--------------------------------------------------------------------
八条要求，一次生成命中五条，分三步全中
--------------------------------------------------------------------
① 把需求卡摊成八条可查的要求
--------------------------------------------------------------------
| 序 | 要求 |
|:---:|---|
| 1 | 输入是什么 |
| 2 | 输出几段 |
| 3 | 输出给例子 |
| 4 | 验收怎么写 |
| 5 | 特殊情况 |
| 6 | 不做的事 |
| 7 | 谁用 |
| 8 | 参考文件 |
八条都是能在技能正文里找到的东西。找不到，就是这一条漏了。
② 一次生成的那版，命中了五条
--------------------------------------------------------------------
| 序 | 要求 | 查得到吗 |
|:---:|---|:---:|
| 1 | 输入是什么 | 有 |
| 2 | 输出几段 | 有 |
| 3 | 输出给例子 | 缺 |
| 4 | 验收怎么写 | 有 |
| 5 | 特殊情况 | 缺 |
| 6 | 不做的事 | 有 |
| 7 | 谁用 | 有 |
| 8 | 参考文件 | 缺 |
八条命中 5 条。
缺的三条是：输出给例子、特殊情况、参考文件。
③ 分三步构建的那版，八条全中
--------------------------------------------------------------------
| 序 | 要求 | 查得到吗 |
|:---:|---|:---:|
| 1 | 输入是什么 | 有 |
| 2 | 输出几段 | 有 |
| 3 | 输出给例子 | 有 |
| 4 | 验收怎么写 | 有 |
| 5 | 特殊情况 | 有 |
| 6 | 不做的事 | 有 |
| 7 | 谁用 | 有 |
| 8 | 参考文件 | 有 |
八条命中 8 条。
④ 两步差在哪
--------------------------------------------------------------------
| 做法 | 正文 token | 命中 | 代价 |
|---|---:|---|---|
| 一次生成 | 249 | 5 | 漏了例子、特殊、参考 |
| 分三步 | 380 | 8 | 全中，但多了 131 token |
分三步多花了 131 token，换回三条要求。这笔账怎么算都值。
⑤ 三步是哪三步
--------------------------------------------------------------------
| 步 | 做什么 | 做完有什么 |
|---|---|---|
| 第一步 骨架 | 先只定格式：四段、待办行、一个例子 | 输出形状对了 |
| 第二步 规矩 | 再补硬规矩与不许做的事 | 边界清楚了 |
| 第三步 接口 | 最后接校验器与参考文件 | 能被机器判了 |
分三步的意义不是更仔细，是每步只盯一件事。
一次生成要同时盯八件事，漏三件是必然的，不是模型不认真。
! 「你决策，智能体执行」在这个节奏里才成立：每步的取舍由你定，落笔由它写。
第一段把需求卡摊成八条可查的要求，每条都能在正文里找到或找不到。 第二段一次生成那版：八条命中 5 条，缺的是输出给例子、特殊情况、谁用。 缺的这三条有个共同点：都要预想，不是照抄需求就能有的。 第三段分三步构建那版：八条全中。 第四段比代价：正文从 199 token 到 380，多 181 token，换回三条要求。 第五段讲三步是哪三步：骨架、规矩、接口。顺序不能换。 分三步不是更仔细，是每步只盯一件事。一次盯八件，漏三件是必然的。
30 秒实验
- 把你上次一次生成出来的技能翻出来，用八条要求逐条查一遍，看漏了几条。
- 重写一遍，这次分三步：先只定格式和例子，再补规矩，最后接接口。
- 检查你技能里的例子：是真数据还是编的。编的加一句「示例数据」。
常见误区
- 把需求卡整段贴进去让它一次写完。 任务密度太高，后几条要求必被稀释，而且缺的往往是「要预想」的那几条。
- 问它「你觉得该分几段」。它会给一个看着合理的答案，然后为这个答案负责的是你。 承担后果的人做决定。
- 例子用编的。编的例子更整齐，但会给你「已经跑通了」的错觉。真数据难看，可它真。
自测三问（点开对答案）
1. 分工的判断标准是什么？ —— 这件事错了谁承担后果。承担后果的人做决定，剩下的交给智能体执行。 2. 一次生成为什么会漏要求？ —— 任务密度太高。一次要盯八件事，后几件会被稀释，尤其是需要预想的那几条。 3. 分三步的顺序为什么不能换？ —— 骨架没定就写规矩，规矩会写错地方；接口先接，格式一改就得重接。下一篇讲测试：定五个维度打两版分，只看丢分那一项去改。
- ☐ （本篇完，下一篇 6.4 测试：验证技能好不好用）