一名开发者在 5 月 22 日发布了一套基于 Claude Code 的 AI 辅助开发流程。他把它称为“Automated Doubt”，核心做法不是让模型一路写到底，而是用多个子代理反复审查规格、代码和发布准备状态。
这不是 Anthropic 官方方法，也不是一套能保证无缺陷的银弹。它真正有参考价值的地方在于：当大模型写代码的速度超过人类审查节奏时，开发者需要重新设计“信任从哪里来”。
从信任危机到自动化怀疑
作者的起点很现实：早期过度放权给 LLM，代码来得快，但信任掉得更快。于是他把子代理主要放在审查位置，而不是写入位置。规格、实现、发布前状态，都要经过不同角度的质疑。
这和过去的工程惯例并不冲突。传统团队靠设计评审、代码评审、测试计划、安全审计和发布清单来控风险；这套流程只是把一部分审查动作交给 LLM 子代理执行。差别在于，AI 写代码越快，审查也必须更频繁、更前置。
| 阶段 | 关键动作 | 代表代理 | 判断 |
|---|---|---|---|
| Design | 先写规格，再审查假设、遗漏和歧义 | Assumption Excavator、Pre-Implementation Architect、Gap Analyzer | 把问题挡在实现前 |
| Development | 主 Claude Code 实例写代码，子代理做审查 | Code Validator、Test Architect、Security Analyst | 作者暂不信任子代理直接写代码 |
| Wrap-up and Ship | 发布前再跑一轮准备度检查 | Release Readiness Validator、API Contract Validator、Anxiety Reader | 形成发布信号，不等于无缺陷保证 |
三阶段流程的重点不是“多代理”，而是分工边界
在设计阶段，作者会让 Claude 生成规格，自己先快速确认核心方向，再启动 Pre-implementation 工作流。Assumption Excavator 会挖出规格里的隐藏前提，Documentation Validator 检查文档缺口，Pre-Implementation Architect 看设计质量和范围。
任务规模决定审查强度。小任务可能只跑一轮前置审查；中等任务会加入 Gap Analyzer、Implied Completeness Detector、Ambiguity Mapper；大任务才会多轮扫描，甚至调用更多专门代理。这一点很关键：它不是一套不分场景的重流程。
开发阶段反而更克制。作者明确说自己不让子代理写代码，原因是过去让子代理批量写入造成过损害。他更倾向于由一个 Claude Code 终端实例完成实现，再用 Code Validator、Type Safety Validator、Test Architect、Code Optimizer、Public Interface Validator 和 Security Analyst 做事后审查。
发布前的 Ship 工作流则像一次小型发布评审。Code Auditor 看实现一致性，Release Readiness Validator 看能否交付，API Contract Validator 只在涉及 API 时加入。问题可以继续修，但循环何时停止，最终还是人来判断。
受影响的是技术负责人，不是只想“快点出活”的人
这套方法最适合两类人：已经在用 AI 编程工具的开发者，以及要为代码质量和发布风险负责的技术负责人。对他们来说，真正的动作不是照抄代理名单，而是把审查问题写进流程：规格是否可实现，测试是否覆盖关键路径，公共接口是否稳定，安全风险是否被记录。
横向看，GitHub Copilot、Cursor、Claude Code 都在把生成代码变得更顺手，但行业现实是，生成能力进步快于组织的验收能力。很多团队的问题不是不会让 AI 写，而是不知道何时该停、该查、该拒绝。
限制也很硬。作者承认这套流程 token 成本高，部分项目会过度；有些项目只需要 Code Validator 和 Test Architect，有些复杂系统可能需要更多审计视角。接下来最该观察的不是代理数量，而是这些审查能否产生高质量信号：能不能指出真实缺陷，能不能减少人工盲区，能不能被团队稳定复用。
更难的是终止判断。LLM 可以不断提出问题，但工程不是无限修补。发布前那一刻，仍要有人决定“够不够好”。自动化怀疑能提高信任信号，却不能替代责任归属。