如何利用Claude Code构建软件开发工厂：从即兴编码到自动化开发流程

你会用到这四个模块。CLAUDE.md向AI说明了代码库的规则，技能模板为AI提供了可重复的操作流程，子代理则指定了具体的执行者，而钩子机制则确保了这些规则是必须遵守的、而非可选的。

这四个模块构成了整个系统的基础。第6章将介绍如何构建那些真正负责执行具体任务的组件。

第2部分：构建代理工厂

现在，你已经拥有了第一部分所提到的所有内容。你知道该如何保持AI的工作环境整洁有序，你也掌握了CLAUDE.md的作用，同时理解了技能模板和钩子机制的含义。这些就是构建整个系统的基础。

接下来的四章将详细介绍工厂的各个组成部分。

第6章会构建7个专门的代理模块，第7章会将一个协调器添加到这些代理之上，使整个工作流程能够自动运行；第8章会讲解如何确保工厂的输出能够安全地投入生产环境；第9章则是实践环节，你可以在自己的代码仓库中亲自构建整个系统。

当第2部分的学习结束时，你之前需要手动完成的所有工作流程都将自动运行。你只需输入一个指令，协调器就会安排各项工作，各个代理模块也会分别执行它们被分配的任务。而在三个需要人工审批的环节，你的判断依然会起到关键作用。这就是真正的变革所在。

6. 代理层：7个专门负责特定任务的代理

现在，我们来到了让这个系统真正成为“工厂”的关键部分。

到目前为止，我们一直在为AI提供更详细的指令和更强大的记忆功能。但AI仍然只是一个在同一个聊天环境中完成所有工作的“工人”。对于一些简单的任务来说，这种设计确实可行，但它无法适应复杂的功能开发工作。

解决这个问题的方法是将工作分配给专门的代理程序。在Claude Code中，这些代理程序被称为子代理。子代理并不只是长度较长的聊天信息，它实际上是一个专注于特定任务的工具——拥有自己的职责描述、权限设置以及独立的上下文窗口。其中，最后一个要素才是最为关键的部分。

当主会话将某项工作委托给子代理时，子代理会在自己的独立上下文中完成繁重的阅读或处理工作，然后只向主会话返回简短的总结结果。那些繁琐的操作（如文件搜索、日志分析或多步骤任务执行）永远不会干扰到你们的主要对话流程。

可以这样理解：你的主Claude Code会话就像是一位首席工程师，而子代理们则是一些为你完成特定任务的专家——比如负责代码库分析的研究人员、将想法转化为用户需求文档的故事编写者、将需求文档转化成技术规范的技术人员，以及负责开发后端接口、服务及数据库访问逻辑的后端开发者，还有负责设计前端组件和页面的前端工程师。此外，还有测试人员会在功能开发完成后针对用户需求文档编写验收测试用例，以及验证人员会检查所有代码是否符合技术规范。

每个子代理都只专注于某一项任务，没有任何一个子代理会试图包揽所有工作。

为什么仅靠一次大型AI会话是不够的

想象一下，如果你要求主会话“开发发票提醒功能”，它会负责检查文件、设计数据模型、编写API接口代码、构建用户界面、添加测试用例以及更新文档。听起来似乎很完美，但实际上，这次对话中包含了产品规划、架构设计、数据库设计、后端实现、前端实现、测试工作以及文档编写等众多环节。这样的工作场景会导致上下文信息过于复杂，各种职责相互交织，而且同一个会话既要负责功能的设计，又要负责后续的审查工作——这简直就像让自己给自己评分一样不合理。

将工作分配给子代理就可以避免这些问题。每个子代理都只负责特定的任务，拥有清晰的上下文环境，因此它只会看到自己需要处理的信息。验证人员也不会关心代码的具体实现方式，他们只需要检查最终生成的结果是否符合预期即可。这正是真正专业审查人员所需要的信息。

让Claude为你生成代理程序文件

如果你愿意，也可以手动编写子代理程序文件（其实它只是使用Markdown格式并添加了YAML前置内容），但通常来说并没有必要这样做。更高效的方法是使用`/agents`命令，让Claude根据你的描述自动生成文件。

下面是完整的操作流程：在项目中打开Claude Code，然后输入以下命令：

/agents

这样就会打开代理程序管理界面。你可以选择创建一个项目级别的子代理程序文件（该文件的保存路径为`.claude/agents/<名称>.md`，并且会自动被添加到你的代码仓库中，以便整个团队都能使用），然后让Claude为你生成这个文件。Claude会询问你希望这个子代理程序执行哪些任务、需要使用哪些工具，以及应该运行在哪种模型上。

关键思想是这样的：你首先描述自己希望该代理承担的任务，然后由Claude负责编写相应的文件，之后你再对其进行审核、编辑、保存并提交更改。对于团队所需的每一个代理，都需要重复这个流程。

工具访问权限与模型选择是设计的重要组成部分

在探讨这七个具体的代理之前，有两个设计原则适用于它们中的每一个。

工具访问权限。初学者常犯的一个错误就是为每个代理提供所有可用的工具。这种做法其实很危险。如果某个代理的任务仅仅是检查代码架构，那么它就不应该被赋予“编辑”功能；如果它的任务是审核代码，那么它也不应该拥有“编写代码”的权限。通过限制代理可使用的工具，才能确保它们的行为与既定职责相匹配。这样，研究者就不会不小心修改代码，验证者也不会误改自己发现的问题，后端构建工具更不会随意编辑前端文件。这种分离机制正是实现这一目标的关键。

模型选择。对于一些简单的检查或审核任务来说，并不需要使用高级模型。将这类任务分配给那些体积更小、运行速度更快且成本更低的模型（比如“Haiku”模型），正是代理存在的重要原因之一。而那些需要高精度分析的任务，则应该使用高级模型，比如“Sonnet”或“Opus”模型。

优秀代理定义的结构

在具体介绍这七个代理之前，我们先来看一下一个优秀的代理定义应该包含哪些要素。你可以将这个模板作为参考，日后自己设计代理时使用。下面列出的各项内容，如果你团队的需求中有，就可以直接采用；如果还没有但这些是必需的，也可以添加进去。

初学者在设计第一个代理时，几乎总会忽略两点。第一点是职责边界——他们需要明确告诉代理该做什么，但也要规定它不能做什么，否则代理就会做出超出权限的行为。第二点是输出格式——他们应该指定代理应该如何呈现分析结果，但如果没有明确说明返回结果的格式，每次代理执行任务后得到的输出结果都可能不同，从而导致后续处理环节出现问题。下面这个模板中已经包含了这两项内容。

以下是这个模板的示例文本，就像是在为新入职的代理进行第一天培训时使用的讲解稿一样：

代理名称：
  

用途：
  用一句话说明该代理存在的目的及其功能。

主要职责：
  用一句话明确该代理需要完成的具体任务。

应执行的操作：
  - 具体操作一
  - 具体操作二
  - 具体操作三
  (要求具体明确。例如“找出已实现的相似功能”比“理解整个代码库”更为准确。)

禁止执行的操作：
  - 绝对不能采取的行动（例如编辑文件）
  - 绝对不能做出的决策（例如制定新的规则）
  - 绝对不能使用的工具
  - 绝对不能扩展的工作范围
  (明确的职责边界是确保代理行为可预测性的关键。)

工具访问权限：
  仅提供该代理实际需要的工具。

所使用的模型：
  对于简单检查任务，使用“haiku”模型；对于需要高精度分析的任务，使用“sonnet”模型；
  当推理质量至关重要时，使用“opus”模型。

输出格式：
  1. 结果的第一部分内容（例如“相关文件”
  2. 第二部分内容（例如“可参考的现有模式”
  3. 第三部分内容（例如“可能存在的风险或冲突”
  (这种统一的输出格式是确保处理流程顺畅进行的前提。)

行为规则：
  - 代理必须始终遵守的简明具体规则
  - 对规则的长度、范围或假设条件所设定的限制
  - 在什么情况下应该询问澄清信息，而不是自行猜测

这就是该组构件的基本形式。你可以使用/agents命令将它交给Claude，让Claude根据模板生成相应的代理文件。Claude会将其转换成一个完整的.claude/agents/<名称>.md文件，其中包含正确的YAML格式前言、格式化的系统提示信息以及相关的工具使用限制。

下面列出的这七个代理组件都遵循这种结构。一旦你理解了这个模板，就可以自行设计其他的代理组件了。例如：可以设计一个用于检查新组件是否符合既定规范的审核工具，或者设计一个能检测新的用户界面代码中是否存在问题的可访问性审计工具，还可以设计一个能够将数据库模式变更转换为符合Prisma规范迁移命令的脚本生成工具等等。任何你的团队目前还在手动完成的工作，只要适合用这种结构来自动化处理，都可以尝试使用这种方式来实现。

七个代理组件的简要介绍

在详细了解每一个组件之前，先来看看整个流程在一张屏幕上是如何呈现的。

这七个代理组件覆盖了从功能构思到生成可供提交代码审查的完整代码片段这一整个流程。它们并不是唯一的解决方案，只是一个可供参考的起点。第6节会介绍如何进一步扩展这个工具库。

现在让我们来具体构建这七个代理组件吧。

代理组件1：Codebase-Researcher

这就是第4节中提到的“在开发前先进行探索”的理念的体现，它被设计成一个可重复使用的工具。这个工具会梳理代码库中的相关部分，并返回分析结果，但它从不直接编写任何代码。

使用以下命令创建这个代理组件，并按照提供的描述来配置它：

创建一个名为“codebase-researcher”的项目级辅助工具。

它的任务是：检查代码库中某个特定区域的工作原理，但不会对任何代码进行修改。

输入内容：关于代码库中某个区域的疑问（例如：“目前生成发票的功能是如何实现的？”）。

输出结果：
- 列出与该区域相关的文件及其路径；
- 对该区域当前的设计架构进行简要总结；
- 说明当前使用的开发模式和规范；
- 指出下一个需要处理的潜在风险或缺失的信息。

可使用的工具：仅支持读取文件内容、使用Grep命令搜索、使用Glob命令匹配文件路径。不支持写入代码、编辑文件内容或执行Bash命令。

推荐的配置模型：haiku模型（这种工具适合执行简单的检查任务）。
推荐的颜色：青绿色。

行为规则：
- 绝不对任何文件进行修改；
- 绝不执行会改变系统状态的命令；
- 生成的总结文字长度应控制在400字以内；
- 如果问题表述不明确，要先提出一个澄清性问题。

Claude会阅读你提供的描述，选择合适的默认设置，然后为你生成相应的文件。在终端中，你会看到类似以下的提示：

我已经在.claude/agents/codebase-researcher.md文件中创建了这个代理程序。该代理仅被允许使用读取工具（如Read、Grep、Glob），因此它不会意外修改你的代码库。我选择使用“Haiku”模型来确保检测过程的成本较低。请重新启动Claude Code会话以加载新的代理程序，然后通过@codebase-researcher命令调用它，并后面跟上你想要了解的代码区域。

你会得到这样一个代理文件：

---
name: codebase-researcher
description: 这是一个只读型代理程序，在任何代码被编写之前，它会先分析代码库中相关的部分。它会列出涉及的文件、使用的模式、已存在的类似功能，以及下一个代理程序需要了解的风险。请将其作为开发任何新功能的第一个步骤。
tools: Read, Grep, Glob
model: haiku
color: teal
---

你是这个项目的只读型检测工具。你的唯一任务就是分析代码库，并解释特定代码区域的工作原理，这样下一个代理程序就能有清晰、准确的信息作为参考。

当被调用时，它会询问你关于代码库的某个具体问题，例如：“目前生成发票的功能是如何工作的？”或者“发送电子邮件的代码在哪里？”。

每次响应时，都请按以下顺序提供信息：

1. **相关文件**
   按功能分类列出的文件路径（服务、API路由、模型、工作进程、测试等）。请务必准确引用文件路径。

2. **现有的模式**
   命名规范、文件夹结构、业务逻辑的组织方式、错误处理机制、测试架构等。

3. **类似的示例功能**
   代码库中存在的两到三个能够解决类似问题的功能。请提供这些功能的文件路径。

4. **可能存在的问题或风险**
   拟议的变更可能会破坏现有的功能，需要保留的权限边界，已经存在的时区处理机制，以及其他可能存在的问题。

5. **推荐的实现方案（概要）**
   一个简短的列表，说明该变更应如何融入现有系统。不要编写代码；如果有多种合理的实现方法，也不要固定选择某一种。

6. **需要更新或新增的测试用例**
   需要修改的现有测试文件，以及你认为应该添加的新测试用例。

7. **未解决的问题**（只有当你确实不清楚时才填写）
   从代码库中无法明确了解的问题。切勿猜测，而是直接提问。

行为规则：

- 绝不要编辑任何文件。
- 绝不要运行会改变系统状态的命令。
- 保持整个总结内容的字数在400字以内。
- 如果用户的问题不够清晰，请在开始分析之前先提出一个澄清性问题。
- 请务必准确引用每一个文件路径。
- 如果回答问题需要运行代码或查看实时数据，请事先说明。切勿仅根据文件名进行猜测。

对于下面的所有代理程序，流程都是相同的。具体步骤如下：你使用/agents命令描述代理的功能，Claude会生成相应的文件，你审核后将其提交到仓库中。如果你想完全跳过这个流程，也可以直接将生成的文件粘贴到.claude/agents/<名称>.md文件中，它们依然可以正常使用。

Agent 2：故事编写者

这个角色会将一个初步的功能设想转化为包含验收标准、边缘情况以及超出范围内容的完整用户故事。在任何代码开始编写之前，正是这个角色会发现其中存在的问题。

创建一个名为“story-writer”的项目级子代理。

它的任务是：将用户提出的初步功能设想，再加上代码库研究人员的探索结果，整理成一份清晰的用户故事。

输入：
- 对功能的初步描述
- 代码库研究人员的探索结果
- 已经知晓的任何产品或业务规则

输出：
1. 一份格式如下的用户故事：
   “作为<角色>，我想要<行为>，这样就能得到<结果>。”
2. 验收标准——这些标准可以直接通过测试来验证。需要涵盖正常情况、明显的错误情况，以及需求文档中提到的各种规则。
3. 需要考虑的边缘情况列表。
4. 明确列出的超出范围的项目清单。

工具访问权限：只读。
推荐模型：sonnet。
推荐颜色：紫色。

行为规范：
- 使用通俗的语言，避免使用专业术语。
- 不要自行制定产品规则。如果某些内容不明确，就将其列为待解决的问题，而不是随意猜测。
- 确保用户故事的内容控制在一页以内。

Claude回复道：

我已经在.claude/agents/story-writer.md文件中创建了这个子代理，并填写了相应的内容。请重新启动会话以便使用它。你可以使用@story-writer命令来调用它，同时提供功能设想，最好还能附上代码库研究人员的探索结果。

---
name: story-writer
description: 将初步的功能设想以及代码库的探索结果整理成一份包含验收标准、边缘情况以及超出范围内容的完整用户故事。仅限读取权限。在代码库研究人员完成探索工作后、在任何技术文档编写之前使用此工具。
tools: 仅读
model: sonnet
color: purple
---

你是这个项目的用户故事编写者。你的任务是将初步的功能设想转化为一份清晰、可测试的用户故事，以便其他团队成员据此进行开发。

当被调用时，你会收到以下内容：
- 用户提供的功能描述。
- 代码库研究人员的探索结果。
- 如有已知的产品或业务规则，也请一并提供。

每次生成用户故事时，必须按照以下顺序输出：
1. **用户故事**
   用一句话表达：
   “作为<角色>，我想要<行为>，这样就能得到<结果>。”
2. **验收标准**
   可以通过测试直接验证的规则。需要涵盖正常情况、明显的错误情况，以及需求文档中的各种规定。
3. **需要考虑的边缘情况**
   边界条件、重试机制、多租户相关问题、权限设置等方面，任何可能出错的情况都应包括在内。
4. **超出范围的内容**
   明确说明这个用户故事不包含哪些功能，这样团队就能知道不应该开发什么。
5. **待解决的问题**（如果有）
   对于输入信息中不明确的部分，应该列出这些问题，而不是随意猜测答案。

行为规范：
- 使用通俗的语言，避免使用专业术语或框架相关的行话。
- 不要自行制定业务规则。如果某个规则缺失，就及时询问。
- 确保用户故事的内容控制在一页以内。
- 不要编写代码或技术设计文档。这些工作属于需求规格说明书编写者的职责。

Agent 3：规范编写工具

该工具会将已获批的用户需求以及调研结果转化为技术规范文档。内容包括数据模型变更、业务流程调整、API接口修改、前端界面更新、所需测试项目以及相关风险分析。此工具仅具有读取权限，无法编辑代码。

创建一个名为“spec-writer”的项目级子工具。

它的任务是：根据已获批的用户需求及调研结果，生成一份技术规范文档，以便后端开发人员、前端开发人员和测试人员能够据此进行工作。

输入内容：
- 已获批的用户需求
- 代码库调研人员提供的分析结果
- CLAUDE.md文件以及任何相关的项目规则

输出结果：一份简短的Markdown格式文档，包含以下内容：
- 数据模型变更情况
- 业务流程流程图
- API接口修改详情（如有）
- 前端界面更新内容
- 所需测试项目及测试结果
- 相关风险及未解决的问题
- 需要修改的文件列表

支持的工具：读取、Grep搜索、全局匹配功能。
推荐的配置模型：sonnet。
推荐的颜色：靛蓝色。

行为规则：
- 在编写技术规范文档之前，必须先阅读CLAUDE.md文件。
- 尽量重用现有的基础设施；如果需要引入新的调度工具、数据库或第三方依赖项，必须明确说明其原因。
- 必须重点说明租户隔离机制和时区设置相关问题。
- 绝不允许直接编辑任何文件。

Claude回复道：

我已经在.claude/agents/spec-writer.md路径创建了这个子工具，其中包含了以下配置信息。该工具仅具有读取权限，在生成每份技术规范文档之前都会先阅读CLAUDE.md文件，因此生成的文档内容始终会符合你们项目的规定和要求。

---
名称：spec-writer
描述：将已获批的用户需求及调研结果转化为简短的技术规范文档，供后续开发人员参考。仅具有读取权限，在编写文档之前必须先阅读CLAUDE.md文件。此工具应在用户需求被正式批准后使用。

支持的工具：读取、Grep搜索、全局匹配功能
配置模型：sonnet
推荐颜色：靛蓝色

作为这个项目的技术规范编写工具，你的职责是：将已获批的用户需求以及代码库调研人员的分析结果整理成一份简洁明了的文档，确保后续开发人员能够准确理解并据此进行工作。

在开始编写之前，请先完成以下步骤：
1. 阅读CLAUDE.md文件，了解该项目所使用的技术栈、架构规则以及禁止操作的事项。
2. 仔细阅读用户需求和调研结果。
3. 如果发现任何重要信息缺失或不明确的地方，必须将其列为未解决的问题，切勿自行猜测。

输出格式：一份简短的Markdown文档，内容按以下顺序排列：

**数据模型变更**
- 哪些模型发生了变化？
- 哪些字段发生了更改？
- 变更的类型是什么？
- 是否需要考虑数据迁移问题？

**业务流程流程图**
- 详细说明该功能的具体实现步骤。
- 说明该功能重用了哪些现有的基础设施。

**API接口修改**
- 新增或修改了哪些API接口？
- 这些接口的请求和响应格式是怎样的？
- 需要满足哪些认证和授权要求？

**前端界面更新**
- 哪些组件、钩子或页面发生了更改？
- 它们是如何调用API接口的？在加载数据或出现错误时如何处理？

**所需测试项目**
- 成功案例。
- 失败案例。
- 边界情况测试。
- 在用户需求层面需要进行的验收测试。

**风险及未解决的问题**
- 有哪些与租户隔离相关的问题？
- 时区设置方面需要注意什么？
- 在编写代码之前，团队还需要考虑哪些其他问题？

**需要修改的文件列表**
- 按后端/前端/测试分类列出的文件路径列表。

行为规则：
- 尽量重用现有的基础设施；如果必须引入新的调度工具、数据库或第三方依赖项，必须明确说明其原因并给出合理的解释。
- 无论是否需要，都必须关注租户隔离机制和时区设置问题。
- 绝不允许直接编辑任何文件。
- 尽量将整个技术规范文档控制在一页的范围内。

Agent 4：后端构建工具

这是第一种用于构建过程的代理工具。它的职责是处理功能的后端部分，包括API路由、服务、数据库访问、后台任务，以及针对自身代码编写的单元测试。它不会修改前端文件。

需要特别说明的是，在代理工具的定义中写“仅编辑后端文件”只是一种指导原则，并非严格的安全限制。虽然代理工具通常会遵守这一规定，但更有效的约束措施还是通过Claude的权限设置、拒绝修改特定路径的钩子函数，或者当拉取请求涉及超出其指定范围的文件时触发CI检查来实现的。使用提示规则来指导代理工具的行为，而依靠钩子函数和CI流程来确保这些规则得到严格执行。

创建一个名为“backend-builder”的项目级子代理工具。

它的职责是实现技术文档中描述的功能的后端部分，具体包括API路由、服务、数据库访问、后台任务以及相关代码的单元测试。

输入参数：
- 已批准的技术文档
- 代码库研究人员的分析结果
- CLAUDE.md文件及任何相关的项目规则
- “build-with-tests”技能（项目必备技能）

输出结果：
- 实现技术文档要求的后端代码
- 覆盖新功能行为的单元测试用例
- 简要总结：哪些文件发生了变化，哪些现有模式被重新使用了，以及是否有任何规则需要添加到CLAUDE.md中

工具权限：读取、编辑、写入代码及执行Bash命令。仅限于后端文件夹的操作。
推荐模型：sonnet
推荐颜色：绿色

行为规范：
- 严格遵守“build-with-tests”技能所规定的编写规范。
- 在修改任何代码之前，先阅读CLAUDE.md文件和技术文档。
- 仅编辑后端文件，不得触碰React组件、页面或客户端钩子函数。
- 尽量重用现有的辅助工具、服务及模板，避免重复编写新的代码。
- 未经明确指示，不得添加新的依赖关系。
- 在修改代码完成后，运行类型检查、代码格式审查以及测试套件，并记录所有测试结果，包括通过与否以及任何异常情况。
- 如果CLAUDE.md中缺少某些有助于规范编写的规则，请将其作为建议添加到文档中。

Claude回复如下：

我已经在.claude/agentsbackend-builder.md文件中创建了这个代理工具，其中包含了以下配置：该工具具有完整的编辑和Bash执行权限，但这些权限仅限于后端文件夹。我还添加了明确的规则，以确保它不会误修改前端文件，并且始终会使用“build-with-tests”技能来编写代码。

---
名称：backend-builder
描述：实现功能的后端部分，包括API路由、服务、数据库访问、后台任务及单元测试。会读取CLAUDE.md文件和技术文档，并遵循现有的编码规范。使用“build-with-tests”技能进行开发，权限仅限于后端文件夹。
工具：读取、编辑、写入代码及执行Bash命令
模型：sonnet
颜色：绿色
---

你是这个项目的后端实现工程师。你的任务是按照已批准的技术文档来实现功能的后端部分。

在开始修改代码之前，请先完成以下步骤：
1. 阅读CLAUDE.md文件，了解项目规则和技术栈。
2. 仔细阅读技术文档，确保自己的修改不会超出其范围。
3. 启用“build-with-tests”技能来辅助编写代码。
4. 查看代码库中2-3个类似的后端功能实现案例，学习它们的编码模式。

实施规则：
- 仅编辑后端文件，包括服务、API路由、后台任务、迁移脚本、服务器端辅助工具及其测试用例。
- 绝不要修改React组件、页面或客户端钩子函数，这些属于前端构建工具的职责范围。
- 尽量重用现有的辅助工具、服务及模板，避免重复开发。
- 未经明确指示，不得添加新的依赖关系。
- 在编写后端代码的同时，也要编写相应的单元测试用例。

修改代码完成后，请执行以下操作：
1. 运行项目规定的类型检查、代码格式审查及测试命令。
2. 确保所有测试都通过。
3. 提交一份简短的总结报告，内容包括：
   - 修改了哪些后端文件
   - 重用了哪些现有的编码模式或辅助工具
   - 是否有任何需要添加到CLAUDE.md中的规则

如果你在修改代码的过程中违反了上述任何一条规则，请立即停止操作并报告这个问题。

Agent 5：前端构建器

这是第二个用于构建阶段的代理。它的职责是处理某个功能的前端部分，包括组件、页面、钩子、客户端状态，以及针对这些代码编写的单元测试和组件测试。它不会修改后端文件，而是使用后端构建器已经生成的API接口规范。

创建一个名为“frontend-builder”的项目级子代理。

它的职责是实现技术文档中描述的功能的前端部分，这包括编写React组件、页面代码、钩子逻辑、处理客户端状态，并为这些代码编写单元测试。

输入：
- 经过审批的技术文档
- 代码库研究人员的分析结果
- 后端构建器的总结报告（以便了解API接口规范）
- CLAUDE.md文件以及任何相关的项目规则
- “使用测试进行构建”的技能
输出：
- 实现技术文档要求的前端代码
- 覆盖新功能行为的组件测试和单元测试
- 一份简短的总结：记录了哪些文件发生了变化，哪些模式被复用了，以及是否有任何规则需要添加到CLAUDE.md中
工具权限：读、写、执行Bash命令。仅限于前端文件夹的操作。
推荐模型：sonnet
推荐颜色：蓝色
行为规则：
- 严格遵守“使用测试进行构建”的技能规范。
- 在修改任何代码之前，务必阅读CLAUDE.md文件和技术文档。
- 仅修改前端文件，不得涉及后端服务、API路由、工作进程或数据迁移相关内容。
- 严格遵循后端构建器生成的API接口规范，不得自行创建新的端点或响应格式。
- 尽量使用现有的组件模板，包括样式、无障碍设计、加载状态及错误处理机制。
- 未经明确指示，不得添加新的依赖项。
- 在修改代码完成后，运行类型检查、代码风格检查以及测试套件，记录所有通过或失败的测试结果，以及任何异常情况。
- 如果CLAUDE.md中缺少某些有助于工作的规则，请将其作为建议添加到文档中。

Claude回复道：

我已经创建了这个代理，文件路径为.claude/agents/frontend-builder.md，其中包含了以下配置信息：该代理具有读、写和执行Bash命令的权限，但仅限于前端文件夹的操作。它会使用后端构建器生成的API接口规范，而不会自行创建新的端点。

---
名称：frontend-builder
描述：负责实现某个功能的前端部分，包括组件、页面、钩子、客户端状态以及组件测试。会读取CLAUDE.md文件、技术文档、后端构建器的总结报告，并遵循现有的组件模板。使用“使用测试进行构建”的技能。仅限于前端文件夹的操作。
工具：读、写、执行Bash命令
模型：sonnet
颜色：蓝色
---

你是这个项目的前端实现负责人。你的任务是根据经过审批的技术文档，使用后端构建器已经生成的API接口规范来实现功能的前端部分。

在开始修改代码之前，请先完成以下步骤：
1. 阅读CLAUDE.md文件，了解项目规则和技术栈。
2. 仔细阅读技术文档，确保自己的修改不会超出其范围。
3. 查看后端构建器的总结报告，明确已知存在的API端点及其返回值。
4. 为保证代码规范的一致性，先学习“使用测试进行构建”的技能。
5. 在代码库中查找2-3个类似的组件或页面，学习它们的实现模式。

实施规则：
- 仅修改前端文件：包括组件、页面、钩子、客户端辅助函数及其测试代码。
- 绝不要修改后端服务、API路由、工作进程或数据迁移相关内容。这些属于后端构建器的职责范围。
- 严格遵循后端构建器生成的API接口规范，如果发现返回值与预期不符，请及时反馈问题，而不是自行调整。
- 尽量使用现有的组件模板，确保样式、无障碍设计、加载状态及错误处理机制与其他代码保持一致。
- 未经明确指示，不得添加新的依赖项。
- 在修改代码后，务必运行项目中的类型检查、代码风格检查以及测试套件，确保所有测试都通过。
完成修改后，请提交一份简短的总结报告，内容包括：
- 添加或修改了哪些文件（仅限前端文件）
- 是否复用了现有的组件或模式
- 是否有任何需要添加到CLAUDE.md中的规则
如果你在执行任务过程中违反了上述任何一条规则，请立即停止操作并报告这个问题。
Agent 6：测试验证器
一旦某个功能被端到端地实现出来，测试验证器就会编写相应的验收测试用例，这些用例会直接用来验证用户故事中描述的功能是否确实能够按预期工作。单元测试是与它们所覆盖的代码一起存在的（这些单元测试是由构建工具编写的）；而验收测试则位于这里。正是通过这些验收测试，我们才能确认该功能确实实现了用户故事中规定的所有功能。
创建一个名为“test-verifier”的项目级子代理。

它的任务是：根据已批准的用户故事、已批准的技术文档，以及已经端到端实现好的功能，编写验收测试用例，以验证用户故事中的各项功能是否能够按预期工作，并确认每一项验收标准是否都得到了满足。

输入：
- 已批准的用户故事（其中包含验收标准）
- 已批准的技术文档
- 后端构建工具和前端构建工具生成的总结报告
- “build-with-tests”技能（项目必备技能）

输出：
- 一个验收测试文件（或者是对现有文件的修改版本），该文件应涵盖用户故事中的所有验收标准
- 一份简短的报告，说明哪些验收标准得到了满足，哪些没有得到满足（仅当有标准缺失或无法被测试时才需要编写这份报告）

工具权限：读取、编辑、写入（仅限测试文件），Bash命令行。
推荐模型：sonnet。
推荐颜色：黄色。

行为规则：
- 在编写测试代码之前，先阅读用户故事和技术文档。
- 遵循“build-with-tests”技能的相关规定进行编码。
- 确保涵盖用户故事中列出的所有验收标准以及各种边界情况。
- 不要修改测试文件夹之外的后端或前端代码文件。
- 编写完成后，运行新的测试用例，记录测试结果，并报告那些无法被成功验证的验收标准。
Claude回复道：

我已经在.claude/agents/test-verifier.md文件中创建了这个子代理。该子代理仅负责处理测试文件相关的工作，它使用“build-with-tests”技能进行编码，并且会在后端构建工具和前端构建工具完成工作之后再运行，这样它就可以有可用的功能作为测试对象了。

---
名称：test-verifier
描述：在后端构建工具和前端构建工具完成工作之后，编写针对用户故事的验收测试用例，确认已实现的功能是否满足所有验收标准。使用“build-with-tests”技能进行编码。在后端构建工具和前端构建工具运行结束后再执行。

工具：读取、编辑、写入、Bash命令行
模型：sonnet
颜色：黄色

--- 

你是这个项目的验收测试编写者，你的职责是通过测试来验证那些已经端到端实现好的功能是否确实满足了用户故事中的所有要求。

在开始编写测试代码之前，请先完成以下步骤：
1. 阅读已批准的用户故事，了解所有的验收标准。
2. 阅读已批准的技术文档，了解这些功能的实现方式。
3. 查看后端构建工具和前端构建工具生成的总结报告，了解系统中存在哪些接口、组件以及它们的功能。
4. 使用“build-with-tests”技能进行编码。
5. 查看代码库中现有的2-3个验收测试用例，学习他们的编写风格。

编写测试代码时，请遵循以下规则：
- 确保涵盖用户故事中的所有验收标准。
- 处理用户故事中列出的各种边界情况。
- 使用项目提供的测试数据构建工具进行测试，而不是使用内嵌的测试设置方式。
- 遵循项目中规定的验收测试格式。
- 仅修改测试文件，不要更改任何代码。

编写完成后，请执行以下操作：
1. 运行新的测试用例。
2. 如果有任何测试用例失败，说明该功能尚未满足用户故事中的要求。请详细报告哪些验收标准失败了以及原因是什么。不要直接修改代码，这些错误应该由后端构建工具在下次开发循环中修复。
3. 如果有某些验收标准无法被成功验证（例如，技术文档中没有提供相应的测试方法），也请及时报告。不要自行发明解决方案。
4. 提交一份简短的总结报告，说明哪些验收标准得到了满足，哪些失败了，以及哪些标准还需要进一步明确。
代理7：实现验证器
该代理会将当前的实现状态与已批准的用户故事和技术文档进行对比，并报告其中存在的差异。但它并不会直接修复这些差异。它的作用就是发现构建代理和测试验证器可能遗漏的问题。
创建一个名为“implementation-validator”的项目级子代理。

它的职责是：将当前的实现代码与已批准的用户故事和技术文档进行对比，並报告其中存在的差异。它不会进行任何修复操作。

输入参数：
- 已批准的用户故事
- 已批准的技术文档
- 当前的实现状态（磁盘上的文件内容）
- 测试验证器的报告结果

输出结果按严重程度分类：
- 严重问题：必须在合并代码之前修复
- 重要问题：应在合并代码之前修复
- 轻微问题：建议修复，但非强制要求
- 下一步推荐处理的代理

需要检查的内容包括：
- 是否缺少验收标准
- 是否缺少针对故障路径的测试用例
- 安全性问题：如身份验证机制缺失、租户隔离措施不到位、错误信息泄露、日志中包含敏感信息等
- 文件内容是否超出了约定的修改范围
- 项目代码格式是否与CLAUDE.md文件中规定的模式不一致
- 是否存在可以复用的重复代码逻辑
- 实现方案是否忽略了文档中提到的时区设置或多租户相关问题

可使用的工具：读取文件、执行Grep搜索、使用Glob通配符
推荐的模型：sonnet
推荐的颜色：红色

行为规则：
- 绝不允许修改任何文件
- 绝不允许执行可能破坏文件内容的命令
- 对于每一个发现的问题，都必须明确指出对应的文件路径和行号
- 如果某个问题只是基于主观判断，并不代表真正的风险，那么就需要明确标注这一点
Claude回应道：

我已经在.claude/agents/implementation-validator.md文件中创建了这个代理。请重新启动您的Claude Code会话以加载该代理配置。一旦构建和验证环节完成，您就可以通过@implementation-validator来调用这个代理进行代码审查了。

---
名称：implementation-validator
描述：这是一个严格的审核工具，它会将当前的实现代码与已批准的用户故事和技术文档进行对比，并按严重程度分类报告差异。它不会修改任何文件。请在构建和验证环节完成后使用它，但在提交合并请求之前使用。

可使用的工具：读取文件、执行Grep搜索、使用Glob通配符
推荐的模型：sonnet
推荐的颜色：红色

--- 

你是这个项目的实现验证器。你的唯一职责就是将磁盘上的代码与已批准的用户故事和技术文档进行对比，然后报告其中缺失或错误的地方。你不需要进行任何修复操作。

你需要接收的输入信息包括：
- 已批准的用户故事
- 已批准的技术文档
- 当前的实现状态（磁盘上的文件内容）
- 测试验证器的报告结果

每次都需要检查的内容包括：
- 用户故事中规定的但尚未实现的验收标准
- 技术文档中提到的但尚未编写测试用例的故障路径
- 安全性问题：如身份验证机制缺失、租户隔离措施不到位、错误信息泄露、日志中包含敏感信息等
- 文件内容是否超出了约定的修改范围
- 项目代码格式是否与CLAUDE.md文件中规定的模式不一致
- 是否存在可以复用的重复代码逻辑
- 实现方案是否忽略了文档中提到的时区设置或多租户相关问题

输出结果的格式如下：
**严重问题**：必须在合并代码之前修复
- <一条错误信息，包括文件路径和行号>
- ...

**重要问题**：应在合并代码之前修复
- <一条错误信息>
- ...

**轻微问题**：建议修复，但非强制要求
- <一条错误信息，如果该问题只是基于主观判断，则需标注“（仅供参考）”>
- ...

**下一步推荐处理的代理**：
- <例如：“请让backend-builder先修复X处的租户隔离问题，然后让test-verifier添加相应的验收测试用例”>

行为规则：
- 绝不允许修改任何文件
- 绝不允许执行可能破坏文件内容的命令
- 对于每一个发现的问题，都必须明确指出对应的文件路径和行号
- 如果某个问题只是基于主观判断，并不代表真正的风险，那么就需要明确标注这一点
- 如果没有发现任何严重或重要问题，就必须如实说明。不要为了显得工作认真而编造问题
这七个示例仅供参考，并非标准配置集
只需七个代理就能实现实际功能，这个数字并非上限。这种模式的本质在于：你的团队可以根据本节前面提供的模板，自行构建所需的代理。可能性是无穷的，想构建什么就构建什么吧。
根据你们团队目前遇到的瓶颈，以下是一些可以优先添加的代理示例：


accessibility-reviewer：用于检查新的用户界面代码，发现缺失的标签、对比度问题、键盘陷阱等不符合项目标准的地方。


security-reviewer：在代码验证之前运行，检查是否存在身份验证漏洞、租户隔离缺陷、不安全的反序列化操作以及依赖关系风险。


migration-writer：根据项目的命名规范和回滚机制，将设计变更方案转换为Prisma或你们所使用的ORM框架支持的迁移脚本。


design-system-reviewer

:在新组件发布之前，会检查它们是否符合设计要求、间距标准以及现有的组件库规范。


docs-updater：读取最终的代码差异文件，然后更新README文档、功能说明或操作指南。


release-note-writer：阅读最近的代码合并记录，按照团队习惯编写面向用户的变更总结。


payments-integration：深入了解Stripe的Webhook接口规范，因此任何工程师都可以在没有支付专家参与的情况下实现与计费相关的功能。


这些代理的功能结构都是相同的：明确的职责范围、有限的工具集、清晰的输入/输出规则以及行为规范。只需使用提供的模板，通过/agents命令将其提交给Claude系统，审核文件后即可提交代码。随着代码库的发展，这些代理也会相应地扩展或淘汰。
如果七个代理看起来太多，可以先从小规模开始尝试
如果在一个周末内搭建七个代理似乎太困难，那就不要勉强。这种模式的最小实用版本只需要三个代理：
codebase-researcher → build-with-tests skill → implementation-validator
“codebase-researcher”用于分析代码结构，“build-with-tests skill”确保构建过程顺利进行，“implementation-validation”则能发现那些被忽略的问题。先使用这个三部分的组合运行几个功能模块，看看哪里会遇到障碍，然后再添加下一个能够解决这些问题的代理。大多数团队在刚开始时并不需要全部七个代理。
你们已经拥有的内置代理
在构建上述七个代理之前，Claude Code系统本身就已经配备了一些内置代理，你应该了解并在适合的情况下使用它们：


Explore：这是一个只读工具，专为搜索和理解代码库而设计。使用成本低且效率很高。你可以直接使用它，或者在自己编写的“codebase-researcher”脚本中加入它，以获得更精确的输出结果。


Plan：在“计划模式”下收集相关信息，并在任何文件更改发生之前提出实施方案。


General-purpose：用于处理那些既需要分析也需要修改的任务。


当内置的解决方案能够满足需求时，就直接使用它们吧。而当你需要更严格地控制输入与输出的结果，或者想要强制执行某些特定的行为规则时，就可以创建自定义的解决方案。
七个代理就已经足以运行一个真正的“工厂”了。而让这些代理协同工作的关键因素，就是下一节中将要介绍的“协调器”。
7. 工作流层：驱动整个流程运行的协调器
现在你已经有七个各司其职的代理了。那么下一个问题就是：谁来决定何时调用哪个代理，以及调用的顺序应该是怎样的呢？
在基于“氛围编码”的工作流中，答案是“人类来输入指令”。这种做法确实有效，但这样一来人类就成为了整个流程的协调者——你需要自己记住先调用研究员，然后暂停等待审核，最后在验证完成后才启动验证器。如果漏掉了其中任何一个步骤，整个流程就会中断。
工厂运行的核心原则就是让各个环节能够自动协同工作。人类只需要参与那些需要判断和决策的环节（比如批准任务内容、确认需求文档或提交代码修改请求），而代理之间的交互过程应该是自动化完成的。
这就是协调器的作用所在。
协调器究竟是什么
协调器是工厂系统中另一个重要的组成部分，它的唯一职责就是按照正确的顺序将任务分配给其他代理，传递正确的输入信息，在需要人类审批的环节暂停流程，并在某个代理报告问题时及时恢复运行。
在Claude Code中，有几种方法可以构建这样的协调器。下面我会向你展示两种方法。


以技能或命令的形式实现。这是最基础的实现方式。你可以创建一个位于`.claude/skills/feature-factory/SKILL.md`文件夹中的`SKILL.md`文件（当描述与你的需求匹配时，该文件会自动被执行），或者编写一个位于`.claude/commands/feature-factory.md`文件夹中的Markdown文件（输入命令`/feature-factory`即可运行）。两种方式的内容相同，只是调用机制不同而已。简单易懂，不需要学习新的概念，也很方便阅读和修改。


以子代理的形式实现。这是更高级的实现方案。这样的协调器会在自己的独立窗口中运行，并且可以通过Claude Code提供的子代理调用功能来与其他七个代理进行交互。这种方式更加高效、功能也更强大，但同时也引入了额外的概念和复杂性。


建议先尝试使用技能/命令形式的实现方式，使用一周后再根据自己对整个流程的理解程度，决定是否升级为子代理形式的协调器。
整个流程链条
以下就是协调器所驱动的整个流程链条。

整个流程中有三个需要人类审批的环节：


在任务内容确定后。

这个问题是否合适？验收标准是否正确？



在需求文档编写完成后。

设计方案是否安全？在开始编码之前是否存在任何潜在的问题？



在验证完成之后。

这个代码修改请求是否已经准备好发布？



其他所有内容都涉及协调者在不同代理之间的工作流程安排。
版本1：将协调者视为一种技能
你可以在.claude/skills/feature-factory/SKILL.md路径下创建一个这样的技能。让Claude为你生成相应的代码：
在。.claude/skills/feature-factory/SKILL.md创建一个Claude Code技能，该技能能够利用七个现有的子代理来协调功能的开发流程：这些子代理包括codebase-researcher、story-writer、spec-writer、backend-builder、frontend-builder、test-verifier以及implementation-validator。

这个技能应该具备以下功能：
- 当用户使用“构建某个功能”、“发布某个功能”或“运行整个开发流程”等指令时，该技能会自动启动。
- 按照以下顺序执行整个开发流程。
- 在故事描述阶段和技术需求文档编写完成后，需要等待人类的审批。在每个审批节点，系统需要处理三种结果：批准、要求修改或拒绝。
- 先运行backend-builder，然后是frontend-builder，最后是test-verifier。
- 在开发流程的最后阶段调用implementation-validator，并报告其中出现的严重问题、重要问题以及次要问题。
- 如果validation工具指出了严重的缺陷，系统需要返回到相应的构建环节（无论是backend还是frontend），然后重新运行test-verifier和validation工具。

具体步骤如下：
1. codebase-researcher：确定涉及哪些代码模块。
2. story-writer：编写用户需求文档。
3. 征求人类审批：如果获得批准，则继续下一步；如果要求修改，则根据人类的反馈重新让story-writer进行修改，重复此步骤直到最终得到批准或拒绝。
4. spec-writer：编写技术需求文档。
5. 征求人类审批：同上。
6. backend-builder：实现后端功能并编写单元测试用例。
7. frontend-builder：实现前端功能并编写组件测试用例。
8. test-verifier：根据用户需求文档编写验收测试用例。
9. implementation-validator：报告测试结果。
10. 如果发现严重问题，则返回到相应的构建环节，重新运行测试流程。
11. 征求人类最终审批：在提交代码合并请求之前，需要得到人类的最终确认。

在保存技能文件之前，请先让我看一下文件内容。
Claude生成后的文件内容大概会是这样：
---
名称：功能开发流程
描述：当用户要求从头到尾完成某个功能的开发、测试或部署时，可以使用此流程。该流程会依次启动七个子代理程序，并在故事描述和需求文档编写完成后等待用户的审批。具体步骤如下：
1. 启动代码库研究子代理程序，提交功能需求及相关代码范围，等待研究结果。
2. 启动故事描述子代理程序，提交功能需求及研究结果，等待用户生成完整的故事描述。
3. 将故事描述展示给用户，询问“这是否符合您的要求？如同意请回复‘批准’，否则可说明需要修改的地方或直接回复‘拒绝’以终止流程”。
   - 如果获得批准，继续下一步；
   - 如果需要修改，根据用户的反馈再次启动故事描述子代理程序，重复此步骤直至得到最终结果；
   - 如果被拒绝，终止整个流程，并向用户总结已进行的准备工作，以便其决定后续行动。
4. 启动技术规范编写子代理程序，提交经过批准的故事描述及研究结果，等待技术需求文档的完成。
5. 将技术需求文档展示给用户，询问“是否存在设计上的问题？如同意请回复‘批准’，否则可说明需要修改的地方或直接回复‘拒绝’以终止流程”。
   - 如果获得批准，继续下一步；
   - 如果需要修改，根据用户的反馈再次启动技术规范编写子代理程序，重复此步骤直至得到最终结果；
   - 如果被拒绝，终止整个流程，但会保留已批准的故事描述，以便用户日后可以尝试其他技术方案。
6. 启动后端开发子代理程序，提交技术需求文档及研究结果，等待后端代码的实现及相应的总结报告。
7. 启动前端开发子代理程序，提交技术需求文档、研究结果以及后端开发子的总结报告（以便其了解API接口规范），等待前端代码的实现及相应的总结报告。
8. 启动测试验证子代理程序，提交经过批准的故事描述、技术需求文档以及两份开发总结报告，等待验收测试结果及验证器的报告。
9. 启动实施验证子代理程序，提交经过批准的故事描述、技术需求文档、测试验证器的报告以及当前的代码实现版本，等待验证结果。
10. 如果验证器发现了严重问题，需将这些问题及相关测试结果转发给相应的开发人员（后端或前端），然后重新运行测试验证和实施验证流程。
11. 将验证结果展示给用户，询问“是否准备提交代码变更请求？”

规则：
- 任何步骤都不得跳过用户的审批环节。
- 在启动前端开发子代理程序之前，必须先完成后端开发工作。
- 在两个开发子代理程序都完成工作之前，不得启动测试验证子代理程序。
- 在整个流程产生任何实际代码实现结果且验证器已完成测试之前，不得启动实施验证子代理程序。
- 每个子代理程序都在独立的运行环境中执行任务，只传递该程序所需的输入数据。
- 如果有任何子代理程序报告无法完成任务，应立即停止当前流程，并向用户说明原因。
这就是完整的协调器。它只是一个Markdown文件，但这个文件会调用另外七个Markdown文件。这些文件共同构成了一个“生产系统”。现在你可能会想：如果我们只需要创建后端接口而不需要前端界面，或者相反呢？这完全取决于你的实际需求，你可以按照特定的方式来构建系统。上面只是示例而已，你需要自己决定究竟想要构建什么。
运行整个流程：一个简洁的端到端示例
你打开Claude Code，然后输入如下内容：
/feature-factory

我想为那些逾期7天仍未支付的发票发送提醒邮件。
接下来会发生什么？让我们一步步来看：
步骤1. 协调器会将任务委托给codebase-researcher。这个模块会在自己的运行环境中读取发票信息、支付记录以及相关邮件文件，然后返回结果：

发票相关的处理逻辑位于services/invoices/create.ts文件中，状态信息会被存储在Invoice模型中。发送提醒邮件的功能通过services/email/send.ts模块实现，其中会使用预定义的模板。而workers/目录下的BullMQ工作进程负责处理定时任务。目前系统中还没有自动发送提醒邮件的逻辑，管理员界面位于app/(admin)/invoices/路径下。可能需要修改的文件包括：Invoice模型、新的提醒服务相关代码、邮件模板配置文件，以及用于手动触发提醒功能的管理员页面。

步骤2. 协调器会将任务委托给story-writer，并向其传递功能需求及相关分析结果。该模块会返回如下内容：

作为账户管理员，我希望系统能够自动为逾期未支付的发票发送提醒邮件，这样就能无需人工跟进就能提醒客户。
验收标准如下：


当发票逾期7天仍未支付时，系统应自动发送提醒邮件。


已支付的发票不应收到提醒邮件。


不会在同一时间段内重复发送同样的提醒邮件。


如果邮件发送失败，系统也不应将提醒状态标记为“已发送”。


管理员能够查看最后一次发送提醒邮件的时间。


管理员也可以为特定的发票手动触发提醒功能。


需要注意的特殊情况包括：发票恰好逾期7天时系统的处理方式、重试机制、多租户环境下的兼容性问题以及时区差异。此外，短信提醒功能及客户端的个性化设置不在本次讨论范围内。

步骤3. 协调器会暂停当前流程，并提供三个选项供你选择：批准、要求修改或拒绝。你仔细阅读了相关描述，发现这些内容符合你的需求，因此你选择了“批准”。
步骤4. 协调器会将已批准的任务以及研究人员的分析结果委托给spec-writer。该模块会返回一份详细的报告，其中包含数据模型变更信息（如lastReminderSentAt字段的调整）、BullMQ任务流程、用于手动触发提醒功能的管理员接口信息、显示最后一次发送提醒时间的管理员界面元素、所需的测试内容以及可能存在的风险点（例如多租户环境或时区差异带来的问题）。
步骤5. 你仔细阅读了这份报告，发现其中提到“系统会将已处理的发票ID存储在内存中”。这个设计存在安全隐患，因此你决定回复……
请更改去重策略，不要使用内存中的状态数据，而是使用“lastReminderSentAt”这一列。
协调器会重新调用spec-writer，更新相关文档后，你再进行审批。
步骤6：协调器会将任务委托给backend-builder，同时传递文档内容以及研究人员的分析结果。构建工具会在“Invoice”模型中添加“lastReminderSentAt”这一列，重新编写提醒服务的相关代码，将其集成到现有的BullMQ工作进程中，并为手动触发功能添加管理员端点；此外还会为所有相关模块编写单元测试。完成这些操作后，会运行类型检查、代码格式审查以及测试套件，所有测试结果均为合格。最后会生成一份总结报告：

后端开发已完成。
新增文件：

services/reminders/send-overdue.ts
app/api/admin/invoices/[id]/remind/route.ts
workers/reminders.worker.ts

修改文件：

prisma/schema.prisma（添加了“lastReminderSentAt”列）

复用的组件/函数包括：prisma、sendEmail、daysAgo，以及现有的invoice-reminder邮件模板和BullMQ的redisConnection配置。在手动触发端点中，通过requireSameTenant辅助函数实现了租户隔离机制。
新增了7个单元测试用例，所有测试均通过。建议遵循CLAUDE.md文件中的规范：“提醒相关列应遵循‘last<操作>SentAt’的命名规则”。

步骤7：协调器会将任务委托给frontend-builder，同时传递文档内容、研究结果以及后端构建工具的总结报告。前端构建工具会从这些资料中读取API接口规范，在管理员管理的发票表格中添加“最后提醒发送时间”这一列，在每行数据上添加“发送提醒”按钮，处理页面加载及错误状态显示的相关逻辑，并编写组件测试用例。完成这些操作后，也会运行类型检查、代码格式审查以及测试套件，所有测试结果均为合格。最终会生成一份总结报告：

前端开发已完成。
新增文件：

app/(admin)/invoices/_components/ReminderColumn.tsx
app/(admin)/invoices/_components/SendReminderButton.tsx

修改文件：

app/(admin)/invoices/page.tsx（添加了新列和按钮）

复用的组件包括：现有的管理员界面DataTable、用于API调用的useMutation钩子，以及用于显示成功/错误状态的Toast组件。前端代码的实现方式与后端文档中描述的完全一致。
新增了5个组件测试用例，所有测试均通过。

步骤8：协调器会将任务委托给test-verifier，同时传递已获批的开发需求、相关文档以及前后端构建工具的总结报告。验证工具会编写一份验收测试文件，涵盖所有六项验收标准及边缘情况。运行这些测试后，会生成相应的测试报告。

已编写的验收测试共有8项：每个验收标准对应1项测试，另外还有2项针对边缘情况的测试。
其中7项测试通过，1项未通过：“手动触发功能在跨租户环境中会返回200状态码而非403状态码”。这表明管理员端点在发送请求之前并未检查租户信息。建议由验证工具再次进行确认。

步骤9：协调器将任务委托给implementation-validator进行处理。验证工具返回了以下结果：

严重问题：手动触发端点未检查管理员是否属于与发票相同的租户。例如，A公司的管理员可以为B公司的发票触发提醒功能。（相关代码位于app/api/admin/invoices/[id]/remind/route.ts文件的第14行。）虽然导入了requireSameTenant辅助函数，但并未实际使用它。
重要问题：目前没有任何测试能够覆盖lastReminderSentAt恰好为7天前的情况。需要明确判断该条件应该是“>”还是“>=”。
次要问题：新的ReminderColumn组件完全可以重用现有的RelativeTime组件，而不必自行编写格式化代码。

步骤10：发现了严重问题，协调器会重新开始处理流程。它将验证工具发现的错误以及未通过的验收测试结果传递给backend-builder。后端构建工具会对相关代码进行修改，并在手动触发端点中添加requireSameTenant逻辑，然后重新运行单元测试。之后协调器会再次执行test-verifier测试，此时所有8项验收测试都会通过。随后implementation-validator也会再次被执行，整个流程就此完成。

步骤11：协调器会暂停当前流程，等待您的最终审核，并询问您是否希望它立即创建Pull Request。
这就是一个高效的工作流程系统：一个初始指令启动了整个流程，7个不同的工具分别执行各自的任务，而协调器则在这些需要人工决策的环节进行暂停。
版本2：作为子代理的协调器（高级功能）
当您熟悉了这个工作流程系统一段时间后，可能会希望让协调器在独立的窗口中运行。虽然该系统会继承您主会话的环境信息，但对于较复杂的任务来说，主会话环境很容易被中间处理步骤产生的数据所占用。
将协调器设置为子代理可以使其具有独立性。请执行以下命令来创建这样的子代理：
创建一个名为“feature-orchestrator”的项目级子代理。

它的任务是：根据用户提供的功能需求，依次调用七个工具（代码库研究员、故事编写者、规范编写者、后端构建工具、前端构建工具、测试验证工具以及实现验证工具），在故事描述和简要评审完成后暂停流程以等待人工确认，然后按顺序运行构建工具，最后进行验证。如果验证过程中发现严重问题，系统会返回到相应的构建步骤重新开始处理。请使用“feature-factory”技能来确保步骤顺序的正确性，包括每个人工审核环节中“批准”、“要求修改”或“拒绝”这些操作的处理方式。

输入参数：
- 用户提供的功能需求概要

输出结果：
- 工作目录中完成的实现代码
- 关于最终生成的结果、添加的测试内容以及任何验证工具发现的问题的总结报告，用户可以在最终审核时决定是否忽略这些问题

工具权限：执行任务（以调用其他子代理）、读取数据、使用Bash命令
推荐模型：sonnet模式（这种模式下需要根据具体需求来路由任务）
推荐颜色：灰色

行为规则：
- 严格遵循“feature-factory”技能中规定的步骤顺序。
- 始终通过子代理来调用其他工具，而不能直接嵌入它们的功能代码。
- 在所有需要人工审核的环节都必须暂停流程，并严格按照技能中的规定处理各种情况。
- 如果有任何工具出现故障，系统会显示该工具的名称并停止当前操作，不会自动尝试重新运行。
- 绝不要直接编辑代码，必须通过相应的构建工具来完成修改。
这种行为与技能版本几乎完全相同。唯一的区别在于，现在这个协调器是在它自己的环境中运行的。你可以通过 `@feature-orchestrator` 和一个功能需求来调用它。协调器的环境会在整个流程中得到保留，而你的主会话环境则不会因此受到影响。
选择其中一个版本，用它来运行几个实际的功能案例。这个“代码工厂”会根据你的代码库情况，指出哪些地方需要进行调整。
为什么这种方法有效
每个步骤都在消除不同类型的模糊性：故事描述消除了业务上的模糊性，需求文档消除了技术上的模糊性，后端构建工具消除了API相关的模糊性，前端构建工具消除了用户界面设计方面的模糊性，测试验证环节则证明了用户故事描述的准确性；而校验器则会发现其他人可能忽略的问题。当整个流程到达校验器这一阶段时，该功能已经受到了前面所有步骤的约束，因此校验器只需要检查需求文档中描述的内容与实际代码实现之间的差异即可。
这个协调器将原本需要人工执行的流程转变成了能够自动运行的流程——只有在真正需要的地方，才会需要人类的参与。
这就是从“凭直觉进行编码”转变为“采用自动化流程进行开发”的过程，也是本文中提到的最重要的思维方式转变。
扩展这个流程链
最初设置七个代理节点和三个人工审批环节只是一个起点，并非上限。一旦你的基本流程链开始运行了，你可以在任何需要增加严谨性的地方再添加更多的代理节点：比如在校验器之前添加安全审查节点，在新代码路径上添加性能检测节点，或者让文档编写者根据代码变更更新README文件等。每次添加新的代理节点时，都可以按照相同的步骤进行操作：使用相应的模板定义代理节点的功能、限制它可使用的工具、将其插入到协调器的流程中，并判断是否需要人工来审核它的输出结果。
如果你的团队信任某些成员，也可以将一些人工审批环节的任务交给这些成员来完成。不过，对于业务决策来说，仍然需要由人类来进行最终判断；而对于低风险的功能，有时可以用第二个需求评审代理节点来替代人工审批环节。无论如何，最终的代码合并请求审批步骤必须保留由人类来完成。
这个“代码工厂”的扩展方式与真实的代码库的发展规律是一样的：从小规模开始，逐步添加团队目前仍需要手动完成的工作，然后淘汰那些不再具有实际价值的流程环节。
并行执行读取操作，顺序执行写入操作
最后还有一个设计原则，它能帮你节省很多麻烦。
只负责读取数据的代理节点可以并行运行。由于它们不会修改磁盘上的文件，因此同时运行多个这样的代理节点也不会导致冲突。并行执行这些读取操作是整个系统中最容易提升效率的方法之一。例如，如果你维护着四个服务，而在季度评审之前需要为每个服务更新文档，那么你可以同时启动四个“代码库研究”代理节点，每个服务对应一个代理节点。每个代理节点都会独立地读取自己负责的服务的代码库信息、总结其中的变化，并返回检测结果。之后，四个“文档更新”代理节点会分别处理这些结果，分别为每个服务重新编写README文件。因为每个文档更新代理节点处理的都是不同的代码仓库，所以它们不会对相同的文件产生干扰。这样，原本需要耗费很长时间才能完成的任务，现在就可以快速地完成了。
编写代码的代理程序（后端构建器、前端构建器、测试验证器）必须按顺序运行。这些程序会修改文件，如果其中两个程序同时修改同一个文件，就会导致部分修改丢失、测试结果出错，以及Git状态混乱。更糟糕的是，这种错误在最初往往不会被察觉，直到你发现差异报告有误时才会发现问题，而要追踪到底是哪个代理程序修改了什么文件，本身也是一件相当麻烦的事情。
如果你正确配置了相关机制，协调器会自动处理这些问题。在构建阶段，后端构建器必须在前端构建器开始之前完成工作，而前端构建器也必须在测试验证器开始之前完成工作；在构建阶段之外，则可以并行执行这些操作。
一个简单的经验法则是：凡是仅涉及“读取”、“搜索”或“匹配”操作的流程，都可以并行执行；而任何涉及“修改”、“写入”或“执行脚本”操作的流程，都必须单独运行。
需要警惕的故障模式
每个使用这种流程的团队在刚开始运行的几周内都会遇到一些常见问题，但这些问题通常不会导致整个系统崩溃。以下是一些需要注意的问题以及相应的解决方法：


协调器跳过了人工审批环节。请在相关代理程序的配置中明确指定审批步骤（例如：ASK HUMAN: approve the story）。


某个代理程序悄悄地省略了部分应该执行的操作。可以在其输出结果中添加“已执行的内容/未执行的内容”清单，以便及时发现这些问题。


验证器漏掉了某些问题，而后来由人工审核人员发现了这些错误。可以为验证器的行为规则添加新的条件，从而提高其检测错误的能力。


在流程运行过程中，上下文信息丢失了。请确保CLAUDE.md文件中的配置始终一致，并且为每个重要功能单独启动构建过程。


整个流程运行得很顺利，但需求规格说明书误解了业务规则。正因为如此，人工审批环节才显得如此重要。


前端构建器生成了一个后端构建器并未产生的接口。需要加强前端构建器的规则设置，确保它只能使用后端提供的数据；对于出现的不一致之处，应该作为反馈信息进行处理，而不是直接编写补丁程序。


一个设计良好的开发流程能够使错误更容易被发现，而不会让问题变得难以察觉。
8. 发布环节：Pull Request、代码审查与新的软件开发生命周期
到目前为止，这篇文章主要讨论了开发流程中的具体技术细节。现在让我们把视角拉远一些，从更宏观的角度来思考这个问题。
当人工智能承担了大部分编码、测试和文档编写工作之后，生成软件变更的成本确实降低了。但这并不意味着软件变得免费了，而是意味着瓶颈已经发生了变化——过去影响开发速度的环节是代码输入、逻辑连接和信息查找，而现在阻碍开发进程的关键步骤变成了功能选择、约束条件定义、行为验证以及确定哪些功能应该被最终发布。
这种变化会直接影响团队的组织结构、代码审查的方式，以及整个软件开发流程的运作方式。

图6：当协调者接管编码工作后，SDLC的流程会发生怎样的变化。任务交接环节消失了，但审核与评估工作仍然需要由人类来完成。
现在，一名工程师就可以完成整个功能模块的开发
当整个开发流程由同一组人负责时，SDLC的架构就会发生变化。
以前，一个新功能的开发需要经过多个专家的协作。例如，前端工程师需要新的API接口，就必须等待后端工程师完成开发；而后端工程师若需要设计用户界面，同样也要等待前端工程师的工作成果。因此，一个新功能在正式发布之前，可能会经过三到四个人的处理，而大部分时间这些工作都处于等待审核的状态。
现在，同一名工程师就可以启动/feature-factory流程，整个开发链会从前端到后端、从测试到验证，一次性完成整个功能模块的开发。整个过程只需要一个人参与，没有任何任务交接环节。第11节会进一步探讨这种模式对团队以及整个行业的影响。目前来说，最重要的是：工作的基本单位已经发生了变化——功能现在是作为一个完整的整体来开发的，而不是零散地分步骤进行。
将多个功能模块依次开发，而不是只专注于其中一个功能
一旦任务交接环节被消除，下一个问题就是：“当我的上一个提交请求还在审核中时，我应该做些什么？”答案是：开始开发第二个功能模块，然后是第三个功能模块。
适合这种开发模式的是依次提交的提交请求，但每个功能模块都应该作为一个独立的提交请求来处理，而不是将一个功能模块的分割部分合并成一个提交请求。每个提交请求都代表由整个开发流程完成的一个完整功能模块。
在实际操作中，具体步骤如下：你首先完成功能A的开发，然后创建一个针对main分支的PR A进行提交。在A等待审核的过程中，你不需要停止工作，可以直接在feature-a分支的基础上继续开发功能B，并为功能B创建另一个PR B进行提交。当A和B都在等待审核时，你可以在功能B的基础上继续开发功能C，然后开始第三个功能的开发。
顺序非常重要：必须先合并A，然后B再基于main分支进行合并，最后C也基于main分支进行合并。像Graphite、Sapling这样的工具，或者git自带的git rebase --onto命令，都能在上游提交请求被合并时自动处理这种基线调整操作，因此你大多数情况下都不需要手动操心这个问题。
有两条规则可以确保这一流程的安全性：
第一，必须严格遵守开发流程。如果功能C依赖于功能B，那么就不能在功能B完成审核之前就尝试合并功能C。分支结构本身就已经起到了这种约束作用，但明确这一点还是很有必要的，因为当某个提交请求的审核进度过慢时，人们确实会想要跳过这个步骤直接进行下一步操作。
其次，切勿将一个功能拆分到多个合并请求中。一个功能应该对应一个合并请求。如果你打算将迁移相关代码放入第一个合并请求中，后端代码放入第二个合并请求中，UI代码放入第三个合并请求中，那么这通常意味着一次操作会产生过多的内容。在这种情况下，你应该回到最初的分割方案，按照功能模块来重新划分这些代码，然后分别提交两个较小的合并请求。这样，每个合并请求仍然只包含一个功能，且每个功能最终也会以一个独立的合并请求的形式发布。
这种开发模式的精髓在于：任何工程师都可以独立完成一个功能的开发工作，而无需等待其他人的协作。通过将多个相关功能分摊到不同的合并请求中，就可以避免因为自己的审核任务堆积而影响整个开发流程。
软件行业正朝着这个方向发展：团队规模越来越小，交接环节也越来越少，每个工程师都能独立完成端到端的开发工作。最终取得成功的那些团队，并不一定拥有最先进的人工智能工具，而是那些能够充分利用现有工具、建立起高效开发流程的团队。
添加合并请求审核代理
对于使用人工智能辅助开发的团队来说，需要一种既适合人类审核员也适合人工智能审核员的统一审核标准。实现这种统一性的最有效手段就是制定一份简短明了的检查清单，所有合并请求在提交时都需要根据这份清单进行审核。如果没有这样的清单，审核过程就会变得主观随意；而有了这份清单，每个人每次审核时都会关注相同的内容。
我在之前发表的文章《如何突破人工智能辅助合并请求审核的瓶颈》中详细介绍了如何利用人工智能辅助进行合并请求审核，其中包含了我使用的检查清单、有效的规则以及那些无效的规则。如果你还没有阅读那篇文章，请先去读一读。你刚才建立的开发流程只是整个工作流程的上半部分，而合并请求审核则属于下半部分。
对于具体的开发流程来说，将这份检查清单放在某个代理程序中是最合适的做法。你可以使用`/agents`命令路径，按照第6节中创建代理程序的方法来创建一个名为`pr-reviewer`的代理程序：
创建一个项目级别的子代理程序，命名为“pr-reviewer”。

它的职责是：根据该项目制定的检查清单来审核提交的合并请求，并按严重程度对审核结果进行分类报告。该代理程序不会修改文件内容，也不会合并合并请求。

输入参数：
- 需要审核的合并请求或差异文件
- `CLAUDE.md`文件以及任何项目级别的规则

输出结果，按严重程度分类：
- 严重问题：必须在合并之前解决
- 重要问题：建议在合并之前解决
- 轻微问题：解决后会对系统有积极影响

每次审核时都必须检查以下内容：
- 功能范围：目标明确，不存在无关的代码重构或无关文件
- 测试情况：单元测试是否覆盖了核心功能，故障场景是否得到测试，现有的测试用例是否仍然有效
- 安全性：身份验证机制是否正常工作，用户数据是否得到了妥善保护，日志或错误响应中是否没有包含敏感信息
- 架构设计：业务逻辑是否与UI和API接口分离，是否遵循了`CLAUDE.md`中规定的设计模式，是否引入了不必要的新依赖项
- 文档编写：针对用户界面上的变更，是否更新了README文件或功能说明文档；在合并请求描述中是否说明了项目中存在的技术债务

工具支持：支持读取文件、使用Grep进行搜索、使用通配符匹配文件，以及执行Bash命令（仅用于git相关操作）
推荐的模型：sonnet模型（选择这个模型需要仔细考虑）
推荐的颜色：橙色

行为规则：
- 绝不要修改文件内容
- 绝不要合并或关闭合并请求
- 对于每一个发现的问题，都必须明确指出文件路径和行号
- 对于那些基于主观判断得出的结论，必须明确标注出来，以便审核人员可以安全地忽略这些结论
Claude会生成相应的文件，你对其进行审核并提交之后，你的项目就拥有了一个统一的审核机制：无论是人类还是AI，都可以使用相同的方式来执行审核操作，即@pr-reviewer review this PR。你还可以将这一机制集成到你的持续集成流程中，这样在人类审核人员看到任何反馈之前，每位开发人员都能先处理自己的PR相关问题，从而减轻审核人员的负担。
这种模式非常重要，因为这个自动化审核系统成为了所有信息的唯一来源。在合并代码之前，人类会先查看它给出的审核结果。第7节中提到的协调工具可以在开启PR审核流程之前，使用该系统进行最终检查；持续集成系统也可以在每次代码提交时自动运行该系统。所有的检查清单都保存在一个地方，并且会在同一个地方得到更新。当你的团队发现新的问题时，只需将这些问题添加到该系统的行为规则中，下一次审核时就会自动考虑到这些新问题。
云审阅工具是功能模块，而非同事
AI已经开始被应用于持续集成流程中：PR审核机器人、安全扫描工具、版本说明生成器、问题分类工具等等。这些工具确实非常有用，但使用的语言也非常重要。
如果你说“Claude批准了这个PR”，那你就已经犯了一个小错误。基于云的AI并不是你的团队成员，它也不是开发人员，因此它不需要对最终决策负责。正确的表达方式应该是“Claude根据项目规定的审核清单执行了审核流程，并给出了相应的报告，然后由人类来判断这个PR是否可以合并”。最终的责任仍然在于人类。
这种规范之所以存在，是有实际原因的。云审阅工具擅长那些被要求去检查的内容：缺失的测试用例、命名不一致的问题、重复存在的辅助功能等等。但对于那些不在审核清单范围内的问题，它们可能就无法发现。例如，如果你的审核清单没有明确要求审核人员检查发票下载接口中的租户隔离机制，那么AI审阅工具可能会忽略这个问题，从而导致用户能够从其他公司下载发票。因此，针对特定项目制定的审核清单，要比通用的AI审阅工具要有用得多。
人类在哪些方面具有优势
AI审核并不能等同于最终批准。AI可以帮助发现问题，可以总结复杂的代码变更，可以将代码与检查清单进行比对，也可以建议需要进行的测试。但最终的决定权仍然属于人类：这个解决方案是否能解决真正的问题？这种权衡是否合理？现在就应该发布这个功能吗？还是应该通过开关机制来决定是否发布？另外，我们是否还需要收集更多的用户数据呢？
这些判断工作仍然需要人类来完成。那些最善于利用AI辅助的团队，并不是那些完全取代了人类的团队，而是那些能够让人类在最重要的决策环节发挥作用的企业。
9. 构建你第一个由Claude支持的软件工厂
理论讲解已经结束，现在来看看如何在你的项目中搭建这样一个软件工厂吧。每一步都会链接到解释其具体原因的相关章节。



#
步骤
执行位置




1
从官方文档中安装Claude代码
https://code.claude.com/docs/en/desktop


2
创建文件夹结构（.claude/agents、.claude/skills/feature-factory、.claude/skills/build-with-tests、.claude/hooks、CLAUDE.md）
第5章


3
编写CLAUDE.md文件（100-300行，内容包括项目的基本信息和规则）
第5章


4
通过/agents命令创建七个子代理程序
第6章


5
创建feature-factory协调工具
第7章


6
创建build-with-tests工具
第5章


7
添加预提交钩子并确保其可执行
第5章


8
创建pr-reviewer代理程序
第8章


9
让一个实际的功能通过整个流程进行测试
详见下方步骤



第一个版本的总开发时间约为两到三个小时。
当你首次运行真正具有功能性的代码时
选择一个小项目来开始吧。比如一个管理工具，或者是一个带有简单用户界面的新API接口。首先打开Claude Code：
/feature-factory

我想用一句话来描述这个功能。
接下来，开发流程会自动进行下去：批准项目需求，审核相关文档，阅读验证报告，然后提交代码请求。
第一次尝试可能不会完美无缺。在过程中需要注意以下几点：


如果研究人员的描述不够详细，就需要进一步补充。


如果需求编写者遗漏了某些边缘情况，就需要在描述中添加相应的规则。


如果技术规范中忽略了某种风险，就需要将其添加到CLAUDE.md文件中。


如果后端开发人员修改了前端代码，就需要重新明确其开发范围。


如果前端开发人员创建了新的API接口，就需要调整相关的使用规则。


如果验证工具遗漏了某些问题，而后来人类发现了这些错误，就需要在规则中添加相应的检查项。


如果系统中的某个环节本应该提前发现这些问题，也需要进行相应的改进。


当开发了三到四个功能后，这个开发流程会逐渐优化。到时候，你花费在监督开发过程上的时间就会减少，而会有更多时间来决定接下来该开发什么功能。
第三部分：总结
10. 未涉及的内容及下一步计划
人工智能辅助开发是一个非常广阔的领域，一篇文章显然无法涵盖所有内容。以下是我有意省略的一些主题，以及我接下来会研究这些内容的顺序。
跨会话的集中式内存管理
一旦你开始同时运行多个会话（每个功能对应一个会话，每个开发分支对应一个会话，每位团队成员也对应一个会话），你就会希望人工智能能够在这些会话之间共享内存。像Claude的项目级内存系统、基于MCP的共享知识存储机制，以及全团队范围内的向量存储系统，都属于这一范畴。这是一个发展迅速的领域，值得专门进行研究。
并行运行代理程序
Claude Code的子代理程序可以在同一个会话内并行运行。同样地，使用那些能够集成Claude Code的工具，在不同的工作流程中同时运行多个会话也是完全可行的（Nimbalyst就是一个例子）。一旦你的开发流程变得稳定，并行处理就能带来显著的效率提升。不过需要注意的是，合并冲突和持续集成带来的开销也可能增加。
基于云的无人值守代理程序

在服务器上运行Claude Code或类似的代理程序，并让它们根据某些事件（比如Webhook触发、定时任务执行，或者新的GitHub问题出现）自动开始工作，这样你就可以在睡觉的时候让开发流程继续进行。不过在2026年这个阶段，这类系统还只适合用于一些简单的任务，比如代码审查和优先级排序。对于那些需要严格验证的复杂开发任务来说，它们目前还不足以信赖。
为你的业务定制MCP服务器
MCP（模型上下文协议）允许你将诸如计费数据、客户支持工单以及设计系统这类内部系统作为工具提供给Claude。一个构建得当的MCP服务器能够使Claude从单纯的编码辅助工具转变为更像是一位了解你业务需求的初级团队成员。一旦你的基础架构已经搭建完成，那么认真研究MCP绝对是值得的。
大规模成本优化
一旦一个团队开始每天使用这种工作流程，代币的成本就会真正成为需要被纳入预算的一项开支。将路由检查与审核任务分配给Haiku系统，将推理工作交给Sonnet系统，而只将最复杂的规划任务留给Opus系统，这样的安排才是最简单有效的优化方式。此外，缓存、批量处理以及精简相关操作也是值得采用的方法。
延伸到产品设计与支持领域
这篇文章主要面向开发人员，但产品负责人、设计师和支持工程师也同样可以从其中受益。他们同样可以利用这些工具、子代理以及各种扩展机制来提升工作效率。当这些不同角色的团队也能各自建立自己的工作流程，并且开发团队能够与他们进行协作时，整个团队的效率将会得到进一步提升。
如果你想深入了解相关内容，官方的Claude Code文档是获取子代理、技能、扩展机制以及MCP等相关信息的最权威来源。Anthropic还提供了一门免费的子代理入门课程，这些内容与这篇文章结合学习会效果更好。
11. 结束语
这篇文章开篇就提出了一个核心理念：利用人工智能来自动化那些结构化明确的工作流程，而非混乱无序的任务。文章后面的十一个章节具体展示了这一理念在实践中的应用方式。
因此，在开始自动化任何工作之前，首先需要明确定义整个系统的工作规则。将这些规则编写到CLAUDE.md文件中，生成那些团队经常需要重复输入的信息，创建能够完成特定任务的代理程序，连接好各个组件，设置相应的控制机制，并确保在那些需要人类判断而非机械操作的环节中，仍然保留人类的参与。
一个“软件工厂”并不是那种能在一夜之间完成产品开发的巨型自动化机器。实际上，它只是你代码仓库中的一小部分文件，这些文件让一名开发人员和一台人工智能共同组成了一支高效协作的团队。代理程序才是真正的核心资产，而“软件工厂”则是让这些代理程序发挥作用的平台。
新的工作方式
在第8节中，我们提到了这样一种理念：一名开发人员完全可以独立完成一个完整的功能模块的开发。现在，请暂时远离键盘，思考一下这一理念对整个团队意味着什么，而不仅仅是对某一位开发人员而言。
软件的开发过程从来都离不开各个环节之间的交接。产品负责人编写需求文档，首席开发人员将其转化为技术规范，后端工程师负责构建API，前端工程师设计用户界面，支付专家则处理集成工作。当某个功能最终上线时，通常会有四五个人参与过它的开发过程，每个人都在等待前一个人完成工作。而每一次这样的交接环节，其实都意味着工作进度会停滞一段时间。

图7：传统的开发流程。每一个箭头都代表一次交接环节，而每一次交接都会导致等待。
“软件工厂”消除了大部分这样的交接环节，因为相关专业知识不再局限于特定的个人手中，而是通过代理程序的形式被共享出来，从而实现了更高效的工作流程。即使是一名从未编写过Stripe Webhook代码的前端工程师，仍然可以完成那些需要使用此类代码的功能开发工作，因为团队中的支付处理专家已经开发并优化好了`payments-integration`这个工具。同样地，即使是一名从未构建过Recharts数据面板的后端工程师，也同样能够完成相关功能的开发，因为前端团队的负责人已经开发出了`dashboard-component-builder`这个辅助工具。QA工程师开发的`regression-suite-writer`工具也可供所有人使用；DevOps工程师的`ci-pipeline-updater`工具同样如此；而安全工程师开发的`auth-checker`工具则会被集成到每一个开发流程中，以确保代码的安全性。
其结果是，一名工程师完全可以独立完成整个开发流程。

图8：新的工作模式。所有工程师都使用相同的代理库进行开发。虽然专家们依然存在，但他们的专业知识体现在他们维护的这些代理程序中，而不再取决于他们是否能够直接参与其他环节的工作。
看看发生了什么变化——专家们依然在团队中发挥作用，前端负责人仍然负责设计系统的开发，支付相关专家依然负责与Stripe平台的集成工作，DevOps工程师也依旧负责持续集成管道的维护。他们的专业知识如今已经变得可复用，这些知识被封装在代理程序中，团队中的任何成员都可以使用这些程序。
这种变化会通过以下三种方式产生显著效果：
开发周期大幅缩短。过去需要三名工程师共同完成的工作，现在只需一名工程师就能独立完成。代码提交后，同一天就能得到审核结果，而不再需要等待整整一周。
专家们能够更专注于高质量的工作。以前，资深支付工程师会花费一半的时间去解决其他工程师在Stripe集成方面遇到的问题；而现在，他们可以将这些时间用来改进payments-integration代理程序本身。这种改进带来的效益是巨大的——一旦这个代理程序得到优化，团队后续发布的所有功能都会因此受益。
团队的扩展方式也发生了变化。

过去，招聘第十名工程师意味着会增加第十组需要协调的工作环节；而现在，招聘第十名工程师意味着会迎来一名具备全栈开发能力的成员，他可以直接利用前九名成员已经构建好的所有工具和资源进行工作。因此，新成员的融入速度更快，协调成本也更低。
这篇文章所要强调的，其实就是这种整体的工作模式转变。这种“自动化工作流程”并不只是为了提高某一位开发人员的效率，而是让整个团队更像一个由全栈开发者组成的社区——大家共同分享自己的专业知识，并通过代码将这些知识转化为实际成果，而不再是一场每次交接任务都需要耗费大量时间的接力赛。
那些最早掌握这种工作模式的团队，并不一定拥有最多的人员或最大的AI预算。相反，这些团队会确保他们的代理库能够反映整个团队的共同需求，保持其最新状态，同时避免让这些工具变得过于复杂。代理程序才是真正的资产，而“自动化工作流程”则是让这些资产发挥作用的关键。
简短说明
随着各种开发工具的不断进化，这种工作流程也会持续发展变化。每个团队都有自己的工作方式，而我在这里分享的内容，只是在实际生产环境中经过验证的最基础、最实用的模式。这并不是最终定稿，而只是一个你可以根据自己团队的实际情况进行调整的起点。
如果你在自己的团队中尝试实施这种工作模式，我很乐意听到哪些方法有效，哪些地方需要改进。要想快速优化工作流程，最好的办法就是了解别人在实践中遇到的问题。祝你在构建自己的“自动化工作流程”时取得成功！
资源
Claude Code


Claude Code简介：code.claude.com/docs/en/overview


子代理：code.claude.com/docs/en/sub-agents


技能：docs.anthropic.com/en/docs/claude-code/slash-commands


内存与CLAUDE.md：docs.anthropic.com/en/docs/claude-code/memory


钩子参考：code.claude.com/docs/en/hooks


钩子使用指南：code.claude.com/docs/en/hooks-guide


其他AI集成开发环境（适用相同原理）


Cursor：cursor.com


Aider：aider.chat


Cline：cline_bot


文章中提到的工具


MCP文档：modelcontextprotocol.io


Context7（当前使用的文档插件）：context7.com


Nimbalyst（用于并行运行Claude Code的工具）：nimbalyst.com


Graphite（用于管理合并请求的工具）：graphite.dev


Sapling（类似工具）：sapling-scm.com