一次故障归因会后所有人都沉默了上个月我们做了一件事把过去半年的线上故障拉出来做了个完整归因。结果出来的那天会议室里安静了好几秒。不是故障数量有多吓人。说实话故障数跟去年同期比差不多甚至还略少一点。但有一个数字让所有人都坐不住了。那 60% 的 bug都能追溯到同一种错误模式。同一种。放在以前这是不可能的。十个开发十种写法你就算想犯一样的错都难。张三漏判空值是张三的风格李四忘加事务是李四的习惯各有各的坑。修一个是一个不会批量传染。但现在不一样了。自从团队全面用上 AI Coding 之后代码产出速度翻了两三倍功能上线快了很多。但 bug 也变了。它们不再是零散的、个人化的而是成体系的、批量化的。AI 喜欢复用历史模式代码库里怎么写的它就学一个不好的写法没被拦住它能又快又稳地把错的东西复制一千份。这才是真正让人后背发凉的地方。以前你怕的是哪个地方又出了个问题现在你怕的是这个模式是不是在十个地方都埋了雷。这篇文章想聊的就是这件事。我们的订单系统花了一年多做了三阶段改造从稳定性到模块化都搞得差不多了按传统研发的标准看已经相当健康。结果 AI 一来整个研发流程都接不住了。然后我们是怎么把一套给人设计的研发流程重构成一套给 AI 用的流水线的。先说说订单系统这一年多都干了啥在聊 AI 之前得先铺垫一下背景。订单系统不是凭空冒出来的它已经跑了好几年前面还有三轮大的改造。这些改造打下的底子是后面所有事情的基础。第一阶段筑牢稳定底线订单系统是交易链路的核心命脉所有下单和支付行为都要经过这里。它稳不稳直接关系到业务赚不赚钱。第一阶段的目标很实在SLA 要做到 99.99%绝对不能跌单。怎么做到的梳理所有下游依赖搞了三级保障规范。什么意思呢就是把下游按重要程度分级核心的下游挂了怎么办非核心的挂了能不能降级弱依赖的直接熔断不影响主链路。这一步的核心思想是不能让下游的抖动把主链路拖垮。做交易系统的都懂最怕的不是自己出问题是别人出问题把你带崩了。第二阶段剥离核心链路稳定底线筑牢了接下来要做的是隔离。以支付节点为分界线把订单创建、支付回调这些最核心的能力从老旧的大应用里独立拆出来单独部署单独保障。核心链路用独立的机器、独立的线程池、独立的数据库连接池跟非核心功能物理上隔开。为什么要这么做因为老应用里什么都有运营后台、数据报表、各种管理功能混在一起。哪天运营导个报表把数据库打慢了核心下单也跟着受影响。拆出来之后核心链路有自己的资源池别人再怎么折腾也影响不到它。第三阶段模块化重构链路前两步做完系统稳是稳了但代码还是一大坨。加个新功能要改好几个地方牵一发动全身。所以第三阶段是按业务语义重构执行序列把每个环节都做成模块化分层再配齐全链路埋点。改哪个环节就动哪个模块不会牵连其他地方。出了问题也能快速定位到是哪个环节出的。三阶段走完订单系统可以说脱胎换骨了。稳定性有兜底核心链路有隔离架构是模块化的整条链路可观测。按传统研发的标准来看这已经是一个相当健康的系统了。但 AI 来了。AI 来了之后旧流程为什么不够用了前面三阶段的改造解决的都是系统本身的问题。但 AI Coding 普及之后问题不在系统里而在写代码的过程里了。我们遇到的挑战总结下来有这么几个。错误模式变了以前出问题大多是个人手误。张三漏判了一个空值李四忘记加事务。这类问题有个特点零散不成规模。修一个是一个不会批量传染。AI 来了之后不一样。AI 喜欢复用历史模式你代码库里以前怎么写的它就学怎么写。如果历史代码里有一个不好的写法AI 会在十个新功能里把这个写法复制十遍。错误从个人手误变成了系统性偏差。一个错误模式没被及时拦住能在代码库里开花结果。知识是散的AI 看不见每个团队都有自己的规约和最佳实践。有的写在 confluence 上有的写在某个 README 里有的藏在老员工脑子里还有的就是大家默认这么写但谁也没写下来过。对人来说这些规约是活的。新人来了看代码问同事慢慢也就学会了。但对 AI 来说规约散落在各处就等于没有。你不主动喂给它它就是看不见。团队积累了好几年的知识AI 根本不知道存在。代码量和审查力的失衡这个最直观。AI 让每个人的产出速度提高了两三倍代码变更量是以前的好几倍。但 CR 的人还是那些人时间还是那么多。以前一个 PR 改 300 行认真看半小时能看完。现在一个 PR 改 1000 行AI 生成的代码看起来还都挺合理的。你怎么办逐行看时间不够大概扫一眼又怕漏东西。缺陷逃逸的风险被放大了。故障回溯变难了以前出了问题git blame 找到写代码的人问一句当时怎么想的大概就能定位根因。现在不一样了。代码是人跟 AI 一起写的。出了问题你去问写代码的人他可能也说不清楚当时是 AI 生成的他觉得没问题就合了。根因到底是知识库没覆盖到还是 skill 写得有问题还是 prompt 没说清楚还是规约本身就写错了一团浆糊。单点提效整体熵增这是最隐蔽也最要命的一个问题。AI 把编码这一步变快了但前后的步骤没变快。需求澄清还是那么慢方案设计还是那么慢测试和上线也还是那么慢。编码变快之后各阶段之间的信息折损反而变大了。需求没说清楚AI 就开写写出来一堆不对的东西返工的时间比省下来的还多。整条链路的熵不是在减少而是在增加。你会发现这些问题的根源都不是AI 不会写代码。AI 写代码的能力其实挺强的。问题在于我们的整个研发流程还是按人理解人的模式设计的。需求文档是写给人看的CR 是人与人之间的审查故障复盘也是人与人之间的沟通。要让 AI 真正稳定地产出高质量代码不能只盯着 AI 本身要改的是它工作的流水线。我们做的事情说起来也简单就是把整个研发流程重构成了五道标准化的关口。每一道关口解决一类问题把风险挡在源头。下面就一道一道说。第一道关口需求澄清把方向钉死很多人觉得写代码的第一步是打开 IDE。其实不是。写代码的第一步是把需求搞清楚。在需求澄清这一步我们不产出任何代码甚至不讨论代码。只做一件事让业务意图被精确地、结构化地记录下来。拿一个真实的例子来说出海下单支持礼品卡支付。礼品卡的金额等于礼品卡面值加上出海服务费。这个算错了就是资损而且有一个跨环节的约束确认订单和创建订单两处都要算礼品卡金额漏改一处就会出现确认时和下单时金额对不上。在需求澄清关口我们要钉死的就是两件事算什么以及什么情况算错了要阻断。BDD 场景驱动验收标准从第一天就是可执行的传统的需求文档是给人看的文章。产品写一篇 PRD开发读完后猜要做什么测试再猜要测什么。两次传递两次折损。最后做出来的东西是不是产品想要的全靠沟通。我们不这么干。我们强制在需求阶段就产出 Gherkin 场景用 Given-When-Then 的格式写出来。这是需求和测试之间的硬契约机器可读可执行。放到出海礼品卡这个例子上场景是这样写的# 正常路径 Scenario: 出海下单礼品卡金额计算正确 Given 出海下单选择礼品卡支付面值 100 元出海服务费 10 元 When 用户确认订单 Then 礼品卡金额 110 元 # 异常边界 Scenario: 礼品卡金额异常时阻断下单 Given 礼品卡面值 服务费计算后金额 ≤ 0 When 用户提交订单 Then 阻断下单并提示金额异常 And 不创建异常金额的订单 # 优先级标记 P0 Scenario: 确认订单与创建订单金额一致 ...每条场景都有优先级P0 的必须通过才能发布。后面的 BDD 验收 Agent 会把每条 Gherkin 场景一对一映射到 TDD 测试用例逐条验收。需求、测试、实现三者一一对齐。不存在我以为是这样的这种灰色地带。统一模板禁止技术语言需求文档最怕的是什么写着写着就开始讨论技术实现了。产品说这里加个字段开发说那个接口要改聊着聊着需求和方案混在一起最后谁也说不清需求到底是什么。我们的 Spec 模板有六节是固定死的文档基本信息业务目标与用户价值核心业务流程边界条件与异常场景业务规则与协作边界优先级与验收方法每一节都要求用业务语言写技术术语一律屏蔽。字段类型、表结构、接口签名、上下游系统名一律不许出现在需求文档里。这些是技术方案阶段的事提前说只会添乱。模板由独立的子 Agent 渲染不注入主会话上下文保证产出格式稳定一致。不会因为换了个人写结构就变了。结合知识库做现状对齐写需求不能凭空写得知道现状是什么。需求澄清开始前插件会自动触发知识库查询。传入 PRD 里的业务场景关键词从知识库和代码现状里拉取一份现状分析报告。这份报告是需求澄清的事实底座。它的作用有三个。第一避免凭印象描述现状。AI 不会觉得某个功能现在是怎么工作的而是基于代码和文档的事实。第二避免新增能力和已有逻辑撞车。写新需求前先知道这块之前是怎么设计的别重复造轮子。第三澄清过程可回溯。每个判断都能溯源到知识库或代码而不是拍脑袋。提问管理该问的问不该问的别瞎问需求澄清少不了问问题。但问问题也是有讲究的。我们把问题分成三类该问的、不该问的、可以跳过的。该问的必须问清楚不该问的别浪费用户时间可以跳过的就基于现有信息判断后面再验证。这个分类是怎么来的是从历史对话里慢慢攒出来的。什么问题 AI 自己能解决什么问题必须问人积累多了就有规律了。需求澄清这道关口核心就是四件事。BDD 钉死验收标准模板屏蔽技术语言知识库兜住现状提问管理把该问的问清楚。目的只有一个让做什么和怎么算做完在起点就被精确记录。方向不错后面的努力才有意义。第二道关口技术方案不让 AI 临场发挥需求澄清把做什么钉死了技术方案这一步要回答的就是怎么改和算错了怎么兜。核心思想一句话不让 AI 在编码时临场发挥。所有设计决策在编码之前就被锁定。从整体架构拆到五段式拿到需求 Spec 之后技术方案阶段不会直接跳进代码细节。先做自上而下的模块拆解。第一步解析服务清单。从需求规格的整体架构和跨服务总览章节解析这次涉及哪些服务。第二步逐服务拆到模块粒度。每个涉及的服务按场景拆解每个场景下面固定五个子部分。就是我们说的五段式场景详细设计 ├── 模块详情五段式结构 │ ├── 目标这个模块要达成什么 │ ├── 变更位置改哪个类、哪个方法 │ ├── 字段/配置变更加什么字段、改什么配置 │ ├── 构建/处理逻辑核心处理流程 │ └── 阻断/兜底行为异常时怎么处理 ├── 异常与边界边界条件清单 ├── 新增清单新增的类/方法/配置 └── 上下游协作表格形式 ├── 上游依赖项 ├── 下游影响项 ├── 是否需要对方改动 └── 联合设计状态为什么要拆这么细因为拆得越细后面编码的时候 AI 就越不会跑偏。每一块要做什么、改哪里、怎么处理异常都写得明明白白。编码就变成了按图施工而不是自由创作。放到出海礼品卡的例子上五段式是这样写的。目标是计算礼品卡应付金额变更位置是 GiftCardCalculator 类的 calcAmount 方法字段变更增加一个 overseasServiceFee 字段处理逻辑是面值加服务费阻断行为是金额小于等于 0 时抛出异常。每个模块都长这样清清楚楚。从知识库拉取模块规约让方案知道历史光有模板还不够方案设计得符合团队已有的规约。出海礼品卡这个需求拉取知识库的时候会命中一条关键的跨环节不变约束确认订单要算礼品卡金额包含出海服务费创建订单也要算两处算法必须一致。命中的约束不会自动生效而是逐条让用户选择纳入还是明确排除。排除必须填理由理由在门禁阶段会被强制复查防止有人为图省事把关键约束排除了。纳入的约束就作为场景详细设计的输入方案从一开始就长在规约上。而且这个关联会像影子一样跟到编码和门禁阶段入口拉了哪些规约出口就查哪些规约形成完整的证据链。CLI 不可用的时候怎么办降级跳过但会在产物里明确标注。不会静默漏掉也不会因为工具不可用就卡住整个流程。统一技术方案模板章节全部硬约束所有技术方案走统一模板五大核心章节固定顺序。一、业务用例分析二、整体架构三、场景详细设计四、数据结构设计五、稳定性设计。稳定性设计是第五章专门的一章。按三个维度展开可灰度、可监控、可回滚。弱依赖模块在这里补全熔断和降级链路。除了层面二的稳定性设计每个模块详情的第五段也要求写阻断/兜底行为。这是层面一的兜底。每个模块必须明确具体动作是阻断、降级还是用默认值不能只写一句模糊的兜底处理。两层兜底模块层和全局层。小问题模块自己兜大问题全局有预案。技术方案这道关口说白了就是一件事把所有设计决策前置。编码之前就把怎么改、改哪里、异常怎么处理、用什么规约全部定死。编码的时候就只剩一件事照方案写代码。第三道关口TDD 实施用测试卡住做完没技术方案把怎么算锁死后编码就变纯粹了。照方案翻译成代码再用 TDD 卡住做完没。任务拆分每个任务都有独立验证点技术方案先要被拆解成任务列表。每个任务有三个硬约束。第一足够小可独立完成。一个任务的产物应该是可独立 review 的最小单元。太大的任务拆小不然不好验证也不好回退。第二有明确的 RED/GREEN 验证点。先写测试让测试失败这是 RED。再写实现让测试通过这是 GREEN。没有例外。第三可独立回退。任务失败了可以单独回退不影响其他任务。不会因为一个任务卡壳整个需求都推进不了。这样拆解的目的是什么呢把写一段大代码这件事变成完成 N 个小任务。每个小任务都有明确的入口和出口入口是失败的测试出口是通过的测试。AI 不再有自由发挥的空间。想写代码先证明你想清楚了它该怎么测。架构预检编码前先卡方向正式开始编码之前还有一道预检架构检测。检查什么呢分层有没有越界比如 Controller 层直接调 DAO 层跳过了 Service 层。依赖方向有没有反转比如领域层反向依赖了基础设施层。模块边界有没有穿透比如订单模块直接调用了支付模块的内部类。这一步的设计意图是避免实现跑偏后再返工。方向错了代码写得再快也没用。架构预检是事前防比事后查成本低得多。RED-GREEN-REFACTOR 循环TDD 的核心就是三步循环。第一步 RED先写测试。这个测试应该是失败的因为功能还没实现。如果测试一上来就通过了说明测试写得不对没测到点上。第二步 GREEN写最少的代码让测试通过。怎么简单怎么来先跑通再说。第三步 REFACTOR重构。测试通过了说明功能是对的这时候再把代码整理干净该抽公共方法的抽该改命名的改。因为有测试兜底重构的时候不怕改坏。放到出海礼品卡的例子上三步循环是这样跑的。RED先写测试。礼品卡面值 100出海服务费 10预期金额是 110。这时候 GiftCardCalculator.calcAmount 方法还没实现测试跑失败。GREEN实现 calcAmount 方法就一行代码面值加服务费。测试通过。REFACTOR把这个算法抽成公共方法确认订单和创建订单两处都调用同一个方法保证算法一致。为什么 TDD 在 AI 时代格外重要因为 AI 写代码最大的问题不是写不出来是它太自信了。它会在没有测试的情况下写一段看起来很合理的实现然后自信地告诉你完成了。TDD 的价值就在于先有一个失败的测试摆在那里。AI 必须让这个测试通过。这是一个客观的、不可糊弄的锚点。没有 TDDAI 的完成是主观判断。有了 TDDAI 的完成是测试通过。客观、可验证、不可糊弄。第四道关口门禁卡控机器判定为主人工决策为辅编码过了 TDD最后还有一道关口门禁。但审核不是只在最后一步发生。每个阶段产物落地的时候都有对应的审核 Agentgate-check 只是最终汇总。门禁的设计遵循四个核心原则。机器判定为主人工决策为辅所有结论落本地磁盘数据可回溯失败必须回退到具体阶段。一个一个说。机器判定为主每个审核 Agent 输出的都是结构化的 JSON。门禁读 JSON 来判断 PASS 还是 FAIL。不靠 LLM 主观总结。为什么要这么设计因为 LLM 做总结太容易和稀泥了。十个检查项里九个过了一个没过LLM 可能给你总结成基本通过建议关注。机器判定就不一样过了就是过了没过就是没过没有中间态。人工决策为辅不是所有事情都适合机器判。比如回退方向怎么选排除某个规约的理由合不合理这些关键决策点才需要人来确认。大部分检查都由机器自动完成人只在真正需要决策的地方介入。这样人的精力才用在了刀刃上。所有结论落本地磁盘数据可回溯每一步的审核结果都结构化地存在磁盘上。不是凭印象觉得没问题而是有实实在在的证据。出了问题翻回去查当时门禁查了哪些项每项的结果是什么哪个 Agent 做的判断一清二楚。这也为后面的埋点监控提供了数据基础。失败必须回退到具体阶段门禁 FAIL 不是简单打回重来。而是定位到具体是哪个阶段出的问题回退到那个阶段去修。比如技术方案漏了一个异常场景那就回退到技术方案阶段补方案而不是让开发在编码阶段自己补上。问题出在哪就在哪解决保证每个阶段的产物都是完整的。全流程的审核分布审核机制贯穿全流程不只是最后一步。需求澄清有需求的审核技术方案有方案的审核编码有编码的审核。放到出海礼品卡这个需求上门禁会查这些东西。invariant-reviewer 查不变约束。技术方案阶段纳入的确认订单和创建订单都要算礼品卡金额这条约束两处调用点是不是都同步改了。只改一处就 FAIL。delta-guard 查增量风险。新增的出海服务费查询是外部调用有没有登记有没有降级。命中了外部调用检查项没降级就高亮提醒。bdd-acceptance 查 BDD 验收。需求 Spec 里写的礼品卡等于 110 元金额小于等于 0 阻断这两条 Gherkin 场景必须有对应测试而且全部通过。门禁检查是三层 DAG 结构层内并行层间串行。同一层的检查可以并行跑提高效率。不同层之间有依赖关系必须等上一层过了才能跑下一层。增量代码体检合入前的快速拍片除了正式的门禁审核我们还有一个轻量级的工具增量代码检测。它的定位是代码准入检查的工具主要用于合并代码前的自动审查和开发者本地自查。用九个维度扫描本次改动的代码比如有没有引入新的外部调用有没有新的线程池错误码有没有重复关键调用链上有没有动到不该动的节点。扫描完生成一份飞书报告直接发到项目组的知识库下。这个工具有三个特点。可扩展每条规则是独立的小目录一个配置加一个扫描脚本新增规则不动其他地方还预留了大模型判断的扩展位。可复用解析代码差异、查代码作者、生成飞书文档这些基础动作下沉为共用工具代码差异只解析一次九条规则读同一份数据。轻量级纯文本扫描60 秒超时秒级返回。流水线有三级兜底单条规则挂了不拖累其他规则飞书发不出也会留本地文件。这个工具的定位很清楚就是快速拍片。有问题先筛出来要不要进一步处理再看人。第五道关口全流程埋点把改进变成数据前四道关口都是闸门告诉你什么能过什么不能过。这第五道关口是仪表盘告诉你改进到底有没有效果。埋点监控把研发过程变成数据。这次需求花了多少人力成本哪个阶段最耗时知识库调用成功率高吗门禁通过率在变好还是变差回退了两次根因是需求没写清还是方案设计漏了。有了数据改进才有据可依。不是拍脑袋说我觉得流程变顺了而是拿数据说话需求澄清的回退率降了多少门禁通过率提了多少平均交付周期短了多少。看板分三层从需求到代码逐层下钻。最上层是需求维度的概览中间层是阶段维度的明细最下层是单个任务的执行细节。想看粗的看粗的想看细的看细的。指标按问什么问题归成五个维度。这里就不展开了重点说说埋点数据怎么驱动改进三个典型场景。场景一知识库该补什么怎么判断知识库够不够用看三个信号。知识库调用成功率低引用的知识条目少用户问答多。三个信号凑在一起说明知识库要么内容少要么命中率低。高频被问到的问题清单就是知识库该补充的内容清单。用户反复问什么就把什么写进知识库。写进去之后再看这个问题是不是就不问了。这是一个正向循环。问题越多补充的内容越多知识库越好用问题就越少。场景二流程哪里设计得不好怎么判断某个流程阶段设计得好不好看耗时和对话轮数。耗时高不一定是问题可能就是这个阶段事情多。但耗时高加上对话轮数异常高就一定是流程设计有问题不是模型慢。比如技术方案阶段来回改了十轮才定下来说明要么需求澄清没做好方案阶段还在反复改需求要么方案模板有问题AI 理解不了来回调整。找到异常的阶段针对性地优化模板或者补充知识库效率就上去了。场景三哪个子 Agent 在白干子代理和工具调用也是一样的道理。某个子 Agent 被调用了很多次但产出很少或者反复调用同一个工具拿不到有用的结果说明这个子 Agent 的设计有问题或者工具不够用。把这些白干的地方找出来该收敛的收敛该加工具的加工具。埋点监控这道关口是前四道关口的反馈回路。没有它前面的改进都是凭感觉。有了它每一步改进都能量化才能持续优化。五道关口串起来就是一条 AI Native 的流水线到这里五道关口就都讲完了。我们把它们串起来看看。最开始是需求澄清BDD 钉死验收标准解决做什么的问题。然后是技术方案五段式拆解加上规约对齐解决怎么做的问题。接着是 TDD 实施任务拆分加红绿色循环解决做完没的问题。再然后是门禁卡控机器判定加结构化证据解决能不能上的问题。最后是全流程埋点数据驱动持续改进解决有没有用的问题。五道关口一道接一道把风险一层一层往下筛。每一道关口都有明确的输入和输出产出物是结构化的、可验证的。整个流水线的架构自底向上分了五层。最底层是基础设施层统一埋点定义和阶段性产出规范通过 Hook 自动采集和 SKILL 显式采集双通道实现全链路数据采集。往上是 Agent 系统层设计 Agent、意图工程、上下文工程通过链式调用、并行协作、反馈修正、结果汇总来编排。再往上是开发流程层就是我们说的五阶段核心研发流程。第四层是度量层全链路可观测量化数据采集、分析、报告与可视化。最顶层是治理层把 spec、code、arch、BDD 四维并行审查的能力内嵌到前四层。五层架构从基础设施到治理每一层支撑上面一层治理层又反过来贯穿下面所有层。最后说几句AI Coding 发展到今天比拼的早就不是谁的模型更强了。模型能力大家都差不多你用 GPT 我用 Claude差距能有多大真正拉开差距的是谁能把 AI 的产出变成可验证、可度量、可负责的研发生产方式。可验证、可度量、可负责这七个字才是 AI Native 研发范式的核心。模型能力是变量今天这个模型强明天那个模型出来又更强了。你没法控制。流程设计是常数你怎么组织需求、怎么设计方案、怎么保证质量、怎么度量效果这些是你能说了算的。变量决定上限常数决定底线。交易核心系统的底线不能交给变量。所以我们花了这么大力气做这五道关口搭这条流水线。不是因为 AI 不够好恰恰是因为 AI 太好了好到如果没有合适的流程去约束它它能把好的坏的都放大十倍。用好 AI 的前提是给它一个好的工作环境。就像一个优秀的工程师你得给他清晰的需求、明确的规范、合适的工具、及时的反馈他才能发挥出最大的价值。AI 也是一样。流水线搭好了AI 的效率才能真正转化为团队的产能而不是更多的技术债和线上故障。这条路我们也是摸着石头过河走了不少弯路。但方向是明确的AI 不会让研发流程变得不重要它只会让好的流程和坏的流程之间的差距变得越来越大。
