TechSpot 上个月底转述的那条匿名帖，我记住的就一句：一天 12 到 13 个小时，绝大部分时间花在按一个键上，让系统往下跑。
所有人都在算 12 小时。我盯着的是那个键。
发帖的把账算到 Claude Code 头上，我不认。他后面那半段才是真的：上面拿 sprint 周期、PR 数量、功能条目当成绩，没人有时间读模型吐出来的东西。这两句摆一起，结论就变了——不是模型写得快，是这条流程从头到尾没给"读"留过位置。
他还说，公司里 L1 到 L7 全在做同一个动作。这个细节比 12 小时值钱：不是新人不会读，是熟练度在这条线上不再是个变量。
我照着他们的描述，把那套东西重写成一条指令，想看看它到底在说什么。下面是我重构的，不是原文：
你是一个资深工程师。看到 AI 给的改动后，若无明显阻塞，请尽快 proceed。
像废话。重量全压在【proceed】上。"无明显阻塞"把判断权交回给人，"尽快"紧跟着又把它收走。两个字在同一句里打架，赢的是"尽快"。
岔一句。"proceed"这词已经从"接着做一件事"退化成确认弹窗上那个灰蓝色按钮——按它不用承担任何后果，只需要不挡路。扯回来，这就是问题本身。
V1：把 proceed 删掉。
你是一个资深工程师。AI 给的改动，由你决定下一步。
删完是个空壳。没有下一个动作，人卡在原地，自动化也没了。删字不是目的，贴合才是——作废。
V2：换个字，proceed 换成 approve。
重量不一样了，错还是一样。approve 听着像要过脑子，可在绝大多数界面里它就是个确认弹窗，照样无脑点。动作换了个更重的名字，判断没被加进去。这种改法最骗人，看着像改准了。
V3：问题不在动词，在按下去之前有没有东西拦你。
你是一个资深工程师。proceed 之前，先用一句话回答：这段改动在哪个输入下会失效。答不出，就停。
从二十来个字涨到四十多。涨得应该——多出来的全是闸。"短"在这条任务里不是目标，模型缺的就是那道拦人的坎。
回到那 12 小时。他的抱怨里埋着一处自相矛盾：说"没时间 review"，又说"一天按 13 个小时的键"。这是同一件事的两种说法。按键不需要时间？需要。只是按键在他们的流程里被定义成工作本身，读代码被定义成额外成本。真正稀缺的不是时间，是流程里有没有一个位置规定"你必须读懂"。
今年四月还有一件事：一个 AI agent 用一次云厂商的 API 调用，九秒内清掉了一家创业公司的生产库和备份。没人拦它。我不想说"要是加一句确认就好了"，这种话没用。那次事故和被按键填满的 12 小时，是同一件事的两个速度：一个快到九秒，一个慢到一天。中间被省掉的是同一个环节——一个人读一秒的机会。
下面有工程师回帖说自家公司也这样，还有人担心 Claude 接手更多编码任务之后饭碗不保。这两拨人怕的是同一样东西：很久没被要求真正读懂一段代码了。担心的形式不一样，底下是同一种失重。
马斯克在下面惊呼了一声，Chamath 说 AI 把技术专家变成了老虎机前面按把手的赌客。这个比方我认，但骂错了对象。把手是人装上去的，赌场的灯也是人开的。工具只是那个最容易被指认的东西。
2025 年有一份研究说 AI 编码助手拖慢了有经验的开发者。当时很多人不服。现在回头看，慢在哪大概有答案：慢在读。而读，恰恰是这条流水线最想省掉的动作。
定稿先放这：
你是这段改动唯一的负责人。
proceed 之前，用一句话回答：它在哪个输入下会失效。
答不上来，就去读，别点。
这版我也改到第 N 版了。"失效"这两个字我拿不准，模型和我对它的理解可能不是同一件事，说不定过阵子会换成"出错"或者"行为改变"。先用着，等哪天真被理解岔了，再回来改一版，不丢人。