代码不是 AI 编程的最终资产，AI Coding 真正该存的是 Checkpoint

AI Coding 让代码生成变得廉价，但也让软件工程暴露出新的断层：Git 记录了 diff，却没有记录生成 diff 的意图、上下文、工具调用和失败路径。真正的价值在于把 Agent session 以 Checkpoint 形式和 commit 绑定，让 review、交接、追溯和二次开发不再只面对最终代码。

导语

Agent 时代有一个反直觉变化：代码越来越便宜，理解代码却越来越贵。

以前一次 commit 大致能代表一次开发工作。人读需求、改代码、跑测试、提交 PR。reviewer 看 diff，基本能还原这次变更的主要逻辑。

AI Coding 把这个前提打碎了。

一个人可以同时开多个 Agent，一个 Agent 也可能继续调别的 Agent。代码生成速度上去了，同一个需求甚至会在短时间里出现多个实现版本。最终留下来的还是 diff，但 diff 背后的东西丢了：最初的 prompt 是什么，Agent 看了哪些文件，试过哪些方案，哪些测试失败过，为什么最后选了这个方向。

当代码只是副产品，真正的工程资产就变成了生成这段代码的上下文 。

图：代码之外，真正需要被保存的是生成代码的上下文

Git 只回答改了什么，不回答为什么

过去的软件基础设施，几乎都围绕代码产物建设：

repo 管代码状态
PR 管审查流程
CI 管构建和测试
CD 管发布和回滚

这些基础设施对人类开发者很有效，因为人的思考过程大多留在会议、评论、文档和经验里。diff 已经足够代表大部分工作。

但 Agent 写代码时，过程本身变得更重要。

如果只记录最终 diff，后续会遇到几个问题：

场景	只看 diff 的问题	需要补上的信息
Code Review	看得到代码改动，看不到原始意图和约束	prompt、任务目标、Agent 推理路径
交接	新会话不知道前一个 Agent 试过什么	session 摘要、失败尝试、下一步
回归排查	git blame 只能找到 commit	当时为什么这样改、哪些测试支撑它
二次开发	Agent 可能重复旧错误	历史反馈、被否决方案、review 意见

AI 生成代码越多，这个问题越严重。因为 reviewer 审的不是"哪一行是不是 AI 写的"，而是"这次变更是否符合原始意图，以及 Agent 有没有走错路"。

行级归因不够，意图归档更关键

社区已经意识到 AI 代码需要新的归属协议。Agent Trace 这类规范尝试在文件或行粒度标注代码来自 human、ai、mixed 还是 unknown。

这个方向有意义。它让团队知道哪些代码由 AI 参与生成，也能为审计和统计提供基础。

但行级归因解决的是 attribution，也就是谁写了哪行代码。它没有解决更关键的问题：为什么这样写。

对于 Agent-first 的软件工程，知道"这行来自 Claude"并不够。另一个 Agent 接手时，它真正需要的是：

当时的任务目标是什么
哪些上下文被读过
哪些方案被尝试过
哪些测试失败过
reviewer 提过什么约束
最终实现为什么被接受

这不是给代码贴身份证，而是给一次变更保留开发记忆。

抽象：把 session 变成 Checkpoint

我们要补的，就是 Git 缺失的那一层。

它不是新的 AI 编码工具，也不是替代 Claude Code、Cursor、Codex 或 OpenCode。它更像一个 Git 感知的记录系统：当 Agent 辅助完成一次变更并提交 commit 时，应该把本次会话上下文归档成 Checkpoint，并和 commit 绑定起来。

一个 Checkpoint 可以包含：

复制代码

Checkpoint
├── user prompt / task instruction
├── agent transcript
├── tool calls
├── files read / files modified
├── command execution
├── token usage
├── diff summary
├── test and error signals
└── linked commit

这里的关键不是复制 Git。

Git 记录代码状态，Checkpoint 记录代码状态背后的生成过程。

为什么要和 commit 绑定

Agent session 如果只存在聊天工具里，很快会散掉。换设备、换 IDE、换模型、换人接手，历史上下文就断了。

和 commit 绑定后，软件工程的基本追溯链路就能继续成立：

图：Agent Session 被采集为 Checkpoint，并绑定到 Git Commit

这样做有三个好处。

第一，review 不再只看结果。reviewer 可以看到 Agent 当时的任务理解、读取范围、工具调用和失败路径，判断它是不是在正确约束下完成的。

第二，交接不再靠复述。一个 Agent 干到一半，另一个 Agent 可以读取历史 session，知道已经试过什么、卡在哪里、下一步该做什么。

第三，知识能沉淀。团队反复处理过的失败、修复、review 意见和工程习惯，可以反过来提炼成 skill、checker 或工作流 。

图：Checkpoint 让 review、交接和知识复用回到同一条链路

低侵入是基础，不然一定会被绕开

这类系统要成立，前提是不能改变开发者已有习惯。

开发者不应该为了记录 Agent 历史，再去打开一个新平台、手动填写一次任务说明、手动上传一次日志。AI Coding 工具已经足够多了，任何额外流程都会被绕开。

更好的形态是 CLI-first、local-first、Git-first。

设计原则	含义	价值
CLI-first	通过 CLI、git hooks、agent hooks 静默工作	不重造 IDE，不打断开发流程
Local-first	采集和检索优先在本地完成	可离线、低侵入、便于审计
Git as database	Checkpoint 作为 Git 可版本化对象保存	数据跟随 repo 和 branch 流动

这也是这类系统最有意思的地方：它不是在软件工程之外另建一个"AI 历史库"，而是把 Agent 产生的上下文放回 Git 这条主链路里。

成本问题反而没那么大

很多人第一反应会担心存储成本。Agent transcript 这么多，每次 commit 都记录，会不会很贵？

如果采用 Git object 存储，成本其实比直觉低。

一次中等复杂度的 session 可能有几十轮对话，原始文本几百 KB。Git 对文本压缩效果很好，写入 object 后可能只有几十到一百多 KB。

哪怕一个 50 人团队每天产生 250 个 checkpoint，按每个 100KB 估算，一天约 25MB，一个月不到 1GB。相比研发资产本身，这个成本不算高。

真正需要治理的不是存储，而是隐私、权限、保留周期和可检索性 。

图：上下文归档应尽量贴近本地工作流和 Git 主链路

Agent 也应该读取这些历史

不只服务人类。

当历史 session 足够多，新的 Agent 可以从中学习团队的工作方式。它不需要猜某个模块为什么这样写，也不需要重复过去已经失败的路线。

典型能力可以分成几类：

能力	回答的问题
search	团队过去做过哪些相关工作
explain	某个函数或 commit 当时为什么这样写
what-happened	某次回归和哪段历史上下文有关
session-handoff	一个 Agent 如何把任务交给另一个 Agent
session-to-skill	如何把反复出现的会话提炼成可复用工作流
review	审查当前分支时同时理解历史意图

这会改变 Agent 的默认行为。

过去是先搜代码，再猜历史意图，再修改。更好的路径是先回忆团队历史，再搜代码，最后动手改。

这不是让 Agent 更啰嗦，而是避免它重复踩同一个坑。

结语

AI Coding 的下一阶段，不只是生成更多代码。

代码产出变快后，工程系统最缺的是解释、追溯、交接和复用。Git 能告诉我们改了什么，但 Agent 时代还需要知道为什么这样改、基于什么上下文改、哪些路被试过又放弃了。

这类基础设施的价值，就在于把一次 Agent 编程过程从临时对话变成可查询、可审查、可继承的工程资产。

当这个资产沉淀下来，AI Coding 才不会只是多写几行代码。它会开始改变软件团队记忆和协作的方式。