Docket：为AI智能体编写的代码建立逐提交证据记录

AI写的代码，谁来审计？

随着AI编程智能体（coding agent）越来越多地参与到实际的代码生产中，一个现实问题浮出水面：当一段代码由AI而非人类工程师编写时，我们如何知道它是怎么产生的、经过了哪些验证、是否可信？Docket 正是针对这一痛点提出的工具——为AI智能体编写的代码建立逐提交（per-commit）的证据记录。

在传统的软件开发流程中，代码评审、CI 测试和人工把关构成了质量保障的核心链条。但当智能体自动生成大量提交时，人类审阅者往往难以逐一核实每次变更背后的推理过程和验证依据。Docket 试图把这个「黑箱」变成「可追溯的记录」，让每一次提交都附带可核查的证据。

什么是「逐提交证据记录」

Docket 的核心理念是：为智能体产生的每一个 commit 生成一份对应的证据文档。这份记录可以包含代码变更的意图、所依据的上下文、运行过程中执行的测试与检查、以及验证结果等信息。

这种做法本质上是把「AI 做了什么、为什么这么做、结果如何」固化下来，与 Git 的提交历史绑定。这样一来，团队在回溯问题时，不仅能看到「改了什么」，还能看到「为什么这样改」以及「改动是否被验证过」。

对于越来越依赖 AI 智能体交付代码的工程团队而言，这类证据记录有几方面价值：

• 可审计性：满足合规、安全审查等场景对可追溯性的要求。
• 可信度：让人类工程师在合并 AI 生成代码前有据可依。
• 调试友好：当出现回归或缺陷时，可以快速定位到具体提交及其上下文。

Git 的提交历史（commit history）本身已记录了代码差异（diff）和提交信息（commit message），但这些信息通常由作者自行填写，质量参差不齐，且不包含机器可验证的证明材料。Docket 的思路类似于软件供应链安全领域的 SBOM（软件物料清单）或 SLSA（软件制品的供应链级别）框架：后两者试图回答「这个二进制文件是从哪里构建的、依赖了什么」，而 Docket 则试图回答「这个提交是由哪个智能体在什么上下文下生成的、经过了哪些验证步骤」。将证据与 Git 对象绑定，使得审计可以随版本历史一起流转，而不是散落在聊天记录或日志文件中。

为什么这类工具正在兴起

AI 编程助手的能力提升带来了一个副作用：代码的「作者」身份变得模糊，责任归属和质量把关的难度也随之上升。当智能体能够自主完成从需求理解到代码提交的完整链路时，传统的信任机制不再够用。

Docket 所代表的方向，是在 AI 与人类协作的开发流程中补上「信任与证据」这一环。它并不试图替代 CI/CD 或代码评审，而是作为一层附加的记录机制，让 AI 参与的开发过程更透明。

从更宏观的视角看，这类工具属于「AI 治理」在软件工程领域的具体落地。随着企业加速采用 AI 编程，如何在提升效率的同时保证代码质量、安全与合规，将成为工程管理的新命题。逐提交证据记录，正是应对这一命题的一种务实尝试。

CI/CD（持续集成/持续交付）是现代软件工程的自动化质量门禁：代码提交后，流水线会自动运行测试、静态分析和构建校验，通过后才允许合并或部署。然而 CI/CD 本质上只检验代码的「结果是否正确」，并不记录「决策是如何形成的」。当 AI 智能体每天可以产生数十乃至数百个提交时，即便所有测试都通过，工程师仍然面临一个盲区：这段代码是基于怎样的上下文推理出来的？有没有被刻意规避某些检查？智能体是否理解了需求的真实意图？Docket 针对的正是 CI/CD 覆盖不到的这一层——它不取代测试，而是为测试结果补上「为什么运行这些测试、结果意味着什么」的叙述性证据。

目前的局限与观望

需要客观指出的是，Docket 目前在 Hacker News 上的讨论热度较低（8 points、1 条评论），公开信息也相对有限。这意味着它仍处于早期阶段，其实际效果、集成成本以及在真实团队中的采纳情况都有待进一步验证。

对于关注 AI 编程工具链的开发者来说，Docket 提供的思路值得留意：当代码越来越多地由机器编写，我们需要相应的机制来记录和验证机器的工作。这类「为 AI 代码做审计」的工具，很可能会随着智能体编程的普及而成为标准配置的一部分。