AI 开发流程中，工程师必须保留否决权

AI 能写代码、拆任务、生成测试，甚至准备部署，但有一个问题不能被「自动完成」掩盖：到底是谁在决定这个系统应该怎么做？作者讨论 AI-DLC、Bolts 和自主 Agent，核心主张是，开发者必须保留拒绝设计、设定约束和叫停执行的权力。

这篇值得读的地方，是它把关注点从「AI 多快交付一个应用」转向「团队半年后能否维护它」。不过，文中的架构案例和工作流主要用于论证，没有长期对照数据，不能当成 AI 开发方法有效或无效的实验证明。

代码生成得快，为什么项目仍可能走偏

AWS 提出的 AI-Driven Development Lifecycle（AI-DLC），尝试围绕 AI 重新组织开发流程。AI 创建计划、提出问题和解决方案，经过人工验证后执行；其中包括 Units of Work、Bolts、Mob Elaboration 和 Mob Construction 等概念。specs.md 则把类似思路带入 Claude Code 等工具。

Bolts 是以小时或天计的短执行周期，而非以周计。它想解决的问题很实际：上下文容易丢失，人工交接慢，实现不一致，重复劳动多。原文提到 AI-DLC 有三个主要阶段，但提供的正文没有列出名称，这里不补写。

问题出在如何理解「进展」。

Agent 几分钟生成五套架构，只能证明方案产出很快，不能证明其中任何一套适合当前业务、运维条件和团队能力。

作者举了一个预约管理的假设案例：系统每天只有几百条预约，使用单个 PostgreSQL 数据库，也没有已经证实的扩展瓶颈，Agent 却建议引入 Kafka topic、Redis 缓存，再增加一个管理预约生命周期的微服务。

这些组件都能解释得通，组合起来也像一套完整架构。但当前需求可能只需要增加一个 endpoint、一段事务、一个数据库约束和两个集成测试。

技术上自洽的方案，也可能是糟糕的工程决策。

新增服务会带来部署、监控、故障排查和一致性维护。代码生成成本下降，并不会让这些长期成本自动消失。作者担心的，正是团队以极快的速度交付了原本不需要存在的复杂度。

人参与了审批，为什么还不算掌握控制权

作者区分了两个概念：human-in-the-loop 是人参与流程，human-in-control 是人拥有决策权。

Agent 提出事件驱动架构，宣布要实现三个服务及配套基础设施，最后报告生成的测试全部通过。即便沿途有三个人工检查点，也不能据此认定团队认真判断过架构是否必要。

真正的控制权，体现在开发者可以追问：现有事务设计解决不了什么问题？请给出三个替代方案，比较运维成本、一致性保证、故障恢复和迁移工作量，并考虑团队基础设施维护能力有限这一条件。

这时，开发者在改变解题范围，而非只给既定答案盖章。

原文据此提出四项应当保留的权力。

第一，拒绝设计，不必立即交出替代实现。指出「新增服务没有证明独立扩缩容、独立部署或领域归属的必要性」，已经构成有效的工程判断。

第二，建立明确约束。Agent 需要知道架构边界和运行条件，不能只收到缩进、命名等编码规范。

下面这段策略示例，把团队不愿反复解释的限制写成了可检查的条目：

architecture:
  new_microservices: prohibited
  database: postgresql
  messaging: existing_kafka_topics_only
  public_api_breaking_changes: prohibited

reliability:
  retries_must_be_bounded: true
  idempotency_required_for_commands: true
  backward_compatibility: required

delivery:
  unrelated_refactoring: prohibited
  integration_tests: required
  production_deployment: manual_approval

要留意 production_deployment: manual_approval：实现完成不等于获得生产发布权。另外，这只是示意策略，不是 specs.md 的原生配置文件；原文没有提供自动执行这些规则的工具实现。

第三，要求替代方案。一份带图表和取舍分析的完整设计文档，很容易让人误以为所有选项都已比较过。开发者应继续问：最简单的可行方案是什么？能否复用现有组件？哪些假设不成立时，这套设计就不适用？六个月后，什么情况会迫使团队推翻它？

第四，在正确的位置停止。遇到尚未解决的架构选择、破坏性操作、安全敏感变更或需求冲突，Agent 应当把问题交还给有权决定的人。

权责也需要分工：产品负责人决定业务结果，领域专家验证业务规则，开发者和技术负责人负责架构、可靠性及可维护性，获授权的运维负责人控制生产发布。AI 可以协助各方分析和执行，却不应悄悄接管这些权力。作者援引《The Scrum Guide（2020）》强调，改变执行方式，不应抹去开发者原有的质量责任。

短周期和完整规格，为什么不保证敏捷

spec-driven development（规格驱动开发）通过需求、架构、任务和测试等文档保存上下文，有助于追溯决策。但文档一旦因为「已经批准」而不可挑战，流程就可能重新变硬。

先生成并批准需求，再生成并批准架构，最后完成实现，才发现最初假设错了。即便每个 Bolt 都很短，整体也未必具有敏捷性。

规格的价值，在于帮助团队做决定、重新审视决定。必要时，它也应该允许修改或删除。

作者建议按风险划定自主执行边界：重命名局部变量不必申请许可，引入新的分布式架构则需要工程审批。下面的指令示例，用来约束涉及架构取舍的功能实现：

Before implementing this feature:

1. Identify the affected domain boundaries.

2. Propose at least two viable solutions,
   including one that reuses existing infrastructure.

3. Compare:
   - Complexity
   - Reliability
   - Operational cost
   - Backward compatibility
   - Migration effort
   - Failure recovery

4. Explicitly identify assumptions and unknowns.

5. Recommend the simplest solution satisfying
   the documented requirements.

6. Do not implement until the architectural
   decision is approved.

7. If new information invalidates the approved
   design, stop and request a new decision.

最容易被漏掉的是第 7 条：新信息推翻了已批准设计，就应暂停并重新决策。批准不能变成继续执行的永久通行证。

评价方法也需要改变。几个小时或几天搭出应用，只能展示初次交付。作者更关心六个月后：别人能否读懂架构，规格是否仍与实现一致，新功能能否安全加入，人工审查和修复要花多少力气，生产故障能否脱离原始 Agent 对话记录完成诊断。

完成多少个 Bolts、生成多少行代码，都回答不了这些问题。

我的判断

我认同作者对决策权的强调。尤其在成熟系统里，团队掌握的历史约束未必都写在仓库中。Agent 看见局部实现后提出的方案，可能漏掉过去事故留下的边界。

但文章没有展示真实团队的长期对照实验。预约案例、Redis 与 PostgreSQL 分开承载告警查询的案例，以及两组人机对话，都应按说明性案例阅读。它们解释了风险如何发生，尚不能证明这种风险出现的频率，也不能证明作者建议的流程一定降低维护成本。

「最简单」同样需要条件。复用数据库通常能减少运维负担，但若存在已经验证的隔离、吞吐或领域归属要求，新增基础设施也可能合理。拒绝方案需要理由，接受简单方案也需要理由。

和常见的「先生成、再在 PR 里审查」相比，作者的做法把重大取舍提前，能减少实现完成后才发现方向错误的返工机会。代价是前期讨论增加。因此，按风险分配自主权比每项改动都跑完整审批更实际；文章自己也明确反对让小改动承担完整架构审查。

能拿来做什么

• 给日常 AI 编程任务补上项目约束，例如使用 PostgreSQL、禁止无关重构、公共 API 不得破坏兼容，并对适用的约束进行版本管理和检查，避免每次会话重新口述。
• 当 Node 服务改动涉及新增缓存、消息队列或微服务时，先要求至少两种可行方案，其中一种复用现有基础设施，再比较可靠性、运维成本和迁移工作量。
• 为数据库迁移、公共接口兼容性和生产发布写清停止条件，指定由谁决策；执行中发现原假设不成立，就重新评审。
• 审查 AI 生成的 PR 时，除了看测试是否通过，还要确认新增依赖是否必要、规格是否同步，以及维护者能否脱离聊天记录理解设计和排查故障。