AI agent 不缺代码，它缺工程记忆
在 RAG 或 grep 之前，先给 agent 工程意图
AI 编程正在变快。
快到什么程度？
一个需求，几分钟出代码。 一个 bug，几轮对话就修。 一个重构，agent 可以通宵跑完。
但越用我越发现： AI agent 最大的问题，不是写不出代码。
它最大的问题是：
它不知道昨天为什么这么写。
它不知道哪个方案试过又放弃了。 它不知道哪个旧实现已经被替代了。 它不知道哪个兼容路径看起来丑，但不能删。 它不知道 reviewer 曾经明确说过：这里不能动。 它不知道队友正在推进一个相关方向。 它不知道代码背后的工程意图。
于是它会很自信地重复旧错误。
AI agent 会重复你昨天放弃的方案
这是最危险的地方。
不是它不会写。 是它太会写。
看到半成品，它会补完。 看到 TODO，它会推进。 看到 deprecated，它会删。 看到两个实现并存，它会两边都改。 看到历史包袱，它会“优化”掉。
从代码角度看，它很合理。
从工程历史角度看，它在犯错。
因为代码只告诉它：
现在是什么样。
但工程真正重要的是：
为什么是这样。
RAG 找代码，grep 找事实，但谁告诉 agent why？
现在 AI Coding 圈一直在讨论 RAG 和 grep。
RAG 派说：代码库太大，必须用索引和语义检索。 Grep 派说：复杂工程任务必须看当前文件系统，代码事实必须新鲜可靠。
我觉得两边都对。
但它们解决的是同一层问题：
agent 怎么找到代码上下文？
RAG 找相似代码。 Grep 验证当前代码。
但真实工程里，agent 缺的往往不是更多代码。
它缺的是：
工程意图。
为什么这段代码还在？ 为什么这个方案没继续？ 为什么这里不能删？ 为什么旧实现还要保留？ 为什么这个决定后来被替代？ 为什么这个文件看起来这么奇怪？
这些不是 code context。 这是 intent context。
下一代 AI 编程工具，不只需要 memory
它需要 intent memory。
不是保存一整段 session。 不是回放 agent 当时说了什么。 不是记录每一行代码是谁写的。 不是把所有 prompt 存成档案。
那些东西有用，但还不够。
因为未来 agent 真正需要的不是：
当时发生了什么？
而是：
未来我应该记住什么？
哪些决策仍然有效？ 哪些方案不要再走？ 哪些风险已经被接受？ 哪些约束不能破坏？ 哪些旧实现只是兼容残留？ 哪些工作正在进行中？
Session 是证据。 Intent 才是记忆。
我最近在做 Mainline
Mainline 是一个很早期的开源实验。
它想解决一个问题：
AI agent 在读代码之前，能不能先读工程意图？
一句话：
Mainline gives agents the why before the code.
中文：
Mainline 让 agent 在读代码前先理解历史意图。
它不是 RAG。 它不是 grep。 它不是 session recorder。 它不是管理者 dashboard。
它是一层 git-native 的 intent memory。
代码之前，先给 agent why。 diff 之前，先给 reviewer why。 下一次工作之前，先给团队历史 why。
这不是一个想法，产品已经基本做好了
Mainline 现在已经不是纯概念。
完整产品骨架已经基本做好了：
agent 开工前可以拿到相关历史意图。 reviewer 可以看到这次变更背后的 why。 Hub 可以把项目的 intent memory 变成人能读的视图。 历史里放弃过的方案、被替代的决策、不能破坏的约束，都可以重新浮出来。
但我现在不急着大规模发布。
因为这件事真正要验证的不是“功能能不能做”。 而是：
真实开发者和真实团队，会不会真的需要这层工程记忆？
所以现在不是 launch。 现在是找一小批认真使用 AI coding 的人一起试。
个人开发者需要它
如果你是个人开发者、indie hacker、OPC，你也会遇到这个问题。
今天用 Claude。 明天用 Cursor。 后天换 Codex。 一周后自己回来，已经忘了为什么这里不能删。
AI agent 很快。 但你的工程记忆会断。
Mainline 对个人来说，是：
给未来的自己和下一个 agent 留一份 why。
不是写日报。 不是写文档。 不是搞流程。
只是让下一个 agent 不要重走旧路。 让未来的你不用重新考古。
团队更需要它
团队的问题更严重。
AI 让写代码变快。 但 review 变慢了。
以前 reviewer 看 PR，还能问作者：
你为什么这么改？
现在很多时候，作者只是 agent operator。 diff 很大，过程很长，意图不清楚。
reviewer 只能猜。
这不是可持续的工程协作。
团队需要一层共享的 intent memory：
reviewer 看 diff 前先看 why。 agent 改代码前先看历史约束。 新人进项目先看决策脉络。 队友互相知道谁在推进什么 intent。 重要变更留下可追溯的工程判断。
AI 越快，团队越需要记忆。
我想抢一个词
叫：
intent memory
工程意图记忆。
RAG 解决的是：
哪些代码看起来相关？
Grep 解决的是：
当前代码到底是什么？
Session 解决的是：
当时 agent 做了什么？
Intent memory 解决的是：
未来 agent 应该记住什么？
我相信，这是 AI 编程进入真实工程后的下一层。
现在我想找一小批人一起试
Mainline 产品已经基本成型，但我不想现在就大规模公开推。 我想先找一小批真正有痛感的人。
如果你符合下面任一条，欢迎关注仓库并 Star：
- 已经重度使用 Cursor / Claude Code / Codex；
- 经常让 agent 改真实业务代码；
- 感觉 review AI 代码变累；
- 遇到过 agent 重复旧方案；
- 遇到过 agent 不理解历史决策；
- 想让未来的自己和下一个 agent 少踩坑；
- 愿意在真实 repo 上试一下。
关注仓库：https://github.com/mainline-org/mainline
我不会在这里暴露完整产品路线，只希望先验证这层需求。
最后
AI 编程会让代码生成越来越便宜。
但工程判断会越来越贵。
代码可以重新生成。 上下文可以重新检索。 session 可以回放。
但一个团队真正的工程意图，如果没有被记录，就会消失。
然后下一个 agent 会假装它从未存在过。
所以我现在最想验证的，就是这句话：
在 RAG 或 grep 之前，先给 agent 工程意图。
Mainline 想做的，就是这层 intent memory。