Agent First Development：面向多智能体协作的团队开发方法论

Vibe coding 让把一个想法变成可以点击操作的东西变得很容易。但当团队需要交付它、另一个团队需要维护它、客户期望它持续可用时，难度就变了。

想象五位工程师，每人运行多个 agent。每个人都在产出代码。但他们也可能在产出对同一需求的五种理解、互不兼容的接口，以及多到没人能认真审查的变更。一次成功的 agent 运行，几乎不能说明团队是否交付了一个有用的系统。

在 PRD 驱动的开发中，我写过要让产品需求文档贴近代码。我认为这个想法需要扩展为团队层面更广泛的方法论。我称之为 Agent First Development：共同理解范围，把有边界的工作委托给 agent，通过证据验收交付。

Vibe first 意味着用快速实验来发现和完善想法。Agent first 意味着组织实现工作，让 agent 能在正确的上下文、工具和限制下执行清晰的任务。人的判断连接两者，并对结果负责。

从瀑布模型那里，我会借用一种纪律：在实现之前，把需求、依赖和设计决策明确下来。Winston Royce 在 1970 年的论文中已经提出了一个重要警告：如果把运行约束的发现留到最终测试阶段，可能会迫使大规模重新设计。早期的理解必须包含实验和反馈。

从敏捷那里，我会保留短交付周期、客户协作，以及在学习到新东西时修订计划的能力。敏捷原则已经把频繁交付与技术卓越和定期反思联系在一起。Agent 让这些反馈循环更有价值。

从 Scaled Agile Framework（SAFe）那里，我会借用三个实践：跨团队规划依赖和容量；维护架构跑道，让即将到来的工作具备所需基础；把质量构建到每个增量中。这些为团队提供了协调跨多个系统工作的具体方法。

由此产生的流程把有意的准备工作放在生产实现之前，然后以小增量交付。团队在把整体预期范围拆分为任务之前，先理解整个范围。每个增量仍然创造学习和调整方向的机会。

完整范围意味着对结果、边界、约束、依赖和验收标准达成一致，并通过探索解决有重大影响的未知项。它不可能意味着预测每一个实现细节。如果某个问题可能改变架构、安全模型或交付承诺，那么在承诺受影响的工作之前先调查它。记录较小的不确定性，并指定负责人和重新审视的条件。

写下问题、预期用户、预期结果、包含的工作流、排除项、依赖和失败情况。就可接受行为的示例达成一致。产品、工程和负责运行系统的人员必须在 agent 开始生产实现之前共享这一理解。

产品负责人接受预期行为；工程负责人确认可行性和约束。构建企业仪表盘的请求仍然只是一个想法。一个有边界的需求——指明用户、权限、数据源和可度量行为——才是团队可以委托的工作。

每个交付物都需要一名负责任的工程师、一名审查者，以及发布后明确的负责人。产品负责人决定它是否解决了约定问题。小团队可以合并角色，但责任必须保持可见。

Agent 可以提出设计、实现变更和调查失败。监督它们的工程师拥有决策权，并且必须足够理解这些变更，以便解释和维护它们。共享代码所有权应该让这种理解在团队中传播。“agent 写的”是对作者身份的说明；团队仍然拥有其行为。

给探索性 vibe coding 一个问题和一个时间限制。用户能完成这个工作流吗？这个集成是否暴露了我们所需的数据？现有架构能否承受预期负载？在把实验转化为交付工作之前，审查实验实际证明了什么。

使用隔离环境和合成数据。记录假设和捷径。当原型代码成为生产候选时，按照约定的架构、验收标准和安全要求检查它。任何差距都成为明确的工作。一个有说服力的演示赢得的是关于下一步构建什么的决策。

把企业级就绪转化为团队可以验证的需求：身份与授权、客户租户之间的隔离、可审计性、数据处理、可访问性、可靠性、性能和运营成本，视产品情况而定。为每项需求指定负责人和验收检查。

例如，明确哪些角色可以导出数据、访问权限如何撤销、记录哪些日志、支持的最大导出量，以及必须在什么负载下完成。把相关的组织义务纳入这一讨论。这些选择从一开始就塑造设计和实现任务。

把约定需求、架构决策、接口契约、任务计划和验收检查保存在共享的、有版本的记录中。每个 agent 任务都应指明它正在实现的修订版本。在私下聊天中做出的决策，必须在其他工作依赖它们之前进入该共享记录。

Agent 可以在工作时更新文档，包括说明方法为何改变。范围或验收标准的变更需要负责人的同意。保留决策历史，这样实现就无法悄悄重新定义团队承诺交付的内容。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）