AI Coding研发体系(二):让AI真正融入研发流程的实践方法

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 落地的朋友，可以关注这个系列。