AI Coding Agent 可信交付：从生成代码到证据闭环
一、引言：当“能写”不等于“能信”
过去一年，AI 写代码的能力突飞猛进，但一个核心问题始终悬而未决：“能写”不等于“能信” 。多数编码 Agent 改完即交，对错仍需人逐行复核——这正是 AI 编码难以真正无人值守、规模化进入生产环境的关键障碍。
在高合规行业，这个问题被进一步放大。银河证券的实践表明，AI 生成的每一段代码都需按 Skills 库中定义的审查标准自动校验，全程可追溯、全部留痕。核心原则是：“AI 生成”不是免责理由，但“AI 生成、人工评审、全程记录”可以成为合规的开发方式。
更精准的表述来自 Proof-or-Stop 论文的开篇论断：“自报告不是证据” （A self-report is not evidence）。一个日志行说“所有测试通过”，并不等于这些测试与即将合并的代码对应。AI Coding Agent 的可信交付，本质上是把“声称改对了”转化为“能够自证改对了”。
本文将从五个环节展开：业务契约与迁移保护、受控代码改造、AI 驱动的验证闭环、可复核交付与证据归档、知识回流。
二、可信交付的业务基础——先明确迁移什么、保护什么
2.1 为什么“业务契约”必须先于代码
AI Coding Agent 最容易出错的环节，往往不是技术实现，而是对业务语义的理解偏差。
某头部券商的智能策略生成试点中发生过一个典型案例：Claude Code 基于 Prompt“对逾期客户自动触发额度冻结与展期评估”生成的 Python 代码，未校验展期操作与原授信客群的归属一致性，导致跨客群额度复用漏洞——该逻辑绕过监管沙盒三重校验，在 UAT 阶段才被人工审计捕获。
这个案例揭示了一个关键问题：自然语言 Prompt 中的业务术语，与代码中的技术实现之间存在巨大的语义鸿沟。Agent 不知道“逾期客户”在系统中的精确定义，不知道“展期评估”涉及哪些数据表和字段，更不知道“原授信客群”的归属校验逻辑应该如何实现。
2.2 历史业务语义的保护策略
在券商定制迁移场景中，保护历史业务语义需要三个层面的工作：
第一层：业务术语词典（Business Glossary） 。将 Prompt 中的自然语言术语映射到代码仓库中的具体实现。某头部券商的实践是通过构建“黑话词典”——将业务黑话与代码语义建立映射关系，配合三层语义对齐校验法，成功拦截了 P0 级逻辑漏洞。
第二层：历史单测基线（Test Baseline） 。存量代码的单测不仅是验证工具，更是业务语义的活文档。在 AI 改造之前，先建立历史单测基线——所有存量测试必须全部通过，才能证明 AI 的改动没有破坏既有业务语义。
第三层：契约冻结（Spec Freeze） 。Proof Loop 协议的核心原则是：在接受标准被冻结之前，不允许开始构建。任务开始前，所有验收标准必须被明确写成机器可检查的形式。
{
"id": "migrate-risk-control-module",
"business_context": "逾期客户展期评估需校验客群归属一致性",
"semantic_mapping": {
"逾期客户": "SELECT * FROM customers WHERE overdue_days > 0",
"展期评估": "sp_evaluate_extension(customer_id)",
"客群归属": "customer_group_id IN (SELECT id FROM groups WHERE type='approved')"
},
"test_baseline": "tests/risk_control/*.py 全部通过",
"allowed_paths": ["src/risk_control/", "tests/risk_control/"],
"forbidden_changes": ["修改公开函数签名", "删除历史字段"]
}
三、受控代码改造——让 Agent 知道如何改、何时停止
3.1 最小改动原则
Agent 驱动的代码改造最怕两件事：改得太多和改错地方。
“最小改动”原则要求 Agent 以最小的代码差异（minimal code delta）达成目标。具体而言：优先复用现有实现 → 标准库 → 已安装依赖 → 新代码，避免无关重构和未经授权的副作用。
在实践层面，可以通过以下机制实现受控改造：
- 路径白名单：在任务契约中明确允许修改的文件路径，差异中出现白名单之外的文件，流水线直接失败并要求人工介入
- AST 验证：通过抽象语法树校验确保改动不破坏代码结构
- 隔离工作区：每次任务使用独立分支或 Git worktree，避免污染主工作区
3.2 分层约束与“何时停止”
AI 改造不能无限迭代。受控改造需要明确的停止条件：
第一层：静态约束。类型检查、格式检查、Lint 检查必须全部通过。不通过则打回重改，但不允许无限循环——设置最大重试次数（如 3 次）。
第二层：动态验证。单元测试、集成测试必须全部通过。OpenSquilla 的做法是“红绿回归证据链”：先写一个注定失败的测试给问题定性、证明它真能抓住 bug，再把功能做好让测试由红转绿，最后跑一遍项目原有测试确认没弄坏别处。
第三层：人工闸门。对于高风险改动，设置人工确认节点。Proof-or-Stop 的研究表明，强制将审查信号作为生命周期门禁（而非仅仅是添加一个审查者），能够显著降低“可见通过、隐藏失败”的风险。
3.3 最小改造示例
假设需要迁移一个风险控制模块，Agent 的输出应该是最小差异的补丁，而非全量重写：
# 改动前后对比（最小差异）
- def check_risk(customer_id):
- # 旧实现：直接查数据库
- return db.query("SELECT risk_score FROM customers WHERE id = ?", customer_id)
+ def check_risk(customer_id):
+ # 新实现：调用统一风险服务（复用现有 client）
+ from src.services.risk_client import get_risk_score
+ return get_risk_score(customer_id)
注意：只改必要的 3 行，不动其他任何东西。
四、AI 驱动的验证闭环——从历史单测到 L1—L5 证据
4.1 验证不是写完代码之后才开始
很多团队做 AI Coding 到一定阶段后都会遇到相似的问题：代码确实生成出来了，PR 也能被采纳，局部功能看起来也跑通了——但到了真正准备 Review、提测、验收、发布时，问题才开始集中暴露。
核心原因是：如果我们只把验证理解成“代码生成之后再做 build、lint、单测、E2E”，其实已经晚了一步。在真实的端到端自动化链路里，很多问题并不是发生在代码实现阶段，而是更早就已经埋下了。
验证需要被拆成一套分层系统：
- 输入层：验证任务是否可执行、需求是否被稳定表达
- 执行层：验证 Agent 是否完成了目标变更、代码能否进入工程体系
- 验收层：验证交互、回归风险与人工验收点
4.2 验证闭环的五层机制
阿里云提出的“生成与裁决分离”范式，通过五层机制构建可审计、可复现、可回滚的智能编程流水线：
| 层级 | 机制 | 核心作用 |
|---|---|---|
| 任务契约 | 定义允许路径、行为约束和验证命令 | 把开放式生成转成封闭式验收 |
| 隔离工作区 | 独立分支或 Git worktree | 避免污染主工作区 |
| 受限执行 | 超时、权限和环境变量白名单 | 防止越权操作 |
| 确定性门禁 | 单元测试、类型检查、格式检查 | 程序化判断，不依赖主观 |
| 证据归档 | 保存提交差异、命令退出码和日志 | 可审计、可复现 |
这里最关键的区别是 “生成”和“裁决”分离：智能体负责生成候选变更，验收器负责裁决。凡是能写成程序断言的要求，都应由程序完成判断。
4.3 L1—L5 证据分级
工业界已形成生成式测试的可信度分级框架（L1–L5），这是判断 AI 生成代码“可信到什么程度”的标尺：
| 证据等级 | 验证方式 | 自动化程度 | 通过率参考 |
|---|---|---|---|
| L1 | 语法正确性（AST 校验） | 全自动 | ~98% |
| L2 | 编译通过 + 类型检查 | 全自动 | ~73% |
| L3 | 通过存量测试（历史单测基线） | 全自动 | ~51% |
| L4 | 变异测试存活（新生成的测试覆盖） | 半自动 | ~29% |
| L5 | 人工等价类验证 + 业务语义确认 | 人工 | <7% |
实践建议：
- L1–L3 可全自动门禁：语法检查 → 编译检查 → 存量测试通过，三级全过才能进入下一步
- L4 作为增强验证：自动生成变异测试，验证新代码的测试充分性
- L5 作为人工闸门：高风险场景必须有人工等价类验证，确认业务语义未被破坏
银河证券的实践与此高度吻合：AI 生成的每一段代码都按 Skills 库中定义的审查标准自动校验（L1–L3），再辅以人工评审（L5），全程可追溯、全部留痕。
4.4 双轨验证：新旧并存的安全网
在存量系统改造中，双轨验证是确保安全的关键策略：
- 旧轨（基线轨） ：历史单测全部通过——证明没有破坏既有功能
- 新轨（增量轨） ：新增测试覆盖新功能——证明新需求被正确实现
美团在 AI Coding 实践中的经验是：构建单测安全网应对存量代码的信任问题。只有当新旧两轨全部通过，才能进入下一阶段。
五、可复核交付与知识回流——让结论可以被别人接受
5.1 证据归档：交付包的可审计性
AI 交付不能止于“代码合进去了”。一个完整的交付包应该包含：
- 提交差异（Diff） ：Agent 到底改了哪些文件、哪些行
- 验证证据（Evidence） ：L1–L5 每一级的验证结果和日志
- 命令退出码和日志：每一次构建、测试的执行记录
- 验收裁决（Verdict） ：每个验收标准是否获得 PASS 结论
Proof Loop 协议的做法是：在仓库中记录持久的证明工件（durable proof artifacts），未来的任何会话都能查看当时到底测试了什么。
招商证券国际的 AI 原生投研系统更进一步：“机器闸不讲情面，证据不带数字即打回；失败归档” ——没有证据的交付，系统根本不接收。
5.2 知识回流：从一次交付到组织能力
每一次 AI 交付都是一次知识沉淀的机会：
失败模式归档：Agent 为什么失败？是语义理解偏差、测试覆盖不足还是环境问题？Proof-or-Stop 的自我应用语料库记录了 565 个故事 / 1007 条审查发现，94.8% 已解决。这些失败模式可以反哺 Skills 库和提示词工程。
验收标准模板化：成功的验收标准可以沉淀为模板，供后续任务复用。从“每次重新写验收标准”到“从模板库中选择并微调”。
业务语义持续积累：每一次迁移都在丰富业务术语词典——AI 对“逾期客户”“展期评估”这些术语的理解越来越精确。
六、总结：可信交付的完整链路
从生成代码到可信交付，AI Coding Agent 需要走过一条完整的证据闭环：
任务契约（Spec Freeze）
↓
隔离改造（最小改动）
↓
L1 语法验证（AST）
↓
L2 编译 + 类型检查
↓
L3 历史单测基线（双轨验证）
↓
L4 变异测试（可选增强）
↓
L5 人工等价类验证（高风险场景）
↓
证据归档 + 交付
↓
知识回流（失败模式 + 语义积累）
这条链路的每一个环节，都在回答同一个问题：“你有什么证据证明你改对了？”
正如 Proof-or-Stop 的标题所言：“不要相信 Agent，相信证据循环工程” （Don‘t Trust the Agent, Trust the Evidence Loop Engineering）。Agent 的输出可以提出生命周期声明（claims），但声明本身并不构成生命周期状态——只有经过门禁验证的证据，才能推动状态向前流转。
在高合规的券商行业，这条链路不是可选项，而是必选项。“AI 生成”从来不是免责理由，但“AI 生成、自动验证、人工评审、全程记录”可以成为合规的开发方式。
扫一扫
291
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
