每个 AI 编程智能体（agent）都能吐出一个 diff。真正的问题在于，你无法判断这个 diff 是来自于一个专注、深思熟虑的过程，还是来自于一次在代码库中疯狂扫荡后偶然撞上了正确答案。目前，大多数团队都无法区分这两者。

这不是技术限制，而是一个可见性问题。

当一个智能体编写三行生产代码时，它可能只读取了三个文件并运行了测试。但也可能触碰了四十个无关的文件，执行了十几次失败的命令，因为依赖安装失败而跳过了你的测试套件，并为此向你收费。无论哪种情况，diff 看起来都是一样的。如果没有过程记录，你只能对最终结果的质量进行猜测。

为什么聊天日志不是“收据”

许多工具提供聊天记录作为工作证明。但聊天记录不是“收据”。它就像一盒散落在你桌上的零件。它包含了每一次思维循环、每一次失败的尝试、每一个系统提示词以及每一次无关紧要的工具调用。如果你需要阅读上千行的对话来验证一个三行的补丁，那么你的评审工作流已经崩溃了。

人类的注意力是有限的。智能体的意义在于节省认知成本，而不是制造作业。聊天记录要求评审者变成侦探，而收据则能让他们一目了然地得到答案。

一个有用的收据是一个实用的总结。它会告诉你智能体被要求做什么、它实际做了什么，以及它是如何得出结论的。它不会掩盖失败，而是会将其凸显出来。

一个好的收据应该是什么样的

一个可评审的收据应该能在无需深挖的情况下回答特定问题：

  • 任务是什么？ 对预期变更的清晰描述，而不是模糊的提示词复读。
  • 读取了哪些文件？ 这样你才能判断智能体是否从正确的来源构建了上下文。
  • 编辑了哪些文件？ 变更的最终足迹。
  • 运行了哪些命令？ 智能体调用的构建步骤、linter、格式化工具或自定义脚本。
  • 哪些命令失败了？ 不仅仅是成功的命令。失败的地方揭示了智能体在哪里不得不临时变通，或者在哪里选择了放弃。
  • 哪些测试通过了或被跳过了？ 跳过的测试是一个危险信号。收据应该说明它们被跳过的原因。
  • 总成本是多少？ Token、API 调用和计算时间。这包括了你架构的成本，而不仅仅是模型的成本。

这种格式将评审从一场“考古挖掘”转变为快速的“合理性检查”。资深工程师应该能够在不到一分钟的时间内扫视收据，并得出“这很合理”或“这看起来很可疑”的结论。

阅读足迹，而不只是历史

智能体运行的足迹展示了工作的形态。智能体是否保持在任务的范围内？还是它漫游到了无关的模块，并更改了没人要求改动的地方？如果收据将“编辑的文件”与“读取的文件”并列列出，这一点就会变得显而易见。

足迹还能揭示重复行为。如果一个智能体不断撞向同一个死胡同——比如三次读取同一个配置文件，或者一遍又一遍地运行失败的测试——那么它就是在浪费计算资源和上下文窗口。这种模式应该是可见的。如果一个智能体尝试了九次才运行完迁移脚本，收据应该如实记录。这些信息会改变你评估输出结果的方式。通过“暴力混乱”产生的“正确”diff，与通过“干净利落”的过程产生的“正确”diff 是完全不同的。

设计不当的隐藏成本

成本不仅仅是每个 token 的价格。设计糟糕的工作流会让智能体在生成任何字符之前就变得昂贵。臃肿的工具 schema、不必要的文件索引以及过于宽泛的系统提示词都会膨胀上下文窗口。收据应该揭示这些额外开销。

如果生成变得更便宜了，但评审变得更难了，那你其实一无所获。你只是转移了瓶颈。工程师的时间通常是团队中最稀缺的资源。如果为了节省 5 美元的 API 成本，却为每个 pull request 增加了 30 分钟的评审时间，那这笔交易非常糟糕。收据能帮助你直接审计这种权衡。

诚实是一种特性

一个有用的收据在必要时应该是令人“不适”的。它应该报告那些让智能体显得低效的事实，因为这种诚实能让下一次人类决策变得更快、更好。

例子很重要：

  • "Read 37 files for a one-line change."
  • "Skipped tests because npm install failed with a peer dependency conflict."
  • "Edited utils.py outside the requested scope to fix an import the agent introduced."
  • "Ran the linter 4 times; first three failed due to path misconfiguration."

These are not bugs in the receipt. They are signals. They tell the reviewer where to focus skepticism. They also tell the platform team where the workflow itself needs tightening.

Smaller Runs, Clearer Oversight

There is a natural temptation to let agents run wild across large surfaces. One giant prompt to refactor an entire service feels fast. It is not. It creates an unreviewable lump of work. Your afternoon disappears into tracing which of eighty changed files were intentional.

Small, inspectable runs are better. Define clear boundaries for the task. Separate the list of files the agent may read from the list it may write. Capture a history of failed commands so the dead ends are visible. Flag skipped verifications explicitly. Note every external tool use, from search APIs to test runners.

The goal is not total autonomy. Total autonomy that no human can verify is just automation with liability. The real goal is reviewability. Every agent output should be easy to approve or easy to reject. There should be no ambiguous middle ground where you accept code because you are too tired to investigate.

The Test for Any Coding Agent

Before adopting any agent or platform, ask one question: Can it leave enough evidence for a human to approve the next step confidently?

If the answer is yes, the tool fits into a professional workflow. If the answer is no, you are not buying productivity. You are buying a mystery that occasionally compiles. That is fine for a weekend side project. It is unacceptable for production engineering.

Teams that treat agent outputs as unexamined gifts will eventually ship a subtle bug introduced by an undetected scope creep. The diff will look innocent. The receipt would have told the truth.

Require receipts. Design for review. Trust is not a strategy. Evidence is.

For more hands-on discussions around AI tooling and developer workflows, you can join the community at GyaanSetu on Telegram.