AI 搜索后,我做了一个 AI 时代的 git —— 意图协作

AI 搜索后，我做了一个 AI 时代的 git

先讲一件让我当场懵逼的事。

某天下午，我用 Claude Code 重构了一段业务逻辑。agent 写得飞快，diff 很干净，逻辑无懈可击。我扫了一遍，approve，合进去。

第二天，老队友走过来：

“你为什么又走这个方案？”

“这条路三个月前试过，有个边界 case 会在生产炸，当时讨论了半天，专门决定放弃的。”

我沉默了五秒。

不是我忘了——是 agent 从头到尾不知道三个月前发生过什么。

---

说一个 AI 编程圈没人正面讲的问题

现在 AI coding 工具确实强。强到什么程度？

需求扔进去，几分钟出代码。bug 报上来，几轮对话搞定。重构这种活，agent 可以通宵不睡给你跑完。

效率拉满，没有问题。

但有一件事越来越让我觉得不对劲——

agent 太会写了。

看到 TODO，它推进。看到半成品，它补完。看到两个并存的实现，它两边都改。看到历史包袱，它”顺手优化”掉。

从代码逻辑的角度，它每一步都合理。

从工程历史的角度，它在不停地犯错。

原因很简单：代码只告诉它现在是什么样，但工程真正重要的，是为什么是这样。

这句话，值得反复想一遍。

---

RAG 也好，grep 也好，都没解决这个问题

AI coding 圈最近有个经典争论：到底该用 RAG 还是 grep？

RAG 派说：代码库这么大，不做语义索引根本找不到相关上下文。

Grep 派说：复杂工程任务必须看真实文件，RAG 召回的东西可能早就过期了。

两边我都认同。

但他们争的，其实是同一层问题：agent 怎么找到代码上下文？

RAG 找相似代码，grep 验证当前代码。

但你想没想过——agent 缺的，可能根本不是更多的代码？

它真正缺的是：

为什么这段代码还活着？为什么那个方案当初没继续推？为什么这里看起来很奇怪但就是不能动？为什么旧实现和新实现要并存？为什么 reviewer 上次明确说，这里不许改？

这些问题，RAG 找不到答案。Grep 也找不到。

因为答案根本不在代码里。

它在某次早已结束的技术讨论里，在某个没人写进 commit message 的判断里，在某个只存在于老员工脑子里的历史决策里。

---

我要定义一个词：intent memory

把几件事排清楚：

RAG → 哪些代码看起来跟当前任务相关？

Grep → 当前代码到底长什么样？

Session → 这次 agent 都干了些什么？

Intent memory → 下一个 agent 应该记住什么？

前三件事，记录的都是”发生了什么”。

Intent memory 要记录的，是判断本身：

哪些决策今天还有效？哪些方案永远不要再走？哪些约束不能破坏？哪些历史包袱只是兼容残留，不是真实设计意图？

Session 是证据，intent 才是记忆。

这两件事，差的不是一点点。

---

所以我做了 Mainline

一句话：让 agent 在读代码之前，先读工程意图。

英文是：Mainline gives agents the why before the code.

它不是 RAG，不是 grep，不是 session recorder，不是什么项目管理看板。

它是一层 git-native 的 intent memory。

agent 开工前，先拿到相关历史约束。reviewer 看 diff 前，先看这次改动背后的 why。新人进项目，先看决策脉络，而不是直接扔进代码库里自生自灭。

历史里放弃过的方案、被替代的决策、不能破坏的约束——全部可以重新浮出来，而不是永远沉在某个没人翻的飞书文档里。

---

你觉得这只是团队问题？不是

独立开发者、indie hacker，一样跑不掉。

今天用 Claude Code，明天换 Cursor，后天上 Codex，一周后自己回来看代码——不记得为什么这里不能删了。

AI 很快，但你的工程记忆会断。

断了之后，下一个 agent 来，会用它觉得最合理的方式把那里改掉。然后你花两小时 debug，发现是三个月前踩过的坑。

Mainline 对个人来说就一件事：给未来的自己和下一个 agent，留一份 why。不是写日报，不是搞文档流程，就是让下一个 agent 不要重走旧路。

---

团队的问题，其实更严重

AI 让写代码变快了。

但 review，变慢了。

以前 reviewer 看 PR，还能拍一下作者肩膀问：你为什么这么改？

现在很多 PR，作者自己都说不清楚。因为他只是个 agent operator，diff 是 agent 吐的，过程是 agent 跑的，他也没有全程跟下来。

Reviewer 只能对着几百行 diff 自己猜意图。

这不是可持续的工程协作方式。

代码生产在加速，但工程判断的传递断掉了。

团队需要一层共享的 intent memory：agent 改代码前先看历史约束，reviewer 看 diff 前先看 why，新人入项目先看决策脉络，队友之间知道谁在推进什么方向，重要变更留下可追溯的工程判断。

AI 越快，团队越需要记忆——这件事，我越来越确信。

---

git 解决了版本，但没有解决意图

git 是伟大的发明，没有之一。

它记录了代码变成什么样、谁改的、什么时候改的。

但它记不住：为什么这么决定。

过去没关系。人写代码，人有上下文，人可以问，人有记忆。

但现在，写代码的越来越多是 agent。

Agent 没有记忆，没有历史感，没有”上次讨论过”的概念。它只有当下的代码，和你给它的这一次 prompt。

所以我们需要一层新东西——不是更好的 git，不是更大的 context window，是一层工程意图的记忆层。

在 RAG 之前，在 grep 之前，在 agent 动手之前，先给它 why。

---

代码可以重新生成。上下文可以重新检索。session 可以回放。

但一个团队真正的工程意图，如果没有被记录，它就消失了。

然后下一个 agent 来了，假装它从未存在过。

然后你又 debug 两小时。

然后又 debug 两小时。

然后又 debug 两小时。

---

Mainline 现在是个很早期的开源实验。我不想马上大规模发布，想先找一小批真正有痛感的人一起验证。

如果你符合下面任意一条，欢迎来看：

•重度使用 Cursor / Claude Code / Codex•经常让 agent 改真实业务代码•感觉 review AI 代码越来越累•遇到过 agent 重复旧方案、不理解历史决策•想让未来的自己和下一个 agent 少踩坑

👉 

https://github.com/mainline-org/mainline[1]

先 star，加群聊

References

[1]: https://github.com/mainline-org/mainline-intro