AI没搞垮开发，是我们制定的流程出了问题

哪怕改动一行代码，也要完整走完既定流程的每一个环节。

团队刚开始适应 AI 编程时难免磕磕绊绊，但坦白讲，我们自己制定的那套流程，反而在三个关键点上把情况搞砸了。

首先，流程鼓励我们用 AI 来挑自己的刺。 团队此前有个惯常动作：写方案前，先让 Claude 对设计方案进行全方位「灵魂拷问」。听起来非常严谨。可在实际执行中，这种拷问会把所有潜在的边缘极端情况（Edge Cases）全部炸出来，却毫无上下文优先级——AI 根本不知道哪个场景更重要，也不知道方案该做多重。很多时候，处理极端情况最好的方式就是直接报错。但 AI 的拷问绝不会止步于此，它把每个疑问都当成必须解决的问题，最终催生出一堆过度设计的冗余代码。

第二，流程搞一刀切。 改一行代码的提交流程，和一个起全新微服务的流程一模一样。繁琐的步骤成了小修小补的沉重负担。久而久之，大家不再把流程当成辅助思考的工具，只当成应付差事的通关卡点。

第三，也是最致命的一点：它把人类的判断力从脑子里抽离，转嫁给了流程。 当流程规定由 Claude 拟定绝大部分方案、再由工程师来审批时，工程师的角色不知不觉间退化成了「质检员」。单看每一步都很合理，合在一起，却把真正需要人类拍板做决定的关键时刻消解掉了。

同时，整个迭代速度慢得惊人。我们当初设计这套详尽流程，是想给以后的质量管控留出钩子。但根本不需要搭这么重的脚手架。像提交前的自动化检查，第一天就能顺手加上。搭这套流程消耗的时间，本可以跑完十几个小型实验，几天就能拿到反馈，而不是折腾好几个月。

我之前复盘时曾觉得问题出在上游的方案设计阶段。现在看来大方向没错，但我错在以为「更复杂的流程」能解决这个问题。

顺应阻力最小的路径

保持专注，如今成了一种主动选择。

研发效能看板上的数据说明了吞吐量问题，但吞吐量背后掩盖的判断力退化，才是更让我心惊的隐患。

人都有不在状态的时候。在那些昏昏欲睡的日子里，直接接受 Claude 的建议就是阻力最小的路径。方案看起来挑不出毛病，步骤拆解详实严密，直接点「同意」比重新推演一遍轻松得多。

各类 Coding Agent（编程智能体）正在把这种状态变成日常。没人主动选择躺平，但 AI 带来的便利让「放弃思考」变得毫无知觉。它让我们显得比实际水平更钝，也让我们给予了它超出上限的信任。

问题在于，模型追求的目标和我们截然不同。技术专家 Dex Horthy 在演讲中提过一个观点：编码智能体的优化目标，是生成当下能跑通的代码。六个月后这套方案带来的技术债与复杂度，不需要它来承担。 当我们全神贯注时，能揪出那些毫无必要的防御性代码；当我们松懈时，模型的默认设置就悄悄变成了整个系统的核心架构。

这绝对不可取。过去，工作本身要求我们必须保持专注；现在，保持专注成了我们需要主动克制惰性才能做出的选择。

一个容易踩坑的直觉误区

顺着这个逻辑，很容易得出一种结论：如果 AI 写代码的速度远超人类阅读速度，那工程师的本职工作就该彻底转向「代码审查」（Review）。工程师不再是写作者，而是审查者。

我认为这绝不是正确方向，尽管顺其自然就会滑向这个结局。

审查别人的 Pull Request，永远比自己从零推导写出方案更难、更心虚。写代码之所以让人有底气，是因为你亲身踩过所有的决策分支；而 Review 意味着你得去反向还原别人当时的权衡逻辑。一旦审查占据了大部分精力，等于把工程师推向了最没有成就感、也最容易自我怀疑的工作场景中。

这直接解释了资深工程师最近的困惑：他们开始对以前看一眼就能决断的事情反复确认「这样真的行吗？」。因为他们被要求去审批的，不是深思熟虑的决策，而是一堆凭空「生成」出来的逻辑。

砍掉流程后的新打法

理解整体架构如何联动，而不是死抠每一行语法。

我们保留了核心原则：人类对最终结果负全责，代码如何构建依然至关重要。随后，我们果断砍掉了原本死板的流程，做了两个针对性的动作，并重新明确了对工程师的理解要求：

第一，重塑需求澄清（Refinement）。 澄清会结束时，必须由工程师写出一份人类能读懂的开发任务卡。严禁贴一段 AI 生成的描述，也严禁直接扔一段 Prompt 提示词。我们绝不接受「带着任务离开会议室，指望 Claude 帮我们搞明白怎么做」。如果现场没人能讲清楚这块功能具体该怎么落地，这个澄清会就没开完。这不代表必须在一开始把所有底层细节想透，有时决策本身就是「先做个技术验证」。但必须有人搞清楚验证的目标和逻辑。拆分出的每一块子任务，都要有对应的负责人把这份理解贯彻到底。

第二，设置阶梯式审查触发机制。 大多数常规改动沿用原有轻量标准。一旦改动复杂度跨过设定阈值，就必须触发深度审查——比如两个人在开发机上联调测试，或者向技术小组公开推演方案。我们目前仍在动态调整这些触发阈值。

我们也明确划定了边界：不再要求工程师逐行去查代码。 比起搞清楚 AI 到底调用了哪个具体函数，理解整个方案如何咬合、为什么能跑通，要重要得多。

最终的反思

这两点改动够不够用，目前还不能盖棺定论。交付吞吐量有数据可查，但团队的决策质量有没有真正变好，光看指标面板说明不了问题。

我唯一确定的是重心的转移。在过去，「读懂每一行代码」和「理解系统整体方案」是一回事，因为代码是人敲出来的，敲出来就必须懂。现在这两件事已经彻底剥离。理解全局方案，才是工程师安身立命的核心。

理解不会凭空产生。它需要耗费巨大的注意力，而现代 AI 工具最擅长的，就是悄无声息地剥夺你的注意力。