1. 项目概述从“代码合并”到“意图对齐”的范式跃迁最近和 Mainline 的几位核心作者聊了聊感触很深。我们这行干了十几年从 CVS、SVN 一路用到 Git协作的核心始终围绕着“代码”这个最终产物。你提交一段代码我审查你的代码冲突了就去解决代码层面的合并问题。但 Mainline 这帮人提出的“意图协作”让我第一次意识到我们过去几十年可能都在解决一个“下游问题”。真正的瓶颈或许从来不在代码合并本身而在于写代码之前我们为什么要写这段代码、想达成什么目标、背后的设计逻辑是什么——这些“意图”的传递与对齐一旦在早期出现偏差后期就会演变成无尽的返工、重构和沟通成本。Mainline 不是一个简单的 Git 增强工具它试图回答一个根本性问题在 AI 辅助编程AI Coding日益普及的今天当生成代码的成本急剧下降什么才是协作中最宝贵、最易出错、也最值得被工具化的部分答案是“意图”。你可以让 AI 在十分钟内生成一个功能模块但如果你的需求描述意图是模糊的、矛盾的或者团队成员对同一个意图的理解是分裂的那么生成的代码越快带来的混乱也就越大。Mainline 想做的就是把协作的焦点从“代码”这一最终执行层前置到“意图”这一设计和规划层让团队在动手写或生成第一行代码之前先就“我们要做什么以及为什么这么做”达成共识。这听起来有点抽象但实操起来却非常具体。它关乎我们如何写提交信息Commit Message如何做代码审查Code Review如何在分支Branch上描述任务甚至如何用工具捕捉和串联那些一闪而过的设计讨论。接下来我会结合与 Mainline 团队的交流和我自己的实践拆解这套从“代码协作”到“意图协作”的完整工作流你会发现其中很多理念无需等待新工具现在就可以在你的团队中实践起来。2. 核心理念拆解意图协作究竟改变了什么2.1 传统代码协作的隐形天花板在经典的 Git 工作流中无论是 GitHub Flow 还是 GitLab Flow协作的基本单元是“提交”Commit和“合并请求”Pull Request/Merge Request。这个模式隐含了一个假设代码本身是意图的充分表达。审查者通过阅读代码来理解作者的意图并判断其正确性。但这里存在几个经典的“坑”意图湮没在细节中一个复杂的提交可能包含数百行代码改动。审查者需要像侦探一样从代码反推作者的原始设计思路。如果作者没有在提交信息或关联的 Issue 中清晰说明这个推理过程极易出错。上下文断裂代码审查往往发生在实现之后。此时作者可能已经忘记了几天前做某个具体决定时的细微考量比如为什么选 A 方案而非 B 方案。这些丢失的“决策上下文”是意图的重要组成部分。反馈循环滞后最糟糕的情况是审查者在代码层面发现了一个设计层面的根本问题。这意味着所有基于此设计的代码都需要推倒重来。反馈发生得太晚成本高昂。我遇到过太多这样的场景在评审一个“优化数据库查询”的 PR 时花了半小时分析代码最后只问了一句“我们为啥要在这个服务里做这个查询这个数据不是应该由另一个服务通过 API 提供吗” 问题根本不在代码实现而在最初的设计意图是否合理。如果这个意图能在写代码前被显式地讨论和确认就能节省大量时间。2.2 意图协作的核心要素将“为什么”工具化Mainline 倡导的意图协作旨在将上述隐性的、易丢失的“意图”变为显性的、可追溯的、可协作的一等公民。它包含几个关键要素意图作为独立对象不再仅仅依附于 Issue 或 PR 的描述栏。一个“意图”可以是一个清晰定义的目标、一个待验证的设计假设、一个需要团队决策的问题。它应该有状态如提议中、已确认、已废弃、有所有者、有相关的讨论和决策记录。意图与代码的显式链接当你要开始实现某个意图时你明确地将代码变更分支、提交与这个意图对象关联起来。这样任何查看代码的人都能一键跳转到其背后的完整设计上下文。意图驱动的评审代码审查Code Review的第一步不再是读代码而是评审意图。审查者首先确认“我是否同意我们要解决这个问题我是否同意这个设计方向” 在意图层面达成一致后代码审查就变成了纯粹的实现质量检查效率和质量都会提升。AI Coding 的意图输入当你使用 GitHub Copilot、Cursor 或任何 AI 编码助手时最耗时的往往不是写提示词Prompt而是厘清自己到底要什么。意图协作流程强迫你在生成代码前先结构化地定义需求、边界条件和验收标准。这个定义清晰的“意图描述”本身就是一份绝佳的 AI 提示词能极大提高 AI 生成代码的准确度和可用性。实操心得你可以立刻开始的一个习惯是在创建任何功能分支或任务分支前强迫自己写一段“意图陈述”。不超过三段话说清楚1我们要解决什么用户问题或达成什么业务目标2基本的解决方案是什么3主要的边界和不确定点是什么把这陈述放在分支描述或第一个提交信息里。这会彻底改变你编码的启动方式。3. 基于 Mainline 理念的实践工作流改造Mainline 提供了一套完整的工具来支持上述理念但即使没有它我们也可以借鉴其思想对现有的 Git 工作流进行升级。下面是一个融合了传统 Git 实践与意图协作思想的混合工作流。3.1 阶段一意图孵化与对齐Pre-Coding这个阶段的目标是在写出第一行代码之前最大限度地对齐认知。创建意图记录不要直接创建“任务”。创建一个“意图提案”。工具上可以是 GitHub Discussion、飞书文档、或专门的工具。内容模板可以包括标题以“意图”开头如“意图为订单列表增加批量导出功能”。问题陈述当前用户遇到了什么具体问题数据支撑是什么预期目标成功实现后用户体验或业务指标会有何改善方案草图文字描述、流程图、甚至手绘线框图。重点不是细节而是逻辑。开放问题明确列出所有不确定的点如导出的数据范围、频率限制、文件格式。关联链接相关的用户反馈、数据看板、旧代码位置。异步意图评审将意图记录链接发到相关频道如 Slack/Teams邀请产品、后端、前端、测试同学进行评论。评审焦点是“这个意图值得做吗”“大方向对吗”“开放问题有没有遗漏”意图确认与分解根据讨论更新意图记录并最终将其状态标记为“已确认”。随后将其分解为具体的、可执行的开发任务每个任务对应一个后续的代码分支。每个子任务都应引用父意图。3.2 阶段二意图与代码的同步演进Coding在开发过程中意图和代码是双向联动的。基于意图创建分支使用能体现意图的分支名。例如不直接用feat/export-order而用intent/export-order-batch或更具体的intent/export-order-batch-api。在分支描述中再次粘贴意图记录的链接。提交信息关联意图在提交信息中使用关键字关联意图。例如git commit -m 实现批量导出API核心逻辑 - 新增 ExportService 及相关DTO - 添加数据分页查询与组装 - 关联意图#123 订单批量导出这里的#123可以是意图记录在项目管理工具中的 ID。意图的实时更新如果在编码过程中发现了新的约束、更好的实现方式、或者推翻了之前的某个假设不要只改代码。务必回到意图记录中更新“方案草图”或“开放问题”部分并添加一条注释说明变更原因。这保证了意图文档始终是代码的最新“设计说明书”。3.3 阶段三意图优先的代码审查Review这是意图协作价值体现最明显的环节。提交 Pull Request 时PR 的描述模板应强制要求填写两部分意图总结用一两句话重申本 PR 要实现的意图是什么并附上意图记录链接。实现要点列出关键的技术实现选择、值得评审者注意的代码片段、以及如何验证。审查者先评意图再评代码审查者收到 PR 后第一步是点击链接阅读意图记录。审查问题包括我是否同意这个意图如果不同意后续代码审查无意义最终的实现方案与意图记录中的方案草图是否一致如有偏离原因是否合理开发过程中发现的新问题是否已更新到意图记录中 在意图层面达成共识后再进行传统的代码风格、逻辑、性能等方面的审查。基于意图的测试测试用例的编写也应围绕意图展开。不仅仅是“这个函数输入 A 要输出 B”而是“为了实现‘批量导出’这个意图我们需要验证在数据量极大、过滤条件复杂、并发请求等场景下系统是否仍能达成目标”。3.4 阶段四意图的归档与追溯Post-Merge代码合并后工作并未结束。关闭循环将意图记录的状态更新为“已实现”并关联最终的 PR 和部署信息。知识沉淀这个完整的意图实现链路问题 - 意图 - 讨论 - 决策 - 代码 - 测试构成了一个极佳的技术决策档案。新成员 onboarding 或日后排查问题时通过代码回溯到意图记录能快速理解当时的完整上下文而不是面对一堆“考古”代码。度量与改进团队可以定期回顾“意图从提出到关闭”的平均周期、在意图评审阶段发现重大问题的比例等指标。这些指标比单纯的“代码提交量”“PR 合并数”更能反映团队协作的有效性和设计质量。4. 工具链整合与实操配置完全采用 Mainline 可能需要一套新工具但我们可以用现有工具链模拟其核心功能。这里以 GitHub 飞书文档为例提供一个可落地的配置方案。4.1 中心化意图库的搭建我们不推荐将意图分散在无数个独立的 Issue 或 PR 描述中。建议建立一个中心化的“意图库”。工具选择飞书/语雀/Notion 等文档协作工具。创建一个名为“技术意图库”的空间。页面模板利用工具的模板功能创建“意图提案模板”。模板内容即上文 3.1 节所述。命名与索引每个意图页面以[INTENT-序号]开头如[INTENT-001] 订单批量导出。在文档空间内建立索引页按项目、状态进行中/已完结/已废弃分类。4.2 Git 工作流的适配配置在 Git 层面我们需要一些约定和自动化脚本来建立代码与意图的链接。分支命名规范在.gitlab-ci.yml或项目 README 中约定分支命名规则。类型/意图简述-可选描述 例如intent/export-order-batch, intent/fix-payment-timeout提交信息钩子Hook可以配置一个commit-msgGit Hook来提醒非强制开发者在提交信息中关联意图 ID。一个简单的示例# .git/hooks/commit-msg (示例) #!/bin/bash COMMIT_MSG_FILE$1 COMMIT_MSG$(cat $COMMIT_MSG_FILE) # 检查是否包含意图ID模式如 #INTENT-123 或 链接 if ! echo $COMMIT_MSG | grep -qE (INTENT-\d|意图(链接|.*#)); then echo 提示本次提交信息未发现明确的意图关联如 #INTENT-123。请确认是否已关联相关意图文档。 2 # 非强制只做提示 fiPR 模板强化在 GitHub/GitLab 仓库的.github/PULL_REQUEST_TEMPLATE.md或.gitlab/merge_request_templates/下创建模板。## 关联意图 **意图链接**[请填写飞书意图文档链接] **意图简述**[用一两句话说明本PR要实现的核心理念] ## 实现要点 - **变更范围** - **核心逻辑** - **测试建议** - **其他说明** ## 自查清单 - [ ] 意图文档已更新至最新状态 - [ ] 代码变更与意图描述一致 - [ ] 已添加或更新了相关测试4.3 与 AI Coding 工作流的结合这是意图协作当前最能产生效率红利的地方。将意图文档作为 Prompt 源当你需要 AI 助手如 Cursor 的 Chat 模式帮你生成某个模块的代码时不要从头开始描述。直接将意图文档中“方案草图”和“开放问题”部分的内容复制过去。这比你临时组织语言要清晰、完整得多。用意图验证 AI 输出AI 生成的代码第一遍审查不要陷入细节。对照你的意图文档问几个问题这段代码是否完全实现了草图描述的功能它是否无意中引入了意图范围外的副作用它对我列出的“开放问题”做了怎样的假设或选择记录 AI 的“设计决策”如果 AI 在生成代码时提出了与你原方案不同的、但有价值的实现方式把这个决策点记录回意图文档的“讨论区”。这既是知识积累也便于后续审查者理解。注意事项过度依赖 AI 生成大型、复杂的模块时意图文档的重要性不降反升。因为 AI 是“黑盒”你更需要一个清晰的“设计白盒”意图文档来锚定它的输出方向并在出现偏差时快速纠偏。5. 文化挑战与落地推广指南引入意图协作最大的阻力往往不是技术而是文化和习惯。从“提交代码”到“先定义意图”需要思维模式的转变。5.1 可能遇到的挑战与应对策略“这太麻烦了直接写代码更快”短期 vs 长期直接写代码在极短期的单次任务上可能“感觉”更快。但一旦涉及修改、协作、或两周后自己回顾意图文档节省的时间是巨大的。可以拿一个因为意图不清导致返工的实际案例做对比分析。试点法选择一个中等复杂度、涉及2-3人协作的新功能进行试点。完整走通一次流程记录下在意图对齐阶段发现并避免了哪些潜在问题用数据说话。“意图文档写多详细会不会变成没人看的文档”适度原则意图文档不是详细设计文档。它聚焦于“为什么”和“做什么”而非“怎么做”的所有细节。坚持使用模板防止过度设计。活文档强调意图文档是随着编码过程一起更新的不是一次性写死的“文物”。把它作为编码过程中思考的草稿纸。评审者不习惯先看意图流程固化在团队评审规范中明确要求PR 描述中没有清晰意图链接的可以打回或要求补充。工具辅助可以在团队沟通频道设置机器人当 PR 创建时自动解析其中的意图链接并将意图摘要一并推送出来引导大家先关注意图。5.2 分阶段推广路线图不要试图一步到位建议分三个阶段每个阶段持续1-2个迭代周期第一阶段意识启蒙与自愿试点目标让团队理解“意图协作”的概念和价值。行动组织一次内部分享讲解传统协作的痛点与意图协作的思路。寻找1-2位积极的同事在下一个任务中自愿尝试记录意图文档并关联到PR。产出一次分享会1-2个实践案例。第二阶段规范建立与工具准备目标形成团队共识的简易流程和工具模板。行动基于试点经验共同敲定一个大家都能接受的“意图提案”简化模板可以比上文提到的更简略确定中心化意图库的位置如一个特定的飞书文件夹。在项目仓库中配置好 PR 模板。产出团队公约文档、意图模板、配置好的 PR 模板。第三阶段全面推行与习惯养成目标在新启动的所有特性/模块开发中默认要求遵循意图协作流程。行动在迭代规划会上明确要求每个特性任务必须先有意图提案并在团队内进行快速对齐可以是异步评论也可以是15分钟的快速同步会然后才能进入开发。技术负责人或架构师在评审时首先检查意图。产出意图协作成为团队默认工作流的一部分。6. 效果评估与常见问题排查推行一段时间后如何评估效果遇到问题怎么办6.1 如何衡量意图协作带来的价值不要只看主观感受可以关注几个客观指标指标测量方法期望的变化趋势PR 首次评审通过率首次合并的PR数 / 创建的PR总数上升。意图对齐减少了方向性返工。PR 平均评审时长从创建到合并的平均时间可排除因需求变更导致的阻塞。下降或保持。意图评审可能增加前期时间但代码评审更高效总周期可能缩短。“重构”或“重大修改”PR 占比因设计问题导致的、需要大规模重写的 PR 比例。显著下降。意图阶段卡掉了错误的设计。线上缺陷溯源到设计阶段的比例分析线上 Bug看有多少是源于需求或设计理解错误而非编码错误。下降。新成员理解代码库的平均时间通过访谈或问卷了解新同事找到某个功能背后设计决策的速度。缩短。意图库成为最好的 onboarding 文档。6.2 实操中遇到的典型问题与解决思路问题意图文档和代码实现逐渐脱节。现象开发后期代码变了但没人回去更新意图文档。排查与解决文化上强调“更新意图文档是开发工作的一部分不是额外负担”。在 PR 自查清单中强制加入这一项。工具上考虑在 CI 流程中增加轻量级检查例如解析 PR 描述中的意图链接并检查该文档最近是否有更新。但这需要较深的工具集成。流程上在代码评审环节审查者如果发现实现与意图描述有重大出入而意图文档未更新应要求作者先更新文档。问题意图讨论陷入僵局迟迟无法决策。现象一个意图提案下大家争论不休无法进入开发。排查与解决设定决策机制明确决策者如技术负责人、产品负责人。在意图模板中增加“决策人”字段。时间盒讨论为意图评审设定一个截止时间例如24小时异步讨论。时间一到决策人必须根据现有信息做出决定并记录决策理由。可以接受“有已知风险的决策”避免“追求完美决策而导致的瘫痪”。拆分意图如果争论焦点集中在某个子问题上尝试将这个子问题拆分成一个独立的、更小的意图提案单独决策。问题觉得写意图文档拖慢了启动速度。现象对于非常小、非常明确的任务如“修复某个拼写错误”写意图文档显得多余。排查与解决设定阈值团队共同定义哪些变更可以豁免完整的意图流程。例如“仅影响单文件、逻辑在50行以内、且不改变任何接口的缺陷修复或文案修改可直接提交无需意图提案。” 将这个规则明确下来。简化模板为小型任务准备一个“轻量级意图”模板可能只包含“问题描述”和“修改方案”两栏1分钟内可填完。从我个人的实践来看推动意图协作最关键的是让团队中的每个人尤其是技术负责人亲身感受到它在避免大型返工和提升跨职能沟通效率上的巨大威力。一旦有几个成功案例大家就会从“被要求做”转变为“主动想做”。这不仅仅是换一个工具或流程而是换一种更高效、更少浪费的思考和工作方式。