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

原创

七牛开发者

发布于 2026-06-05 16:56:56

前段时间，小七和 Mainline 的两位开发者豁如、钰泽聊了聊这个项目，也聊了聊它背后的思考和开发故事。本文便是这次专访的整理稿。

开始之前，先介绍下 Mainline 是什么。它是一个围绕「工程意图」构建的协作工具。

地址：github.com/mainline-org/mainline

Mainline 关注的问题是：当团队越来越多地使用 AI Coding，代码生成速度越来越快之后，开发者之间还要怎么理解彼此的工作？

过去我们 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 Intent，AI 可以 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 recorder，Agent session 本身会非常大。比如你做一个功能开发，可能有很多上下文、Prompt、文档、多轮对话、工具调用和输出。这些信息当然有价值，但它太多了。

如果你想分享意图，或者记录意图，最好有一个 schema。这个 schema 应该简单、清晰，固定有哪些字段，每个字段写什么。

另外，团队协作也涉及隐私问题。你大概率不会想把自己和 Agent 的所有对话过程都分享给整个团队，或者永久存到云端。

所以我们认为 session 是有意义的，但需要把它凝练出来。Mainline 本身其实就是让 Agent 从会话信息中概括出意图。这样会更高效，也更适合团队协作。

豁如：对，session 很好。就是太多了。一个 session 不仅包括用户对话，也包括 Agent 自己完整的思考过程和输出。它远远超过真正需要长期保存的内容。

Mainline 要记录的是其中真正关键的部分。

现在还有哪些想做但没做的功能

小七：你们做这个东西大概做了几个月？有哪些功能是想做但还没做的？

豁如：我们大概做了两个月左右。目前比较想做但还没做的，是类似 GitHub 的东西。就像 Git 有 GitHub，Mainline 未来也可能需要一个 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 的价值就会更明显。