一、四种形状

参考手册型：内容多、结构稳、按需查。形状是「正文薄加 refs 厚」。典型是代码审查细目、API 说明。 流程编排型：有先后顺序、每步有判据。形状是「编号步骤加命令」。典型是提交、发版、数据迁移。 检查清单型：一次要过很多项、每项可判定。形状是「勾选清单加阈值」。典型是上线前风险核查、安全自查。

路由分发型：入口分几类、每类不同做法。形状是「先分流加各自引用」。典型是客服问答、财务分析。 四种形状的差别不在内容长短，在读者（模型）拿到它之后做的第一个动作：查、做、核、还是分。

二、先定形状再写内容

写一个技能之前，先问一句：这一次任务的动作是哪一种？ 是「模型得先知道一些事才能干」——参考手册型。 是「模型要按顺序做几步」——流程编排型。

是「模型要逐项确认有没有问题」——检查清单型。 是「模型要先判断这次属于哪一类」——路由分发型。 四个问题问完，正文的骨架就定了。剩下的工作只是往里填内容，而不是边写边想结构。

反过来，先写内容再套模式，通常写成四不像：一段背景、几条步骤、几个条目混在一起，读起来什么都有， 用起来什么都不是。

三、最容易混的两对

第一对是参考手册型和检查清单型。分界是：前者是「要知道」，后者是「要过一遍」。 参考手册型的产出是理解，读完之后模型知道该怎么判断； 检查清单型的产出是结论，过完之后每一项都有「过」或「不过」。 第二对是流程编排型和路由分发型。分界是：前者是一条线走到底，后者是进来先分岔。

流程编排型里，步骤之间是时间关系（先做 A 再做 B）； 路由分发型里，支路之间是选择关系（走了 A 就不走 B）。 演示里六个需求，判对六个。 但这一节的判据是「人按经验选」，演示把它写成了几个关键词——所以全对不说明判据准， 只说明关键词跟需求贴得近。

四、模式可以叠加

四种模式不是互斥的。同一个技能里可以同时出现两种。 复合型就是路由加参考：第一段分流，每条支路后面跟一份参考文件。 任务型经常是流程加清单：主流程是编号步骤，其中某一步是「过一遍这份清单」。

叠加的时候要注意主次：一个技能只能有一个主形状。主形状决定第一段写什么， 其他形状退到第二段以后。 如果两个形状都想当主，那就是两个技能——这是最可靠的拆分信号。

五、判不出来的时候

分不清参考手册型和检查清单型的时候，问一句：这一次任务里，模型需要「做出判断」还是「逐项核对」？ 需要判断的走参考型——给它判据。需要核对的走清单型——给它条目和阈值。 分不清流程编排型和路由分发型的时候，问一句：这一次任务里，模型需不需要做「选哪条路」的决定？

需要就是路由型，不需要再看有没有固定顺序，有就是流程型。 这两个问题加起来不到十秒，但能省掉一次重写。结构错了，内容写得再好也白搭。

六、动手 Demo：四种设计模式，先看形状再选

先把四种模式的形状摆出来，再拿六个需求逐个判它该用哪种。 判据在这里写成了一组关键词——真机上是人按经验选。 所以这一节只验证「形状能不能被区分」，不验证「判据够不够聪明」。

keys = {
    u"参考手册型": [u"查", u"怎么用", u"细目", u"说明"],
    u"流程编排型": [u"步骤", u"按顺序", u"提交", u"执行"],
    u"检查清单型": [u"过一遍", u"十二项", u"检查", u"核对"],
    u"路由分发型": [u"还是", u"分别", u"分几类", u"哪种"],
}
got = max(((sum(1 for k in keys[p] if k in text), p) for p in keys))[1]

实跑输出：

--------------------------------------------------------------------
四种设计模式，先看形状再选
--------------------------------------------------------------------


  ① 四种模式各自的形状
  --------------------------------------------------------------------
| 模式 | 什么时候用 | 长什么样 |
|---|---|---|
| 参考手册型 | 内容多、结构稳、按需查 | 正文薄＋refs 厚 |
| 流程编排型 | 有先后顺序、每步有判据 | 编号步骤＋命令 |
| 检查清单型 | 一次要过很多项、每项可判定 | 勾选清单＋阈值 |
| 路由分发型 | 入口分几类、每类不同做法 | 先分流＋各自引用 |


  ② 六个需求，各自该用哪种
  --------------------------------------------------------------------
| 需求 | 该用 | 判成 | 结果 |
|---|---|---|---|
| 上线前把十二项风险过一遍 | 检查清单型 | 检查清单型 | 对 |
| 根据改动写提交信息并提交 | 流程编排型 | 流程编排型 | 对 |
| 帮我查一下这个 API 怎么用 | 参考手册型 | 参考手册型 | 对 |
| 客户问的是退款还是换货，分别怎么 | 路由分发型 | 路由分发型 | 对 |
| 数据迁移的五个步骤按顺序做 | 流程编排型 | 流程编排型 | 对 |
| 代码审查的二十四条细目 | 参考手册型 | 参考手册型 | 对 |

  六个里判对 6 个。

  ③ 六个全对，但这次不算数
  --------------------------------------------------------------------
  全对的原因是关键词表本身就是照这六个需求写的——这叫循环论证，不是判得准。
  真正要看的不是分数，是边界：一句话里混了两个模式的词，这套判据就会乱。
  比如「查一下这个 API 怎么用」里既有「查」又有「怎么用」，两个都指向参考型；
  但如果句子里再出现「分别」，同一个关键词计数会把路由型顶上来——这时候谁分高看的是词的数量，
  不是人的意思。
  ! 这就是为什么模式要先定、再写内容。先想清楚这一次任务的动作形状，再决定正文怎么写；
  反过来先写内容再套模式，通常写成四不像。

  ④ 四种模式最容易混的两对
  --------------------------------------------------------------------
| 容易混的一对 | 分界 |
|---|---|
| 参考手册型 vs 检查清单型 | 前者是「要知道」，后者是「要过一遍」 |
| 流程编排型 vs 路由分发型 | 前者是一条线走到底，后者是进来先分岔 |

  分不清的时候问一句：这一次任务里，模型需不需要做「选哪条路」的决定？
  需要就是路由型，不需要再看有没有固定顺序，有就是流程型。
  四种模式不是四个模板，是四种思考方式。
  同一个技能里可以同时出现两种：复合型就是路由加参考，任务型经常是流程加清单。

①四种模式各自的形状：参考手册型「正文薄加 refs 厚」，流程编排型「编号步骤加命令」， 检查清单型「勾选清单加阈值」，路由分发型「先分流加各自引用」。 ②六个需求判对六个。 但要看清这一节的判据是怎么来的——关键词表是照着这六个需求写的，这叫循环论证，不是判得准。 ③真正要看的不是分数，是边界：一句话里混了两个模式的词，这套判据就会乱。 比如「查一下这个 API 怎么用」里既有「查」又有「怎么用」，两个都指向参考型； 但如果句子里再出现「分别」，同一个关键词计数会把路由型顶上来——这时候谁分高看的是词的数量， 不是人的意思。 ④四种模式最容易混的两对：参考手册型对检查清单型（要知道对要过一遍）， 流程编排型对路由分发型（一条线走到底对进来先分岔）。 分不清的时候问一句：这一次任务里，模型需不需要做「选哪条路」的决定？ 需要就是路由型，不需要再看有没有固定顺序，有就是流程型。 四种模式不是四个模板，是四种思考方式。 同一个技能里可以同时出现两种：复合型就是路由加参考，任务型经常是流程加清单。

30 秒实验

1. 加一个需求「帮我把这次改动按模块整理成变更说明」，它该用哪种模式？ 跑一遍看判成什么，如果判错，缺的是哪个关键词？
2. 把「检查清单型」的关键词从四个减到一个（只留「检查」），重跑第 ② 步。命中率掉到多少？ 这说明关键词数量和判定能力是什么关系？
3. 给同一个需求同时写出两种模式的正文骨架（各三行），比较它们的第一句。 第一句的差别能用来判断该用哪种吗？

常见误区

1. 把四种模式当四个模板，挑一个往里填内容。模式是动作形状，填之前得先想清这次的动作是哪一种。
2. 一个技能里让两种形状并列当主。主形状只能有一个，两个都想当主就是两个技能。
3. 参考手册型写成了检查清单型：给了几十条要核对的条目，却没给「怎么判断」的判据。
4. 路由分发型的分流条件写成一句概括。判不了的条件等于没有分流。
5. 凭一句需求的关键词判断模式，不看这次任务的真实动作。词是表面，动作才是形状。

形状定了，下一节讲怎么验证它真的按预期被触发：准备请求集，一版一版改。

• ☐ （本篇完，下一篇 3.11 测试与迭代）

相关笔记

• 构建三类 Skill：三类技能各建一份
• 测试与迭代：描述该怎么迭代
• Claude Code 橙皮书 · 索引
• 🐎 Claude Code 实战 · 索引