我做了个工具防止 AI agent 在不熟悉的代码里乱改 — 找几个内测

最近 dogfood 一个工具叫 mainline ，分享一下做这个的真实故事，顺便看 V2EX 上有没有人感兴趣内测。

起因

我在公司推团队用 AI 编程，作为 staff engineer 写过内部 guideline 。过程中发现一个反复出现的现象：

AI agent 写出的代码不是"明显错"——是"看起来合理，但基于错误的历史前提"。

具体例子：

repo 里有个半成品的 Redis 队列：redis.go 、TODO 注释、docker-compose 里也配了 redis 。Claude Code 看到这些，合理地想把这个实现完。

但实际情况——这个团队 3 周前已经放弃 Redis 了，因为 replication 延迟导致 billing 事件重复。这个决定散在某个 PR 评论里、Slack 几条消息、几个工程师脑子里。

代码搜索能看到 redis 文件——但看不到那个决定。

先尝试过现成方案

• AGENTS.md / CLAUDE.md 写 not-todo——能写"don't use redis"，但只解决你能预判到的。新决定一直在产生，没人持续维护。
• ADR / RFC——太重，团队不愿意写
• Wiki / Notion——和代码不同步，过半年 wiki 还说"我们用 Redis"
• PR description——埋在 GitHub 里，agent 不会主动去翻
• Agent harness 自带 memory （比如 jcode ）——work ，但 lock-in 到那个 harness

每个都在某些场景下 work——但都没解决"agent 改不熟悉的代码前能拿到团队的真实决策"这个问题。

做了什么

mainline 的 thesis：决策记忆应该是 git 一等公民。

具体设计：

1. 每个 dev 有自己的 actor log （ refs/heads/_mainline/actor/<id>），append-only 。Bob 、Alice 各自 push 自己的，不冲突。
2. Sealed intent 通过 git notes 关联 commit 。
3. SealResult 是结构化字段：what / why / decisions / rejected_alternatives / risks / architectural_claims 。
4. Agent 改代码前先 mainline context <keywords>——拿到结构化决策，不是一坨 free text 。
5. 跨人 in-flight 可见——Bob sealed 立刻 push ，Alice fetch 时看到，不等 PR review 才发现冲突。

设计上反直觉的几个选择

• 进程式 CLI ，不是 daemon 。Git AI 走 daemon 路线，撞了一堆 macOS sleep / zombie / socket 问题。Git protocol 已经 battle-tested ，不要发明轮子。
• Intent 级别，不是 line 级别。Line-level attribution 在 formatter / amend / git mv 下天然脆弱。Intent 是任务级别，文本变换不影响 semantic 。
• Push 模式（ agent 主动 seal ），不是 pull / 自动 capture 。自动 capture 听起来好，但产生大量 noise + 假记忆。显式 seal 有 friction ，但保证质量。
• Append-only ，sealed 后不能改——只能 supersede 。决策档案改了就失真，"当时怎么想"不可篡改才有价值。

现状

• v0.1 ship 了 12 个核心命令
• 我和一个朋友 dogfood 一个月
• 0 个外部用户，正在找深度内测
• Apache 2.0
• 网页：mainline.sh
• 代码： https://github.com/mainline-org/mainline

局限我也直接说

• 需要 agent 配合主动调用 mainline 。如果你团队没这个习惯，价值发挥不出来。
• 比 AGENTS.md 重——多了 seal 这一步。
• 比 jcode 这种 agent harness 内置 memory 的"自动"差，但换来的是数据在 git 、跨 agent 、可移植。
• 单人 + 好 git 习惯 + 写好 plan ，你不需要 mainline 。

适合谁试

• 5+ 人团队，多个 agent （ Claude Code / Cursor / Codex 都行）在同一 repo 工作
• 跨时间工作多——3 个月前的决定还在影响今天的 PR
• 已经被"agent 在不该改的地方乱改"坑过

找内测

如果上面场景命中你——欢迎私信或评论，我直接给你安装包 + 文档 + 每周一次 30 分钟同步。bug 我会优先 fix 。

也想听 V2EX 上的反馈——有没有更好的现有解决方案我没想到的？有没有觉得这个方向不对的？

不卖东西，纯粹想找几个深度用户 + 听不同视角。