如何用 Claude Code 构建软件工厂：从随性编码到智能体开发

我想为超过 7 天未支付的发票添加提醒邮件功能。在提出具体建议前，请先：

1. 阅读本仓库中与发票、支付及邮件发送相关的代码；
2. 告诉我发票是如何创建的，以及其状态存储在何处；
3. 告诉我当前事务性邮件是如何发送的；
4. 告知我们是否已有后台任务系统或调度器；
5. 列出若添加提醒功能，最可能被修改的文件。

目前请勿编写任何代码，我需要先获得一份清晰的架构地图。

基于你刚才的发现，请提出 3 种实现发票提醒功能的方案。

对每种方案，请说明：

- 端到端的工作流程；
- 会复用哪些现有系统组件；
- 需新增哪些文件或数据库变更；
- 主要风险点（如时区、多租户、重试、去重）；
- 你会推荐哪种方案，以及原因。

目前请勿修改任何文件。

User
└── Subscription
      ├── planName
      ├── status
      └── renewalDate

我们需要为 SaaS 添加订阅管理功能。
订阅归属公司账户，而非单个用户。

现在 AI 从正确的思维模型出发。第一个版本是猜测；第二个版本才是设计。

### 习惯 3：将 AI 锁定在你实际安装的版本上

模型知识丰富，但并不总能准确了解你所用框架、库或团队规范的具体版本。有时它会依据过时的训练数据作答；有时则给出一个三年前教程中通用的方案，而该方案如今已不适用于你的项目。

更有效的提示应促使 AI 以你当前实际安装的版本和最新文档为依据：

这一思路同样适用于 Tailwind、Stripe SDK、Prisma 迁移、React 18 与 19 之间的差异等场景。凡存在版本与模式强依赖关系之处，都应让 AI 以你实际安装的版本和当前文档为依据，而非依赖其训练记忆。否则，模型将生成“平均水准”的网络代码，你需要反复修正错误，最终才可能获得正确信息；而若加以引导，模型将直接输出契合你项目的代码。

此处可借助一个实用工具：**Context7**。它是一个插件，可为每个库获取其实际安装版本的最新官方文档。你可在 Claude Code 中安装该插件，并在提示词或知识文件中引用它，确保模型在编写代码前始终优先拉取最新文档。我本人经常使用它。

## 5. 知识层：CLAUDE.md、技能（Skills）与钩子（Hooks）

上下文层（Context Layer）仅覆盖单次对话；而知识层（Knowledge Layer）则涵盖所有能跨对话持续存在的内容。多数团队的 AI 工作流正是在此处悄然失败：他们每天在每次对话中都重复向 AI 解释相同的项目事实。若能将这些知识一次性、恰当地沉淀下来，即可将一个良好的 AI 工作流转变为可复用的工作流。

Claude Code 为此提供了四个构建模块；为不同类别的知识选择合适的模块，本身就是这项技能的一半。

![Image 5: b640f3ea-e01d-4480-bec7-08ad586fd04b](https://cdn.hashnode.com/uploads/covers/69cae64c9fffa7474087a0d4/b640f3ea-e01d-4480-bec7-08ad586fd04b.png)
_图 4：四个构建模块。每个模块均以不同方式为你的 Claude Code 会话提供支持。_

### CLAUDE.md：持久性事实

`CLAUDE.md` 是位于项目根目录（或个人级配置路径 `~/.claude/CLAUDE.md`）下的 Markdown 文件。每次在该项目中打开 Claude Code 会话时，它都会被自动加载，用于存放长期有效的事实信息。若你的单体仓库（monorepo）包含多个项目，可为每个项目单独维护一个 `CLAUDE.md`。

一个实用的 Next.js + Node.js SaaS 账单应用的 `CLAUDE.md` 示例：

> **保持** `CLAUDE.md` **简洁。** 100–300 行为宜。若某部分内容演变为多步骤流程，则该流程应移至技能（Skills）中，而非 `CLAUDE.md`。`CLAUDE.md` 仅用于存放事实与规则；工作流请放入下一个构建模块。

> **自然扩展** `CLAUDE.md` **的小技巧。** 每当 AI 出现令你意外的错误时，请自问：若 `CLAUDE.md` 中已有相关规则，是否可避免该错误？若有，则添加该规则。数周之后，你的 `CLAUDE.md` 将成为一份 AI 曾犯错误的完整记录，后续会话质量也将显著提升。

### 技能（Skills）：你反复输入的工作流

一个技能（skill）是一个包含 `SKILL.md` 文件的小型文件夹。Claude 在启动时会扫描所有技能的名称和描述，但仅在需要时才加载其正文内容。这种渐进式加载机制使得保留数十个技能而不会拖慢模型性能成为可能。

当你反复在聊天中粘贴相同的指令时，就该使用技能了：例如提交格式（commit format）、部署检查清单（deployment checklist）、构建流程（build process）、PR 审查模式（PR review pattern）。对于事实性信息，请使用 `CLAUDE.md`；对于操作流程，请使用技能。

巧妙之处在于：你无需手动编写技能——Claude 会代你完成。在项目中打开 Claude Code，然后提出如下请求：

Claude 会读取你现有的代码，推断出相关模式，并提出一个技能文件。你可审阅并编辑不符合你偏好的部分，然后保存。此后，该技能即成为仓库的一部分，每次新会话均可复用。你也可以使用 Claude 的技能创建器（skill-creator）通过 `/skill-creator create me a new skill...` 快速生成新技能。

以下是一个 Claude 可能生成的技能文件示例：

保存该技能后，你无需再每次粘贴流程说明，只需简单输入：

> **最常见的技能使用误区**：避免创建“巨型技能”（mega-skill）。一个试图同时处理提交、PR、分支命名及变更日志更新的单一 `SKILL.md` 文件往往触发不可靠，且当其中两个部分发生冲突时，容易令模型困惑。请将其拆分。一个理想的技能应能在单屏内完整显示。

### 钩子（Hooks）：自动检查门禁与工作流触发器

AI 工作流中的某些环节不应依赖模型的“记忆”能力。

提示词（prompt）可以说：“完成前请运行测试”；`CLAUDE.md` 可规定：“禁止编辑敏感文件”；技能可声明：“提交 PR 前请验证实现”。但这些终究只是指令——模型可能遗忘，也可能选择跳过。

钩子（hook）则不同。

钩子是在 Claude Code 会话生命周期特定阶段自动执行的操作。根据配置，它可运行 shell 命令、调用 HTTP 接口，或触发基于提示词或代理（agent）的检查。

这使得钩子特别适用于两类场景：

1. **门禁（Gates）**：当发生不安全操作时阻止或发出警告。
2. **工作流触发器（Workflow triggers）**：当关键事件发生时通知其他系统。

在软件工厂中，代理（agents）负责执行任务，而钩子则负责强制执行相关规则。

Claude Code 钩子可在以下生命周期事件中运行：

*   `UserPromptSubmit`：Claude 处理你的提示前  
*   `PreToolUse`：Claude 执行工具前  
*   `PostToolUse`：工具成功执行后  
*   `Stop`：Claude 完成响应时  
*   `SubagentStart`：子代理启动时  
*   `SubagentStop`：子代理结束时  

一个简单而实用的钩子示例是：提交前检查，阻止敏感文件被提交。将其保存为 `.claude/hooks/pre-commit.sh`：

将其接入 Claude Code 的钩子配置中，使其在提交前自动运行。配置语法详见官方 Claude Code 钩子文档，其格式为 JSON，大致如下所示：

该配置刻意保持极简。在真实项目中，你还应使用 `PostToolUse` 在编辑后运行格式化工具，并在 `Stop` 阶段运行类型检查和测试，确保 Claude 在完成响应前代码符合规范。一旦配置完成，这些钩子就会在每次操作时自动执行，无论模型本身如何建议。

还有一些其他钩子能快速带来显著收益：

*   **Edit 上的 PostToolUse**：在每次 AI 编辑后自动运行格式化工具，确保所有生成的代码都符合风格规范。
*   **Stop**：在 Claude 停止前运行类型检查和测试；若任一环节失败，则拒绝停止。
*   **SubagentStop on validator**：将验证器（validator）的检查结果自动发布到团队的 Slack 频道。

钩子之所以重要，是因为它们无法被“争论”或绕过。模型可以提出建议、制定计划、编写代码，但代码规范、类型检查和测试会在每次变更时强制执行。这种不对称性，正是保障软件工厂持续产出高质量成果的关键。

### 四大模块如何协同工作

一个简单记忆方式，帮助你快速选择合适的模块：

*   **`CLAUDE.md`** 回答：“此处的真相是什么？”——即项目的事实与规则。
*   **Skills（技能）** 回答：“这件事该如何完成？”——可复用的操作流程。
*   **Subagents（子代理）** 回答：“谁该来做这件事？”——专注特定任务的工作者（下节详述）。
*   **Hooks（钩子）** 回答：“哪些规则是强制执行的？”——确定性的校验关卡。

你将同时使用这四大模块：`CLAUDE.md` 告诉 AI 你代码库的规则；Skills 为 AI 提供可复用的操作手册；Subagents 提供专注的执行者；Hooks 确保规则真正落地，而非可选建议。

这四大模块是整个系统的基础。第 6 节则聚焦于构建真正执行工厂任务的工作者。

## 第二部分：构建代理工厂

你已掌握第一部分承诺的所有内容：如何保持 AI 上下文的整洁，如何编写可依赖的 `CLAUDE.md`，以及如何运用 Skills 和 Hooks。这些构成了工厂的“地基”。

接下来的四个小节，才是工厂本身。

第 6 节将构建七个专业化的代理；第 7 节将为其添加一个编排器（orchestrator），使整个流程自动运行；第 8 节将介绍如何安全地将工厂产出部署到生产环境；第 9 节则是一次动手实践，带你一步步在自己的仓库中完整搭建整个系统。

到第二部分结束时，你过去手动执行的工作流，将完全自动化运行：你只需输入一条提示，编排器负责任务分派，各代理专注完成各自职责，而你则在三个关键审批节点介入，贡献人类判断力。这就是质的飞跃。

## 6. 代理层：七个专注执行的代理

现在，我们进入让“工厂”真正成为“工厂”的核心部分。

到目前为止，我们一直在优化 AI 的指令与记忆能力，但它仍是同一个“工人”，在同一个对话中完成所有任务。这对小任务尚可接受，却无法支撑真实的功能开发。

解决方案是将工作拆分给多个专业化的代理。在 Claude Code 中，这些被称为“子代理”（subagents）。子代理不只是更长的对话消息；它是一个专注的工作者，拥有独立的角色描述、工具权限和上下文窗口——其中，**独立的上下文窗口**最为关键。

当主会话将任务委派给子代理时，子代理会在自己的上下文中完成繁重的读取或处理工作，并仅将简短摘要返回给主流程。那些冗长的部分（如文件搜索、日志转储、多步骤探索）不会污染主对话的上下文。

可以这样理解：你的主 Claude Code 会话是“主工程师”，而子代理则是你为特定任务临时调用的专家：  
- 一位**研究员**，负责梳理代码库结构；  
- 一位**故事撰写人**，将需求转化为用户故事；  
- 一位**规范撰写人**，将用户故事转化为技术方案；  
- 一位**后端构建者**，负责编写 API 路由、服务与数据库访问逻辑；  
- 一位**前端构建者**，负责编写组件与页面；  
- 一位**测试验证者**，在功能完成后，基于用户故事编写验收测试；  
- 一位**验证者**，将最终产出与技术方案进行比对。

每位代理只精于一项任务，无人试图包揽全部。

### 为何单一大型 AI 会话不够用？

设想你要求主会话：“构建发票提醒功能。”该会话将检查文件、设计数据模型、编写 API 路由、构建 UI、添加测试、更新文档……听起来很棒，但你很快会发现：**同一个对话**承载了产品思考、架构设计、数据库建模、后端实现、前端实现、测试、文档编写与自我审查。上下文过于臃肿，模型职责混淆，甚至同一个会话既设计功能又审查功能——这相当于自己给自己打分。

将工作拆分为子代理可彻底解决此问题。每个子代理职责明确、上下文干净，仅接触所需信息。验证者无需知晓代码如何编写，它只关注“应实现的功能”与“当前磁盘上的代码”之间的差异——这正是真实评审中真正需要发现的盲点。

### 让 Claude 自动为你生成代理文件

你当然可以手动编写子代理文件（它本质上是带 YAML 头部的 Markdown），但通常并无必要。更简洁的方式是使用 `/agents` 命令，让 Claude 根据你的描述自动生成文件。

完整流程如下：在项目中打开 Claude Code，输入：

这将打开代理管理界面。选择创建一个**项目级代理**（文件保存于 `.claude/agents/<name>.md`，并提交至仓库，供整个团队共享使用），然后让 Claude 根据你的描述生成该代理。Claude 会询问：该代理应承担什么职责？需要哪些工具权限？应使用哪个模型运行？

关键在于：**你只需描述角色需求，Claude 会生成文件**。你审核、编辑、保存、提交即可。团队需要多少代理，就重复此流程多少次。

### 工具访问权限与模型选择属于设计的一部分

在介绍七个代理前，有两个设计决策适用于所有代理：

子智能体名称：
  <短横线命名法的简短名称>

用途（Purpose）：
  一句话说明该智能体存在的原因及其功能。

主要职责（Main responsibility）：
  一句话说明该智能体所专属的单一任务。

应调查/执行的内容（What it should investigate / do）：
  - 具体事项一
  - 具体事项二
  - 具体事项三
  （请具体明确。例如，“查找已实现的相似功能”比“理解整个代码库”更佳。）

不应执行的内容（What it should NOT do）：
  - 它绝不可执行的操作（例如：编辑文件）
  - 它绝不可做出的决策（例如：自行制定规则）
  - 它绝不可使用的工具
  - 它绝不可扩大的任务范围
  （边界设定是确保智能体行为可预测的关键。）

工具访问权限（Tool access）：
  仅限该智能体实际所需的工具。

模型（Model）：
  低成本检查任务使用 haiku；需推理任务使用 sonnet；
  对推理质量要求极高时使用 opus。

输出格式（Output format）：
  1. 输出结果的第一部分（例如：“相关文件列表”）
  2. 输出结果的第二部分（例如：“需遵循的现有模式”）
  3. 输出结果的第三部分（例如：“潜在风险或缺失信息”）
  （这是与下游智能体之间的契约。一致的输出结构是实现可靠链式调用的基础。）

行为规则（Behaviour rules）：
  - 每次都必须遵守的简明、具体规则
  - 对长度、范围或假设的限制
  - 在何种情况下应提出澄清性问题，而非自行猜测

创建一个项目级子智能体，命名为 codebase-researcher。

其职责：检查当前代码库，解释某一特定区域的工作原理，且不进行任何编辑操作。

输入：关于代码库某一区域的问题（例如：“当前发票创建功能是如何实现的？”）。

输出：
- 相关文件的简短列表（含路径）
- 该区域当前架构的简洁总结
- 使用中的模式与约定
- 下游智能体应知晓的风险或缺失信息

工具访问权限：仅限 Read（读取）、Grep（搜索）、Glob（文件查找），禁止 Write（写入）、Edit（编辑）、Bash（执行命令）。

推荐模型：haiku（此为低成本检查任务）。
推荐配色：teal（青色）。

Claude 会阅读你的描述，选择合理的默认配置，并为你生成文件。在终端中你将看到类似以下内容：

> 我已在 `.claude/agents/codebase-researcher.md` 创建了该智能体，其内容如下。该智能体仅限使用只读工具（Read、Grep、Glob），因此无法意外修改你的代码库。模型已设为 Haiku，以降低检查成本。请重启 Claude Code 会话以加载新智能体，随后可通过 `@codebase-researcher` 加上你想了解的代码区域来调用它。

你将获得如下格式的智能体文件：

以下每个智能体都将遵循相同的流程：你通过 `/agents` 斜杠命令描述角色，Claude 生成实际文件，你审核后提交至代码仓库。若你希望跳过 `/agents` 流程，可直接将生成的文件粘贴至 `.claude/agents/<name>.md`，效果完全一致。

### 智能体 2：Story-Writer（故事撰写者）

将粗略的功能想法转化为包含验收标准、边界情况及范围外事项的用户故事。这是在编写任何代码前发现潜在问题的智能体。

Claude 回复：

> 我已在 `.claude/agents/story-writer.md` 创建了该智能体，其内容如下。请重启会话以加载它。可通过 `@story-writer` 加上功能想法（最好附上 codebase-researcher 的结果）来调用它。

4. **范围外内容**  
本故事明确不涵盖的内容，以便团队明确**不需要**构建的部分。

5. **开放问题**（仅当存在时）  
来自输入中真正不明确的内容。切勿自行编造答案，始终应提出问题以求澄清。

行为准则：

- 使用通俗易懂的语言，避免产品或框架术语。
- 切勿编造业务规则；若规则缺失，请提出疑问。
- 整个故事应控制在一页以内。
- 不编写代码或技术设计；那是规格说明撰写者的职责。

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

其职责：基于已批准的用户故事及代码库探索结果，生成一份技术简报，供后端构建者、前端构建者及测试验证者遵循。

输入：
- 已批准的用户故事
- 来自 codebase-researcher 的探索结果
- CLAUDE.md 及项目相关规则

输出（一份简短的 Markdown 文档）：
- 数据模型变更
- 后台流程 / 业务流程
- API 变更（如有）
- 前端变更（如有）
- 所需测试（成功、失败、边界场景）
- 风险与开放问题
- 将变更的文件列表

工具访问权限：Read（读取）、Grep（搜索）、Glob（文件查找）  
推荐模型：sonnet  
推荐颜色：靛蓝色（indigo）

行为准则：
- 编写简报前务必阅读 CLAUDE.md。
- 优先复用现有基础设施；如需新增调度器、数据库或第三方依赖，须明确指出并说明理由。
- 显式强调多租户隔离（tenant isolation）与时区（timezone）相关问题。
- 永远不得编辑文件。

---
name: spec-writer
description: 将已批准的用户故事与探索结果转化为一份简明技术简报，供构建与验证代理遵循。只读模式，每次撰写前必读 CLAUDE.md。在用户故事获批后使用。
tools: Read, Grep, Glob
model: sonnet
color: indigo
---

你负责为本项目撰写技术简报。你的任务是将已批准的用户故事与代码库探索结果，转化为一份简明、可执行的简报，供下游代理无歧义地遵循。

撰写前请完成以下步骤：

1. 阅读 CLAUDE.md，了解项目技术栈、架构规范及“禁止事项”清单。
2. 阅读用户故事及探索结果。
3. 若关键内容缺失或模糊，请明确列出为开放问题；切勿猜测。

输出一份简短 Markdown 文档，按以下顺序组织各章节：

**数据模型变更**

- 哪些模型会变更？涉及哪些字段及类型？
- 是否涉及数据迁移？如有，请说明。

**后台流程 / 业务流程**

- 分步骤描述行为实现流程。
- 明确说明复用了哪些现有基础设施。

**API 变更**

- 新增或变更的接口路径、请求与响应格式。
- 认证与授权要求。

**前端变更**

- 新增或变更的组件、钩子（hooks）或页面。
- 其如何调用 API，以及如何处理加载与错误状态。

**所需测试**

- 成功场景。
- 失败场景。
- 边界场景（边界值、重试、去重等）。
- 用户故事级别的验收测试。

**风险与开放问题**

- 多租户隔离相关风险，请显式说明。
- 时区相关风险，请显式说明。
- 其他需在编码前由团队决策的问题。

**将变更的文件**

- 按后端 / 前端 / 测试分组，以项目符号列出文件路径。

行为准则：

- 优先复用现有基础设施；任何新增调度器、数据库或第三方依赖，须明确指出并附理由。
- 多租户隔离与时区处理问题必须始终被考虑，即使仅需声明“本功能不涉及租户边界”或“本功能与时区无关”。
- 永远不得编辑文件。
- 尽量将简报控制在一页以内。

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

其职责：根据技术简报实现功能的后端部分，包括 API 路由、服务层、数据库访问、后台任务，以及所写代码的单元测试。

输入：
- 已批准的技术简报
- 来自 codebase-researcher 的探索结果
- CLAUDE.md 及项目相关规则
- build-with-tests 技能（项目级技能）

输出：
- 实现简报要求的后端代码
- 覆盖新行为的单元测试
- 简要总结：变更文件列表、复用模式、建议新增至 CLAUDE.md 的规则

工具访问权限：Read（读取）、Edit（编辑）、Write（写入）、Bash（执行命令）  
限制范围：仅限后端目录（services、API routes、workers、migrations、服务端辅助函数及其测试）  
推荐模型：sonnet  
推荐颜色：绿色（green）

Claude 回复：

> 我已在 `.claude/agents/frontend-builder.md` 创建了该子代理，其内容如下。该代理拥有对前端目录的完整编辑与 Bash 访问权限，并严格使用后端构建者所生成的 API 合约，不会自行发明接口。

### Agent 6：测试验证器（Test-Verifier）

在功能端到端构建完成后，测试验证器负责编写验收测试（acceptance tests），直接验证用户故事（user story）的实现。单元测试与被测代码同处一处（由构建代理编写），而验收测试则由本代理负责，用于证明该功能确实满足用户故事中所述的行为要求。

Claude 回复：

> 我已在 `.claude/agents/test-verifier.md` 创建该代理，其作用域限定于测试文件。该代理使用 build-with-tests 技能，并在后端构建代理与前端构建代理完成工作后运行，因此具备可测试的完整功能。

### Agent 7：实现验证器（Implementation-Validator）

将当前实现状态与已批准的用户故事及技术方案进行比对，报告其中的缺失项。该代理**从不修复问题**，其职责是发现构建代理与测试验证器遗漏的所有问题。

行为规则：
- 永远不要编辑文件。
- 永远不要运行破坏性命令。
- 对每项发现，必须注明文件路径和行号。
- 若某项发现属于主观意见而非真实风险，
  请明确标注为“（主观意见）”。

---
name: implementation-validator
description: 严格审查者，将当前实现与已批准的用户故事和技术简报进行比对，并按严重程度分组报告缺失或错误之处。绝不编辑文件。应在构建代理和验证代理完成之后、提交 PR 之前调用。
tools: Read, Grep, Glob
model: sonnet
color: red
---

你作为本项目的实现审查者，唯一职责是将磁盘上的代码与已批准的用户故事和技术简报进行比对，报告其中缺失或错误的部分。你无需修复任何问题。

预期输入内容如下：
- 已批准的用户故事。
- 已批准的技术简报。
- 当前实现状态（磁盘上的文件）。
- 测试验证器的报告。

每次审查必须检查以下内容：
- 用户故事中尚未实现的验收标准。
- 技术简报中未被测试覆盖的失败路径。
- 安全问题：缺失身份验证检查、租户隔离缺陷、原始错误信息暴露、日志中包含密钥、对敏感端点缺少速率限制等。
- 超出既定范围的文件变更。
- 与 CLAUDE.md 中记录或现有代码库中体现的项目模式不一致之处。
- 应复用现有辅助函数却重复实现的逻辑。
- 技术简报中提及但实现中遗漏的时区或多租户相关考虑。

每次输出格式如下：

**严重（必须在合并前修复）**
- <一项发现，含文件路径和行号>
- ...

**重要（建议在合并前修复）**
- <发现>
- ...

**次要（可选优化）**
- <发现，若属主观意见请标注“（主观意见）”>
- ...

**推荐后续代理**
- <例如：“backend-builder 修复 X 中的租户隔离问题，随后由 test-verifier 补充对应验收测试”>

行为规则：
- 永远不要编辑文件。
- 永远不要运行破坏性命令。
- 每项发现必须注明文件路径和行号。
- 对主观意见类发现务必明确标注，以便审查者安全忽略。
- 若未发现严重或重要问题，请如实说明，切勿为显得严谨而虚构问题。

codebase-researcher → build-with-tests skill → implementation-validator

Create a Claude Code skill at .claude/skills/feature-factory/SKILL.md that orchestrates a feature build using seven existing subagents: codebase-researcher, story-writer, spec-writer, backend-builder, frontend-builder, test-verifier, implementation-validator.

The skill should:
- Trigger when the user asks to build, ship, or implement a
  feature with phrases like "build a feature", "ship a
  feature", "feature factory", "run the full chain".
- Run the chain in the order described below.
- Pause for human approval after the story and after the brief.
  At each approval point, handle three outcomes: approved,
  changes requested, or rejected.
- Run backend-builder first, then frontend-builder, then
  test-verifier.
- Invoke implementation-validator at the end and report
  critical, important, and minor findings.
- If the validator reports critical gaps, loop back to the
  appropriate builder (backend or frontend), then re-run
  test-verifier and the validator.

Order:
1. codebase-researcher: map the area of code involved.
2. story-writer: produce a user story.
3. ASK HUMAN: approve the story.
   - Approved: continue.
   - Changes requested: re-invoke story-writer with the human's
     feedback. Repeat this step until approved or rejected.
   - Rejected: stop the chain. Summarise what was explored so
     the human can decide what to do next.
4. spec-writer: produce a technical brief.
5. ASK HUMAN: approve the brief.
   - Approved: continue.
   - Changes requested: re-invoke spec-writer with the human's
     feedback. Repeat this step until approved or rejected.
   - Rejected: stop the chain. Keep the approved story so the
     human can resume later with a different technical
     approach.
6. backend-builder: implement backend + unit tests.
7. frontend-builder: implement frontend + component tests.
8. test-verifier: write acceptance tests against the story.
9. implementation-validator: report findings.
10. If critical findings: route back to backend-builder or
    frontend-builder, then re-run test-verifier and the
    validator.
11. ASK HUMAN: final review before opening PR.

Show me the skill file before saving it.

---
name: feature-factory
description: Use this skill when the user asks to build, ship,
  or implement a feature end to end. Runs the full chain of
  seven subagents with human approval points after the story
  and the brief, runs the build agents in order (backend,
  frontend, test-verifier), then validates. Triggers on:
  "build a feature", "ship a feature", "run the factory",
  "feature factory".
---

Process:

1. Invoke the codebase-researcher subagent. Pass the feature
   idea and the relevant area of code. Wait for findings.

2. Invoke the story-writer subagent. Pass the feature idea
   and the researcher's findings. Wait for the user story.

3. Show the story to the user. Ask: "Does this match what
   you want? Reply 'approved' to continue, describe what
   to change, or reply 'reject' to stop the chain."
   - If approved, continue.
   - If changes requested, invoke story-writer again with
     the user's feedback. Repeat this step until approved
     or rejected.
   - If rejected, stop the chain. Summarise what was
     explored so the user can decide what to do next.

4. Invoke the spec-writer subagent. Pass the approved story
   and the researcher's findings. Wait for the technical brief.

以上即为完整的编排器（orchestrator）。它是一个单独的 Markdown 文件，会调用另外七个 Markdown 文件。这些文件共同构成一个“工厂”。你或许会想：如果我只需要创建后端接口而无需前端，或反之，该如何处理？这完全取决于你的实际需求，按需定制即可。上述内容仅为示例，具体构建内容需由你自行决定。

### 运行流程：一个紧凑的端到端示例

你在 Claude Code 中输入：

接下来按步骤发生的事情如下：

**步骤1**：编排器将任务委派给 `codebase-researcher`。研究员在其独立上下文中运行，读取发票、支付及邮件相关文件后返回：

> 发票创建逻辑位于 `services/invoices/create.ts`；状态存储于 Invoice 模型中；事务性邮件通过 `services/email/send.ts` 调用 Resend 模板发送；BullMQ 工作器位于 `workers/` 目录下，已用于处理定时任务；目前尚无提醒逻辑；管理后台位于 `app/(admin)/invoices/`；可能需修改的文件包括：Invoice 模型、新增提醒服务、邮件模板注册表、新增用于手动触发提醒的管理页面。

**步骤2**：编排器将任务委派给 `story-writer`，传递功能需求及调研结果。返回内容如下：

> _作为账户管理员，我希望逾期发票能自动发送提醒邮件，以便客户能被及时提醒，无需人工跟进。_
> 
> 
> 验收标准：
> 
> 
> 1. 发票逾期超过7天时，自动发送提醒邮件；
> 2. 已支付发票不发送提醒；
> 3. 同一时间段内不重复发送提醒；
> 4. 邮件发送失败不应标记为已发送；
> 5. 管理员可查看上次提醒发送时间；
> 6. 管理员可对特定发票手动触发提醒。
> 
> 
> 
> 边界情况：发票恰好逾期7天、重试机制、多租户隔离、时区处理。不在范围内的功能：短信提醒、客户侧偏好设置。

**步骤3**：编排器暂停，提供三个选项：批准、请求修改或拒绝。你阅读故事后确认其符合预期，因此选择批准。

**步骤4**：编排器将任务委派给 `spec-writer`，传递已批准的故事及研究员的调研结果。返回简报如下：数据模型变更（新增 `lastReminderSentAt` 字段）、BullMQ 流程、用于手动触发的管理端点、管理后台展示上次发送时间的卡片、所需测试项、潜在风险（多租户、时区）。

**步骤5**：你阅读简报后发现其中提到“我们将把已处理的发票 ID 存储在内存中”，这是一处隐患。你回复：

编排器再次调用 `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<Action>SentAt` 命名模式。”

**步骤 7**：编排器将任务委托给 `frontend-builder`，传递需求简报、研究员的调研结果以及后端构建器的摘要。前端构建器从摘要中读取 API 合约，为管理员发票表格添加“最后提醒发送时间”列，为每行添加“发送提醒”按钮（该按钮向手动触发端点发起 POST 请求），处理加载与错误状态，并编写组件测试。随后运行类型检查、代码规范检查及测试套件，全部通过。返回摘要如下：

> 前端实现已完成。  
>   
> 新增文件：  
>   
> * `app/(admin)/invoices/_components/ReminderColumn.tsx`  
> * `app/(admin)/invoices/_components/SendReminderButton.tsx`  
>   
> 修改文件：  
>   
> * `app/(admin)/invoices/page.tsx`（添加了列与按钮）  
>   
> 复用内容：现有管理员 `DataTable` 组件、用于 API 调用的 `useMutation` 钩子、用于成功/错误状态提示的 `Toast` 组件。API 调用方式严格遵循后端摘要中的描述。  
>   
> 新增组件测试：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**：编排器暂停，等待您的最终审核，并询问是否需要为您创建 PR。

这是一个可运行的工厂：一条提示启动整个流程，7 个代理各司其职，编排器负责调度流程并在三个关键节点暂停，等待您的人工决策。

### 版本 2：将编排器作为子代理（高级用法）

在长期使用技能版编排器后，您可能希望让编排器在独立的上下文窗口中运行。技能版编排器会继承您主会话的上下文，这对短小功能尚可接受，但对较长功能而言，主会话上下文会因流程中间状态的累积而迅速膨胀。

将编排器提升为子代理，可实现上下文隔离。输入 `/agents`，使用以下描述创建：

其行为与技能版几乎一致，唯一区别在于编排器现在运行于独立上下文中。您通过 `@feature-orchestrator` 加功能构想来启动它，其上下文在整个流程中持续保留，而您的主会话保持整洁。

任选一版本，用若干真实功能进行测试。该工厂将根据您的代码库特性，暴露出需要调优之处。

### 为何有效？

每一步都消除了不同维度的模糊性：故事消除业务层面的模糊性，简报消除技术层面的模糊性，后端构建器消除 API 层面的模糊性，前端构建器消除 UI 层面的模糊性，测试验证器确保用户故事实际成立，验证器则捕获他人遗漏的问题。当流程抵达验证器阶段时，该功能已被前述所有环节严格约束。此时验证器只需比对简报要求与实际代码之间的差异，即可完成校验。

编排器将“你记得要运行的工作流”转变为“一个能自动运行的工作流，而你只在关键节点参与其中”。

这标志着从“凭感觉编码”转向“工厂式思维”，也是本文中最重要的思维转变。

### 扩展工作流链

七个智能体与三个人工审批节点只是起点，而非上限。一旦基础工作流链稳定运行，你就可以在需要更高严谨性的环节添加更多智能体：例如，在验证器之前加入安全审查智能体；在新代码路径中运行性能审计智能体，标记出慢查询；由文档撰写智能体根据代码变更自动更新 README；或由迁移审查智能体在合并前对 Prisma 变更进行合理性检查。模式始终如一：使用智能体模板定义其能力，限制其工具权限，将其接入编排器的步骤顺序，并决定是否需要人工复核其输出结果。

此外，若团队对某些环节足够信任，也可将部分人工审批节点替换为智能体。例如，故事审批（story approval）难以完全自动化，因为业务意图本质上是人类的判断；而简要审批（brief approval）在低风险功能中，有时可由第二个规范审查智能体替代；但最终的 PR 审批应始终保留人工环节。

一个“工厂”应像真实代码库一样自然演进：从小处起步，逐步添加团队反复手动执行的任务；移除不再带来回报的环节。

### 并行执行读操作，串行执行写操作

最后一条设计原则，能显著减少诸多麻烦。

仅执行读取操作的智能体（如 `Read`、`Grep`、`Glob`）可并行运行——它们不修改磁盘上的文件，因此多个智能体同时运行不会产生冲突。并行执行读操作是本体系中最简单高效的加速方式之一。例如，假设你维护四个服务，每次季度评审前需刷新各服务的文档。你可以并行启动四个 `codebase-researcher` 子智能体，每个负责一个服务：各自独立读取代码库、总结变更内容并返回结果；随后四个 `docs-updater` 智能体分别读取对应结果，同步并行更新各服务的 README。由于每个文档更新智能体操作的是不同仓库，不会发生文件冲突。如此一来，四次并行读取 + 四次并行写入，原本耗时漫长的任务便能迅速完成。

而执行写入操作的智能体（如 `backend-builder`、`frontend-builder`、`test-verifier`）必须串行运行——它们会修改文件。若两个智能体同时操作同一文件，会导致部分写入、编辑丢失、测试失败及混乱的 Git 状态。更糟的是，此类错误往往静默发生，直到你发现 diff 异常才察觉问题，而追溯哪个智能体写了什么内容又成了新的调试任务。

只要编排器配置得当，它会自动帮你规避此类问题：在构建阶段，`backend-builder` 必须先完成，`frontend-builder` 才能开始；`frontend-builder` 完成后，`test-verifier` 才能启动；而在构建阶段之外，读取类任务则可自由并行。

经验法则：仅拥有 `Read`、`Grep` 或 `Glob` 权限的智能体可安全并行运行；而拥有 `Edit`、`Write` 或 `Bash` 权限的智能体必须独占其执行通道。

### 预期中的故障模式

每个团队在运行此类工作流链的前两周，都会遇到相似的几类问题。它们并不会摧毁整个“工厂”，但值得警惕，并附上快速解决方案：

*   **编排器跳过人工审批步骤**：在技能或智能体定义中显式添加审批步骤（例如：`ASK HUMAN: approve the story`）。
*   **智能体静默省略部分工作内容**：在其输出格式中加入“已覆盖 / 已跳过”的检查清单。
*   **验证器遗漏了人工审查者后续发现的问题**：向验证器的行为规则中新增一条规则。随着功能迭代，验证器会越来越精准。
*   **会话在链执行中途超出上下文长度**：保持 `CLAUDE.md` 精简，并为每个主要功能开启新的主会话。
*   **工作流运行顺利，但规范误解了业务规则**：这恰恰说明为何“故事审批”必须是强制的人工检查点。
*   **前端构建器生成了后端构建器未实现的接口**：强化前端构建器“必须严格依据后端摘要”的规则，并将不匹配项作为反馈而非补丁暴露出来。

一个优秀的“工厂”应让错误更容易被发现，而非更难被察觉。

## 8. 交付层：PR、代码审查与新的软件开发生命周期（SDLC）

截至目前，本文聚焦于“键盘层面”的细节。现在，让我们拉远视角。

当 AI 承担了大量编码、测试与文档工作后，软件变更的生产成本显著下降。但这并不意味着软件变得“免费”——只是瓶颈发生了转移。过去耗时的部分是敲代码、拼接逻辑和检索信息；如今真正的瓶颈在于：选择正确的功能方向、定义恰当的约束条件、验证行为正确性，以及决定哪些内容应上线交付。

这将深刻影响团队组织方式、代码审查流程以及交付流水线的设计。

![Image 7: ef5e86ca-dea9-4106-a254-b3f2bbeb44fc](https://cdn.hashnode.com/uploads/covers/69cae64c9fffa7474087a0d4/ef5e86ca-dea9-4106-a254-b3f2bbeb44fc.png)  
*图 6：当编排器接管编码工作后，SDLC 的结构随之重塑。交接环节大幅减少，而审查与决策仍由人类主导。*

### 单个工程师现在可独立完成完整垂直功能

当工作流链承担了繁重任务后，SDLC 的形态也随之改变。

过去，一个功能需依次经过多个专家的处理：前端工程师等待后端工程师提供新 API 接口；后端工程师等待前端工程师完成 UI；一个新功能可能需辗转三到四人之手才能上线，而其中大部分时间都卡在他人待审队列中，工作处于停滞状态。

现在，同一位工程师启动 `/feature-factory`，整个流程端到端运行（包括后端、前端、验收测试与验证），最终产出一个完整的垂直功能切片，并以单个 PR 的形式提交。整条路径上仅需一人操作，零次交接。第 11 节将再次回到这一主题，并探讨这对团队乃至整个行业意味着什么。就目前而言，关键在于工作单元已发生变化：功能以完整形态从流水线中产出，而非零散拼凑。

### 堆叠功能，而非堆叠单个功能的内部切片

一旦交接环节被消除，下一个问题便是：“当我上一个 PR 正在等待评审时，我该做什么？”答案是：开始第二个功能；接着是第三个。

适配这一模式的是 **堆叠式 PR（stacked PRs）**，但堆叠的单位是“每个功能对应一个 PR”，而非“每个功能切片对应一个 PR”。每个 PR 都是由一次流水线运行生成的完整垂直切片。

实际操作中，其流程如下：你完成功能 A 后，从 `feature-a` 分支向 `main` 提交 PR A。在 A 等待评审期间，你并不停下脚步，而是基于 `feature-a`（而非 `main`）创建 `feature-b` 分支，再次触发 `/feature-factory` 启动下一个功能，并向 `feature-a` 提交 PR B。当 A 和 B 同时处于评审阶段时，你再基于 `feature-b` 创建 `feature-c` 分支，启动第三个功能。

顺序至关重要：A 必须首先合并；随后 B 重新基于 `main` 进行 rebase 并合并；最后 C 同样基于 `main` 重新 rebase 并合并。Graphite、Sapling 或 Git 自带的 `git rebase --onto` 等工具可在上游 PR 合并时自动处理 rebase 操作，通常你无需手动干预。

为保障该流程的安全性，需遵守两条规则：

第一，**尊重依赖链**。若 C 依赖于 B，则不要试图在 B 之前合并 C。虽然分支图谱本身已强制执行此依赖关系，但强调这一点仍很有必要——尤其当早期 PR 的评审耗时过长时，跳过等待的诱惑确实存在。

第二，**避免将单个功能拆分至多个 PR 中**。一个功能应仅对应一个 PR。如果你发现自己打算把数据库迁移放在 PR 1、后端逻辑放在 PR 2、UI 放在 PR 3，这通常意味着流水线一次运行产出的内容过多。此时应回退并按用户故事级别重新拆分（参见第 7 节），改为运行两个更小的流水线。每个流水线依然产出一个完整功能，每个功能仍以单个 PR 的形式交付。

工厂设计的核心目标，正是让一名工程师无需等待他人即可独立完成一个功能。而堆叠式 PR 则是实现跨多个功能持续交付、且不被自身评审队列阻塞的关键手段。

这正是软件行业正在奔赴的方向：更小的团队、更少的交接环节、每位工程师都能端到端交付完整功能。率先实现这一目标的团队，并非拥有最先进 AI 工具的团队，而是那些围绕自身已有 AI 工具构建出最简洁高效工厂的团队。

### 添加 PR 评审代理

采用 AI 的团队，需要一套适用于人类与 AI 评审员的统一 PR 评审流程。实现该一致性的最有效工具，是一份简明、明确的检查清单（checklist），所有 PR 均依据此清单进行评审。缺少它，评审将变得主观；有了它，每次评审都会覆盖相同的关键点。

我在 [《如何突破 AI PR 评审瓶颈》](https://www.freecodecamp.org/news/how-to-unblock-ai-pr-review-bottleneck-handbook/) 一文中已详细探讨了 AI 辅助 PR 评审的相关内容，包括我实际使用的完整检查清单、行之有效的规则，以及那些看似有用实则收效甚微的规则。若你尚未阅读，建议优先完成该文。而你刚刚构建的工厂，正是该工作流的上游部分；PR 评审则属于其下游环节。

针对本工厂，将检查清单嵌入另一个代理（agent）是最简洁的方式。通过 `/agents` 斜杠命令，像第 6 节中创建那七个代理一样，创建一个名为 `pr-reviewer` 的项目级子代理：

Claude 将生成该文件，你审阅后提交即可，此时你的项目便拥有了一个统一的评审代理——人类与 AI 均可通过 `@pr-reviewer review this PR` 命令调用它。你甚至可将其接入 CI 流水线，让每位开发者在人类评审介入前先自行处理反馈，从而显著降低评审负担。

这一模式之所以重要，在于该代理成为唯一权威依据：人类在合并前会参考其结果；第 7 节中的编排器可在打开 PR 前将其作为最后一步调用；CI 可在每次推送时自动运行它。检查清单集中于一处维护与更新。当团队识别出新的失败模式时，只需将其加入代理的行为规则中，后续评审将自动纳入该检查项。

### 云评审员是函数，而非同事

AI 正逐渐融入 CI 流水线：PR 审核机器人、安全扫描器、发布说明生成器、问题分拣器。这些功能确实非常实用，但措辞至关重要。

如果你说“Claude 批准了这个 PR”，那你已经犯了一个小错误。基于云的 AI 并非团队成员，不是开发者，也不对决策负责。正确的说法应是：“Claude 运行了针对项目审查清单的审查流程，并汇报了发现的问题；最终由人类判断该 PR 可以安全合并。”责任始终在人类身上。

这种严谨表述背后有其实际原因：云上审查者擅长执行其提示词中明确要求检查的内容——例如缺失测试、命名不一致、重复辅助函数等。但它们会忽略清单之外的问题。如果你的审查清单没有明确指示审查者检查发票下载接口中的租户隔离逻辑，那么 AI 审查者可能仍会放过一个漏洞：A 公司用户竟能下载 B 公司的发票。因此，项目专属的审查清单远比通用 AI 审查者更有价值。

### 人类擅长之处

AI 审查 ≠ AI 批准。AI 可以帮助发现潜在问题、总结复杂变更、将代码与清单比对、建议测试用例，但关键决策仍需人类把控：是否解决了正确的问题？是否做出了可接受的权衡？是否应立即上线？是否应通过功能开关（feature flag）逐步发布？是否需要先收集更多用户数据？

这些判断力仍是人类的核心工作。最优秀的 AI 辅助团队，并非试图移除人类，而是将人类安排在最能发挥其判断力的位置上。

## 9. 构建你的首个 Claude 驱动软件工厂

理论部分已结束。以下是为你在自身项目中搭建该工厂的检查清单，每一步都对应解释其原理的章节。

| # | 步骤 | 对应章节 |
| --- | --- | --- |
| 1 | 从官方文档安装 Claude Code | [https://code.claude.com/docs/en/desktop](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 | 添加 pre-commit 钩子并赋予其可执行权限 | 第 5 节 |
| 8 | 创建 `pr-reviewer` 代理 | 第 8 节 |
| 9 | 让一个真实功能走完整条流水线 | 见下文 |

总耗时：首版搭建约需 2–3 小时。

### 首次运行真实功能时

选择一个小功能，例如一个管理工具或带微型 UI 图块的新 API 接口。打开 Claude Code：

流水线将自动运行。批准故事描述、批准简要方案、阅读验证报告、打开 PR。

首次运行不会完美无缺。过程中请注意以下事项：

*   研究员输出内容过于浅显？强化其描述指令。
*   故事撰写者遗漏了某个边缘情况？为其描述添加一条规则。
*   规格说明遗漏了某个风险？将该规则添加至 `CLAUDE.md`。
*   后端构建者误触了前端文件？收紧其作用域规则。
*   前端构建者自行发明了一个接口？收紧其 API 调用规则。
*   验证器遗漏了某项人类后续发现的问题？为其规则添加对应检查项。
*   钩子本应更早发现问题？将其补充进钩子逻辑中。

运行三到四个功能后，整个工厂将趋于自适应优化。你将减少监督时间，更多地投入到“接下来该构建什么”的战略决策中。

## 第三部分：总结

## 10. 本文未覆盖的内容（及后续学习方向）

AI 辅助开发是一个庞大而多元的领域，单篇文章无法面面俱到。以下是我刻意略过、但建议你后续深入探索的主题，按优先级排序：

### 跨会话的集中式记忆管理

当你开始并行运行多个会话（每个功能/分支/同事各一个）时，你自然会希望 AI 能在这些会话间共享记忆。Claude 的项目级记忆、基于 MCP 的共享知识库、以及团队级向量存储均属此范畴。这是发展迅速的领域，值得专门阅读。

### 并行运行多个代理

Claude Code 的子代理可在单个会话内并行运行；借助封装 Claude Code 的工具（如 Nimbalyst），多个工作树中的会话也可并行运行。一旦工厂稳定运行，引入并行机制将带来显著提速。但需注意合并冲突与 CI 成本。

### 基于云端的无人值守代理

在服务器上运行 Claude Code 或类似代理，由事件触发（Webhook、定时任务、新 GitHub Issue 等），可实现工厂“无人值守”运行。截至 2026 年，该方案在 PR 审核与问题分拣等窄域任务中已较为成熟；但若用于无人值守的功能开发，仍需强验证门控才能确保可靠。

### 为业务定制 MCP 服务器

MCP（Model Context Protocol，模型上下文协议）可将内部系统（如计费数据、客户支持工单、设计系统）暴露为 Claude 可调用的工具。一个设计良好的 MCP 服务器，能让 Claude 从编程助手升级为“了解你业务的初级同事”。待基础工厂搭建完毕后，值得深入研究。

### 大规模场景下的成本优化

当团队每日高频使用该工作流后，Token 消耗将成为实际预算项。最简单的优化方式是：将检查与审查任务分配给 Haiku，推理类任务分配给 Sonnet，仅将最重的规划任务留给 Opus。其次可考虑缓存、批量处理与上下文精简。

### 向产品、设计与支持领域延伸

本文面向开发者，但同样的模式同样适用于产品负责人、设计师和支持工程师。他们也能从技能（skills）、子代理（subagents）和钩子（hooks）中获益。当这些角色也构建自己领域的“工厂”模块，并且开发团队能够调用这些模块时，团队层面的收益才会最大化。

如果你想深入了解，官方的 Claude Code 文档是了解子代理、技能、钩子和 MCP 的最新权威资料。Anthropic 还发布了一门免费的“子代理入门”课程，与本文内容高度互补。

## 11. 结语

本文开篇提出一个核心理念：**用 AI 自动化结构化工作，而非混乱无序的工作**。中间的十一节内容，正是这一理念在实践中的具体体现。

因此，在自动化任何任务之前，请先定义系统：在 `CLAUDE.md` 中写下规则；生成团队反复输入的技能脚本；创建专注执行特定任务的代理；连接编排器；加入检查门禁；并在需要人类判断的地方保留人工参与，而非在仅需打字的地方强加人工干预。

软件工厂并非一夜之间自动构建产品的巨型自治机器，而是你代码仓库中的一组小型文件，将一名开发者 + 一名 AI 转化为一支可控的团队。代理是核心资产，而工厂则是你组织这些资产的方式。

### 新型工作模式

第 8 节曾提出一个观点：**一名工程师即可交付完整垂直功能模块**。请暂时离开键盘，从团队视角重新审视这一变化的意义，而不仅限于单个开发者。

软件开发始终依赖于“交接”：产品负责人撰写用户故事，技术负责人将其转化为规格说明，后端工程师实现 API，前端工程师构建 UI，支付专家负责集成。当功能最终上线时，往往已有四至五人参与其中，每人需等待前一人完成。每一次交接，都意味着工作停滞等待。

![Image 8: 2aa870cf-17f7-4fc1-8b7c-14095bb61980](https://cdn.hashnode.com/uploads/covers/69cae64c9fffa7474087a0d4/2aa870cf-17f7-4fc1-8b7c-14095bb61980.png)  
*图 7：旧有模式。每条箭头代表一次交接，每一次交接都是一次等待。*

而工厂模式则消解了大部分交接环节——因为专业能力不再局限于个体，而是以代理的形式被共享。

一位从未编写过 Stripe webhook 的前端工程师，依然可以交付需要该功能的模块，因为团队的支付专家已提前构建并优化了 `payments-integration` 代理；一位从未使用 Recharts 构建仪表盘的后端工程师，也能交付相关功能，因为前端负责人已构建了 `dashboard-component-builder` 代理；QA 工程师的 `regression-suite-writer` 代理、DevOps 工程师的 `ci-pipeline-updater` 代理、安全工程师的 `auth-checker` 代理，均对全团队开放，并可作为链式流程的一部分自动运行。

其结果是：**一名工程师即可独立完成完整垂直功能模块的开发与交付**。

![Image 9: 64d37829-30cc-46bc-9047-72f34081ab12](https://cdn.hashnode.com/uploads/covers/69cae64c9fffa7474087a0d4/64d37829-30cc-46bc-9047-72f34081ab12.png)  
*图 8：新模式。每位工程师均可调用同一份代理库。专家依然存在，但其专业能力已沉淀于他们维护的代理中，而非受限于其可投入交接的时间。*

观察变化所在：专家依然存在——前端负责人仍负责设计系统，支付专家仍负责 Stripe 集成，DevOps 工程师仍负责 CI 流水线。他们依然贡献着团队中无人可替代的品味与判断力。所不同的是，**他们的专业能力现在具备了可移植性**，可封装进代理中，供团队任意成员调用。

这一转变带来三重复利效应：

**迭代周期缩短**：过去需等待三位工程师依次参与的功能，如今一名工程师即可端到端完成；PR 可在同一天打开，而非跨周等待。

**专家专注高价值工作**：此前，资深支付工程师每周需花费大量时间协助他人解决 Stripe 集成问题；如今，他们可将时间投入优化 `payments-integration` 代理本身——杠杆效应显著提升：代理的每一次改进，都将惠及团队后续所有相关功能。

**团队扩展方式转变**：过去，新增第十名工程师意味着新增第十组交接环节；如今，新增第十名工程师意味着新增一名全栈贡献者，他可立即复用前九人构建的所有代理。入职效率提升，协调成本下降。

这正是本文所指向的更深层变革：**软件工厂不仅是提升单人效率的技巧，更是工程团队向“全栈贡献者社群”演进的路径——他们将专业能力编码共享，而非像接力赛般，每一次交接都耗费一天时间**。

率先实现这一转变的团队，未必是人员最多或 AI 预算最高的团队，而是那些**代理库充分反映团队集体品味、持续更新、精简高效、高度协同的团队**。代理是核心资产，工厂则是你组织这些资产的方式。

### 补充说明

随着工具持续演进，该工作流形态也将不断演进；每个团队都有其独特的工作方式。本文所呈现的是：**在真实生产环境中经受住交付压力考验的最小可行版本**。它并非最终答案，而是一个可依据你团队、技术栈与偏好进行适配的起点。

若你在团队中实践了类似方案，欢迎分享哪些做法奏效、哪些未达预期——**优化工作流最快的方式，就是学习他人的失败经验**。祝你构建自己的工厂顺利！

### 资源链接

**Claude Code**

*   Claude Code 概览：[code.claude.com/docs/en/overview](https://code.claude.com/docs/en/overview)  
*   子代理文档：[code.claude.com/docs/en/sub-agents](https://code.claude.com/docs/en/sub-agents)

*   技能文档：[docs.anthropic.com/en/docs/claude-code/slash-commands](https://docs.anthropic.com/en/docs/claude-code/slash-commands)

*   记忆功能与 `CLAUDE.md`：[docs.anthropic.com/en/docs/claude-code/memory](https://docs.anthropic.com/en/docs/claude-code/memory)

*   Hook 参考文档：[code.claude.com/docs/en/hooks](https://code.claude.com/docs/en/hooks)

*   Hook 使用指南：[code.claude.com/docs/en/hooks-guide](https://code.claude.com/docs/en/hooks-guide)

**其他 AI 集成开发环境（适用相同模式）**

*   Cursor：[cursor.com](https://cursor.com/)

*   Aider：[aider.chat](https://aider.chat/)

*   Cline：[cline.bot](https://cline.bot/)

**本文提及的工具**

*   MCP 文档：[modelcontextprotocol.io](https://modelcontextprotocol.io/)

*   Context7（当前文档插件）：[context7.com](https://context7.com/)

*   Nimbalyst（用于并行运行多个 Claude Code 会话的可视化工作区）：[nimbalyst.com](https://nimbalyst.com/)

*   Graphite（堆叠式 Pull Request 管理）：[graphite.dev](https://graphite.dev/)

*   Sapling（堆叠式 Pull Request 管理）：[sapling-scm.com](https://sapling-scm.com/)

* * *

* * *

免费学习编程。freeCodeCamp 的开源课程已帮助超过 40,000 人成功入职开发者岗位。[开始学习](https://www.freecodecamp.org/learn)