Agentic SE Audit Checklist v1：把”完成”变成可审计的证据束

问题在哪里

AI 辅助开发团队普遍存在一个尴尬的现实：

演示很美，生产很乱。一个能跑通的概念验证，和一个能通过审计的生产系统，之间隔着一整个工程治理体系。

更麻烦的是”完成”这个词的歧义：

  • Vibe Coding 的”完成”：AI 说它做完了，屏幕上看起来是对的
  • Agentic Engineering 的”完成”：有迹可循、有据可查、有边界可审计

两种”完成”看起来一样，但监管机构查过来的时候，只有后者能过关。

Agentic SE Audit Checklist v1 就是针对这个鸿沟来的。

核心重构：什么是”完成”

传统软件工程的”完成”是二元判断：代码写完、测试过了、Review 批准了。

但 AI 介入后，这个判断变得模糊——AI 生成的代码，Reviewer 没看懂就过了怎么办？测试过了但覆盖的是错误行为怎么办？任务完成了但没有人能重建中间过程怎么办？

Checklist v1 的回答是：“完成”不是一个状态，是一个证据束。

一个任务只有当以下四个证据同时齐备时才算完成：

1. Spec Delta — 规格变更记录。不是最终规格，是相对起点的变化。记录这次做了什么、没做什么、为什么这样改。

2. Tool Trace — 工具调用轨迹。Agent 访问了哪些文件、调用了什么命令、看到了什么输出、做出了什么决策选择。全程可回放。

3. Test Proof — 测试证明。不是”测试过了”，而是哪些测试覆盖了什么，边界条件有没有被照顾到。

4. Human Sign-off — 人工确认。不是说有人看过，而是确认看过的人有权、看过的是什么、有明确记录。

这四样东西放在一起，才构成一个可审计的”完成”。缺任何一件，Checklist 的判断是：这件事还没完。

Vibe Coding vs Agentic Engineering：治理分离

Checklist 最有价值的地方可能不是那个四件套，而是明确把 Vibe Coding 和 Agentic Engineering 当作两种需要不同治理模型的东西分开处理。

Vibe Coding：快速探索、原型验证、个人开发者试错。没有问题，不需要治理，它的目的就是快和灵活。

Agentic Engineering：生产系统、可重复执行、需要对结果负责。必须有治理，而且治理必须在工具链层面嵌入，而不是事后补。

这种分离在现实中很少被明确说出来。多数团队是在 Vibe Coding 阶段开始，等到出了问题才意识到”怎么这个也在用生产账号跑”，或者”Agent 改的代码没有人能重建当时发生了什么”。

Checklist 的价值在于：它把这个问题提前到了决策点。不是问”出事了怎么办”，而是问”这个任务到底属于哪个治理域”。

为什么这个时间点出现

这不是巧合。2026 年多个监管节点同时逼近：

  • EU AI Act 高风险义务 2026 年 8 月正式执行，对自主 AI 系统的文档、审计轨迹、人工监督有明确要求
  • ISO/IEC 42001 AI 治理体系认证在企业中推进，审计轨迹是核心证据
  • 企业内部合规：越来越多的团队在监管压力下需要回答”AI 改的代码，谁负责”

这些压力汇到一起，Checklist v1 的出现时机就很清楚了：行业需要一个能把”AI 做了什么”说清楚的最小集，而不只是”我们用了 AI”。

我的判断

这个 Checklist v1 的贡献不是技术突破，而是概念澄清。

它把一个模糊的治理需求——”AI 生成的代码怎么管”——拆成了一个具体的四要素结构。任何团队拿着这个清单去对照，都能快速发现自己在哪个环节缺了证据。

值得关注的延伸问题：当这个清单成为事实标准之后，工具链会被倒逼着输出这些证据。Git 系统、CI 平台、Agent 框架都会开始内嵌 spec delta、tool trace、test proof 的记录能力。那才是这个 Checklist 真正的影响。

参考

  • Checklist：https://agentic-se.org/audit-checklist-v1