懒人版

这期专访主要聊了 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 分支，也就是主线上。