威尔·多尔曼 // 2026年8月13日 近年来，我们分享了更多关于我们的工作方式：用Amp构建Amp、或bs、去除功能、不使用Pull Request。最常见的反应并不是关于AI工作流程或任何一种周图工程的流行趋势，而是：等等，你们不使用Pull Request？你们直接推送到主分支？如何做到的？这不符合SOC 2合规。实际上是符合的。从第一次提交开始跳过Pull Request就是一个故意的选择。这是我们构建方式的重要组成部分，也是我们能够持续发布的原因。因此，当我们开始致力于SOC 2时，我们直接问我们的审计员：“你们需要Pull Request吗……对吗？” 控制 SOC 2并不要求使用Pull Request。它要求你考虑你的风险。这才是我们得出的真正答案。审计员和SOC 2本身比你想象的更灵活。我们的审计员没有要求我们提供Pull Request；他们询问我们的变更过程，并与我们一起制定了一套适合的控制措施。信任服务标准从未提到 git 或 Pull Request。他们要求的是，变更需要经过授权、测试、批准并记录——而 Pull Request 只是做这件事的一种方式。以下是我们最终确定的控制措施： 限制推送访问。访问主分支根据业务功能进行分配：Amp 的每一位工程师都可以推送，而且Amp的绝大多数都是工程师。但拥有访问权限的人数比例不如能够清楚解释到底谁有权限以及原因来得重要。 签名提交。推送已经需要身份验证，但提交作者是元数据。GitHub 在主分支上强制执行经过验证的签名，从而使每个提交的作者都是可验证的。 自动化CI。每项变更都会经过完整的验证管道：测试、基础设施检查、安全检查。错误的变更会阻止推送到主分支。审计跟踪与Pull Request同样有效。提交与生成它们的Amp线程相关联，因此记录不仅仅是一个差异，而是所有导致这个差异的过程。之后，CI/CD记录了从提交到部署的路径。所有这些都并不奇特。但它也不能被视为一种常规流程省略了一步。这是一个有目的地设计的系统，它为审计员提供了与Pull Request工作流程相同的东西。另一个方面，代码审查并不在清单上。标准没有说给一个差异视图必须有第二个人盯着。这样的做法适用于规模吗？我们团队有20个人，主要是工程师，每个人都与代码紧密相连。小规模和高信任是我们的优势，而我们不打算为了一个我们不需要的流程而放弃它。当写代码速度很快时，缓慢的过程才真正成为你在等待的事情。但我们也不打算假装一个2000人的公司应该让每个人都推送到主分支。真正需要考虑的是你的风险，因为风险在公司内部也不是均匀的。Amp是面向客户的生产软件，我们就是这样发布它。与此同时，许多大公司里的代码的风险还不及这个，但每次变更都要经过同样的标准流程，调整到公司的最苛刻系统。而且你不需要改造整个公司来解决这个问题。选择一个系统，并问：“我们的Pull Request实际上管理了什么风险？”然后问还有什么其他方式可以管理它们。答案不一定是Pull Request。