AI 编程进入深水区：工程师需要补的工程课
AI Coding 的终局不是 "AI 取代人写代码"，而是 "人做架构师，AI 做执行者"。但要走到这一步，需要补的工程课比想象中多。
前言
过去半年，AI Coding 工具的普及速度超出了很多人的预期。编码环节的效率提升是肉眼可见的——一个工程师上午 10 点上线一个新功能、中午做 A/B 测试、下午根据数据下线、5 点上线更好的版本。这是过去需要六周才能完成的迭代，现在一天就走完了。
但与此同时，大量团队卡在了一个共同的瓶颈上：编码快了，交付却没快多少。
这篇文章不讲工具怎么用——那些已经有很多人在写了。我想讲的是：工具用好之后，工程体系需要补什么课。
一、省下来的时间去哪了
编码效率提升 10 倍是不少团队的实际数据。但端到端交付效率往往只有 2 到 3 倍。省下来的时间去哪了？
被审查、对齐、返工吃掉了。
这里有一个容易被忽略的剪刀差：AI 产出速度越快，审查者越跟不上。很多人以为等模型再聪明一点就好了，但方向反了——这不是模型问题，是流程问题。模型越聪明，这个剪刀差越会加剧。更反讽的是，有些团队的测试阶段反而因为 "AI 写得太快、人需要花更多时间理解和确认产物" 而耗时增加了。
比剪刀差更深层的问题是：过去二十年的研发基础设施是给人用的。
一份不完整的需求、一段没注释的代码、一个不一致的 API 接口——这些缺陷之所以系统能正常运转，是因为人在用自己的灵活性、推理能力和经验悄悄把缺口补上。开个会问一下、走过去问老王、凭经验猜一下、跑去预发环境试一下。这些动作发生得太自然，自然到我们不再把它看作 "工作"。
但它们是工作。它们是人扛在肩上的隐性成本。
当 AI 进入流程之后，这些成本就会暴露，而且回不去。你没法假装不知道系统的问题。就像你没法看完 X 光片假装骨头没问题一样。
所以最大的风险不在代码质量——代码错误反而容易发现和修复。真正致命的是约束没说清。需求模糊、上下文丢失、验收标准缺失，AI 会在这些空白处用训练数据的 "通用模式" 来填充，写出来的代码能跑，但跑的方向完全不对。
二、约束前置：把默契变成规则
在传统开发里，很多东西靠人和人之间的默契补齐。一句话、一个点头就够了。但在 AI Coding 里，凡是你没有明说的部分，Agent 大概率会自行合理化。
AI 最危险的不是 "不知道"，是 "以为自己知道"。它给出的答案看起来合理，但实际上是用训练数据里的普遍模式填充出来的，不一定符合你的业务场景、工程规范和线上要求。
所以第一课就是：在 AI 动手之前，先把约束说清楚。
具体来说，需求阶段需要多问几个问题。这个功能要解决的根因是什么——去掉它能达成同样目标吗？如果并发量翻十倍、数据量翻一百倍，系统行为会怎样？这里的 "正常处理" 具体指什么，在不同角色看来含义相同吗？攻击者会怎么利用这个功能，运维怎么排查异常？
这些问题看起来像是在找茬，但其实是在强制暴露盲区。这个过程不能交给 AI 自己做——追问必须是交互式的，人必须参与。这是整个约束体系里唯一不能自动化的环节。
到了技术方案阶段，约束需要变成结构化的清单。每条约束应该包含几个要素：具体的描述、约束等级（哪些是硬卡点不能碰、哪些是软卡点尽量遵守、哪些是建议）、怎么验证、在哪个阶段验证、预期结果是什么。
但很多人走到这一步就停下了，觉得写了个清单就完事了。这里有个常见的误区：把 "约束" 等同于 "文档"。约束的核心标准只有一个——能否被机械化地验证。如果不能，就是无效约束。文档写得再漂亮，审查时没人逐条核对，等于没写。
还有一个更细的层次：任务拆解时的约束绑定。不是把整个约束清单丢给 AI，而是为每个编码任务精确匹配相关的约束子集。AI 在写 T3 任务时只需要关注 T3 相关的约束，而不是面对一堆不相关的规则。
三、流程编排：让 AI 按流程走
AI 编码最危险的不是 "写错"，是 "写偏了"——边写边自由发挥，最后和初衷对不上。
所以需要把流程拆成几个职责分离的阶段，每个阶段强制 AI 切换角色。
第一步是只读不写。让 AI 先读代码库，做架构考古、Git 热点分析、依赖追踪，但不允许写代码。这步的核心是 "先看再想"，而不是 "看了就写"。
第二步是想不做。不写代码，先想清楚有哪些方案可选，对比优缺点。这步很多人会跳过，觉得 "我想好了直接写就行"，但跳过探索的代价往往是写到一半发现方向错了。
第三步是把方案变成可执行的规范文档，包含设计、任务拆解、验收标准。想法到规范的转换，是把模糊的 "我觉得应该这样" 变成精确的 "你需要做这三件事，验收标准是这四个条件"。
第四步才是按规范实施。TDD，反模式检测，严格按规范逐任务落地。
第五步是规范对齐验证——不是泛泛看代码，是逐条核对约束清单是否被遵守。
第六步是安全审查——攻击面、数据流、依赖漏洞扫描。
这套流程的核心价值是职责分离：侦察只读不写，探索只想不做，提案只定方向不写代码。每个阶段切换角色，避免在一个 session 里角色混乱。
但流程不等于仪式。对于熟悉的项目，侦察可以跳过；对于简单需求，探索可以合并到提案。流程的价值在于可裁剪，不在于完整性。我见过不少团队把六步当成必须全跑的 checklist，结果效率反而更差了。
还有一个容易被忽视的环节：编码过程中发现方案需要调整，不是重新跑一遍流程，而是把变更反向同步到方案文档，保持方案和代码一致。没有这一步，流程和实际代码很快会脱节。
四、验收：从希望遵守到验证遵守
传统代码审查有个问题叫 "泛泛看"——reviewer 可能只看了逻辑对不对，没注意到关键约束是否被遵守。产出速度远超审核速度的时候，这套机制就失效了。
所以需要从 "人眼看" 变成 "机器查"。
在技术方案到编码的入口处设一道关：硬卡点为零、约束完备才允许进入编码。在代码审查到发布的入口设第二道关：硬卡点风险为零、约束覆盖率达到要求才允许提交。在发布到线上的入口设第三道关：影响范围可控、风险评级不超过中等才允许上线。
最容易做砸的是变更规模的自适应。一刀切全量检查会扼杀效率，一刀切全部快速通过会扼杀质量。正确做法是多维度判断：代码行数、涉及的资金或状态或安全、变更的文件数、历史 bug 率——综合判断走哪条通道。这不是流程问题，是算法问题。
同时还需要检测一些 AI 特有的缺陷：代码里调用的 API 在项目依赖中是否真的存在（幻觉 API）、实现范围是否超出了任务定义（过度实现）、当前任务绑定的约束是否都被覆盖了（约束遗忘）、代码和设计方案的偏差是否超过阈值（偏差放大）。
这些检查不是要替代人的审查，而是帮人的审查聚焦到真正需要判断的地方。硬卡点机器来守，建议项人来看。
五、上下文管理：不是越多越好
很多人以为上下文窗口越来越大，问题就解决了。方向反了——窗口越大，AI 越容易迷失重点。
类比操作系统：虚拟内存不是因为物理内存不够才发明的，是因为 "全量加载" 本身就是错的架构选择。上下文窗口也一样——按需加载、分级压缩、不可换出页，这些是架构问题，不是资源问题。
具体来说，上下文应该分三级。第一级是必须传的、不可压缩的：约束清单、硬卡点规则、资金安全规则。第二级是重要的、可以摘要压缩的：技术方案核心章节、代码变更摘要。第三级是参考性的、按需注入的：知识库、历史变更记录。
随着对话推进，上下文会不断增长，需要做三阶段压缩：先结构化提取保留语义骨架，再摘要压缩保留核心结论和数据，紧急情况下截断第三级、进一步精简第二级。但有一个原则——约束清单在任何阶段都不可压缩，它是硬红线。
和上下文管理相关的一个问题是知识防腐烂。
知识库不更新，三个月就废。但防腐烂最难的不在技术，在激励。一个可行的做法是把知识更新和代码变更绑定：PR 改了某个模块，自动触发关联知识的更新提醒，不处理不能合并。把防腐烂从自觉行为变成流程硬约束。
具体可以做三件事：PR 关联复核——修改的文件路径若在某条知识的绑定路径里，评审阶段强制确认知识是否需要更新；定时巡检——定期扫描长尾知识，生成腐烂候选清单；AI 起草加人审签——大部分更新由 Agent 起草，owner 确认，边际成本压到最低。
六、人和组织
写到这里，技术问题基本讲完了。但还有一个更大的问题不能回避：人怎么办。
有一个词叫 "蒸馏焦虑"。员工每写一份 SOP、每教 AI 一个流程，都是在把知识导出到组织资产里。当员工意识到 "我说的越多被替代得越快"，关键知识开始藏匿——而 AI 友好化恰恰需要员工说出哪些隐性约定需要被结构化。
还有一个叫 "培养断裂"。旧路径很清楚：day 1 写简单代码，几年后写复杂代码，然后设计系统，最后定战略。新路径里这条线断了——day 1 AI 已经在写代码，那 day 1 的人到底应该做什么？
这两个问题叠加起来，会形成一个负反馈环：入门级岗位消失导致资深工程师断层，资深工程师因为蒸馏焦虑藏匿知识导致转型无法推进，评价系统不匹配导致员工没有动力参与转型。
最诚实的做法是承认没有完美方案。但有几个方向能避免最坏的情况发生。
第一，明确 AI 红利的分享方式。是用它来扩展组织边界、做以前做不了的事，还是用它来收缩团队？这两条路给员工的信号完全相反。
第二，把 "蒸馏" 重新定义。写 SOP 不是把自己教没，是把自己从执行者变成架构师。
第三，评价系统必须真实跟着变。口头说 "判断比执行值钱" 但 KPI 还是产出量，员工不会信。
还有一个容易被忽略的维度：AI Native 不等于全透明加全自动化。创新需要三个条件——持续注意力、愿意显得愚蠢、反共识。这三个条件在全透明的环境下都很难存在。
所以组织治理需要区分三种工作：执行类工作全透明加自动化没问题；优化类工作需要结构化但要留批判空间；创新类工作需要保护性环境——半私密、不强制广播、允许试错。用同一种治理方式管三类工作，结果是执行高效加创新死亡。
结语
AI Coding 的终局不是 "AI 取代人写代码"，而是 "人做架构师，AI 做执行者"。
但要走到这一步，需要补的工程课比想象中多。约束前置、流程编排、验收闭环、上下文管理——这些不是 AI 时代的新发明，是软件工程本该有、但之前被人兜底兜掉了的基本功。
AI 把这些基本功显式化了。不是 AI 要求你这么做，是 AI 让你没法再糊弄了。