你没看到它写代码，是因为你一整天都在验
那道转圈的检查只量不改，代码在更早一步就定型了。
三个问题连在一起，是一个能自圆其说的模型——每一步都解释得通。也正因为自圆其说，它不会让你卡壳，于是你没有机会发现它是错的。
这一页不绕过它，正面拆。
一、这三句不是外行话
「自动检查运行的时候，是不是在做那一整套『按提示词写代码』的活？」
「合并的时候，是在合并那一瞬间才去写代码吗？」
「我好像没经历过写代码的这个过程——以前至少能看见它一行行长出来。」
这三句底下，是同一个前提：「一次提交 → 一段等待 → 一个结果」这个形状，我在别处见过。
在终端里让 AI 编程助手干活，这个形状是：发一段指令 → 等它想 → 代码一行行长出来。
在协作流程里，这个形状是：提一次合并请求 → 等那个圈转完 → 绿灯亮。
两边的体感一模一样。 于是很自然会推出这套对应：
- 合并请求 ≈ 你发的那段提示词
- 自动检查 ≈ 它正在照着提示词写代码
- 合并 ≈ 写好的东西落地生效
三条全错，但错得很讲道理。 任何第一次盯着那个转圈的圆看的人，都会先冒出这个念头。所以下面不从"你理解错了"讲起，从"那两段等待到底差在哪"讲起。
二、写字的、量字的、盖章的，是三件不同的东西
笔写字，尺量字，章让字生效。尺量不出没写的部分，章也盖不出没量过的确定性。
- 笔 ＝ 提示词 ＋ 大模型 ＋ 那个执行的人。它在定型之前动手，它会改内容。
- 尺 ＝ 自动检查。它在东西推上去之后才动，只量，不改。
- 章 ＝ 合并。它只让已经定型的东西生效，一个字都不改。
放回真实次序里，一次改动要走七步：
写 → 暂存（git add）→ 定型（git commit） → 推上远端（git push）→ 开合并请求（＝提交审阅） → 自动检查 ＋ 人审 → 合并
三件东西各管哪一段：笔管第 1 步，尺管第 6 步，章管第 7 步。
关键的一刀落在第 3 步：代码在"定型"那一刻就已经是最终形态。后面所有环节——包括那个转圈的自动检查，包括最后的合并——都不再动它一个字。
唯一的例外是合并时撞上冲突。那时候确实要改字，但改字的是人，不是机器。
三、不用懂原理也能当场判
判法一 · 看指纹。 每一次"定型"都会得到一串固定的指纹（commit hash）。凡是有确定指纹的环节，都不是生成环节。
生成是不确定的：同一段提示词跑两次，出来的东西可以不一样。而自动检查从开始到结束，指纹全程同一个；合并前后再比一次，还是同一个。同一个指纹，就是"这中间没有人写过字"的铁证。
判法二 · 看权限。 翻开自动检查的配置，最上面通常明写着它有哪些权限。我们自己那两条检查流程，头上都写着只读。
一个连写仓库的权限都没有的东西，不可能在替你写代码。 这一条比原理更快——不用懂它在跑什么，看它有没有手就行。
四、理解错不要紧，要紧的是它会让你真出事
动作一 · 不看改动内容就合。 心里想的是"自动检查会把它写对"。实际上它什么都不写——没人替你把它写对，它只会告诉你"你写的这些没触发我设的警报"。
动作二 · 把合并请求的描述当提示词写。 洋洋洒洒写一段"请帮我注意某某"。自动检查不读自然语言，那段话对机器来说等于空白。（有一处例外，而那处例外恰好能把话讲透，见下一节。）
动作三 · 红了就再推一次，指望它自己修好。 生成环节重试是有意义的，换一次可能就对了；测量环节重试没有意义——尺量出来短了，再量一次还是短。红灯之后没有人在修，除非你去修。
五、那一处例外，正好把判据讲透
上一节说自动检查不读自然语言，但有一处例外。
我们的自检流程里确实有一条会去读合并请求的描述。但它读的不是意思，是一个勾选框——描述里那一行"若改动了某类关键文件，请勾选"，它只看那个方框里有没有那个记号。
它读的是记号，不是意图。
你想让机器守住什么，就得先把它翻译成一个它能判的记号。翻译不出来的，机器就守不住——不是它不愿意，是它没法判。
这也解释了绿灯到底是什么意思：
绿灯不等于"对"。绿灯等于"我设的那几项检查没有报警"。没设的项，永远不会红。
我们自己被这句话教育过一次
我们有一道检查，专门扫某一类不该出现的词。它的做法是：先列出这次改动了哪些文件，再逐个打开扫内容。
问题出在"列文件名"这一步：当文件名里带中文时，列出来的名字被加上了引号和转义符。下一步拿着这串被转义的名字去找文件，一个也找不到。找不到文件，就没有内容可扫；没有内容可扫，就一条也报不出来。
于是它每一次都是绿的。
规则写了，检查跑了，日志里也确实有它的名字——但它那一次实际扫过的内容是空的。这不是"它放过了坏东西"，是它压根没看见东西。
闸还有另外一种坏法：规则和检查都在，但在那条路上它根本没被触发过。那一种在《为什么要多这几道手续》里完整讲过一遍，这里不重复。
两种坏法合起来是同一句话：一道检查有没有用，要沿着它真正要拦的那条路走一遍才知道；别处的绿，只能证明别处。
六、不是理解错，是位置换了
回到第三句原话：「我好像没经历过写代码的这个过程。」
这不是理解错，是位置换了以后的必然体感。 先把位置说清楚：你现在站在第 5 步到第 7 步之间——开合并请求、看检查结果、决定合不合。而"写"发生在第 1 步。
体感缺失有三个成因，三个是并列的，缺一个都解释不完整：
成因一 · 那天确实几乎没写代码。 一整天的产出里，真正新增的功能代码少到一只手数得过来；其余全是文档、任务单、留痕、配置。没看见写，首先是因为写得少。
成因二 · 唯一那次真写，不在你的视野里。 那段东西由执行侧的人在他自己的机器上写成，你看到它的时候，它已经是一份改动清单——成品，不是过程。而这恰恰是授权面下放之后的正常结果，不是流程出了毛病：你把"怎么写"交出去了，换回来的就是"只看结果"。
成因三 · 写的样子变了，你没认出那是写。 那一整天在对话框里改文件改了十几次，每一次的形态是：一段脚本 → 一句"写入成功" → 一条自证命令。那就是写。 它只是从"逐行滚动"变成了"写完当场自证"。
两种形态对照：
两种形态对照：
| 终端里让 AI 编程助手写 | 现在这条流程 | |
|---|---|---|
| 你看到什么 | 代码一行行长出来 | 一句"写入成功" ＋ 一串判据输出 |
| 怎么判断对不对 | 肉眼看着它写，边写边判 | 看判据的数值对不对 |
| 写和验的关系 | 混在同一个窗口、同一个人、同一时刻 | 被刻意分开——不同的人，不同的时刻 |
那一天真正落地的字数是几百行量级——字都在，写的人也一个都不少。缺的不是写，是你亲眼看着它写的那个过程。
你没看到写，是因为你一整天都在验。
怀念"看着它长出来"的那种直观，本质上是"既写又验"时才有的。一旦分工，你必然只看得见一半——而看得见的那一半（验），恰好是只有你能做的那一半。
过程也没有消失，它只是换了形态：从转瞬即逝的滚动，变成可以回头翻的记录——每一次定型都留着，每一份改动清单都在，每一次写入前的那段脚本也在。滚动看完就没了，记录半年后还能调出来。