「这次做对了」和「下次还能做对」是两件事，中间差一份写下来的流程。 流程的价值不在「这次对了」，在「别人也能对」——写在脑子里的叫习惯，会随人走。 四步够用：改前跑测试、改、改后再跑、提交写两段。
这一篇是第 3 章收口，也是全书的第一个转折点。 前面五节讲「怎么跑通一次」，这一节讲「怎么让它能重复」。 为什么这一节重要？因为「跑通一次」的成本很低，「稳定跑通」的成本很高—— 差别就在「流程有没有写下来」。 Demo 里演了一个对照： 不照流程的那次，改完直接提交，测试最后才跑，提交信息是「update clamp」； 照流程的那次，第三步拦住了同一个错误。 两次改的代码一模一样，差别全在顺序上。
一、把这次成功写成步骤
跑通一次之后，立刻做一件事：把刚才那几步写下来。
不是写「心得」，是写「步骤」——每一步都要有「做什么」和「怎么知道这步成了」。
判断一条是不是「步骤」的标准：
别人照着它能做出来吗？
「注意代码质量」不是步骤（没法照做）；
「改完跑 python test.py，看到 失败 0 才能提交」是步骤。
写下来之后有个额外的好处：你会发现自己跳过了哪一步。
很多人写流程的时候才发现「我好像从来没跑过全量测试」——这一步一直在被跳过，只是没人提。
还有一个更实际的好处：它能变成脚本。
四步里有三步是命令，那就能串成一行。
串成脚本之后，「照流程走」的成本从「记住四步」变成「跑一条命令」。
二、工作流要能被别人接手
流程写在脑子里，叫习惯；写在文件里，才叫流程。 两者的区别在「人在不在」。 你休假两周，习惯就跟着你休假；文件还在仓库里。
| 载体 | 新人接手要多久 | 你休假时会怎样 |
|---|---|---|
| 脑子里 | 得跟着看几次 | 流程停摆 |
| 聊天记录里 | 得翻记录、还得猜上下文 | 新人找不到 |
| 仓库里的文件 | 打开就能看 | 照文件走 |
「仓库里的文件」有一个额外好处：它有历史。 「为什么加这一步」能查到、能讨论、能被推翻。 写在聊天记录里的流程没有历史——它只活在那一次对话里。 所以第 1.4 节那句话在这里又出现了一次： 规则写进仓库，别记在脑子里。 这一节是它在流程图上的版本。
三、本章小结
第 3 章六节，讲的是「第一次怎么跑通」： 3.1 装好、登进去、跑一条只读命令；3.2 判本地还是云端；3.3 读改验三段循环； 3.4 选模型（先想给什么）；3.5 三类红线；3.6 把这次的步骤写下来。 这六节其实是一条时间线： 装 → 判 → 跑 → 调 → 守 → 固化。 走完一遍，你就有了一个「能重复的最小闭环」。 接下来第 5～8 章讲的是「怎么把这个闭环做得更稳」： AGENTS.md 把规矩写下来、Rules 和 Hooks 把约束变成程序、Skill 和 Subagent 和 MCP 把能力装进系统。 第 5 章会拿一个真项目走一遍完整链路——那一章是这一章的放大版。 最后留一句： 这一章所有内容都可以忘掉，只要记住一件事——做对了之后，立刻写下来。 因为下一次你未必记得，而下一个人肯定不知道。
四、动手 Demo：把一次成功写成流程，下次照着走
这个 Demo 演一个对照实验。 第一段：不照流程——改完直接提交，测试最后才跑。 第二段：把四步写下来，然后照着走一遍，中间故意再犯一次同样的错。 两次改的代码是一样的，差别全在顺序上。 第一段的结果是「坏提交已经进去了」；第二段的结果是「第三步拦住了，提交没发生」。
# 不照流程：改 -> 提交 -> 才跑测试
put(base, "util.py", 改错的版本)
git add -A && git commit -m "update clamp"
python test_util.py # 通过 2 / 失败 1 —— 晚了
# 照流程：测 -> 改 -> 再测 -> 提交
python test_util.py # 第一步：确认起点是绿的
put(base, "util.py", 改错的版本)
python test_util.py # 第三步：通过 2 / 失败 1，拦住了
put(base, "util.py", 改对的版本)
python test_util.py # 通过 3 / 失败 0
git commit -m "refactor: ..." -m "为什么改"
实跑输出：
--------------------------------------------------------------------
把一次成功写成流程，下次照着走
--------------------------------------------------------------------
① 先看「不照流程」会怎样
--------------------------------------------------------------------
改完直接提交（没跑测试）：
提交完成，工作区干净：是
事后跑测试：通过 2 / 失败 1
这就是「不照流程」的典型后果：提交已经进去了，测试是最后才跑的。
! 更糟的是：这条提交的信息是「update clamp」——三个月后没人知道它想改什么。
② 把流程写成四步
--------------------------------------------------------------------
| 步骤 | 目的 | 命令 |
|---|---|---|
| 一、先跑一遍测试 | 确认起点是绿的 | python test_util.py |
| 二、改 | 只改该改的 | — |
| 三、再跑一遍测试 | 确认还是绿的 | python test_util.py |
| 四、提交 | 信息写两段 | git commit -m ... |
③ 照着流程重做一遍
--------------------------------------------------------------------
第一步，起点检查：通过 3 / 失败 0
第二步，又写错了一次（hi 减了 1）
第三步，改完再跑：通过 2 / 失败 1
第三步拦住了。 改动还没提交，测试先说了不行——这就是流程的全部意义：错在提交之前被发现。
改回来再跑：通过 3 / 失败 0
第四步，提交完成。
[ok ] f1549ba refactor: clamp 用 max/min 表达
392146e Revert "update clamp"
da395e5 update clamp
④ 流程化之后，省下的是什么
--------------------------------------------------------------------
| 项目 | 不照流程 | 照流程 |
|---|---|---|
| 测试何时跑 | 提交之后 | 两次，改前改后 |
| 坏提交是否能避免 | 不能，已经进去了 | 能，第三步拦住 |
| 提交信息 | update clamp | 两段：改了什么 / 为什么 |
| 别人接手要看多久 | 得翻代码猜 | 读提交信息就懂 |
四行里最值钱的是最后一行。流程的价值不在于「这次做对了」，在于「下次别人也能做对」。
! 写成文件才算流程。写在脑子里的是习惯——习惯会随人走，文件不会。
第一段的输出里有两行值得看：
「提交完成，工作区干净：是」——坏提交已经进去了，而且工作区看起来很正常。
「事后跑测试：通过 2 / 失败 1」——但这时候已经晚了。
第二段第三步的 通过 2 / 失败 1 是关键：
它是在提交之前出现的。
同样一个错误，出现在提交前和提交后，代价完全不同——
前者改一行，后者要 revert 加重新提交，还要在历史里留一条坏记录。
提交信息的差别也值得看：
第一段是「update clamp」，第二段是两段——改了什么、为什么。
三个月后回来看，前者什么都说明不了，后者能直接读懂意图。
最后一句话是这一篇的落点：
写成文件才算流程，写在脑子里的是习惯。
习惯会随人走，文件不会。
30 秒实验
- 把你最近一次「改对了」的过程写成四步。 写完数一数：有没有哪一步你其实从来没做过？
- 把四步里有命令的部分串成一条脚本。 从「记住四步」变成「跑一条命令」，成本降一个数量级。
- 让一个同事照你的流程做一遍，你不说话。 他卡住的地方，就是流程里没写清的地方。
常见误区
- 「流程太死板，会拖慢速度。」 Demo 里两次改的代码一样，照流程那次只多了两条命令。 拖慢的是「多跑两次测试」，快回来的是「不用 revert」。
- 「我记得住，不用写。」 你记得住，别人记不住；你休假时，你自己也记不住。 写成文件的成本是十分钟，收益是「下次不用重新想」。
- 「流程写好了放在那儿就行。」 不执行的流程等于没有。 能变成脚本的变成脚本，不能变的放进钩子（第 7 章）—— 让「照流程走」变成默认行为，而不是需要记得的事。
自测三问（点开对答案）
1. 为什么「写在脑子里的叫习惯，写在文件里的才叫流程」？ —— **因为习惯随人走，文件不会。** **你休假两周，习惯跟着休假；新人入职，得跟着你看几次。** **文件在仓库里，打开就能看，还有历史（能查为什么加这一步）。** 2. 同样一个错误，「提交前发现」和「提交后发现」差多少？ —— **提交前改一行就行；提交后要 revert、重新提交、还在历史里留一条坏记录。** **Demo 里两次改的代码一模一样，差别全在顺序上。** 3. 一条规矩怎么判断它是不是「步骤」？ —— **看「别人照着它能不能做出来」。** **「注意代码质量」不是步骤，「改完跑 python test.py，看到失败 0 才提交」是步骤。**第 3 章到这里收住。 下一次课进第 4 章，先把「任务地图」铺开—— 四个入口、五个版本、本地云端的边界，一张图看完。
- ☐ （本篇完，下一篇 4.1 IDE、CLI、App、Web 各自做什么）