一、四周的轨迹

先看轨迹。五个技能不是设计出来的，是一周加一个加上去的。

产出那一列能看出节奏：第 1 周 4 份，第 2 周 9 份，第 3 周掉到 1 篇，第 4 周 3 篇。 第 3 周掉下去是正常的——第一次并联写三节，全耗在调接口上了。 加技能的那个星期，产出一定会掉。掉了别慌，那是学费，不是能力问题。

二、坑一：一个词被两个技能认领

五个技能的描述写完之后，有两个词同时住在两个描述里：「大纲」和「初稿」。 write 写「按大纲写初稿」，outline 写「生成文章大纲」，polish 写「润色初稿」。 结果四个请求里有两个是并列第一，靠名字的字母序侥幸选对了。 并列第一等于没选。真机上模型看到两个都像，也是随便挑一个。 修法很简单：把重复的词换掉。write 里的「大纲」换成「提纲」，「初稿」换成「正文」。 改完重测，并列从 2 个降到 0 个。分数没怎么变，变的是不用再靠名字排序决定谁上。

三、坑二：上下文被前一步塞满

五步走完，桌面从 22% 一路涨到 99%。 涨得最狠的是「三节初稿」那一步：1800 字一次进来，从 34% 跳到 66%。 最后润色再进 1800 字，8086 token，占 8192 的 99%。只剩 106 token。 这就是「跑到最后没地方干活」的真实样子。它不是突然坏的，是一路涨上来的。 修法不是「少读点」，是把中间产物落盘：写完就存文件，对话里只留结论。 落盘之后，重跑下游可以直接读文件，不用把全文再搬一遍进上下文。

四、坑三：并联三节风格不一样

三节是三路同时写的，每路只看到大纲，看不到别人怎么写。 量出来平均句长是 36、8、14 字，一节比一节短，最大差 28 字。 三个人写三节，读者会觉得是三个人写的——因为它确实是三个人写的。 解法不是让它们互相看。互相看就变成串联了，并联的收益全没了。 解法是在派活时把同一份「措辞约定」发给每一路：句长上限、禁用词、段落句数。 约定要短，短到能塞进每一路的派活话里。长了就等于让它们各自去读一份文档。

五、体力活交出去，脑力活自己干

四周下来最值钱的一条经验，不是哪个技能写得好，是分工的比例。 交出去的：清洗、套格式、写初稿、配图方案。这些有明确标准，错了能一眼看出来。 自己留着的：定选题、挑大纲、判断哪个版本更好、决定要不要发。 交界处最容易搞错的是「写初稿」。很多人舍不得交，觉得初稿就是文章。 初稿不是文章，初稿是能改的东西。写初稿是体力活，改初稿才是脑力活。 这也解释了为什么第一章说「技能是菜谱」：菜谱能替你切菜配料，替不了你决定今天做什么菜。

六、本章小结

第 5 章讲的是组合，四件事。 拆：几处都要用的能力拆成独立技能。省 token 是小事，改一处只动一个文件是大事。 排：组合的本质是排依赖。串联、并联、循环三种，一条真实的工作流里三种都有。 派：并联受限于上下文空间，不受限于速度。派子智能体是拿空间换空间的办法。 接：五个技能串起来，崩在接口上。接口处只允许一种形状，由上游负责。 三个坑的共同点值得再说一遍：单看每个技能都没毛病，凑成一条链就全是毛病。 下一章往上再走一层：把「拆、排、派、接」变成一套从需求到上线的固定流程。

七、动手 Demo：四周才凑齐五个技能，三个坑是花钱买来的

这一段把四周的轨迹和三个坑的实测数摆出来：描述查重、上下文预算、并联风格差异。 三个数都是真算的，不是估的：关键词归属、累计 token、平均句长。

KEY = ['大纲', '初稿', '正文', '润色', '配图', '素材', '方案', '提纲']
dup = [(k, [n for n, d in DESCS if k in d]) for k in KEY]
dup = [(k, v) for k, v in dup if len(v) > 1]   # 被两个技能共用的词

used = 0
for n, add in STEPS:
    used += tokens(grow(add))
    print(n, used, '%.0f%%' % (used * 100.0 / 8192))

实跑输出：

--------------------------------------------------------------------
四周才凑齐五个技能，三个坑是花钱买来的
--------------------------------------------------------------------


  ① 四周的轨迹
  --------------------------------------------------------------------
| 周 | 这周加了什么 | 怎么用 | 产出 |
|---|---|---|---|
| 第 1 周 | 会议纪要 | 一个技能，手动一句一句喊 | 纪要 4 份 |
| 第 2 周 | 加清洗技能 | 两个技能，先清洗再出纪要 | 纪要 9 份 |
| 第 3 周 | 加大纲、写作 | 四个技能，第一次并联写三节 | 长文 1 篇 |
| 第 4 周 | 加润色、配图 | 五个技能，一条链跑完 | 长文 3 篇 |

  四周加五个技能，平均一周一个。加得太快会互相打架，加得太慢会一直手忙脚乱。

  ② 坑一：两个词被两个技能共用
  --------------------------------------------------------------------
| 关键词 | 几个描述里有 | 是哪几个 |
|---|:---:|---|
| 大纲 | 2 | outline、write |
| 初稿 | 2 | write、polish |

  这 2 个词，每个都同时住在两个技能的描述里。
  用户一说「大纲」，两个技能都觉得自己该上；一说「初稿」，又是两个。

  ③ 并列第一，靠名字排序侥幸选中
  --------------------------------------------------------------------
| 请求 | 选中 | 分数 | 是否并列 |
|---|---|---:|---|
| 出个大纲给我 | outline | 0.200 | 并列 |
| 把这段初稿润一下 | polish | 0.143 | 并列 |
| 帮我写一节正文 | write | 0.500 | 唯一 |
| 给这篇文章配几张图 | illustrate | 0.250 | 唯一 |

  四个请求里 2 个是并列第一。
  ! 这次侥幸选对了，因为 polish 的字母序在 write 前面。名字一换就错。

  ④ 改描述：一个词只归一个技能
  --------------------------------------------------------------------
| 关键词 | 改前在哪 | 改后在哪 |
|---|---|---|
| 大纲 | outline、write | outline |
| 初稿 | write、polish | polish |
| 提纲 | — | write |

  做法很简单：把重复的词换掉。write 里的「大纲」换成「提纲」，「初稿」换成「正文」。

  ⑤ 改完之后重测一遍
  --------------------------------------------------------------------
| 请求 | 选中 | 对不对 | 是否并列 |
|---|---|---|---|
| 出个大纲给我 | outline | 对 | 唯一 |
| 把这段初稿润一下 | polish | 对 | 唯一 |
| 帮我写一节正文 | write | 对 | 唯一 |
| 给这篇文章配几张图 | illustrate | 对 | 唯一 |

  并列从 2 个降到 0 个。现在每个关键词只有一个技能认领。
  ! 分数没怎么变，变的是「不用再靠名字排序决定谁上」。

  ⑥ 坑二：上下文被前一步塞满了
  --------------------------------------------------------------------
| 步 | 这一步进多少 | 累计 | 占 8192 |
|---|---:|---:|---:|
| 素材 | 1200 | 1765 | 22% |
| 分析 | 400 | 2354 | 29% |
| 大纲 | 300 | 2796 | 34% |
| 三节初稿 | 1800 | 5441 | 66% |
| 润色 | 1800 | 8086 | 99% |

  走到最后一步，桌面已经占掉 99%。
  ! 这也是为什么第 3 步之后要把中间产物落盘：留在上下文里的每一份都在重复付费。

  ⑦ 坑三：三节同时写，风格不一样
  --------------------------------------------------------------------
| 节 | 句数 | 平均句长 | 字数 |
|---|---:|---:|---:|
| 第一节 | 3 | 36 | 111 |
| 第二节 | 7 | 8 | 60 |
| 第三节 | 4 | 14 | 59 |

  三节是三路同时写的，每路都只看到大纲，看不到别人怎么写。
  平均句长从 8 到 36，差 28 字，读起来像三个人写的。
  ! 解法不是让它们互相看，是在派活时把同一份「措辞约定」发给每一路。

  ⑧ 三个坑的共同点
  --------------------------------------------------------------------
| 坑 | 根因 | 怎么绕开 |
|---|---|---|
| 描述打架 | 一个词被两个技能认领 | 一个词只归一个技能 |
| 上下文塞满 | 中间产物一直留在桌上 | 落盘，只把结论留在对话里 |
| 风格不一致 | 并联的两路互不可见 | 派活时发同一份约定 |

  三个坑都不是「技能写得不好」，是「几个技能放在一起才出现的问题」。
  ! 单技能看每个都没毛病，凑成一条链就全是毛病——这就是工程化要解决的事。

第一段是四周轨迹，产出那一列能看出节奏：加技能的那个星期产出一定会掉。 第二段查重复归属词，两个词被两个技能共用：「大纲」和「初稿」。 第三段四个请求里两个并列第一，靠字母序侥幸选对——并列第一等于没选。 第四、五段改描述再重测：并列从 2 个降到 0 个，分数没怎么变，变的是不用靠名字排序。 第六段算上下文：从 22% 涨到 99%，最后只剩 106 token，跑到底没地方干活。 第七段量三节的平均句长：36、8、14，最大差 28 字，读起来像三个人写的。 收益最大的一条经验是分工比例：有标准可判的体力活交出去，判断和取舍自己留着。

30 秒实验

1. 把你的几个技能的 description 列出来，找被两个以上技能共用的词。找到就换掉一个。
2. 给你最近一次多步任务标一下每一步进多少 token。超窗口一半的时候，就该落盘了。
3. 写一份三行的「措辞约定」：句长上限、禁用词、每段句数。下次并联写作时发给每一路。

常见误区

1. 以为加技能会立刻提效。加技能的那个星期产出一定掉，因为要调接口。掉是学费，不是能力问题。
2. 放任两个技能共用一个词。并列第一等于没选，真机上模型看到两个都像就随便挑。 一个关键词只归一个技能。
3. 舍不得交出初稿。初稿不是文章，初稿是能改的东西。写初稿是体力活，改初稿才是脑力活。

第 5 章完。下一章把这套做法变成固定流程：需求、设计、实现、测试、上线。

• ☐ （本篇完，下一篇 6.1 需求分析：动手前先想清楚）

相关笔记

• 五个技能搭起一条写作工作流
• 先拿会议纪要开刀
• 网络与信息安全 · 索引
• 🧩 Skill提效实战 · 索引