波仔
🛠️ 第5章 第一个可复用工作流：在 emotional_chat 项目中稳定复用
📄 一句话概括

值得抄成模板的只有一样东西：下次还会一模一样发生的事。 成本的大头不是「它想了多久」，是「它读了几遍」。 Demo 里一次任务读四个文件共四百一十三 token，五步写成脚本后一条命令跑完。

📝 本章和前面几章的关系

这一章最后一篇，做两件事：把闭环变成可复用的东西，把成本算清楚。 「团队资产」这个说法可能有点大，实质就是：你做第二遍的时候，比第一遍少想了多少。 Demo 先把一次任务的成本拆开（读了几个文件、多少 token），再把五步写成一个脚本， 一条命令跑完。

一、什么值得抄成模板

判断标准很朴素：下次还会一模一样发生的事，才值得抄。

东西 值不值得抄 为什么
步骤的顺序 值得 每次一样
验收的断言 值得 同类需求反复用
提交信息格式 值得 写进模板就不用想
具体改了哪几行 不值得 每次都不一样
这次的思考过程 不值得 抄下来也没人看

「具体改了哪几行」不值得抄，这一条要强调。 很多人喜欢把上一次的 diff 存成模板——结果第二次照着改，改出一堆不该有的东西。 真正能复用的是「骨架」：走哪几步、每步验什么、提交怎么写。 骨架不变，内容每次都变。

二、一次任务的成本拆解

成本有三个来源，按影响从大到小排：

来源 怎么算 怎么降
读进去多少 文件数乘单文件 token 缩小范围
读了几遍 轮数乘每轮的量 给好报错，少绕圈
写出来多少 diff 行数 把范围说死

Demo 里一次任务读四个文件、共四百一十三 token。 听起来很小，但每轮都重读一遍——三轮下来就是一千二百多。 所以降成本的第一手段不是换小模型，是缩小范围。 这一点在 4.2 节量过：整仓塞进去和只给目标文件，差三个数量级。

三、本章小结

这一章四篇，收成一张表：

问题 答案在哪一节 一句话
能不能进这个项目 5.1 一键跑、一键验
仓库要补什么 5.2 八条 readiness
一次变更怎么走 5.3 计划、改、验、留痕
怎么变成资产 5.4 抄骨架，别抄 diff

下一章开始铺 Harness 四件套的第一件：AGENTS.md。 在写它之前，请确认你已经有： 一个一键入口、一条能返回退出码的验证、一次走完的闭环。 这三样没有，AGENTS.md 写了也没人用。

四、动手 Demo：把这次闭环写成模板：第二次省了什么

这个 Demo 两段。 第一段把一次任务的成本拆开：读了几个文件、各多少行、各多少 token。 第二段把五步写成一个脚本，一条命令跑完，看它替掉了哪些「想起来」的动作。 脚本里的「改」那一步，跑的是一个真的 patch 脚本—— 它给 main.py 加一行注释。所以五步全是真的，没有假装。

STEPS = [u"确认能跑", u"确认能验", u"改", u"验", u"留痕"]

def main(req):
    for s in STEPS:
        if s == u"确认能跑":
            rc, out = run(ME + ["run"])
        elif s == u"确认能验":
            rc, out = run(ME + ["test"])
        elif s == u"改":
            rc, out = run([u"python", "patch.py"])
        elif s == u"验":
            rc, out = run([u"python", "check_empty.py"])

实跑输出：

--------------------------------------------------------------------
把这次闭环写成模板：第二次省了什么
--------------------------------------------------------------------


  ① 上一次任务的成本，拆开看
  --------------------------------------------------------------------
| 读进来的文件 | 行数 | token |
|---|---:|---:|
| emo.py | 16 | 139 |
| main.py | 17 | 74 |
| test_emo.py | 8 | 82 |
| tasks.py | 16 | 116 |

  一次任务读进四个文件，合计 411 token。再加上三轮改动、每轮重读一遍，实际消耗大约是它的三倍。
  ! 成本的大头不是「它想了多久」，是「它读了几遍」。
  要降成本，先降「每轮读进去多少」，不是先换小模型。

  ② 把五步写成一个脚本
  --------------------------------------------------------------------
  确认能跑 -> 退出码 0
  确认能验 -> 退出码 0
  改 -> 退出码 0
  验 -> 退出码 0
  留痕 -> 退出码 0
  五步合计 2462 毫秒
  这 2462 毫秒不是重点。重点是：下一次同类需求，你不用再想「该走哪几步」。

  ③ 什么值得抄成模板
  --------------------------------------------------------------------
| 东西 | 值不值得抄 | 为什么 |
|---|---|---|
| 五步的顺序 | 值得 | 每次一样，写成脚本最省 |
| 验收那两条断言 | 值得 | 同类需求反复用 |
| 提交信息的两段格式 | 值得 | 写进模板就不用想 |
| 具体改了哪几行 | 不值得 | 每次都不一样 |
| 这次的思考过程 | 不值得 | 抄下来也没人看 |

  ! 判断标准很朴素：下次还会一模一样发生的事，才值得抄。
  具体的代码改动永远不会一模一样，所以别把 diff 存成模板。

  ④ 同类任务用哪一档模型
  --------------------------------------------------------------------
| 任务 | 用哪档 | 依据 |
|---|---|---|
| 改一处判断、加一条断言 | 小模型 | 答案在代码里，跑一遍就知道 |
| 跨三个文件改一个语义 | 中档 | 要顺着调用链想 |
| 为什么这里会偶发失败 | 大模型 | 答案不在代码里，靠推理 |

  判断标准还是那一条：这次错了，是重跑一次，还是重写一遍。

五个步骤、五个退出码零。 这条命令替掉的是「想起来该走哪几步」这件事，不是那几秒钟。 「五步合计两千五百多毫秒」这个数别当真——它主要是五次起进程的固定开销，五步本身的活很少。 这正是上一篇那条结论的另一面。 成本那张表：四个文件、四百一十三 token。 注意 emo.py 十六行就一百三十九个 token，tasks.py 十六行一百一十六个—— 中文注释多的文件更贵。 这不是毛病，是提醒：给文件时先想「这个文件真需要它读吗」。 最后一节那张模型表，判断标准还是 4.2 节那条： 这次错了，是重跑一次，还是重写一遍。 改一处判断用小的，跨三个文件用中档，问「为什么偶发失败」用大的。

30 秒实验

  1. 把你这周做过的三件事，各写成四行步骤。 重复的部分挑出来——那就是你该做成模板的东西。
  2. 算一下你最近一次任务读了多少 token。 再想办法把它砍一半，比如只给两个文件而不是整个目录。
  3. 给同类任务定一条模型档位的规矩。 写下来，下次不用再纠结。

常见误区

  1. 「把上次的 diff 存下来当模板。」 下次照着改，会改出一堆不该有的东西。 抄骨架，别抄内容。
  2. 「成本主要是模型贵。」 成本主要是「读了几遍」。 读进去的量乘轮数，才是账单。
  3. 「模板写好了就一劳永逸。」 模板会过期。 每次用完花十秒看一眼「哪一步这次没用上」——那一步就该删了。
自测三问（点开对答案） 1. 什么值得抄成模板？举两个例子，各说为什么。 —— **值得：步骤顺序、验收断言**——下次一模一样发生。 **不值得：具体 diff、思考过程**——每次都不一样，抄了还要改。 2. 一次任务的成本有三个来源，哪个最大？ —— **「读进去多少」乘上「读了几遍」。** **单轮的 token 乘以轮数，才是账单。** **所以降成本先缩范围，不是先换小模型。** 3. 这一章走完，进入 Harness 之前应该已经有什么？ —— **一个一键入口、一条能返回退出码的验证、一次走完的闭环。** **三样没有，AGENTS.md 写了也没人用。**

第 5 章到这里收住。下一章进第二部分：Harness 四件套。 第一件是 AGENTS.md——给 Agent 的项目说明书。 先讲三段结构、再讲目录分层、最后给三个模板。

相关笔记