夜雨聆风AI Coding 研发体系｜第二篇
这一篇拆流程层：为什么把 AI 塞进旧研发流程，常常会带来更多返工。后面会继续写组织能力、监督式工程、评价指标和治理体系，适合连起来看。
本篇聚焦第三层：流程层。它连接 Agent 执行层和组织能力层。
很多团队第一次用 AI Coding，流程其实没有变。
需求还是产品写一段话，开发还是自己理解，AI 只是在编码时被叫出来：“帮我实现一下”“帮我修一下”“帮我补个测试”。
短期看，这样确实能省几步。但进入真实项目后，很快会出现另一种返工：AI 写得很快，人改得也很快；AI 生成很多 diff，团队却花更多时间解释背景、补充约束、回滚错误方向。
问题通常不在 AI 不会写代码，而在旧流程没有给 AI 准备可执行的输入和可验证的出口。
所以 AI Coding 的流程层，不是把“开发”那一步换成 AI，而是要重新整理需求表达、上下文组织、验证方式和反馈循环。
从总架构图看，流程层是一个承上启下的位置：下面的执行层负责让 Agent 做事，上面的组织层负责让人管理这些 Agent。中间如果没有流程设计，AI 的产出就会变成一堆散落的 diff、日志和对话记录。
这篇不抽象讲概念，就用一个常见需求贯穿：给订单列表增加 CSV 导出。看起来只是一个小功能，但它足够说明 AI Coding 为什么不能只靠一句“帮我做一下”。
传统流程更像：一句需求 -> 工程师脑补 -> 写代码 -> 测试发现问题 -> 返工。
AI 流程更应该像：意图说明 -> 上下文包 -> 生成修改 -> 自动验证 -> 人工判断 -> 反馈沉淀。
旧流程靠人脑补
传统研发流程有一个隐性前提：人能补全很多没写出来的东西。
产品说“订单列表加个导出”，老工程师可能会自动补出一堆信息：导出的是当前筛选结果，不是全量订单；字段顺序要和财务模板一致；超过 5000 行不能直接导出；手机号和地址可能要脱敏；已有 Excel 导出逻辑不能被破坏。
这些信息在团队里流动，但不一定在需求里、文档里、测试里。人可以靠经验补，AI 不行。
如果只把“做一个订单导出”丢给 AI，它很可能先实现一个能下载 CSV 的按钮。代码看起来没问题，但业务上可能已经错了：导出范围不对，字段不对，权限不对，性能边界也不对。
AI 不怕任务复杂，怕的是任务边界一直在对话里漂。
需求要变成意图
这就是 Intent Engineering 的位置。
它不是 Prompt 技巧，也不是把一句话包装得更像命令。它真正要解决的是：任务目标、边界、验收标准和禁止事项能不能在 AI 开始行动前说清楚。
以前写需求，很多时候是写给人看的。人看到不完整的地方，会开会、追问、翻代码、找同事确认。AI 也可以追问，但如果每次都靠对话临时补，它就会把研发流程拖回“边做边猜”。
拿订单导出来说，好的意图不是“做导出”，而是把任务压成一组明确约束：只导出当前筛选结果；复用现有权限判断；字段顺序按财务模板；超过 5000 行给提示；不改订单查询接口；补一组导出字段测试。这样 AI 才知道哪些是目标，哪些是红线。
需求表达越含糊，AI 生成越勤快，返工就越稳定。
上下文要先整理
有了意图，还不够。
AI Coding 进入真实代码库以后，最耗的往往不是写代码，而是理解环境：订单列表入口在哪里，已有导出组件在哪，权限判断怎么写，测试怎么跑，哪些模块不能碰，历史上为什么这么设计。
这就是 Context Engineering。
它不是把所有文档都塞给 AI。上下文越多，未必越好。长日志、过期文档、无关代码和泛泛规范一起丢进去，只会让 AI 花更多成本判断什么重要。
更好的做法，是在任务开始前整理一个小上下文包。对订单导出这类需求，上下文包至少应该包含：
订单列表页面和数据请求入口；
已有 Excel 或 CSV 导出的相似实现；
字段映射、脱敏规则和权限判断；
相关测试文件和本地验证命令；
禁止修改的订单查询接口和公共组件。
上下文不是资料堆得越多越好，而是要让 AI 少走弯路。
验证要提前设计
传统流程里，测试常常在开发之后才出现。代码写完了，再跑测试；PR 提了，再做 Review；出了问题，再补修复。
AI 流程不能这样。
原因很简单：AI 让生成和试错成本变低，未经验证的改动也更容易堆起来。如果验证仍然滞后，团队会得到大量“看起来合理”的代码，然后把时间花在筛选、解释和回滚上。
Verification Engineering 要做的，是在任务开始前就说明验证方式。不是等 AI 写完才问“能不能跑一下测试”，而是一开始就告诉它：导出文件字段顺序必须正确，筛选条件必须生效，超过 5000 行必须提示，未授权用户不能导出，旧的订单查询测试不能挂。
没有验证入口，AI 很容易把“能生成 CSV”误认为“导出功能完成”。这在小工具、小脚本里问题不大，在企业代码库里会迅速变成质量风险。
AI 可以加速写代码，但不能替一个没有验证体系的项目承担质量责任。
反馈要能沉淀
AI Coding 还有一个容易被忽略的地方：反馈循环。
很多团队的反馈停在聊天窗口里：“字段顺序不对”“这里要复用权限判断”“这个模块不能碰”“测试挂了再修一下”。当次订单导出需求可能被救回来了，但这些纠偏没有进入团队资产。
下次换一个人、换一个 Agent、换一个任务，错误还会重来。
更好的反馈循环，应该把一次次纠偏沉淀成四类东西：
导出类需求模板；
订单模块上下文说明；
字段顺序、权限和大数据量测试用例；
Agent 修改订单模块时的禁止事项。
这也是个人用 AI 和团队用 AI 的分水岭。个人可以靠经验临场补救，团队必须让经验进入流程。
如果每次纠偏都只停在聊天窗口里，团队不会真的变强，只是当次任务被救回来了。
AI Coding 的流程层，核心不是把“开发”换成“AI 开发”，而是把研发流程改成 AI 能理解、能执行、能验证、能复盘的形态。
这也是为什么我不太建议企业只从工具培训开始。会用工具当然重要，但如果需求仍然含糊、上下文仍然分散、验证仍然滞后、反馈仍然不沉淀，AI 只会把原来的流程问题放大。
下一步，变化会落到人身上。
当流程开始围绕意图、上下文、验证和反馈重新设计，工程师的核心能力也会变。以前最重要的是亲自写代码，之后越来越重要的是表达任务、组织上下文、设计验收和纠偏结果。监督式工程师会在这个位置出现。
后续会继续拆 AI Coding 体系里的组织能力层。做研发管理、工程效率或企业 AI 落地的朋友，可以关注这个系列。
