最近 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 一等公民。
具体设计:
- 每个 dev 有自己的 actor log ( refs/heads/_mainline/actor/<id>),append-only 。Bob 、Alice 各自 push 自己的,不冲突。
- Sealed intent 通过 git notes 关联 commit 。
- SealResult 是结构化字段:what / why / decisions / rejected_alternatives / risks / architectural_claims 。
- Agent 改代码前先 mainline context <keywords>——拿到结构化决策,不是一坨 free text 。
- 跨人 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 。决策档案改了就失真,"当时怎么想"不可篡改才有价值。
现状
局限我也直接说
- 需要 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 上的反馈——有没有更好的现有解决方案我没想到的?有没有觉得这个方向不对的?
不卖东西,纯粹想找几个深度用户 + 听不同视角。