一次故障归因会后，所有人都沉默了
上个月我们做了一件事，把过去半年的线上故障拉出来做了个完整归因。
结果出来的那天，会议室里安静了好几秒。
不是故障数量有多吓人。说实话，故障数跟去年同期比差不多，甚至还略少一点。但有一个数字让所有人都坐不住了。那 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 必须让这个测试通过。这是一个客观的、不可糊弄的锚点。
没有 TDD，AI 的"完成"是主观判断。有了 TDD，AI 的"完成"是测试通过。
客观、可验证、不可糊弄。
第四道关口：门禁卡控，机器判定为主，人工决策为辅
编码过了 TDD，最后还有一道关口，门禁。
但"审核"不是只在最后一步发生。每个阶段产物落地的时候都有对应的审核 Agent，gate-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 不会让研发流程变得不重要，它只会让好的流程和坏的流程之间的差距，变得越来越大。