My automated doubt development process：构建AI辅助开发中的“自动化怀疑”工作流

背景

这一开发流程的起源源于一种“信任危机”。作者在早期使用 AI 辅助开发时，曾允许大语言模型（LLM）合作伙伴在过短的时间内承担过多的工作，且未遵循其内化的标准工程实践。这种过度依赖导致了信任的丧失。

为了重建信任，作者采取的策略是：尽可能将“怀疑”（Doubt）自动化。这里的“怀疑”并非指消极的否定，而是指对产物（如代码、规范、文档等）进行反复的批判性审查。核心思想在于从多个视角进行自动化怀疑，并将审查前置。在 AI 开发中，视角的视差覆盖（Parallax coverage）越多越好——就像双眼提供深度感知一样，不同的视角能捕捉到不同的缺陷。

核心内容

作者主要使用 Claude Code 及其子代理（Subagents）来执行这一流程。子代理处于整个流程的支点位置，它们以特定方式运作，能够审计标准实例（如普通的 Claude 调用）可能无法覆盖的视角表面。整个开发过程分为三个阶段：

第一阶段：设计（Design）

流程始于一个想法或功能需求，以及一份规范（Spec）。遵循良好的开发实践，作者首先要求 Claude 编写规范，并花费 2-5 分钟快速浏览文件，以验证核心实现方面是否被准确捕捉。这是迭代过程的起点。

1. 预实施工作流（Pre-implementation workflow）： 使用 Claude Code 的斜杠命令触发，由三个子代理执行第一轮“怀疑”：

   • Pre-Implementation Architect（预实施架构师）
   • Documentation Validator（文档验证器）
   • Assumption Excavator（假设挖掘器）

   这些代理负责验证设计质量、范围评估、完整性、文档缺口以及规范中存在的隐藏假设。所有发现的相关问题由主终端代理折叠并整合进规范中。通常会产生 10-25 个发现点。

   • 示例发现：
     • 假设挖掘器指出：registry-sdk 中的 executionStatsSchema 返回 {totalCount, recentCount, windowMinutes}，但规范假设的是 {avgScore, medianDurationMs, passRate, lastRunDate, lastRunScore}。这意味着在没有新 API 端点的情况下，整个历史记录部分无法构建。
     • 预实施架构师指出：HarnessProfile 将 mcp.read/merge/remove/write 方法与路径配置嵌入在一起，建议提取 McpConfigStrategy 以分离关注点，否则每个 harness 文件将增长至 80-120 行。

2. 深度迭代： 根据范围大小，迭代可能继续引入下一组代理：Gap Analyzer（缺口分析器）、Implied Completeness Detector（隐含完整性检测器） 和 Ambiguity Mapper（歧义映射器）。这些代理擅长发现系统中若未加处理将被遗漏的方面。

   • 示例发现：
     • 缺口分析器指出：McpConfigStrategy 定义了读写方法，但未指定对畸形输入、权限拒绝、部分写入失败或文件锁定的行为处理。这对用户配置文件构成了破坏性操作风险。
     • 隐含完整性检测器指出：清单在根目录记录版本，但每个 harness 的安装状态独立。当 v0.3.0 用户（Claude Code）运行 v0.4.0 并带有 --harness opencode 参数时，行为未定义。未解决每 harness 版本控制或升级协调问题。

3. 实践策略：

   • 小范围：仅使用预实施阶段。
   • 中等范围：预实施 + 缺口、隐含、歧义分析。
   • 大范围：全面扫描，多次运行各代理，偶尔引入其他专用代理。

4. 人工审查与清单： 作者会暂停 15-60 分钟阅读规范。如果一切就绪，要求 Claude 生成一个配套的检查清单（Checklist），作为单独文件保存，便于在开发中途暂停或恢复时跟进。

第二阶段：开发（Development）

Claude 读取规范和清单开始开发。如果在新的会话中接手部分完成的工作，作者通常会要求 Claude 进行探索，或发送 Chain Tracer 或 Deep Explore 子代理以获取完整上下文，然后再重启。

关键原则：不使用子代理进行写入（Writes） 这是作者流程中显著且强调的一点。出于信任考量，作者禁止子代理直接进行文件写入。过去子代理写入失控的经历往往弊大于利，因此作者划定了界限。虽然未来可能会改变，但目前作者倾向于让单个 Claude Code 终端实例构建项目，仅在必要时由 Claude 终端代理生成批量更新。

后实施工作流（Post-implementation workflow）： 开发完成后，进入“自动化怀疑”的高光时刻。运行包含以下子代理的工作流：

• Code Validator（代码验证器）
• Type Safety Validator（类型安全验证器）
• Test Architect（测试架构师）
• Code Optimizer（代码优化器）
• Public Interface Validator（公共接口验证器）
• Security Analyst（安全分析师）

这些代理审计代码库，提供关于代码与测试质量、安全态势、重复代码、性能考量、语义或结构完整性、文档及公共接口等方面的发现。首次运行通常产生 15-35 个发现点，其中前 15-20 个通常被标记为严重或高优先级。作者解决这些问题后重新运行工作流，直到达到其认为的质量标准。

• 示例发现：
  • 代码验证器指出：每个执行方法在完成后调用 trackIfEnabled()，但 startPipeline() 直接返回 PipelineHandle 而未进行跟踪。异步管道用户无法获得跟踪数据。
  • 安全分析师指出：PreflightError 包含未经处理的 shell 扩展目标路径。包含解析后的文件系统路径的错误消息可能会传播到跟踪 API 和仪表板。

第三阶段：收尾与发布（Wrap-up and Ship）

当作者认为准备就绪且实际与质量检查均通过时，运行最终工作流：Ship（发布）。

该工作流包含以下代理：

• Code Validator
• Type Safety Validator
• Test Architect
• Code Auditor（代码审计器）
• Public Interface Validator
• Security Analyst
• Anxiety Reader（焦虑读取器）
• API Contract Validator（如果是 API）
• Release Readiness Validator（发布就绪验证器）

此工作流旨在终结前一阶段的迭代。由于其中 5/9 的代理已在后实施阶段使用过，它们应发现极少问题或进入偏好领域。其他代理则检查 API 契约、运行时一致性、潜在故障点及系统的发布态势。核心问题是：“这准备好发布了吗？”根据复杂性，可能需要 2 次以上的 Ship 迭代。

• 示例发现：
  • 焦虑读取器指出：Promise.allSettled 同时触发所有代理且无并发限制，存在资源耗尽和 API 速率限制风险。
  • 代码审计器指出：writeReportFiles 中的文件 I/O 错误由 handleCoreError 捕获，该处理程序提供 SDK 特定的提示，而非文件系统特定的消息。

关键要点

• 信任重建机制：通过自动化“怀疑”（即多视角的批判性审查）来重建对 AI 辅助开发的信任，而非盲目信任 AI 的输出。
• 子代理的核心作用：利用 specialized subagents（专用子代理）提供不同视角的审计，弥补标准 LLM 实例的视角盲区，实现“视差覆盖”。
• 分阶段审查策略：
  • 设计阶段：重点在于消除假设、填补规范缺口、明确歧义。
  • 开发阶段：重点在于代码质量、类型安全、测试覆盖、安全性及公共接口一致性。
  • 发布阶段：重点在于发布就绪度、