#V2EX

原始 JSON

{
  "kind": 1,
  "id": "28d0b54ad02b5d3970661d8546cd8d5be610e83889dd43bb54d78f89cb7bdebf",
  "pubkey": "2d0154e14033e848b448a971322bfbf4e04a29c377012ee0f5ab66099b56f1ad",
  "created_at": 1778037518,
  "tags": [
    [
      "t",
      "v2ex"
    ]
  ],
  "content": "#V2EX\n### [程序员] 我做了个工具防止 AI agent 在不熟悉的代码里乱改 — 找几个内测\n\n最近 dogfood 一个工具叫 mainline ，分享一下做这个的真实故事，顺便看 V2EX 上有没有人感兴趣内测。\n\n## 起因\n\n我在公司推团队用 AI 编程，作为 staff engineer 写过内部 guideline 。过程中发现一个反复出现的现象：\n\n\u003e AI agent 写出的代码不是\"明显错\"——是\"看起来合理，但基于错误的历史前提\"。\n\n具体例子：\n\nrepo 里有个半成品的 Redis 队列：redis.go 、TODO 注释、docker-compose 里也配了 redis 。Claude Code 看到这些，合理地想把这个实现完。\n\n但实际情况——这个团队 3 周前已经放弃 Redis 了，因为 replication 延迟导致 billing 事件重复。这个决定散在某个 PR 评论里、Slack 几条消息、几个工程师脑子里。\n\n代码搜索能看到 redis 文件——但看不到那个**决定**。\n\n## 先尝试过现成方案\n\n* [AGENTS.md](http://AGENTS.md) / [CLAUDE.md](http://CLAUDE.md) 写 not-todo——能写\"don't use redis\"，但只解决你能预判到的。新决定一直在产生，没人持续维护。\n* ADR / RFC——太重，团队不愿意写\n* Wiki / Notion——和代码不同步，过半年 wiki 还说\"我们用 Redis\"\n* PR description——埋在 GitHub 里，agent 不会主动去翻\n* Agent harness 自带 memory （比如 jcode ）——work ，但 lock-in 到那个 harness\n\n每个都在某些场景下 work——但都没解决\"agent 改不熟悉的代码前能拿到团队的真实决策\"这个问题。\n\n## 做了什么\n\nmainline 的 thesis：决策记忆应该是 git 一等公民。\n\n具体设计：\n\n1. 每个 dev 有自己的 actor log （ refs/heads/\\_mainline/actor/\u003cid\u003e），append-only 。Bob 、Alice 各自 push 自己的，不冲突。\n2. Sealed intent 通过 git notes 关联 commit 。\n3. SealResult 是结构化字段：what / why / decisions / rejected\\_alternatives / risks / architectural\\_claims 。\n4. Agent 改代码前先 mainline context \u003ckeywords\u003e——拿到结构化决策，不是一坨 free text 。\n5. 跨人 in-flight 可见——Bob sealed 立刻 push ，Alice fetch 时看到，不等 PR review 才发现冲突。\n\n## 设计上反直觉的几个选择\n\n* 进程式 CLI ，不是 daemon 。Git AI 走 daemon 路线，撞了一堆 macOS sleep / zombie / socket 问题。Git protocol 已经 battle-tested ，不要发明轮子。\n* Intent 级别，不是 line 级别。Line-level attribution 在 formatter / amend / git mv 下天然脆弱。Intent 是任务级别，文本变换不影响 semantic 。\n* Push 模式（ agent 主动 seal ），不是 pull / 自动 capture 。自动 capture 听起来好，但产生大量 noise + 假记忆。显式 seal 有 friction ，但保证质量。\n* Append-only ，sealed 后不能改——只能 supersede 。决策档案改了就失真，\"当时怎么想\"不可篡改才有价值。\n\n## 现状\n\n* v0.1 ship 了 12 个核心命令\n* 我和一个朋友 dogfood 一个月\n* 0 个外部用户，正在找深度内测\n* Apache 2.0\n* 网页：[mainline.sh](http://mainline.sh)\n* 代码： \u003chttps://github.com/mainline-org/mainline\u003e\n\n## 局限我也直接说\n\n* 需要 agent 配合主动调用 mainline 。如果你团队没这个习惯，价值发挥不出来。\n* 比 [AGENTS.md](http://AGENTS.md) 重——多了 seal 这一步。\n* 比 jcode 这种 agent harness 内置 memory 的\"自动\"差，但换来的是数据在 git 、跨 agent 、可移植。\n* 单人 + 好 git 习惯 + 写好 plan ，你不需要 mainline 。\n\n## 适合谁试\n\n* 5+ 人团队，多个 agent （ Claude Code / Cursor / Codex 都行）在同一 repo 工作\n* 跨时间工作多——3 个月前的决定还在影响今天的 PR\n* 已经被\"agent 在不该改的地方乱改\"坑过\n\n## 找内测\n\n如果上面场景命中你——欢迎私信或评论，我直接给你安装包 + 文档 + 每周一次 30 分钟同步。bug 我会优先 fix 。\n\n也想听 V2EX 上的反馈——有没有更好的现有解决方案我没想到的？有没有觉得这个方向不对的？\n\n不卖东西，纯粹想找几个深度用户 + 听不同视角。\nhttps://www.v2ex.com/t/1210451#reply2",
  "sig": "7836acf0d0868b6713d23f479b1da28b0dd056aa80e56168335d4459359b99baa82e5da77bb61b67ac8f4c7f807b097294d93383533d52885786f1bc54ae46bd"
}