AI 原生团队如何重新设计代码审查

AI 进入研发流程以后，代码审查不是不需要了，而是传统的 PR 式异步审查不再足够。过去我们习惯的流程是：一个人写完代码，提交 PR，其他人抽时间看 diff，在评论区指出问题，然后作者再修改。这种模式在人工编码时代已经有延迟，但还能接受，因为代码产出速度相对有限。

AI 原生开发改变了这个节奏。一个工程师可以在很短时间内让 Agent 生成大量代码、测试、配置和重构 diff。如果团队仍然把主要判断都放在最后的 PR review，结果往往不是质量更高，而是 review 队列变长、上下文丢失、架构问题发现太晚，最后大家面对的是一个“能跑但没人真正理解”的大改动。

所以，真正要重构的不是“要不要 code review”，而是 code review 在团队协作中的位置。它应该从事后的异步挑错，转向过程中的同步对齐、风险分级、自动化验证和团队共同理解。

为什么异步 PR 审查在 AI 原生流程里会变低效

第一，反馈速度和生成速度不匹配。AI 可以几分钟生成一个完整实现，但人类 reviewer 可能几个小时甚至几天后才看。等反馈回来时，作者可能已经切到别的任务，工作记忆里的取舍、约束和未写下来的判断已经淡了；原来的 AI 会话也可能不再是当前工作入口，继续修改时需要重新恢复上下文，修改成本反而上升。

这里说的不是 trace 丢失。trace 可以记录工具调用、文件变更、测试结果和部分推理过程，是很重要的底层证据。但 trace 通常太细、太长，而且更偏“发生了什么”，不能直接替代 reviewer 需要的审查入口：为什么这么拆边界、哪些规则不能改、哪些失败是 AI 自愈修复的、哪些地方需要人判断。commit 历史、PR 摘要、风险说明和测试证据的作用，是把 trace 提炼成可消费的审查路径。

第二，问题发现得太晚。AI 写出的代码表面上可能格式正确、测试能过，但真正危险的问题经常是方向性的：需求理解错了，领域边界错了，推理契约设计错了，验证器被绕开了，审计轨迹和供应商侧推理状态混在一起了。这些问题如果等 PR 阶段才发现，通常意味着核心实现已经成型，推翻重来会很痛。

第三，低层次 review 应该被自动化吸收。命名、格式、简单重构、类型错误、lint、测试覆盖、安全扫描，这些不应该继续占用大量人类 review 注意力。AI、formatter、linter、type checker、CI 和安全扫描工具更适合处理这些问题。人类 review 应该上移到意图、架构、领域规则和风险判断。

第四，AI 会放大 diff。以前一个人一天可能写几百行代码，现在可能生成几千行。PR 变大以后，reviewer 很难判断哪些是关键逻辑，哪些是机械改动，哪些是 AI 自己“顺手”引入的抽象。异步 review 面对大 diff 时，常常会退化成只看局部问题，而错过整体设计。

第五，知识传递效果变差。PR 评论区只能看到结果，很难看到为什么这么设计、为什么放弃另一个方案、哪些假设被验证过。新人需要学习的不是“这里换成 map”，而是如何判断一个方案是否符合系统边界。成熟团队需要共享的也不是每一行代码，而是系统当前的心智模型。

新目标：不是取消审查，而是把审查前移

AI 原生团队需要把代码审查拆成四层：

意图审查：需求是不是理解对了，目标是不是清楚，哪些假设需要验证。
设计审查：架构边界、领域模型、履约模型、推理契约、接口契约、数据模型是否合理。
实现审查：代码是否符合既有模式，是否有过度抽象，是否容易维护。
证据审查：测试、类型检查、CI、日志、截图、trace、性能数据是否能证明变更可信。

传统 PR review 把这四件事混在最后做。AI 原生流程应该把它们分散到开发过程中：意图和设计在写代码前审查，关键实现过程中同步校准，低层次问题交给自动化，PR 阶段主要检查证据和最终风险。

为了避免下面的原则过于抽象，先用一个 Agent 推理案例做引子：薪酬 SaaS 在 6 月结算时发现异常，需要判断哪些薪资项可以自动放行，哪些必须转人工审核。

这个需求表面上像是“给 Agent 加一个思维链”或“把 trace 记录得更完整”。但从履约建模看，它其实是一组权责履约：企业租户请求薪酬系统给出可审计的异常审核结论，系统需要基于薪资快照、考勤、政策版本、审批单和验证器结果，履行异常识别、证据核验、推理决策和升级退出的责任。

比如系统遇到四类问题：小冰这个月几号发薪，咖哥应发比上月高 18% 是否能自动放行，小雪同时命中两版奖金政策该按哪版算，月底总账差了 37 万要从哪里查起。它们需要的推理模式不同：直接回答、链式分解、并行探索、迭代假设验证。真正要审查的不是 Agent 有没有写出一段漂亮分析，而是它是否选择了正确的推理履约方式，是否留下了可核验的证据链。

这个案例会反复对应四层审查：先审查“企业租户请求系统履行什么判断责任”的意图，再审查推理契约、证据引用、验证器和停止条件，接着审查前后端实现是否遵守同一套审计轨迹契约，最后用测试、trace、验证器结果、监控和升级记录证明它可以上线。

同时，它也天然横跨领域系统和业务系统。薪资快照、政策规则、审批系统、差异计算器、验证器注册表更接近领域系统；异常审核协议、自动放行规则、人工升级规则、审计责任链则是业务系统。前者更容易通过类型、测试和契约让 AI 自愈；后者涉及运营承诺、合规、权责、凭证和审计，必须由人同步判断。

风险分级决定协作强度

不是所有改动都需要 pair 或 mob。真正有效的方式是按风险分级，而不是一刀切。但风险分级也不能只看“改了多少代码”或“前端还是后端”。按照履约建模的视角，第一步应该问：这次改动落在领域系统、业务系统，还是二者之间的推理履约协作边界上？

领域系统通常是运营中立、领域特定的能力，例如薪资快照读取、考勤数据、政策版本、审批记录、差异计算器、验证器注册表。它们的风险主要来自算法、协议、数据一致性、性能和安全边界。

业务系统则是运营特定、领域中立的履约逻辑，例如异常审核协议、自动放行规则、人工升级规则、审计轨迹、SLA 和责任链。它们的风险主要来自权责是否清楚、凭证是否可追溯、升级退出是否合理、合规和审计是否能解释。

所以协作强度可以这样区分：

改动落点	例子	主要风险	推荐协作方式	AI 自愈边界
低风险表达层	文案、样式、小配置、非关键页面状态	用户理解偏差、视觉回归	个人 + AI + 自动化检查	高：format、lint、截图差异、构建失败
领域系统局部实现	payroll delta calculator、policy parser、approval validator	协议错误、类型错误、算法错误、性能问题	个人实现，必要时轻量 review	中高：在单测、类型、契约、性能基准约束下可自愈
领域系统边界变化	新政策版本模型、新审批数据源、新验证器注册方式	既有调用方兼容性、数据一致性、安全边界	先同步方案，再分开实现	中：可修适配和测试失败，不能自行改变边界语义
业务系统履约变化	新增自动放行规则、人工升级规则、推理预算策略、审计保留规则	权责不清、凭证断裂、审计不可解释、运营承诺变化	pair / mob + AI	低：只能修实现错误，不能自行改履约规则
业务与领域协作边界	审批单扮演奖金合法性确认，政策版本扮演规则有效性确认，验证器扮演放行确认	变化点识别错误、核心业务依赖支撑系统、事实来源混乱	pair / mob + 契约 checkpoint	低：可修 contract mismatch，不能改凭证角色和依赖方向
架构迁移、跨团队协议	ReasoningTrace schema 迁移、SDK 版本升级、跨服务事件协议	兼容窗口、灰度、回滚、跨团队影响	设计评审 + 分阶段实施 + 多轮 checkpoint	低，只适合 codemod、编译错误、文档链接等机械部分

这样做的关键是：领域系统的风险更容易被类型、测试、协议和性能指标捕获；业务系统的风险更依赖履约模型、凭证链和运营判断。 前者可以给 AI 更大的自愈空间，后者必须保留更多同步判断。

前面这个薪酬异常审核案例不是因为代码量大才高风险，而是因为一个错误可能同时影响发薪准确性、员工权益、合规审计、客户解释和人工审核成本。

哪些部分可以让 AI 自愈迭代修复

AI 自愈不是让 AI 自己决定产品和架构，而是让 AI 在一个明确的验证闭环里反复执行：运行检查、读取失败原因、修改代码、再次验证，直到通过或触发人工介入。

从领域系统和业务系统的划分看，AI 自愈的空间并不相同。

领域系统更适合 AI 自愈，前提是正确性已经被稳定的机器信号表达出来。比如类型检查、单元测试、属性测试、协议测试、性能基准、安全扫描。因为领域系统关注的是某个问题域自身的正确性，很多错误可以被明确地定义为“违反不变量”。

业务系统只能局部 AI 自愈。因为业务系统关注的是运营特定的权责履约。AI 可以修复“实现没有符合已经确定的推理契约”，但不能自己重新解释合规规则、放宽自动放行条件、改变人工升级规则、补写凭证或删除审计。

系统边界	可以让 AI 自愈的部分	必须转人工判断的部分
领域系统：Payroll Snapshot	schema 校验失败、字段映射错误、版本字段漏传	哪个快照版本应作为本次结算事实来源
领域系统：Policy Engine	政策有效期解析错误、规则表达式测试失败	单月涨幅阈值是否从 15% 调到 20%
领域系统：Approval Validator	审批单金额、审批人、生效月份匹配逻辑 bug	哪类审批单可以扮演自动放行凭证
领域系统：Delta Calculator	工资项差异计算单测失败、重复项识别错误	哪些工资项需要纳入异常口径
业务系统：Reasoning Contract	contract test 不通过、API response shape 不一致	这类异常应该走 direct、CoT、parallel 还是 iterative
业务系统：Decision Gate	已定义的放行测试失败、依赖未通过却继续决策	自动放行、拦截、转人工的业务责任边界
业务与领域协作	OpenAPI / SDK mismatch、mock 漏字段、trace 字段缺失	哪个领域凭证可以扮演业务履约确认

适合 AI 自愈的部分通常有四个特征：

反馈信号明确：有失败测试、类型错误、lint 错误、契约测试、视觉回归截图、CI 日志等机器可读证据。
修改范围有限：只影响少量文件、局部模块或机械性迁移，不会改变系统边界。
验收标准稳定：AI 不需要重新解释业务规则，只需要让实现满足既定规则。
失败可以回滚：改坏了可以撤回，不会造成数据、安全或生产事故。

因此，AI 自愈最适合处理的是“机器已经证明有问题，并且机器也能证明修好了”的事情。比如 TypeScript 编译失败、单元测试失败、contract test 不通过、视觉回归截图不一致、lint 报错、迁移脚本语法错误等。

放到薪酬异常审核案例里，可以让 AI 自愈的事情包括：前端 ReasoningTraceView 类型和后端 schema 不一致、mock 字段漏了、状态页视觉回归失败、migration 语法错误、审批验证器单测失败、E2E 找不到“转人工”按钮、埋点字段类型不匹配。它们都有明确反馈，并且修复目标是“符合已经定好的领域不变量或推理契约”。

不适合 AI 自愈的是需要重新判断规则的问题：异常涨幅阈值应该是多少、审批单是否足以支撑自动放行、政策冲突时谁优先、什么时候升级人工、是否允许模型在证据缺失时给出推测。这些问题可以让 AI 提供方案，但不能让 AI 自己闭环修复并合并。

在薪酬异常审核里，AI 不能自己决定“缺少审批单时仍然自动放行”，不能自己放宽跨租户证据引用，不能为了通过测试删掉验证器失败分支，也不能把尚未通过 Decision Gate 的判断在前端显示成“已放行”。

为了避免“自愈”变成“自作主张”，团队需要给 AI 自愈设置护栏：

限定边界：先声明本次自愈发生在领域系统、业务系统，还是二者的契约适配层。
限定目标：一次只修一个失败信号，不要顺手重构无关代码。
限定范围：明确允许修改哪些目录、文件或模块。
禁止篡改验收标准：除非人明确要求，否则 AI 不能为了让测试通过而修改测试语义。
禁止改变履约语义：不能新增 / 删除推理履约项，不能改变权利方、义务方、凭证角色或升级退出规则。
要求保留证据：每轮迭代都要留下失败原因、修改内容和最终通过的命令。
设置停止条件：连续多轮失败、需要改变业务规则、修改范围扩大、触及安全或数据一致性时，必须转人工判断。

这样，AI 自愈就不是替代 review，而是把 review 中低层次、可验证、重复性的修复前移到开发过程中。人类 reviewer 最后看到的就不再是一堆编译错误和格式问题，而是更清楚的边界判断、推理契约、风险说明和验证证据。

反例：端到端自由发挥 Agent 会把审查变成看表演

最常见的错误做法，是给 Agent 一个大目标：

帮我完整实现薪酬异常审核 Agent，自己看代码、自己拆任务、自己设计推理、自己写前后端、自己补测试，最后给我一个 PR。

这个模式在 demo 里很容易显得惊艳。Agent 会读代码、生成计划、修改后端、补前端、跑测试、修报错，最后给出一段漂亮总结。问题是：这类端到端自由发挥，评价的往往是“Agent 表演得像不像一个聪明工程师”，而不是“主流程是否可复现、可审计、可交接、可回滚”。

企业级主流程不能只看 Agent 这一次有没有跑通。真正要问的是：

它为什么把小冰发薪日走 direct，把咖哥 18% 走 CoT，把小雪政策冲突走 parallel，把总账差异走 iterative？
它从哪里拿上下文？上下文是否完整、可信、可复用？
它为什么认为某个审批单可以扮演奖金合法性确认？
它失败时是重试、中断、绕过，还是自己补了一个规则？
它有没有为了让测试通过修改验收标准？
它生成的 ClaimStep、EvidenceRef、Validator 和 Decision Gate，换一个 Agent 执行是否仍然稳定？

如果这些问题的答案都是“Agent 自己判断”，那这不是工程流程，而是把流程责任塞进了一个更会说话的黑箱。

所以，当前文章强调的不是让 Agent 更像一个端到端员工，而是把主流程拆成可审查的生产线：

Workflow：先建模边界，再定推理契约，再实现领域系统，再实现业务决策，再补证据。
Context：上下文来自代码、schema、测试、凭证、trace 和明确的业务规则，而不是 Agent 自己记得。
Script：格式化、schema 检查、迁移校验、重复扫描、类型检查这些确定性工作交给脚本和工具。
Constraint：哪些规则不能改，哪些权限不能放宽，哪些凭证不能伪造，哪些失败必须中断。
Validator：测试、contract test、E2E、trace、验证器和人工确认点共同验收。

这样 Agent 仍然有价值，但它只是在明确节点里执行、生成、解释和修复。主流程的稳定性来自 workflow、context、script、constraint 和 validator，而不是来自某个 Agent 这一次自由发挥得很好。

这也是为什么 commit 历史、PR 证据、AI 自愈边界和同步 checkpoint 都很重要。它们的目标不是给 Agent 增加流程负担，而是让 reviewer 不必评价一场表演，而是在审查一条可复现的交付路径。

AI 参与下的 pair / mob 角色

在老带新的场景里，经常可以用 “Senior + Junior + AI” 来描述：Senior 负责判断方向和架构，Junior 负责推进实现，AI 负责快速生成和修改代码。

这里的意思不是 Junior 只是打字员，也不是 Senior 不写代码。真正的分工是：

Senior 提供判断力：需求拆解、架构取舍、领域边界、长期维护风险。
Junior 推动落地：把讨论转成具体步骤，操作 AI，阅读生成代码，补测试，跑验证。
AI 提供执行力：生成候选方案、局部代码、测试、重构和变更摘要。

对于已经成熟的团队，角色不必固定成 Senior / Junior，而可以轮换成：

Driver：操作编辑器和 AI，把讨论变成代码。
Navigator：盯设计方向、边界条件和复杂度。
Domain owner：确认业务规则和领域语言没有偏。
Quality owner：关注测试、安全、性能、可观测性和回滚。
AI：加速生成、修改、解释和总结。

关键是：AI 不负责最终判断。它可以提出方案和生成代码，但团队必须决定哪些方案可以进入系统。

在薪酬异常审核案例里，Domain owner 负责确认薪资快照、政策版本、审批单和异常口径的语义，Quality owner 负责验证器、权限、回滚和观测，Driver 操作 AI 生成推理契约、ClaimStep schema、EvidenceRef、ValidatorRegistry、前端 trace 页面骨架和测试。AI 的输出越快，Navigator 越要盯住“它有没有绕过证据链、有没有伪造放行态、有没有把供应商侧推理状态当成应用审计轨迹”。

如何避免同步协作拖慢效率

对同步协作最大的担心是：大家都 pair / mob，效率和并行会不会变低？答案是：如果所有事情都这么做，当然会变低。

所以原则不是“所有代码都一起写”，而是“把同步投入放在最能减少返工的地方”。

一个更合理的节奏是：

前面短同步：对齐意图、边界、接口、风险和测试策略。
关键骨架共创：一起写最影响系统一致性的部分。
中间并行实现：边界明确后拆开做低风险工作。
关键点再同步：遇到架构分歧、领域规则不清、测试失败时再一起校准。
PR 做证据确认：不把所有判断都推迟到最后。

表面上看，同步会减少一部分局部并行；但如果它能减少大 PR 堵塞、返工、重复实现和上线事故，整体流速反而会更高。

在薪酬异常审核案例里，这意味着团队不需要全程 mob 到所有页面细节都完成。真正需要同步的是业务系统部分：推理契约、模式路由、ClaimStep 类型、证据闸门、确定性验证闸门、升级退出规则和审计保留策略。领域系统部分则可以在契约稳定后并行推进，例如 payroll delta calculator、policy parser、approval validator、前端 trace 页面、埋点和文档。领域系统里的失败测试可以更多交给 AI 自愈；业务系统里的判断责任变化必须回到同步讨论。

AI 时代真正的瓶颈不再是写代码速度，而是方向是否一致、系统是否还能被团队理解、风险是否被及时发现。

高风险推理履约改动应该怎么做

涉及薪酬、风控、合规、权限、财务等高风险判断时，不能只是“让 Agent 多想几步”。更准确的节奏是：先用履约模型把判断责任建出来，再把关键推理骨架一起写出来，边界清楚后才前后端并行实现，并且把上线后的观察和反馈也纳入同一条知识流。

这可以用全流程交付和履约建模的视角来理解：高风险推理改动不是一个“加 CoT”任务，而是一条从业务问题、方案建模、任务分解、编码测试，到上线运营的完整知识流。AI 可以加速其中很多环节，但团队必须保证每一段知识都没有断裂。

前面已经用薪酬异常审核做了引子。这里继续把它展开成完整的履约建模过程。这个需求同时涉及证据检索、推理模式路由、ClaimStep 编译、验证器、前端审计轨迹展示、后端 trace 存储、人工升级和上线监控，是典型高风险改动。

第一步：先区分领域系统和业务系统

不能一上来就问“要加哪些表、哪些接口、哪些页面”。要先区分：哪些是领域逻辑，哪些是业务逻辑。

在这个例子里，领域系统更接近这些稳定能力：

Payroll Snapshot：薪资快照、工资项、版本、租户隔离。
Attendance System：考勤缺失、假勤记录、有效期。
Policy Engine：薪酬异常政策、奖金政策、社保基数政策、政策版本。
Approval System：审批单、审批人、金额、生效月份、审批权限。
Delta Calculator：薪资差异计算、工资项归因、重复发放检测。
Validator Registry：金额验证、政策验证、审批验证、权限验证、决策闸门。

业务系统则不是“怎么计算工资差异”，而是：薪酬 SaaS 如何代表企业租户履行异常审核责任，并给出可审计、可复核、可升级的放行 / 拦截 / 人审决定。

这一步的结论很重要：薪酬异常审核不是一个自然语言解释功能，也不是一个 trace 展示页面，而是一个推理履约过程。前端页面、后端 API、RAG 检索、CoT、验证器和人工升级，都只是这个履约过程的不同凭证和实现载体。

因此，后续风险也要分开看：如果改的是 Delta Calculator、Policy Parser、Approval Validator，主要是领域系统风险，可以更多依赖测试和 AI 自愈；如果改的是自动放行规则、推理模式路由、升级退出条件、审计责任链，则是业务系统风险，必须同步确认履约语义，AI 只能修实现，不能改规则。

第二步：识别合同前上下文，也就是请求入口变化点

履约建模不只看决定生成之后，也要看决定之前的请求入口。放到薪酬异常审核里，合同前上下文就是各种“审核请求渠道”：

请求入口	请求邀请 / Request	候选响应 / Proposal	履约形成点
结算批处理	6 月薪资快照生成后，系统发现异常	系统建议进入异常审核队列	payroll release job 接受审核任务
人工查询	薪酬专员询问“哪些可以自动通过，哪些要人审”	系统生成异常列表和建议推理模式	薪酬专员确认发起审核
合规抽检	审计人员要求复核某员工薪资变化	系统生成证据包和审核计划	审计任务进入复核流程
员工申诉	员工对工资项提出异议	系统生成差异解释和待验证问题	客服或 HR 接受申诉处理任务

这里的关键判断是：请求入口是变化点，推理履约上下文要尽量稳定。

前端上，批处理可能没有页面，人工查询可能是控制台，员工申诉可能是工单入口。后端上，它们可能来自不同服务、不同权限、不同数据范围。但只要进入异常审核，应该生成同一种核心业务产出：PayrollAnomalyReviewRequest，也就是薪酬异常审核请求。

所以团队不能把“某个页面上的按钮状态”直接当成推理模型。正确做法是：入口可以多样，但入口最终只负责产生履约上下文所需的凭证，例如 anomaly id、tenant id、employee id、snapshot version、requester role、requested decision type。

第三步：识别合同上下文和参与方

履约建模的第一步是寻找合同上下文，明确合同的参与方。因为合同是最小业务上下文，权责履约是最小业务交互。

这个例子至少有三个合同上下文：

合同上下文	参与方	说明
薪酬异常审核服务约定	企业租户与薪酬 SaaS Provider	核心业务合同，约定异常识别、证据核验、决策放行和人工升级责任
企业内部薪酬审批约定	企业与管理者、HR、财务角色	支撑审批单、奖金发放、社保基数调整，不应该污染异常审核模型
支付 / 发薪执行约定	企业与银行、支付通道或内部财务系统	支撑最终发薪执行，异常审核只提供是否可放行的凭证

由于合同原则上只存在于双方之间，所以不要把企业租户、SaaS Provider、员工、审批人、银行、审计人员全部塞进一个“大流程”。多方协作应该拆成多个上下文，再通过凭证引用连接起来。

这对架构很有帮助：异常审核服务不应该直接依赖每一种审批来源或发薪通道；审批系统产生的审批确认凭证，可以扮演薪酬异常审核中的“奖金合法性确认”。这就是通过凭证角色化发现变化点。

第四步：寻找主要履约项，而不是先写思维链

在薪酬异常审核服务约定中，团队要先找主要履约项。每个履约项都要回答：谁是权利方，谁是义务方，请求是什么，确认是什么，凭证是什么，时限是什么。

履约项	权利方	义务方	履约请求 Request	履约确认 Confirmation	关键凭证
异常事实确认	企业租户	SaaS Provider	`AnomalyFactReviewRequest`，包含员工、月份、快照版本	`AnomalyFactConfirmed`	payroll snapshot、delta calculator result
推理模式选择	企业租户	SaaS Provider	`ReasoningRouteRequest`，包含任务风险和证据状态	`ReasoningRouteConfirmed`	route reason、budget、mode
证据核验	企业租户	SaaS Provider	`EvidenceVerificationRequest`，引用异常事实和待核验证据	`EvidenceVerifiedConfirmation`	policy version、approval record、validator result
决策放行	企业租户	SaaS Provider	`DecisionGateRequest`，引用已通过的 ClaimStep	`DecisionGateConfirmed`	ClaimTrace、Decision Gate result
人工升级	企业租户 / SaaS Provider	SaaS Provider	`HumanReviewEscalationRequest`，引用失败步骤和原因	`HumanReviewEscalatedConfirmation`	stop_reason、failed_step、review ticket

这里有两个关键点。

第一，推理天然是异步履约。ReasoningRouteRequest 发出后，在 ReasoningRouteConfirmed 出现之前，系统不应该假设它一定走 CoT；DecisionGateRequest 发出后，在 DecisionGateConfirmed 出现之前，前端不能显示“已自动放行”。

第二，思维链只是推理履约模型的技术投影。可以在代码里实现 OBSERVE、DECOMPOSE、DERIVE、VERIFY、DECIDE，但这些步骤必须能追溯到请求、确认和凭证，而不是开发者为了让模型“看起来会想”临时拼出来的自然语言段落。

第五步：把 CoT 建模为可验证命题链

以咖哥 18% 薪资异常为例，CoT 不应该是一段散文式分析，而应该是一组可验证命题。每一步只表达一个命题，并且绑定证据、依赖和验证器。

步骤	类型	履约意义	证据 / 验证器
S1	OBSERVE	确认异常事实：咖哥 6 月应发比 5 月高 18%	payroll_snapshot:2026-05、payroll_snapshot:2026-06
S2	DECOMPOSE	把异常拆成增量来源、规则触发、审批匹配三个待验证问题	依赖 S1
S3	DERIVE	推导 18% 增量主要来自季度奖金	payroll_delta_calculator
S4	VERIFY	核验租户规则：单月应发涨幅超过 15% 需要审批	policy:payroll_anomaly:v7
S5	VERIFY	核验季度奖金审批单存在，金额、审批人、生效月份匹配	approval_validator、approval:BONUS-18472
S6	DECIDE	在 S3、S4、S5 均通过时，本次可自动放行	payroll_release_gate

这条链和普通“逐步分析”最大的不同，是每一步都能回到外部对象。薪资快照、政策版本、审批单、验证器结果都不是模型编的，系统可以重新读取、重新计算、重新验证。

普通 CoT 说：“我认为它合理。”生产 CoT 说：“S6 依赖 S3、S4、S5；S3 来自差异计算器；S4 来自政策版本 v7；S5 由审批验证器通过；所以 S6 可以放行。” 这就是从思维链到可核验轨迹的关键变化。

第六步：寻找违约和异常，并把异常变成新的履约项

履约建模很重要的一点是：异常不是在原流程里偷偷修掉，而是作为不能履约的情况，触发新的履约项。因为业务一致性不是“系统最后看起来对了”，而是各方的责任、凭证和补偿都可追溯。

在薪酬异常审核例子里，可以这样找异常：

异常场景	业务解释	新履约项或处理方式
缺少审批单	SaaS Provider 无法完成奖金合法性确认	触发 `HumanReviewEscalationRequest`
政策版本冲突	单链 CoT 无法确认适用规则	升级到并行探索，比较不同政策口径
总账差异 37 万	信息不足，不能一次性决策	升级到迭代假设验证，逐轮缩小根因
验证器失败	证据无法通过确定性闸门	中断决策，返回 failed_step 和 stop_reason
模型改写已验证事实	推理漂移	中断并升级人工复核
工具结果和模型解释不一致	外部观察与推理解释冲突	保留冲突凭证，进入人工复核或更高成本推理模式

这一步会直接影响前后端实现。

前端要展示的是推理履约状态，而不是模型状态：证据收集中、模式已路由、命题验证中、等待人工复核、自动放行、已拦截、验证失败。每一个状态都应该能解释“当前在等待谁履约”。

后端要保存的是应用侧审计轨迹，而不是只保存最终答案或供应商侧推理状态。Provider state 帮模型续想，Application trace 帮系统负责。审核员需要看到的是 task id、mode、route reason、ClaimStep、EvidenceRef、validator、status、final decision 和 stop reason，而不是模型内部长篇独白。

第七步：通过凭证角色化发现变化点

如果一个履约确认可能由多个上下文中的凭证来扮演，就说明这里是变化点。薪酬异常审核里最典型的是“证据核验确认”和“决策放行确认”。

异常审核服务只关心一件事：某个命题是否被可核验凭证确认。至于这个凭证来自工资快照、考勤系统、政策引擎、审批系统、差异计算器，都是领域系统的事情。

所以模型里应该有角色化的凭证：

扮演确认的凭证	来自哪个上下文	可扮演的业务确认
`PayrollSnapshotDelta`	薪资快照 / 差异计算器	异常事实确认
`AttendanceRecordMissing`	考勤系统	考勤缺失确认
`PolicyEffectiveVersion`	政策引擎	规则有效性确认
`BonusApprovalMatched`	审批系统	奖金合法性确认
`ValidatorPassed`	验证器注册表	命题验证确认
`DecisionGatePassed`	决策闸门	自动放行确认

这样做的架构含义是：核心异常审核模型不依赖具体证据来源。新增一个审批系统、一个政策引擎或一个工资项计算器时，不应该改异常审核履约项本身，而是新增一种可以扮演对应确认的凭证适配。

同理，推理模式选择也是变化点。小冰发薪日可以由直接回答确认，咖哥 18% 需要 CoT，小雪政策冲突需要并行探索，总账差异 37 万需要迭代假设验证。核心业务不应该写死“所有异常都逐步思考”，而应该让不同推理凭证扮演不同的审核履约确认。

第八步：把履约模型映射成前后端契约

建模完成后，再谈前后端实现。此时前后端并不是各自猜状态，而是共同消费同一套推理履约模型。

后端 API 不应该只返回：

{ "decision": "approved", "reason": "looks reasonable" }

它更应该返回一个可解释的 audit trace summary，例如：

{
  "taskId": "payroll-review-2026-06-kage",
  "mode": "cot",
  "routeReason": "gross_pay_delta_exceeds_threshold",
  "budget": {
    "maxModelCalls": 4,
    "maxToolCalls": 8,
    "maxLatencyMs": 12000
  },
  "steps": [
    {
      "stepId": "S3",
      "kind": "derive",
      "claim": "18% delta is mainly caused by quarterly bonus",
      "dependsOn": ["S1", "S2"],
      "evidenceRefs": ["payroll_delta:2026-06:kage"],
      "validator": "payroll_delta_calculator",
      "status": "passed"
    },
    {
      "stepId": "S5",
      "kind": "verify",
      "claim": "bonus approval matches amount, approver, and effective month",
      "dependsOn": ["S3", "S4"],
      "evidenceRefs": ["approval:BONUS-18472"],
      "validator": "approval_validator",
      "status": "passed"
    }
  ],
  "finalDecision": "auto_release",
  "stopReason": "all_required_claims_verified"
}

前端据此渲染：

如果只有异常事实，没有路线确认，展示“正在选择审核路径”。
如果 route 是 direct，展示“直接回答，低风险查询”。
如果 route 是 cot，展示“正在逐步核验证据”。
如果 route 是 parallel，展示“存在多个规则口径，正在比较”。
如果 route 是 iterative，展示“信息不足，正在逐轮调查”。
如果 DecisionGatePassed，才展示“可自动放行”。
如果 stopReason 是 evidence missing、validator failed、policy conflict，展示“已转人工”。

后端则围绕推理履约项组织代码：

createPayrollAnomalyReviewRequest
routeReasoningMode
compileStepDraftToClaimStep
attachEvidenceRefs
runValidatorForClaimStep
runDecisionGate
escalateHumanReview
persistApplicationAuditTrace

这样，前端状态、后端服务、数据库表、测试用例和审计日志都围绕同一套业务语言展开。

第九步：一起实现关键推理骨架，再前后端并行

讨论完不要立刻散开。高风险改动里，很多问题只有写到代码里才会暴露。所以团队最好一起用 AI 打出第一版关键推理骨架。

后端关键骨架包括：

ReasoningContract：是否深想、采用哪种拓扑、预算、验证器、停止条件。
StepDraft：LLM 只提出候选命题，不直接进入正式审计链。
ClaimStep：原子命题、类型、依赖、证据、验证器、状态。
EvidenceRef：证据引用、版本、有效期、hash、租户边界。
ValidatorRegistry：金额、政策、审批、权限、决策闸门。
ClaimTrace / ApplicationAuditTrace：任务、模式、步骤、最终决定、停止原因。
TraceRunner：执行结构化步骤、检查依赖、运行验证器、决定是否停止。
测试：证据缺失、政策冲突、审批不匹配、验证器失败、依赖未通过、推理漂移、人工升级。

前端关键骨架包括：

异常审核列表：显示 direct、cot、parallel、iterative 等审核路径。
trace detail 页面：展示 claim、evidence、validator、status、depends_on。
决策状态：自动放行、已拦截、待人工、证据缺失、验证失败。
风险提示：不要展示“模型认为合理”，而是展示“哪些命题已验证”。
操作入口：重新运行验证器、转人工、查看证据、导出审计报告。
contract mock 或 MSW mock，用后端推理契约驱动前端状态渲染测试。

这一步可以采用 mob + AI：一个人操作 AI 和编辑器，另一个人盯推理契约、命题原子性和证据链，另一个人盯前端状态表达和审核路径。AI 负责生成第一版代码、测试和迁移草案，但团队要不断打断它：不要新增无关抽象，不要让模型自评替代验证器，不要为了测试通过改变业务规则。

当推理骨架稳定后，就可以前后端并行：后端接具体验证器、证据源、trace 存储和升级任务；前端做 UI 细节、人工审核入口、审计导出、埋点和 E2E。并行的前提是契约稳定，而不是大家各自定义一套状态。

第十步：设置同步检查点

分开实现不是各写各的直到最后 PR。这个例子至少应该设置这些 checkpoint：

履约模型 checkpoint：请求入口、合同上下文、参与方、推理请求、推理确认和凭证是否清楚？
路由 checkpoint：小冰、咖哥、小雪、总账差异分别为什么走 direct、CoT、parallel、iterative？
证据 checkpoint：每个 ClaimStep 是否绑定 EvidenceRef？是否包含租户、版本、有效期和来源？
验证器 checkpoint：能确定性验证的部分是否都交给 validator？有没有让 LLM 自评放行？
依赖 checkpoint：上游命题失败时，下游结论是否自动失效？
前端 checkpoint：页面是否展示可验证命题，而不是展示模型散文式思维链？
升级 checkpoint：证据缺失、冲突、预算耗尽、验证失败时是否会中断并转人工？
证据 checkpoint：CI、contract test、E2E、trace、监控是否足够支撑合并？

这些 checkpoint 可以很短，但它们能防止团队在错误方向上并行太久。它们也是 AI 自愈的边界：编译错误、契约不匹配、测试失败可以让 AI 迭代修；推理模式、放行规则、升级退出和审计责任必须由人重新判断。

第十一步：上线运营也属于这次改动

高风险推理改动不能在“代码合并”处结束。上线和运营反馈会反过来影响实现方式。

这个例子上线前至少要准备：

Feature flag：先对内部租户、测试 payroll run、少量客户开放。
灰度策略：前端入口灰度和后端决策闸门灰度要一致，不能出现前端显示自动审核但后端没有审计轨迹的情况。
监控指标：验证通过率、首次路由命中率、单位验证成功成本、推理漂移率、人工升级率、平均审核延迟。
日志和 trace：一次审核从 anomaly id 到 route、ClaimStep、EvidenceRef、Validator、DecisionGate，必须能用 taskId 串起来。
告警：验证器异常、跨租户证据引用、依赖未通过仍然决策、人工升级积压、推理预算超限。
运营后台：薪酬专员能查询异常事实、证据、验证器结果、失败步骤、停止原因和人工审核记录。
回滚策略：可以关闭自动放行，可以强制所有高风险异常转人工，但不能删除已经产生的审计轨迹；对已进入流程的任务要有补偿脚本。

前端上线证据包括：直接回答、CoT、并行探索、迭代调查、证据缺失、验证失败、人工升级的状态截图。后端上线证据包括：schema migration、验证器测试、路由测试、依赖失效测试、审计轨迹查询、监控面板和回滚演练。

到这里，代码审查才真正完成。因为团队审查的不只是 diff，而是整条知识流：业务问题是否被正确理解，推理履约上下文是否被识别，命题和凭证是否可追溯，前后端实现是否共同消费同一套推理契约，上线后是否可观察、可解释、可恢复。

PR 在新流程里的作用

PR 不会消失，但它的角色会变化。

以前 PR 像是：“我写完了，你们来审。”

AI 原生流程里的 PR 更应该像是：“关键问题已经对齐，核心风险已经验证，这是变更摘要、证据和剩余风险。”

一个好的 AI 原生 PR 应该包含：

这次变更要解决什么问题
影响了哪些模块和接口
关键设计决策是什么
AI 参与生成了哪些部分
哪些测试已经运行
哪些风险仍然存在
如何回滚
reviewer 应该重点看什么

如果是前面的薪酬异常审核案例，PR 还应该按“领域系统 / 业务系统 / 协作边界”组织证据：

边界证据：这次改动哪些属于领域系统，哪些属于业务系统，哪些是二者之间的凭证适配。
业务履约证据：异常审核服务约定、主要履约项、权利方 / 义务方、推理模式规则、放行规则和升级规则。
领域系统证据：Payroll Snapshot schema、Policy Engine 测试、Approval Validator 测试、Delta Calculator 测试。
前端证据：异常列表、trace detail、证据缺失、验证失败、人工升级、自动放行的截图或 Storybook 链接。
契约证据：OpenAPI / schema / SDK diff、contract test、MSW mock 是否同步。
自愈证据：哪些失败由 AI 自愈修复，修复是否只发生在允许的边界内，有没有修改测试语义。
上线证据：feature flag、灰度范围、监控面板、trace 字段、告警和回滚脚本。

这会把 reviewer 从“大海捞针式看 diff”里解放出来，让他们集中判断真正重要的问题：这次变更是否真的维护了薪资准确性、审核责任、证据链和用户体验的一致性。

用 commit 历史表达审查路径

在 AI 原生流程里，PR 不应该只有一个巨大 commit。更好的做法是用多个 commit 表达一条可审查的知识流，让 reviewer 能沿着提交顺序理解：先划边界，再定契约，再实现领域系统能力，再实现业务履约流程，最后补证据和上线保护。

这不是为了保留所有试错过程。fix test、wip、try again 这类噪音应该在本地整理掉。最终 commit 历史应该表达思路，而不是暴露操作流水。

对前面的薪酬异常审核案例，一个合理的 commit 顺序可以是：

model payroll anomaly review fulfillment contract
add reasoning contract and routing schema
add claim step and evidence ref schema
implement payroll delta calculator adapter
implement policy and approval validators
add decision gate and escalation flow
persist application audit trace
render reasoning trace frontend states
add contract and trace runner tests
add rollout metrics and rollback notes

这里的 commit 不是按“前端 / 后端 / 测试”粗暴切分，而是按审查边界切分：

边界 commit：领域系统、业务系统和协作边界怎么划分。
契约 commit：推理请求、推理确认、凭证角色、API schema 怎么定义。
领域系统 commit：Delta Calculator、Policy Engine、Approval Validator 等稳定能力怎么实现。
业务系统 commit：异常审核、模式路由、放行、拦截和人工升级怎么流转。
前端状态 commit：页面如何表达推理履约状态，而不是展示模型散文式思维链。
证据 commit：测试、trace、监控、灰度和回滚方案。

这样做有三个好处。

第一，reviewer 可以按知识层次看 diff，而不是在一个大提交里同时处理建模、接口、页面、测试和上线策略。

第二，AI 的工作边界更清楚。每个 commit 可以对应一次明确任务，减少 Agent 顺手改无关文件、跨越领域 / 业务边界自作主张的概率。

第三，回滚和定位更容易。如果问题出在审批验证器适配，就不必回滚整个异常审核流程；如果问题出在业务放行规则，就能直接定位到推理契约或 Decision Gate commit。

所以，推荐多个 commit，但每个 commit 应该代表一个可理解、可验证的设计步骤。commit 历史本身就是 PR 证据的一部分。

团队可以直接采用的检查清单

写代码前

写代码时

AI 生成的代码是否符合既有架构？
是否出现了重复抽象、新框架或第二套 trace 模型？
前端是否只表达审计轨迹状态，而不是自行推断自动放行？
领域系统的不变量是否写进测试？
业务系统的推理契约、凭证链和升级退出是否写进测试？
权限、幂等、事务、审计、回滚是否被考虑？
AI 自愈是否只围绕明确失败信号进行？有没有跨越领域 / 业务边界？有没有修改测试语义？
是否保留了关键决策记录？

提交 PR 前

合并后

是否需要更新系统文档或轻量摘要？
是否需要团队共同阅读这次变更，确保大家理解新的推理契约、凭证链和权限边界？
是否有线上指标、日志和 trace 观察点？
是否需要通知运营、客服、审计或财务相关变化？
是否有后续重构、补偿脚本或清理任务？

最终原则

AI 原生团队里的代码审查，核心不再是“写完以后让别人挑错”，而是“在系统被塑造的过程中持续校准”。

低风险的地方，让个人和 AI 保持速度；高风险的地方，让团队同步判断；重复性的检查交给自动化；最终 PR 负责记录证据和确认风险。

更具体地说：领域系统里的局部实现错误，可以更多交给 AI 在测试和契约下自愈；业务系统里的推理履约规则变化，必须由人同步判断；领域系统和业务系统之间的凭证适配，则要重点审查依赖方向和事实来源。端到端自由发挥 Agent 可以用于探索，但不能作为企业主流程的交付形态。

如果用薪酬异常审核案例来总结：代码审查要覆盖的不只是“Agent 有没有想出答案、页面有没有显示 trace”，而是业务语言是否统一、领域 / 业务边界是否清楚、推理契约是否正确、命题和凭证是否可追溯、前后端契约是否稳定、AI 自愈是否越界、上线后是否可观察和可恢复。

代码审查不会死，死掉的是把 PR 队列当作主要协作方式的旧习惯。新的 code review 应该更早发生、更贴近设计、更依赖证据，也更重视团队对系统的共同理解。

以我所主，为我所用

Explorer

AI 原生团队如何重新设计代码审查

AI 原生团队如何重新设计代码审查

为什么异步 PR 审查在 AI 原生流程里会变低效

新目标：不是取消审查，而是把审查前移

风险分级决定协作强度

哪些部分可以让 AI 自愈迭代修复

反例：端到端自由发挥 Agent 会把审查变成看表演

AI 参与下的 pair / mob 角色

如何避免同步协作拖慢效率

高风险推理履约改动应该怎么做

第一步：先区分领域系统和业务系统

第二步：识别合同前上下文，也就是请求入口变化点

第三步：识别合同上下文和参与方

第四步：寻找主要履约项，而不是先写思维链

第五步：把 CoT 建模为可验证命题链

第六步：寻找违约和异常，并把异常变成新的履约项

第七步：通过凭证角色化发现变化点

第八步：把履约模型映射成前后端契约

第九步：一起实现关键推理骨架，再前后端并行

第十步：设置同步检查点

第十一步：上线运营也属于这次改动

PR 在新流程里的作用

用 commit 历史表达审查路径

团队可以直接采用的检查清单

写代码前

写代码时

提交 PR 前

合并后

最终原则

Graph View

Table of Contents