我的自动化质疑开发流程

# 我的自动化怀疑开发流程 来源：https://www.alexself.dev/blog/automated-doubt 该流程源于缺乏信任。早期进行AI辅助开发时，我因允许LLM伙伴做得太多、太快，且未遵循我已内化的标准工程实践而失去了信任。通过尽可能多地自动化怀疑，重新建立了信任。执行怀疑是什么样子的？反复批判一个制品的实现。如果你正在使用AI编写代码、规格、文档或其他制品，这篇文章或许对你有所启发。 我大量使用了子代理。它们处于整个过程的支点位置。它们专门用于审计那些标准Claude实例不一定覆盖到的视角表面。所有这些的核心思想是来自多个角度的自动化怀疑，以及前置的严格审查。AI开发中的视差覆盖越多越好；不同的视角捕捉不同的缺陷，就像两只眼睛赋予你深度一样。开发过程大致如下： ## 阶段 1 — 设计 一切始于一个想法或我想要构建的特性，以及一份规格。像任何好的开发实践一样，通常最好从规格、PRD、计划或任何你偏好的设计形式开始。我让Claude编写规格，然后花 2-5 分钟快速浏览文件，以确保该想法的核心实现方面被捕获。迭代过程由此开始。 我从一个预实现工作流（Claude Code 中的斜杠命令）开始，它由三个执行第一轮怀疑的代理组成：预实现架构师、文档验证者和假设挖掘者。这些代理做几件事：验证设计质量、范围评估、完整性、文档缺口以及规格中所有隐藏的假设。所有相关的发现都由主终端代理合并回规格中——通常根据想法的范围有 10-25 个。 示例发现： > **假设挖掘者：**"executionStatsSchema in registry-sdk returns {totalCount, recentCount, windowMinutes}. 规格假设 {avgScore, medianDurationMs, passRate, lastRunDate, lastRunScore}. 没有新的 API 端点，整个历史记录部分无法构建。" > **预实现架构师：**"HarnessProfile 嵌入了 mcp.read/merge/remove/write 方法以及路径配置。考虑提取 McpConfigStrategy 以分离关注点。否则每个 harness 文件将增长到 80-120 行。" 范围决定迭代次数。如果范围需要，迭代将继续下一组代理：差距分析者、隐含完整性检测者、歧义映射者。这些代理特别擅长发现系统中所有被省略的方面，如果不去处理，这些方面会被遗漏。当发现差距时，它们会被添加到规格中。 示例发现： > **差距分析者：**"McpConfigStrategy 定义了 read/merge/write，但没有指定对格式错误输入、权限拒绝、部分写入失败或文件锁定的行为。对 3 种格式的 4 个 harness 中的用户配置文件进行破坏性操作。" > **隐含完整性检测者：**"Manifest 在根目录记录版本，但安装状态是按 harness 记录的。当 v0.3.0 用户（Claude Code）使用 --harness opencode 运行 v0.4.0 时，行为未定义。未处理按 harness 的版本管理或升级协调。" 实际使用： - **小范围：**仅预实现 - **中范围：**预实现 + 差距、隐含、歧义 - **大范围：**全面扫描，每个多次运行，偶尔深入其他专门代理 现在我暂停，花大约 15-60 分钟阅读规格。如果一切没有问题且规格已准备好进行开发，我让 Claude 生成一份配套检查清单，我们可以更新并遵循。检查清单创建为一个单独的文件，如果需要在开发中途离开并关闭会话，它会很有帮助。 ## 阶段 2 — 开发 Claude 调出规格和检查清单并开始开发。如果我在一个新会话中接手部分完成的开发，我通常会先让 Claude 探索，或者发送一个 Chain Tracer 或 Deep Explore 子代理以获取完整图像后再重新开始。 我开发过程中的一个可能引人注目且我想强调的方面是：我不使用子代理进行写入。这又回到了信任的角度。我让子代理进行写入的经历常常出错，弊大于利，这导致了一个暂时的界限。我说暂时，是因为这无疑会改变。据我了解，有适当的 swarm 编排、worktree、代理驱动开发的方法，但目前超出了我的信任水平。有时 Claude 终端代理会生成它们进行批量更新，但我更喜欢单个 Claude Code 终端实例来构建项目。 我处理规格的所有阶段直到完成。验证构建是否正常，然后进入实现后开发过程。我提到了自动化怀疑，这正是它大放异彩的地方。开发过程的接下来几次迭代包括运行一个后实现工作流，由以下子代理组成：代码验证者、类型安全验证者、测试架构师、代码优化者、公共接口验证者和安全分析师。这些代理审计代码库并提供发现：代码与测试质量、安全态势、重复、性能考量、语义或结构完整性、文档、公共接口等。第一次运行通常会产生（取决于范围）15-35 个发现，通常前 15-20 个发现被标记为关键或高严重性。这些发现会被处理，然后我重新运行后实现工作流。接着处理下一轮问题，如此反复，直到达到我对质量应该有的样子的想法。 示例发现： > **代码验证者：**"每个其他执行方法在完成后都会调用 trackIfEnabled()。startPipeline() 直接返回 PipelineHandle，而没有跟踪。异步 pipeline 用户得不到任何跟踪数据。" > **安全分析师：**"PreflightError 包含 shellQuote-expanded 目标路径原文。包含已解析文件系统路径的错误消息可能传播到跟踪 API 和仪表盘。" ## 阶段 3 — 结稿和发布 一旦我对准备发布的内容满意，并且一切在实际和质量方面都检查通过，我就运行最终的工作流：Ship。该工作流由以下代理组成：代码验证者、类型安全验证者、测试架构师、代码审计者、公共接口验证者、安全分析师、焦虑读者、API 契约验证者（如果涉及 API）、发布就绪验证者。该工作流完成了前一阶段处理的迭代过程。其中 5/9 个代理已经在后实现工作流中，所以它们应该发现很少的问题或进入偏好调整领域，其余代理检查 API 契约（如果相关）、运行时一致性、可能出问题的地方以及系统的发布态势。运行此工作流时，问题是：这准备好发布了吗？取决于复杂性，可能需要 Ship 的 2 次或更多迭代。 示例发现： > **焦虑读者：**"Promise.allSettled 同时触发所有代理，没有并发限制，存在资源耗尽和 API 限速的风险。" > **代码审计者：**"writeReportFiles 中的文件 I/O 错误被 handleCoreError 捕获，该函数提供的是 SDK 特定的提示而不是文件系统特定的消息。" ## 结论 在哲学层面，这是制品、代理和操作者之间的协商，是质量概念汇聚之处。我们每个人都有自己对质量意味着什么的想法，甚至代理本身也有关于什么量化和符合质量的想法。这是我们与自己以及代理达成的协议：什么构成就绪状态。这一切的基础是我们旨在追求某种一致性、可用性、可读性、可维护性，而在这些之下，是我们能更有信心的东西。质量可以是一种主观状态，具有客观目标。我迭代直到这些想法汇合。如何知道何时终止循环？我认为这是直觉性的：耐心、实践、判断力以及你提出正确问题的专业知识的结合。下一次修复或特性是否值得投入精力？这又回到你准备发布的项目状态的个人阈值。艺术家永远不会完成，工程师会吗？最终取决于操作者。版本控制的好处在于，你总是可以以某种方式进行添加、删除或修改，而质量如何体现则源于偏好和制品的轨迹。 对该方法的一点考虑，我可以自信地说：这个过程在 token 消耗上不一定便宜。对于我们这些花了无数小时燃烧 token 并达到使用限制的人来说，这在我们如何用 AI 开发中可能扮演重要角色。对于某些项目，这个过程绝对是过度设计，而对于另一些项目，则根本不够，需要附加一套完全不同的代理进行审计。我个人倾向于运行这个过程并反复运行。我希望确保我用 Claude 或任何其他 AI 系统开发的代码可以被验证、确认，并且理想情况下达到更高的标准。有些项目可能只需要一个代码验证者和测试架构师进行审查，其他项目则涉及 40 多个不同角度的代理。如果至少有一个代理应该在任何制品（代码库、规格、文档等）上尝试，那就是假设挖掘者，因为它几乎普遍适用。 --- 该流程源于缺乏信任，现已发展成一个信任信号。 本文中提到的代理、命令和管道可在 github.com/aself101/agents-and-pipelines (https://github.com/aself101/agents-and-pipelines) 获取。