Cate Huston：严谨如何支撑 AI 辅助开发的交付速度

团队产出中应有多大比例用于防护措施？当 AI 改变行业时，哪些旧的工作方式仍然有用？我带着这两个问题来演讲，我认为它们密切相关。

我花了十多年扩展远程团队，曾在 Automattic 和 DuckDuckGo 工作。今年我离开 DuckDuckGo，开始实验：与朋友用 Claude 建设一个平台，并担任 Twill 的兼职 CTO。我与另一位工程师一起协助平台从 Bubble 迁移。

迁移花了四个月。这些系统比我过去领导的大团队所做的项目小，但它们是真实运行并产生收入的产品。我的视角结合了让大型团队有效运作的经验，以及近期让 AI 辅助开发发挥作用的经验。

过去我的影响力主要体现在别人的成果上，如今更多体现在 GitHub 上。日程表让位给终端，但目标没有变：持续交付可靠、有用的软件。

在 Twill，数据模型已成为瓶颈。我并没有第一天就开始重新搭建平台，而是先稳定现有系统，包括停止双向写入，再花数月创造迁移到正式数据库的条件。

团队在六月进入节奏，七月基本完成功能，随后准备基础设施和数据迁移。八月上线后需要处理突发问题；九月则重新推进路线图上的较大功能。工作由两名工程师和一位工作六周的实习生完成，大部分问题在发布前就得到修复。

当我把这套做法移植到另一个平台时，我意识到管理方法仍然有用，只是应用方式不同。我引入发布分支、编排器和合并队列，验证工作、退回问题或创建后续任务。按顺序合并也减少了 CI 时间的浪费。

我让看板优先级与编排器保持一致，并标记下一次发布要包含的功能。我还加入临时数据库目标、经过身份验证的端到端测试、环境变量要求、设计系统和每晚备份，再让 AI 无人值守地工作。如果不聚焦发布内容，我们可能提交 50 个 PR，却没有一个重要功能。

小团队现在也需要大团队过去逐渐积累的实践。我认为流程不仅取决于人数，还取决于每个人管理的 agent 数量及管理效果。这个公式只是简化表达，并非精确测量。

好的管理者会放大团队效能：寻找并移除瓶颈，帮助个人进步，同时关注团队需要。流程让判断扩展为执行，关系让判断在人与人之间传递。把 token 开销转化为商业价值，也包含管理问题。

Agent 在较窄的范围内可能更一致，但它们可能不追问原因，也很少承认不确定。被要求管理 agent 的人并非都有管理经验。我意识到，自己把管理实践带入了工作，却没有向身边的工程师解释，因此需要提供指导。

我用四个层次来理解工作：使命定义团队要交付的价值；战略确定优先级；战术和流程让工作可观察、可执行；执行则完成任务。如果团队没有确定做什么以及为什么做，单纯快速执行是不够的。

这些层次仍然存在，但节奏变了。使命相对稳定；战略可能需要按周而非按季度调整。面向 agent 的流程可以快速编写和执行，执行也能持续到夜间，但前提是其他层次保持一致。

好的人员流程会问：在状态不佳的一天，什么能帮助一个有能力的人？面对 agent，我还会问：一个持续执行的 agent 在最坏情况下可能做出什么？与其等几周复盘，不如趁事件记忆尚新，为同一类问题建立防护。

我把防护措施定义为防止问题发生的方法。大公司过去建立多层保护，让人们即使只理解部分系统也能安全工作；小团队则常常依靠隐性知识或资深员工。事故和维护构成第二张路线图，它常常没有写下来，却与计划功能争夺资源。

我引用了一些报告：AI 辅助带来的变更量增加，可能伴随更多事故，而用户价值未必同比增长；我还提到关于开发者速度的研究。这些研究场景不同，不能当作普遍适用的生产率估计。工程上的问题是，如何在控制事故的同时把产出转化为商业价值。

我们起初依赖书面规则，后来逐步将其变成机器检查，因为 agent 并不总遵守说明。要求测试的规则直到覆盖率被度量和检查后才稳定发挥作用。在我的团队，防护措施平均约占产出的 30%；这是基于我们经验的起点，不是通用指标。

防止 bug 上线，比上线后才观察或修复更好。我们引入带视觉快照的设计系统；在反复出现某类服务器错误后，又根据数据库 schema 生成查询。这些投入让一致性更容易实现，也有助于无障碍体验。

高产出带来更多变化时，架构需要更早受到重视。我们很早投入基于角色的访问控制：第一月看起来成本很高，后来权限变化证明这项决策有价值。找出关键承重部分，为它们投入更强的测试、防护和韧性架构，而不是试图把所有东西做到完美。

对小团队来说，把发布与主分支分开，可以设立明确的人工审阅关口。界面变化在进入生产环境前应该实际查看。要考虑哪些东西可以回滚，在有用时使用功能开关，并监控系统，让人看到整体情况。

AI 产出除了消耗 token，也会消耗 CI 时间，而更严格的检查可能增加成本。我把运营成本分为基础成本和随产出增长的速度成本，再将后者与交付价值比较。有一个月，我们的 CI 花费超过 AI 订阅费；如果 AI 按量计费，比较结果可能不同。

执行变便宜后，做所有事情很有诱惑力，但做所有事情并不是战略。产品工作仍然需要判断什么对用户最有价值，以及先做什么。让 AI 起草规格，并不能免除人认真思考的责任，尤其是当其他人需要阅读并据此行动时。

我认为团队没有充分利用面向所有 agent 的共同默认指引。不同工作流加入 agent 后，其差异可能进一步扩大；人们也需要支持才能学会管理 agent。我引用 CircleCI 报告，说明较强的 CI 与较好结果相关；这是报告中的相关性，并不能证明某一种流水线导致了所有收益。

上线后，我们两人团队平均每周发布五次，每次约 25 个 PR；后来逐渐转向次数更少、规模更大的发布。这样的产出量依赖防护措施。我建议把产出的 30% 当作讨论起点，而不是用它代替对软件可靠性和用户价值的衡量。

路线图必须包含防护措施。事故是一个信号：应自动防范整类问题，而不只是修补眼前的 bug。这类工作很多是机械性的，因此产出的 30% 不等于人的时间的 30%。个人贡献者需要指导，学会向上看一层，关注反复出现的问题及其影响。

非技术背景的 CEO 会要求功能；我的工作则是建立让这些功能成为可能的防护措施。迁移期间，我为了控制范围拒绝了不少请求。后来，她以为还要等待的一个功能其实当天早上已经发布。领导者需要展示基础工作如何推进共同的速度目标。

大功能仍然需要稀缺的人力关注和优先级安排。另一位工程师负责一个大功能和数据工作；我负责一个中等功能、发布及 CTO 职责；编排器则处理待办事项。可以做很多事，但不能同时做完：要先决定什么最重要。

我并不是说这套具体工作流对所有人都正确。我们每个人看到的都只是快速变化的局部。在我们的案例里，没有 Claude 就不可能完成无代码平台迁移，而 Claude 也无法在没有我们的情况下完成。失败的方式是放弃判断；严谨的方法则帮助人和 agent 一起取得进展。