AI 来了之后，我的心流状态去哪了一个很多人可能都存在的困惑自从用上 AI 写代码，我丢了一个东西：心流。以前写代码

一个很多人可能都存在的困惑

自从用上 AI 写代码，我丢了一个东西：心流。

以前写代码，手一直在键盘上，脑子和代码之间没有等待，改一行看一眼，即时反馈，很爽。现在呢？我把需求丢给 Agent，它咣咣跑几十分钟甚至几小时，我坐在旁边不知道干嘛，忍不住掏出手机刷两下。等它跑完，我回来对着一大坨产出发呆——上下文早就断了，还得重新捡起来。

时间被切得稀碎，人反而更累了。我一度以为这是 AI 时代的必然代价，忍忍就过去了。

后来想明白了：这不是 AI 的锅，是我自己把流程设计错了。

我把开发里的判断拆成两层：

第一层，AI 能干，而且干得不错——所以我搭了一堆 Agent 互审（测试审查、代码审查、功能验收）去接管它。

第二层，AI 干不了。它交付不出来不是因为笨，是因为业务上下文不够，或者上下文太多产生幻觉。这层判断，恰恰是我在这个流程里最稀缺、最不可替代的产能。

我原来的流程是这样的：人在最开头确认一下需求文档PRD，AI是否理解的正确，然后 AI 全自动跑完——生成方案、写测试、写代码、互相审查——中间人一律不插手，最后人再来验收一大坨成品。

初衷是"让人尽量别管"，觉得这样效率最高。

但这里藏着一个我自己都没意识到的矛盾：我一边承认人的判断力最稀缺，一边拼命想把人从流程里删掉。 这两件事不可能同时成立。

结果就是那个熟悉的痛苦：AI 干活的时候人没事干，只能刷手机；等它干完，第二层的业务判断全攒到了最后，变成一场巨大的批量 review。

更要命的是，第二层的偏差有个特性——越早发现越便宜，越晚发现越贵。 方案阶段业务意图偏了 10%，写代码的时候会被放大成一整片。我在最后才看见，要么大返工，要么捏着鼻子接受。

我在末尾兜的，全是被放大了 N 倍的偏差。心流断在那里，一点都不奇怪。

真正的解法，藏在我流程本来就有的一个结构里：方案文档是有先后顺序的——需求文档 → 设计文档 → 任务拆解，一层依赖一层。

这个顺序天然能造出一条流水线：

AI 在生成设计文档时，我在读 需求文档 ；AI 在拆任务时，我在读设计文档。

看出来妙在哪了吗？我和 AI 处在同一个上下文里，各自往前推，谁都不空转。

我要的那种"注意力不被打断"的感觉，不是靠找点事把等待填满，而是——等待本身消失了。因为 AI 正在生成的下一段，恰好是我要读的这一段的下游。

而且这个点上人的判断最值钱：文档短、可读、改一行成本极低，我又刚看完 PRD 脑子里面信息最全。在这儿纠偏 10% 的业务意图偏差，比等它变成一片代码再返工，便宜几十倍。

这跟"围绕已生成的上下文继续思考、校准边界"是一回事——只不过我把它固化进了流程，而不是靠自觉。

这里有个坑，得提醒一句，别让好方案变成新的自欺。

这条流水线成立的前提是：每个阶段之间要有一个"人点头才往下"的闸，而不是 AI 一路自动跑到底、我在后面追着读。

如果 AI 生成设计文档时我还在读需求文档，但我没读完它就自己开始拆任务了——那我又变回了"追赶式 review"，只是把末尾那一大坨切成了追着跑的一路小坨。

正确的做法是用人的确认当阀门：我读完需求文档点头，AI 才生成设计文档；我读设计文档的时候它不许往下，它在等我。这样节奏由我定，我永远有完整的当前上下文，不空转也不追赶。

代价是什么？是要承认"让人尽量别管"这个初衷本身就错了。在文档阶段，人恰恰要管，而且这是整个流程里最划算的一次管。用几次点头，换掉末尾那场批量 review。

问题从来不是"AI 干活时我该做什么"，而是"我为什么把人和 AI 设计成了互斥的接力，而不是同一上下文里的并行协作"。

新时代的心流，对象不再是敲代码，而是持续 hold 住问题和判断。而这份判断力，正是在这些"点头"的间隙里，被一次次磨出来的。