专访 Mainline 作者们：聊聊从代码协作到意图协作

过去我们 Review 代码主要看 diff、commit message 和 PR 描述。但如果未来大量代码都由 AI 生成人类可能不会再逐行看完所有代码。团队真正需要同步的可能是这次改动背后的目标、原因、决策和取舍。Mainline 想做的就是把这些「意图」记录下来并和代码一起进入协作流程。本次专访的嘉宾豁如Mainline 开发者此前做过 AI 搜索产品 Hika钰泽Mainline 开发者最近两年主要在美团做 AI Infra 相关基础设施建设由于这次采访内容比较长觉得太长的小伙伴可以先看下面的“懒人版”。懒人版这期专访主要聊了 Mainline 是什么以及它为什么把 AI Coding 时代的团队协作重点放在「意图」上。简单来说Mainline 可以理解成 Git 之上的一层协作机制。Git 记录代码怎么变Mainline 想记录的是这段代码为什么会这样变。在 AI Coding 越来越普遍之后代码生成会变得更快也更多。团队成员如果还只靠逐行看代码、看 diff 来理解彼此成本会越来越高。Mainline 的做法是让 Agent 在开发过程中自动总结 Intent意图并把它和 commit 关联起来。这样团队在 Review 时可以先看这次改动的目标、原因和关键决策再决定是否需要深入看代码。如果只用一句话概括Mainline 想让 AI Coding 时代的团队协作从「看代码」逐渐变成「看意图」。Mainline 是什么小七先简单介绍一下 Mainline 是什么。豁如如果讲得通俗一点可以把它理解为 AI 时代的 Git。在没有 AI 的时代开发者之间的协作主要通过 Git 来完成。比如我写了一个功能提交一个 commit开一个 branch你可以通过我的代码改动、commit message 和 PR 描述理解我做了什么。但 AI 引入之后代码生成量会越来越大。未来很多代码可能都由 AI 生成人类越来越难通过直接看代码来理解对方想做什么。因为这段代码可能不是人一行行写出来的而是通过一段任务、一组上下文、多轮对话和一系列决策生成出来的。所以我们认为未来人类会越来越少地关注具体代码更多关注生成这段代码背后的意图和决策。也就是说在 AI 时代我和你协作的时候看的重点可能不再是代码本身而是你为什么要解决这个问题你想怎么解决你做了哪些决策你为什么引入这些代码这些东西就是 Mainline 想记录的内容。钰泽我补充一下。我们的思路是代码相关的东西可以越来越多地交给 AI。比如代码怎么写、有没有格式问题、有没有潜在 bug这些可以由模型、Code Review Agent 或其他工具去解决。但如果有一天我们真的可以把代码细节都交给 AI那对人来说项目里最重要的东西是什么我们认为是 Intent也就是意图。比如一个团队一起开发同一个产品。我这段代码可能是 AI 写的但它背后表达的是我这个人的目标和判断。那团队里其他人要 Review 的就不只是这段代码有没有问题还要看这个意图本身是否符合团队共识是否走在产品正确的方向上。Mainline 定义了一套 Intent Schema希望把这些东西记录下来。人类可以 Review IntentAI 可以 Review Code。这样协作的层次会更清楚一些。为什么叫 Mainline小七我刚刚听下来其实很好奇你们为什么叫它 Mainline钰泽一开始我们考虑的是这个项目要解决的是人类以及属于人类的 AI Agent在开发过程中出现的各种分歧。就像 Git 里会有各种 branch但最后这些分支还是要合回 main branch 或 master branch。意图也是类似的。团队里可能会出现很多不同方向的意图。一个人在改这里另一个人在改那里一个 Agent 在实现 A 方案另一个 Agent 可能在推进 B 方案。Mainline 想提供一套机制把这些意图上的分歧收束起来最终回到一条主线上。这就是名字的来源。为什么 AI Coding 时代需要 Intent小七现在 AI Coding 已经很强了真实工程里还缺什么豁如可以从一个 manager 的视角来看这个问题。假设你是一个团队的管理者。你的团队里有新人也有老员工。现在因为公司要求大家都在大量使用 AI 写代码。那你自然会担心几个问题他们真的能掌握 AI 吗AI 能不能掌握项目的完整上下文AI 写出来的代码稳定吗团队成员会认真 Review AI 生成的代码吗其他人怎么知道这次改动背后的目的是什么从这个角度看虽然现在 AI Coding 工具已经很强了但团队还缺少一种机制让管理者和团队成员可以更轻松地 Review 对方用 AI 写出的代码。或者更准确地说是先 Review 这段代码背后的意图和决策。如果能先看意图再看代码就可以大大减少 Review 需要花费的精力也能更快完成团队里的方向对齐。钰泽我举一个简单例子。假设你的一个同事用 AI 写了一段代码然后提了一个 PR。你要怎么 Review 这个 PR如果是代码格式、潜在 bug、实现问题这些都可以让 AI 帮你 Review。但 AI 不一定会判断这个功能方向是否正确或者这个改动是否符合团队对产品的共识。你当然可以把 PR 链接丢给 AI让它总结这个 PR 做了什么。但如果这些事情可以在开发过程中就被前置地记录下来并且形成一个固定 Schema团队协作效率会更高。这就是我们觉得 AI Coding 里还缺的部分。Intent Memory 具体在记什么小七Mainline 的 Intent Memory 具体在记什么它和 commit message、PR 描述有什么区别豁如我们会记录一些比较规范化的内容。第一是 Goal也就是目标。这个目标可以理解为用户和 AI 对话时让 AI 做了什么事情。第二是为什么要做这件事。这部分也是通过用户和 AI 的交流总结出来的。它描述的是这次改动背后的原因。第三是 Turns也就是多轮对话。你和 AI 开发的时候很多时候不是一次就能让它全部做完。可能先让它实现一版测试的时候发现有问题再继续跟它聊。或者做着做着发现有东西漏了再补充要求。这些来回对话也很重要。Mainline 会把这些过程记录下来让后面的人可以看到用户在使用 AI 时做过哪些补充、纠正和调整。最后是 Decisions也就是决策。比如这次决定做什么不做什么采用什么方案放弃什么方案。这些内容会由 Mainline 的 skill 引导 Agent 主动描述然后记录到 Git notes 里。至于它和 commit message、PR 描述的区别从某种意义上说目标是接近的。你当然也可以把这些东西写进 commit message 里。但 Mainline 的区别在于它会用更规范化的结构来组织这些信息并且通过 Git notes 和 commit 关联起来。顺便提一嘴Git notes 是 Git 自带的能力可以给一个 commit 添加额外说明。Mainline 利用它来保存 Intent。这样做的好处是Intent 可以跟着 commit 走。以后你看到一行代码就有机会通过 Mainline 回溯到它当初是基于什么意图生成的当时发生过哪些对话做过哪些决策。这也是它和项目文档、CLAUDE.md、AGENTS.md 这类文件最大的区别。项目文档需要人工更新而且它和代码不一定同步。你想知道某一行代码当初为什么这样写通常很难通过项目文档精确回溯。但 Mainline 希望让意图和代码变动绑定在一起。Intent 是给人看的还是给 Agent 看的小七我刚刚听下来有一个问题。Intent Memory 是针对人设计的还是针对 AI Agent 设计的钰泽我觉得不完全是只针对人。Mainline 的一个基础要求是所有操作本身都尽量由 Agent 完成。比如通过 skill、CLI、Agent Hook 等机制把 Mainline 融入原有的 AI Coding 流程。你不会想要手动写一个意图进去也不应该额外打开一个工具来专门维护 Intent。理想状态下它对人类是无感的。Agent 在开发过程中会自动使用 Mainline自动记录和提交 Intent。那人什么时候看比如意图出现冲突或者需要 Review 的时候人就需要看其他开发者的意图并基于这些意图做判断和决策。当然人也可以通过 Agent 去查看这些 Intent。Agent 可以通过 CLI 或 skill 把意图拿出来给人看。豁如我的补充是Intent 本身不应该区分是给人用还是给 Agent 用。因为人需要理解的东西Agent 也需要理解。差别在于Agent 可能会从上到下先看意图再看代码。人类未来大部分时候可能只需要关注意图本身。只有在出现 bug、Agent 无法解决或者人类对 Agent 不够信任时才需要深入看代码。Mainline 怎么跑起来小七开发者实际使用 Mainline 的时候大概是什么运行模式钰泽流程上我们希望尽量标准。首先是安装。Mainline 涉及 skill、CLI 和 hook这些是基础依赖。安装完成之后会进行初始化把 Mainline 相关配置文件放到仓库里。它不会影响整个仓库正常运行只是一些旁路配置。之后如果你要让 Agent 修改代码Agent 在开工前会通过 Agent Hook 意识到自己需要使用 Mainline 流程。它会先读取 Mainline 的 skill。Mainline 相关流程信息会通过 skill 渐进式加载给 Agent。比如 Agent 会知道在开工之前它需要检查之前的一些 Intent看看有没有风险、有没有之前写死的约定、有没有其他人正在改动相关内容。这里检查的不只是代码冲突也包括意图冲突。我们会通过 Intent 的生命周期来实现这件事比如草稿、已提交、已合并等状态。如果 Agent 检测到别人正在做相关改动它就会去看对方的意图是什么、在哪个分支、代码是什么。这样它可以在开始工作前就尽量避免冲突。如果开工前检查没问题它就正常写代码。Mainline 不会改变 Agent 写代码的方式。写完之后它会总结本次代码改动对应的用户意图然后把 Intent 上传。这个 Intent 也是通过 Git 管理的。之后其他同事或者 Agent 在 Review 的时候就可以直接 Review 这个已经提交的 Intent。如果最后 PR 被合并Intent 也会随着代码一起合并到 master 或 main 分支也就是主线上。图注提 PR 的时候有 CI bot 可以自动总结 intent 描述便于 review比 Git 冲突更早发现问题小七我觉得开工前检测意图冲突这个点挺有意思。它能提前预防和别人开发方向冲突。钰泽对这其实也是 Mainline 名字来源的一部分。假设没有 Mainline正常开发流程里我写一段代码给流水线加一个节点 A。豁如也在写流水线代码给流水线加一个节点 B。这两部分代码有可能在 Git 上冲突因为我们可能同时改了同一个文件。但也有一种情况是Git 不冲突。代码文件没有冲突但项目逻辑或者产品逻辑上有冲突。比如这两个节点的顺序有问题或者两个改动都在改变流水线逻辑最终组合起来不符合产品预期。这种冲突如果没有 Mainline通常要等代码写完之后才会发现。甚至可能我的代码已经合进主线另一个人的代码合并时才发现问题。更危险的是Git 没有发现冲突代码就被合进去了。这就很滞后。如果有 Mainline在投入开发之前Agent 就可以看到有另一个同事正在进行相关改动这两个意图可能会打架。它可以提前提醒我们这两个操作都会影响流水线并且可能涉及节点顺序问题。这种冲突不是代码文件层面的冲突而是意图层面的冲突。它需要 Agent 去理解产品里的冲突。所以它比 Git 冲突更早也可能发现一些 Git 本身发现不了的问题。为什么选择 Git-native小七为什么选择 Git-native 的方式实现上有什么比较有意思的设计豁如选择 Git-native 的原因很直接。Git 已经是几乎所有开发者写代码时的事实标准。只要是一个靠谱的程序员基本都会使用 Git。所以我们很自然会选择在 Git 上继续做。另一个原因是过去代码时代靠 Git 协作。到了 AI 时代我们认为 Mainline 可以是 Git 之上的更抽象一层。一开始我们也考虑过不同方案。比如直接用 commit message或者新开一个 branch在 branch 里用文件存这些信息。后来发现 Git notes 比较适合。Git notes 可以给 commit 写 note。你可以把它理解成另一种形式的 commit message。我们就可以比较优雅地在 Git 上继续实现 Intent 记录。另外意图冲突检测也是一个比较有意思的设计。我们会通过一个共享 branch 来实现。每个人的 Intent 都会同步到这个 branch 上。Agent 在做决策前会先把这些 Intent 拉下来。这样它在本地开发时就可以看到其他人还没正式推上来的 Intent。也就是说不需要对方 commit也不需要对方 push只要他开始工作我就大概能知道他正在做什么以及这件事会不会和我冲突。钰泽我补充一个小点。Git-native 的方式还有一个好处是本地友好。它相当于纯本地存储用户不用太担心数据交给了谁也不用太担心网络延迟这类问题。为什么用 Go 开发小七Mainline 好像 90% 以上都是 Go 开发的。现在很多项目用 Python也有很多项目在 Rust 化你们为什么用 Go豁如首先这个工具天然适合做成一个二进制。所以我们自然不会优先选 Python。打包成二进制这件事Go 和 Rust 明显更有优势也更自然。至于为什么选 Go没有选 Rust主要是因为我们更熟悉 Go。对 Mainline 来说Go 的性能已经足够了。所以我们就直接选 Go 来实现。Mainline 和 RAG、grep、session recorder 的关系小七Mainline 和 RAG、grep、session recorder 这类方案是什么关系为什么只记录 Agent session 还不够钰泽这里可能要先区分一下。像 RAG 和 grep我理解它们更像是获取信息的技术或方式。它们解决的是怎么找到信息。但 Mainline 提供的是一种新的信息形式也就是 Intent。它给 Agent 和人增加了更多结构化信息。它不是在解决怎么检索信息而是在定义团队协作里值得被记录和传递的信息。至于 session recorderAgent session 本身会非常大。比如你做一个功能开发可能有很多上下文、Prompt、文档、多轮对话、工具调用和输出。这些信息当然有价值但它太多了。如果你想分享意图或者记录意图最好有一个 schema。这个 schema 应该简单、清晰固定有哪些字段每个字段写什么。另外团队协作也涉及隐私问题。你大概率不会想把自己和 Agent 的所有对话过程都分享给整个团队或者永久存到云端。所以我们认为 session 是有意义的但需要把它凝练出来。Mainline 本身其实就是让 Agent 从会话信息中概括出意图。这样会更高效也更适合团队协作。豁如对session 很好。就是太多了。一个 session 不仅包括用户对话也包括 Agent 自己完整的思考过程和输出。它远远超过真正需要长期保存的内容。Mainline 要记录的是其中真正关键的部分。现在还有哪些想做但没做的功能小七你们做这个东西大概做了几个月有哪些功能是想做但还没做的豁如我们大概做了两个月左右。目前比较想做但还没做的是类似 GitHub 的东西。就像 Git 有 GitHubMainline 未来也可能需要一个 MainlineHub。现在 Intent 虽然已经能记录下来但没有一个 SaaS 方案去查看。目前你要查看 Intent要么通过命令行要么在本地生成一个网页。但它还不像 GitHub 那样你可以在一个平台上看项目、看 PR、做 Comment、Review。所以现在 Mainline 还是一个偏单机版的工具。等 Mainline 有一定使用人数之后我们会考虑做 MainlineHub。钰泽命令行模式现在已经支持了。我们官网上也放了一个 Mainline 项目本身的最小模式 Hub算是一个 demo。真正想做但没做的是刚刚提到的云端 Hub。什么样的团队适合试用 Mainline小七项目早期你们希望什么样的团队来试用希望他们帮你们验证什么能力豁如我们会比较希望中型或者大型公司的团队来尝试。我们想验证的是有了 Mainline 之后开发者之间的协同、manager 和员工之间的协同、团队之间的协同是不是会有明显提升。尤其是在 Review 代码和代码协作这两个环节。小七那你们对团队人数有要求吗比如 10 人团队、20 人团队之类的。豁如两个人也可以用 Mainline。但当然团队越大价值可能越明显。比如 10 个人以上应该更能体现 Mainline 本身的价值。钰泽我也认为越 AI-native 的团队越能认识到 Mainline 的价值。如果一个团队还在手写代码Mainline 的用处可能没那么明显。如果一个团队还习惯逐行 Review 代码也不一定能很快意识到 Mainline 的价值。但如果一个团队已经大量使用 AI Coding团队人数也比较多需要记录和 Review 的东西很多遇到的冲突也更多那 Mainline 的价值就会更明显。Coding 技能分享小七最后分享一下你们最近觉得好用的 AI Coding 技巧吧。豁如我觉得还是先做 TDD。可以先让 AI 把所有测试样例构造好然后再开始实现。这样 AI 就有一个稳定、可复现的方式去验证结果。不管是性能压测还是集成测试都可以先让它完成这些测试再开始写实现。钰泽我最近更多是在尝试建立一个比较完整的 AI 工作流程。比如 AI 不只是写代码还要能够验证自己的代码是不是符合预期。这个验证需要你定义一些标准或者设置一些检查点让它能证明自己的代码是有效的输出是成功的。如果没有达到标准它就要回退、修改再继续验证。这有点接近 auto research 的核心AI 自己开发、验证甚至自己提出想法。但这里面很重要的一点是验证要有回归测试效果也要符合预期标准。尾声