AI 时代新工作流：全面构建、小范围交付，降低结构决策成本！
目录
- 有何改变
- 设计仍需先行
- 全面构建
- 在他人阅读代码前进行演示
- 小范围交付
- 收益与成本
- 适用场景
全面构建，小范围交付
优秀的工程师在构建前会进行规划。以往常见的工作流程是怎样的呢？是撰写一份描述功能的 RFC（请求注释），将其拆分为更小的问题，然后逐个解决，每个问题通常会阻碍下一个问题的解决。在编写第一行代码之前，工作结构就已确定。
这是合理的做法，它使代码审查易于管理，避免了大规模合并。但它也存在问题，它要求你在对问题了解最少的时候做出最关键的结构决策。
在还未构建任何东西时，你只能靠猜测：哪些部分可以分离，每个部分的复杂程度如何，第三步是否会让你重新思考第一步。有时你猜对了，但很多时候并非如此，第一步的工作可能会被推翻。虽然在构建过程中你学到了一些东西，但如果先构建整个功能，你会学得更快。
我们付出这样的代价是有原因的：另一种选择是先构建所有内容，然后手动梳理，而梳理一周的工作比提前规划要困难得多。提前确定边界从来都不是为了让构建更容易，而是为了让审查成为可能，这也是当时唯一可行的方法。但现在情况发生了变化，究竟有哪些改变呢？
有何改变
有三件事的成本大幅降低：
- 构建：AI 助手可以在数小时甚至数分钟内将一个明确的问题转化为可用的代码。
- 设计：你可以快速审视和重塑一个计划。
- 分解已完成的分支：这是最重要的一点。过去，将一周混乱的工作拆分成一系列小的 PR（拉取请求）是最繁琐的工作，这也是我们一直避免的原因。而现在，只需一个指令就能完成。
有两件事的成本并未降低。首先是代码审查中的判断部分。AI 代理使机械性的审查（如代码一致性、小错误和明显的 bug）几乎变得免费，但它们无法解决微妙的正确性问题以及相关疑问，比如这个更改是否应该放在这里，这个接口形状在六个月后是否会有问题。机器人批准你的 PR 并不等同于你理解了代码，如果你没有亲自编写代码，阅读代码是你掌握它的途径。小范围的 PR 让阅读代码成为可能。
其次是产品验证。运行产品并确定它是否值得构建仍然很耗时。新的变化是，现在可以在任何人阅读代码之前，让整个功能提前运行起来并展示给他人。
所以，不要再为了避免一个已经不存在的成本而提前确定边界了。现在的工作流程是怎样的呢？
1. 审视计划：直到计划中有明确的决策。
2. 提交规范：当设计新颖时，在编写代码之前提交规范。
3. 全面构建：在构建过程中设置保存点。
4. 演示与迭代：在任何人阅读代码之前进行演示并迭代。
5. 拆分为 PR：根据代码呈现的边界进行拆分。
6. 合并与清理：最后进行纯删除操作，放在一个单独的最终 PR 中。
设计仍需先行
需要明确的是，这并不是“跳过规划直接编码”。在打开编辑器之前，会有一个计划，每个功能都从一次审视开始。使用 [grill - me] 这个工具，它会以对抗性的方式询问你的想法，直到有明确的决策。比如，如果 API 调用失败，备用方案是什么？对所有事情都会使用它，包括小的更改，它总能发现之前没意识到的问题。
当设计新颖时，计划会变成一个规范，在编写代码之前提交。在另一个项目中，第一个 PR 是一个文档，描述了功能是什么、如何工作以及信任边界在哪里。它在任何实现代码之前就合并了，这样团队可以先提出意见。
永远不要提前确定 PR 的分解方式。在构建之前确定要构建什么，在构建之后再确定如何拆分。
全面构建
一旦设计确定，就开始构建。通常会分步进行，但不会在每一步都打开一个 PR 等待审查。所有工作都在一个分支上进行，直到整个功能端到端都能正常工作，无论涉及多少文件。
会有提交操作，但这些提交对其他人来说不是里程碑，它们只是保存点，比如证明了某个概念，或者即将尝试有风险的操作，需要一个回退点。最近完成的一次重构，一天内在几十个文件中进行了十几次提交，并带有操作信息。这些提交点让自己知道进度，而不是为了给审查者讲故事。
这可能会让一些工程师感到不舒服，原因是什么呢？因为 git 历史记录通常被认为是一种记录。但这个构建分支的历史记录不会成为最终的记录。最后的 PR 是从 `main` 分支上重新创建的，而构建分支就像草稿纸，完成后就可以扔掉。这里有两个不同的受众，自己和审查者，将他们分开可以让你同时为两者优化。
在他人阅读代码前进行演示
一旦工作达到一个较好的状态，会停下来展示成果。不是以 PR 或代码审查的形式，而是在 Slack 上发一个简短的视频，或者进行预览部署（如果更改需要实际操作）。在开始任何代码审查之前，从使用者那里获取对可用软件的反馈。
现在，由于机械性审查部分已经自动化，审查变得更加耗时。如果在审查时才发现构建了错误的东西（如混乱的 UI 模式、不适合前端数据使用方式的接口形状），会浪费审查者和自己的时间。而演示可以在更改成本较低的时候发现问题。如果演示中出现需要重新思考的问题，会先用 grill - me 工具分析反馈，这样迭代就不是凭感觉进行的。
小范围交付
构建顺序只是拆分的一个粗略草案，步骤会被重新组合和切割。删除 PR 就是一个明显的例子，它是一个只有在新功能就位后才会存在的单元。
使用一个指令：
“将当前工作拆分成最小的、可独立审查的 PR 集合，每个 PR 都可以安全地单独合并，并且在工作允许的情况下，每个 PR 都能为用户带来价值。为每个 PR 创建一个 git 工作树并从 `main` 分支派生。只有在存在实际依赖关系时才进行堆叠；否则从 `main` 分支派生。任何被替换代码的删除操作都放在一个单独的最终 PR 中。在创建任何东西之前，展示建议的拆分方案。”
拆分所需的时间取决于工作的混乱程度，从几分钟到几次来回沟通不等。无论如何，都不需要手动挑选提交。
那次重构最终拆分成了五个 PR：两个后端接口作为 `main` 分支的兄弟分支，两个前端视图分别依赖对应的后端接口 PR，最后一个 PR 是纯删除旧路径的操作。删除的代码行数比整个新功能添加的代码行数还多几百行。这就是按照这个顺序进行重构的样子。
通过反复实践，总结出两条规则：
- 仅在存在实际依赖关系时进行堆叠：前端视图 PR 依赖于其后端接口 PR，分支结构应反映这一点。其他所有内容都从 `main` 分支派生。为了方便而进行堆叠会创建一个变基链，一旦底层 PR 收到反馈，你就会后悔。
- 清理工作最后交付：旧代码在新功能上线后，放在单独的 PR 中删除。将删除操作与创建操作混在一起会让审查者感到困惑，使回滚操作不明确，并且会将清理工作淹没在功能开发的噪音中。
拆分也是阅读自己工作的时候。逐个查看 PR 的差异，以能理解的规模进行，这让自己不仅交付了 AI 编写的代码，还真正理解了它。更希望在这里发现自己的问题。
一个实际的注意事项：管理堆叠会很快消耗注意力，所以将拆分工作交给子代理，让它们向主代理报告。在 Cursor 中，`split - to - prs` 工具可以实现这一点。
收益与成本
大型 PR 仍然很重要，也应该如此。后端的 PR 承担着真正的架构风险（新的数据模型、新的 API 接口、信任边界），这是审查者应该关注的地方。而消费这些后端接口的前端 PR 几分钟就能审查完。小而专注的 PR 流程顺畅，大型 PR 则容易停滞。
在这个规模下，AI 代理的审查循环也更快。在 Adapt 公司，使用 Adapt 本身作为审查者，它是一个具有过往工作业务背景的 AI 代理。它会在 PR 打开后几分钟内进行评论，并且交流（提问、澄清、小修复）在十分钟内就能解决。但这只有在 PR 足够小，能够快速阅读时才有效；一个包含多个问题的 2000 行代码的 PR，人类审查者根本无法这样处理。
逐步合并也使部署更容易管理。如果出现问题，可以回滚一个专注的更改，错误跟踪系统会指向这个更改，而不是整个合并的代码堆。
这些是收益，但也伴随着两个成本：
- 变基操作：当审查者要求对一个被其他 PR 依赖的 PR 进行更改时，所有依赖它的分支都需要进行变基操作。这种情况并不常见，因为审查者通常会关注最上层的 PR，但一旦发生，会很头疼。保持生成拆分方案的聊天会话打开，因为它仍然保存着拆分信息，可以重新使用指令来更新上面的分支，而不是手动操作。
- 拆分并不等同于交付：在写这篇文章时，那次重构的五个 PR 仍然处于打开状态。一个好的拆分应该使每个 PR 既易于审查，又值得单独合并。AI 代理可以帮完成前者，而后者取决于决定每个 PR 包含的内容，以及团队决定是否合并。PR 停滞不前是因为只完成了前者。即使五个 PR 在同一天合并，仍然能获得审查的好处和每个更改的清晰回滚目标，但失去了增量交付的优势，因为没有任何功能提前交付给用户，所有部署一次性完成。
适用场景
- 适合场景：跨后端和前端的多界面功能、在完成之前不知道最终形状的重构，以及任何需要猜测问题边界的工作。
- 不适合场景：必须在生产环境中按顺序进行的迁移和架构更改，这种情况下顺序是实际存在的，应该提前规划。还有那些有明显拆分点的工作，以及第一步永远不能单独交付的功能；如果所有内容一次性交付，后期分解只能让获得增量审查的好处，没有更多的优势。
判断方法是：如果在编写 RFC 时，在还未构建任何东西之前就猜测如何将其拆分成问题，那么这段时间可能更适合用来构建。最后会得到更好的答案。已经在几个项目中测试了这种方法，效果不错。
结构决策仍然需要做出，只是当面前有代码时，做出这个决策的成本会大大降低。那么，在不同的项目中，如何更好地运用这种新的工作流程呢？