这个过程源于缺乏信任。在我的 AI 辅助开发初期，由于允许我们的 LLM 合作伙伴做得太多、太快，并且没有遵循我已经内化的标准工程实践，导致我失去了信任。通过尽可能自动化怀疑，重新获得了信任。那么，执行怀疑的过程是什么样的呢？就是批评某个工件的实施，并反复进行。如果您使用 AI 来编写代码、规格、文档或任何工件，您可能会发现这篇文章很有用。我使用了许多子代理。它们是整个过程的支点。它们的专业化可以审计出标准 Claude 实例可能遗漏的视角表面。所有这些的核心思想是从多个角度自动化怀疑，并提前进行审查。在 AI 开发中，覆盖的视差越多越好；不同的视角捕捉到不同的缺陷，就像两只眼睛提供了深度。开发流程大致如下：第一阶段 — 设计。这一切始于我想要构建的想法或特性和一份规格。像任何好的开发实践一样，通常从一个规格、PRD、计划或任何喜欢的设计形式开始是明智的。我请 Claude 编写规格，并花 2-5 分钟浏览文件，以核实核心实施方面是否得到了捕捉。这就是迭代过程开始的地方。我开始一条初步实施工作流程（在 Claude Code 中的斜杠命令），由三个代理执行第一轮的怀疑：初步实施架构师、文档验证者和假设挖掘者。这些代理执行几项任务：验证设计质量、范围评估、完整性、文档缺口和规格中所有隐藏的假设。所有相关的发现都由主要终端代理折叠到规格中 — 通常是 10-25 个，具体取决于想法的范围。示例发现：假设挖掘者："registry-sdk 中的 executionStatsSchema 返回 {totalCount, recentCount, windowMinutes}。规格假定 {avgScore, medianDurationMs, passRate, lastRunDate, lastRunScore}。没有新的 API 端点，整个历史部分无法构建"；初步实施架构师："HarnessProfile 嵌入了 mcp.read/merge/remove/write 方法以及路径配置。考虑提取 McpConfigStrategy 以分离关注点。否则，每个程序包文件将增长到 80-120 行。" 范围决定我进行的迭代次数。如果范围需要，迭代会继续进行到下一组代理：缺口分析师、隐含完整性探测器、模糊图绘制者。这些代理特别擅长发现系统中所有未解决的方面，这些方面如果不加以处理将被遗漏。当发现缺口后，这些缺口会被添加到规格中。示例发现：缺口分析师："McpConfigStrategy 定义了读取/合并/写入，但未指定对格式不正确的输入、权限被拒、部分写入失败或文件锁定的行为。对 3 种格式中的 4 个程序包中的用户配置文件进行破坏性操作。" 隐含完整性探测器："Manifest 在根目录记录版本，但每个程序包的安装状态。当 v0.3.0 用户（Claude Code）以 --harness opencode 运行 v0.4.0 时，行为未定义。每个程序包版本控制或升级协调未得到解决。" 实际使用：小范围：仅进行初步实施；中等范围：初步实施加上缺口、隐含、模糊；大范围：全面扫查，多次与每个进行运行，偶尔深化到其他专业代理。现在我暂停，花一些时间阅读规格，约 15-60 分钟。如果一切正常，规格准备好进行开发，我请 Claude 生成一个伴随清单，我们可以更新并跟随。这个清单作为一个单独的文件创建，有助于在开发中需要离开并关闭会话时使用。第二阶段 — 开发。Claude 调出规格和清单并开始开发。如果我在新会话中继续部分完成的规格，通常会请求 Claude 探索，或者发送一个链追踪器或深度探索子代理，以便在重新启动之前获得完整画面。我的开发过程中的一个突出的方面，我想强调的是：我不使用子代理进行写入。这又回到了信任的问题。过去让我误用子代理进行写入的经历，往往造成了比好处更多的伤害，这导致我在沙滩上划了一条暂时的分界线。我也说是暂时的，因为这无疑会改变。根据我的理解，有一些合适的群体协调、工作树、代理驱动的开发方法，但这超出了我目前的信任水平。有时 Claude 终端代理会为批量更新生成它们，但我更喜欢一个独立的 Claude Code 终端实例来构建项目。我处理规格的所有阶段，直到完成。验证构建是否正常工作，然后进行后期实施开发过程。我提到了自动化的...