复杂项目里，AI 最强的地方不是最难的地方编程正在从"终点能力"变成"前提能力"——你依然需要懂代码，因为不懂就无法审查

AI 能把复杂项目快速推进到"像样的初稿"，却很难独立做到生产可用。它压缩的是 0→0.6 的时间，跨不过的是 0.6→1.0 的鸿沟。问题从来不是 AI 能不能写代码，而是谁在定义问题、约束边界、审查结果、承担决策。

这里说的复杂项目，指多角色、多状态、跨模块联动、验收标准不完全显式的项目——不是代码多就算复杂。

一、0.6 的瓶颈来自哪里

在熟悉技术栈、需求边界初步明确的前提下，AI 半天就能跑通 happy path：页面有了，接口通了，流程能走了。但后面的调整修复，往往还要再花 2~3 天。问题不在于"剩下的代码还没补完"，而在于项目从这里开始，撞上的已经不是单纯的编码工作量，而是三类很难被提前消化掉的结构性复杂度。

第一堵墙，是边界情况。 表单重复提交时 UI 怎么响应，接口超时后加载状态有没有回退，空数据列表是渲染兜底还是直接空白，乐观更新失败要不要回滚。这些问题在 happy path 里通常都不会出现，真正麻烦的是它们会在真实环境里组合出现，而这种异常组合不是靠事先列一张清单就能穷举完的。

第二堵墙，是隐式约束。 很多关键规则不在代码里，也不完整地写在文档里，而是存在于经验中。某个字段为什么不能随意改，某个流程为什么必须先保存再提交，某个组件为什么必须受控。它们不是"再补一点说明"就能完整传递的知识，而是需要在真实系统里反复踩过、观察过，才会形成稳定判断。

第三堵墙，是联动与时序。 字段显隐联动、异步校验竞态、草稿恢复、权限差异渲染、路由回退后的状态恢复，单看都不复杂，但一旦叠在一起，就开始出现状态错位和难以复现的 bug。这类复杂度的问题，不是谁再多补一轮代码就能兜住，而是它本身就很容易超出单次上下文能稳定处理的范围。

判断一份 AI 产出到底是初稿还是可上线的实现，可以用三条验收标准：

异常流和边界情况有没有被覆盖

跨组件、跨页面的状态一致性有没有被验证

真实环境下（多角色、多分辨率、真实数据量）的行为有没有被观察过

三条里有两条以上是空的，大概率就只是一个"看起来完成"的初稿。

十万行的 CRUD 系统，很多时候只是页面重复、流程重复，难点在体力而不是判断。反过来，一个几千行的状态机或权限引擎，可能每一处改动都牵一发动全身。复杂项目难，不是因为代码量大，而是因为系统行为不再是线性的。

这种非线性通常集中在三个维度，而 AI 恰好在这三个维度上最弱。

单独看每个组件都不难。但一旦开始组合，可能性迅速膨胀——真正的问题不是"某段代码怎么写"，而是"这些状态碰到一起时会发生什么"。经验工程师对这种风险有直觉，知道哪些地方最容易出事；AI 只是在已有上下文里补出一个局部合理的答案。

很多困难不是实现困难，而是选型困难。你选大表单还是分步向导，会影响校验策略、状态管理和错误处理方式；你选组件内状态还是全局 store，会影响性能、可测试性和重构成本。每个技术决定都会向后传导。AI 能列出方案，但不能替你承担权衡后果。

真实项目的需求通常不是一开始就完全明确的。目标在变、边界在变、"什么叫做好"也在变。AI 依赖输入上下文工作，不给它澄清后的目标，它就只能在含糊的目标上做局部最优。

同样一个 AI，有的人用出 3~5 倍加速，有的人用出故障放大器。差别不在模型，而在使用者的判断力——AI 放大的是你已有的能力。

使用 AI 的能力可以分成四层梯度：

能看懂单文件代码。 至少能判断一段实现是不是在胡写，变量有没有跑偏，控制流是不是合理。做不到这层，AI 就是黑箱。
能审查跨模块逻辑。 风险很少只藏在一个函数里，更多出现在接口契约、状态传递、数据一致性这些模块之间的缝隙里。能不能看出"每段都对，但拼起来不对"，决定了 AI 产出对你是帮助还是负担。
能发现缺失的边界和约束。 AI 不会主动提醒你所有隐含前提，它更常见的做法是"在没被禁止的前提下给出一个合理实现"。你必须能指出哪些输入是危险的、哪些路径没覆盖、哪些默认值不能信。
能定义问题、拆解问题、验证结果。 这是最关键的一层——把问题拆到 AI 最擅长处理的粒度，再把结果放回系统里判断。

高水平使用者被放大，是因为他能给出清晰的约束、知道重点 review 哪里、出错时能迅速判断问题在设计层、实现层还是环境层。典型的失控模式则恰好相反：整段接收、局部修补、最后没人说得清系统为何成立。

AI 不是在替代判断，而是在放大判断。可以用四个问题自测你是否具备主导能力：

如果大部分答案是否定的，问题通常不是"模型还不够强"，而是你还没建立起足够的主导能力。

AI 适合承担执行性工作，不适合替代责任性判断。

阶段	AI 适合做什么	人必须负责什么	团队闸门	常见误用
设计	列方案、补盲区、挑战假设	明确目标、约束、取舍、验收标准	设计评审	把核心架构决策直接外包给 AI
实现	写初版、补样板、生成局部模块	控制边界、审查关键逻辑、保证跨模块一致性	关键路径 CR	一句"帮我写完整系统"后直接接收结果
测试	生成测试样例、补边界用例、造测试数据	决定测什么、什么算通过、系统级验证怎么做	回归测试 + 多角色验证	以为测试数量多就代表质量高
Debug	分析线索、提出排查路径、解释报错	先定位现象、缩小范围、确认根因	—	没定位就把一大段报错直接扔给 AI
发布	生成变更说明、检查清单	确认影响范围、制定回滚预案	灰度验证 + 回滚预案	跳过验证直接全量发布
文档	整理表达、生成草稿、统一格式	判断哪些内容重要、哪些理由真实成立	—	让 AI 事后"编"设计理由和决策过程

压缩成几句话：

编程正在从"终点能力"变成"前提能力"——你依然需要懂代码，因为不懂就无法审查 AI 的产出；但光会写代码已经不够了。真正拉开差距的是四件事：定义问题、评估方案、识别失控点、在高速度中保持判断力。

AI 越强，理解越不能让渡。 你不再理解系统为什么这样工作的那一刻，就是项目开始失控的那一刻。