Chapter 15: 生产级工作流设计

这是教程的收官章节。第 1 到 14 章的所有内容在这里汇聚为大规模部署 Claude Code 的生产级模式。

你将学到

Claude Code 生态系统中顶尖团队使用的 R-P-E-R-S 工作流
GSD 的 Wave 执行模式（并行任务处理）
HumanLayer 的 RPI 模式（处理 300k+ LOC 大型代码库）
gstack 的效率表：各任务类型的真实生产力倍增
何时使用各框架：ECC、gstack、GSD、BMAD、HumanLayer
完整演练：使用生产工作流为 Express 应用添加 OAuth
成本对比：单会话 vs Subagent vs Teams vs Waves

研究参考：本章记录的 R-P-E-R-S 工作流来源于多个出处：Anthropic 的"Building effective agents"博文（倡导结构化的 Agent 工作流而非临时提示）、ECC 项目在数十个 Agent 上的经验评估数据，以及 gstack 和 GSD 等社区框架——它们独立地收敛到了类似的阶段结构。这个工作流并非由任何单一权威规定——而是从业者观察到大规模应用中什么有效而自然涌现的。

生产工作流

每个主要的 Claude Code 框架都收敛到了同一个基本模式，尽管叫法不同：

Research   ->   Plan   ->   Execute   ->   Review   ->   Ship
   |              |            |              |            |
   |              |            |              |            |
 探索           创建         按计划          验证         提交
 空间           地图         编码           质量         和部署

这不是建议。跳过阶段的团队——特别是 Research 和 Review——产出的质量明显更差。ECC 项目跨多个 Agent 追踪发现，遵循 R-P-E-R-S 的 Agent 比直接跳到实现的 Agent pass@1 得分显著更高（改善在各任务类型上一致可见，但具体幅度因任务复杂度而异）。

阶段分解

阶段	工具	发生什么	上下文影响
Research	Explore subagent	读取文件、理解架构、映射依赖	Subagent 隔离上下文——主 Agent 保持干净
Plan	Plan subagent 或 `/plan`	生成可审查的规格：要修改的文件、方法、风险	人类在执行开始前审查计划
Execute	主 Agent + Skills + Hooks	实现计划，每步运行测试	Skills 自动化重复操作
Review	Code reviewer subagent	独立审查：安全、正确性、性能	独立上下文防止实现阶段的偏见
Ship	`/commit` + CI/CD	结构化消息提交、创建 PR、运行流水线	自动化质量门禁

框架模式

gstack 的"Boil the Lake"原则

gstack 框架（68k 星）基于完整性原则运作：彻底完成工作，对付出的努力完全透明。它的关键贡献是效率表——来自实际在生产环境中使用 gstack 的团队的经验数据，展示 Claude Code 如何加速不同任务类型：

效率压缩比——实际效果因人而异

以下压缩比由特定团队在生产环境中使用 gstack 时报告。你的实际结果取决于代码库复杂度、编程语言、测试覆盖率以及 CLAUDE.md 对项目描述的完善程度。请将这些数据视为方向性指标，而非保证。

任务类型	人工耗时	使用 Claude Code	压缩比
样板代码（CRUD、表单、配置）	4 小时	2-3 分钟	~100x
测试（单元、集成、e2e）	3 小时	3-4 分钟	~50x
功能（新功能开发）	8 小时	15-20 分钟	~30x
Bug 修复（诊断 + 修复）	2 小时	5-10 分钟	~20x
架构（设计 + 重构）	2 天	2-3 小时	~8x

随着任务需要更多判断而非打字，压缩比会下降。

gstack 还引入了自动决策逻辑——六个原则决定 Claude 何时应该自主决策 vs 询问人类：

可逆决策：自动决定（容易撤销）
既定模式：自动决定（匹配现有代码库惯例）
性能权衡：询问（人类需要权衡约束）
架构变更：询问（影响范围大）
外部 API 契约：询问（影响其他团队）
安全边界：询问（凭据暴露风险）

GSD 的 Wave 执行

GSD 框架（50k 星，被 Amazon、Google、Shopify 采用）解决一个具体问题：如何执行一个有很多独立子任务的大型任务，而不让上下文窗口（Context Window）爆炸？

Wave 执行将任务分组为并行工作的波次。每个波次在全新的上下文中运行：

Wave 1（并行，全新上下文）：
  ├── Agent A: 创建用户模型 + 迁移
  ├── Agent B: 创建订单模型 + 迁移
  └── Agent C: 创建产品模型 + 迁移

  等待全部完成。用测试验证。

Wave 2（并行，全新上下文）：
  ├── Agent A: 用户 API 端点 + 测试
  ├── Agent B: 订单 API 端点 + 测试
  └── Agent C: 产品 API 端点 + 测试

  等待全部完成。集成测试。

Wave 3（顺序，基于 Wave 2）：
  └── Agent A: 连接跨模型关系，
               添加认证中间件，运行完整测试套件

上下文利用率"黄金区间"——社区经验报告

40-60% 的上下文利用率范围在 Claude Code 社区框架（GSD、HumanLayer 等）中被广泛引用为有效的操作区间。低于 40%，Claude 可能缺少足够的上下文做出好的决策。高于 60%，质量随着上下文窗口被噪声填满而趋于下降。这基于许多项目的社区经验报告，而非正式基准测试。你的最佳区间可能因任务类型和上下文组成而异。

HumanLayer 的 RPI 模式

HumanLayer 用 Research-Plan-Implement 模式配合频繁的有意压缩（Intentional Compaction），让 Claude 在约一小时内处理了一个 300k LOC 的 Rust 代码库：

Research（在 subagent 中）：
  读取代码库结构
  识别所有与变更相关的文件
  映射依赖图
  输出：结构化摘要（不是原始文件）
  
  --> Subagent 退出，其上下文被释放

Plan（主 agent，带研究摘要）：
  基于摘要设计方案
  列出要修改的具体文件和方式
  识别风险和边界情况
  输出：逐步计划
  
  --> 压缩上下文（移除研究细节，保留计划）

Implement（主 agent，上下文中有计划）：
  逐步执行计划
  每步后运行测试
  如果上下文超过 40%，再次压缩
  
  --> 重复：每个主要步骤后压缩

关键技术是有意压缩——不要等到 83.5% 的自动压缩阈值。在 40-50% 时主动压缩，保持 Claude 的工作记忆干净和专注。实践中意味着：

bash

# 在 Claude Code 会话中主动压缩：
/compact 只保留：(1) 当前计划，(2) 已修改的文件，
         (3) 测试结果。丢弃所有探索上下文。

BMAD-METHOD 的 Agent 角色

BMAD（44k 星）采取不同的方法：它不定义阶段，而是定义 12 个 Agent 角色来处理软件交付的不同方面：

角色	职能	Claude Code 等价物
Analyst	需求收集	带领域提示词的 Explore subagent
PM	功能优先级排序	带业务上下文的 Plan subagent
Architect	系统设计	关注架构的 Plan subagent
Developer	实现	带 Skills 的主 Agent
QA	测试	Code reviewer subagent
Scrum Master	进度追踪	Desktop App 定时任务

BMAD 的贡献是规模-领域自适应（Scale-Domain-Adaptive）复杂度：同一框架根据项目规模调整开销。周末项目用 3 个角色。企业迁移用全部 12 个。

Demo 40: 完整 R-P-E-R-S 工作流——为 Express 应用添加 OAuth

Production Workflow: OAuth Feature End-to-End

Advanced~45 min

场景

你有一个使用 JWT 认证的 Express.js API。你需要添加 OAuth2 支持（Google 和 GitHub 提供商），不能破坏现有认证。这是一个真实的功能，涉及中间件、路由、数据库 Schema 和前端回调。

阶段 1：Research

bash

claude

> 使用 subagent 研究当前的认证实现。我需要知道：
>
> 1. JWT 认证目前如何实现？（中间件、token 生成、验证）
> 2. 用户模型 schema 是什么？（数据库、ORM、字段）
> 3. 路由如何保护？（中间件链、角色检查）
> 4. 有什么 session/cookie 处理？
> 5. 有没有现有的 OAuth 相关文件或依赖？
> 6. 认证相关的测试覆盖如何？
>
> 仅研究。不要修改任何内容。

Claude 启动一个 Explore subagent 读取约 15 个文件并返回结构化摘要：

terminal

认证架构摘要：
- JWT 中间件在 src/middleware/auth.ts 中使用 jsonwebtoken
- 用户模型在 src/models/user.ts（Prisma ORM，PostgreSQL）
  字段：id, email, passwordHash, name, role, createdAt
- 路由保护通过 requireAuth() 中间件
- 无 session/cookie 处理——纯无状态 JWT
- 无现有 OAuth 代码或依赖
- 23 个认证相关测试在 tests/auth/
- Token 刷新由客户端处理

刚才发生了什么？（Research 阶段）

Explore Subagent

Codebase auth files

↓

Glob

src/middleware/*.ts, src/routes/*.ts

↓

Read

src/models/user.ts

↓

Grep

oauth OR passport in all files

阶段 2：Plan

> 基于研究结果，创建添加 Google 和 GitHub OAuth 的计划。
>
> 计划必须涵盖：
> - 数据库 schema 变更（新字段或新表）
> - 新依赖
> - 新路由和中间件
> - OAuth 用户如何与密码用户共存
> - 如何处理账户关联（相同邮箱，不同认证方式）
> - 测试计划
> - 回滚策略
>
> 将计划写入 OAUTH_PLAN.md，让我在你实现之前审查。

Claude 生成详细计划。你审查它：

terminal

## OAuth 实现计划

### 数据库变更
- 为 User 模型添加：googleId, githubId, authProvider (enum: local|google|github)
- 新增 OAuthToken 模型：userId, provider, accessToken, refreshToken, expiresAt
- 迁移：ALTER TABLE users ADD COLUMN auth_provider DEFAULT 'local'

### 新依赖
- passport, passport-google-oauth20, passport-github2

### 新路由
- GET /auth/google（重定向到 Google 授权页面）
- GET /auth/google/callback（处理 Google 回调）
- GET /auth/github（重定向到 GitHub 授权页面）
- GET /auth/github/callback（处理 GitHub 回调）

### 账户关联
- 如果 OAuth 邮箱匹配已有用户：关联账户（添加 googleId/githubId）
- 如果无匹配：创建新用户，设置 authProvider
- 用户可以同时拥有密码 + OAuth（关联账户）

### 要修改的文件
1. prisma/schema.prisma（User 模型 + OAuthToken 模型）
2. src/middleware/passport.ts（新建 - passport 策略）
3. src/routes/auth.ts（添加 OAuth 路由）
4. src/services/auth.service.ts（添加 OAuth 用户创建/关联）
5. src/config/oauth.ts（新建 - 提供商配置）

### 要创建测试的文件
1. tests/auth/oauth-google.test.ts
2. tests/auth/oauth-github.test.ts
3. tests/auth/account-linking.test.ts

### 回滚策略
- 迁移只做增量操作（新列、新表）
- 回滚 = 移除新路由，删除新列
- 现有 JWT 认证不受影响

你批准计划："看起来不错。实现它。"

刚才发生了什么？（Plan 阶段）

Plan Subagent

Research summary from Phase 1

↓

Write

OAUTH_PLAN.md

阶段 3：Execute

> 按照 OAUTH_PLAN.md 的计划实现 OAuth。规则：
>
> 1. 一次一个文件，按依赖顺序
> 2. 每次文件修改后运行 `npm test`
> 3. 如果测试失败，先修复再继续
> 4. 每个成功步骤后提交
> 5. 不要修改现有认证逻辑——在旁边添加

Claude 按计划工作：

terminal

步骤 1：数据库迁移
  - 更新 prisma/schema.prisma
  - 运行 npx prisma migrate dev --name add-oauth
  - npm test: 23/23 通过（无回归）
  - 提交："Add OAuth fields to User model and OAuthToken table"

步骤 2：OAuth 配置
  - 创建 src/config/oauth.ts
  - npm test: 23/23 通过
  - 提交："Add OAuth provider configuration"

步骤 3：Passport 策略
  - 创建 src/middleware/passport.ts
  - npm test: 23/23 通过
  - 提交："Add Google and GitHub passport strategies"

步骤 4：认证服务更新
  - 更新 src/services/auth.service.ts（添加 findOrCreateOAuthUser, linkAccount）
  - npm test: 23/23 通过
  - 提交："Add OAuth user creation and account linking service"

步骤 5：OAuth 路由
  - 更新 src/routes/auth.ts
  - npm test: 23/23 通过
  - 提交："Add OAuth routes for Google and GitHub"

步骤 6：测试
  - 创建 tests/auth/oauth-google.test.ts（8 个测试）
  - 创建 tests/auth/oauth-github.test.ts（8 个测试）
  - 创建 tests/auth/account-linking.test.ts（6 个测试）
  - npm test: 45/45 通过（22 个新 + 23 个现有）
  - 提交："Add OAuth and account linking tests"

刚才发生了什么？（Execute 阶段）

Read

OAUTH_PLAN.md

↓

Edit

prisma/schema.prisma

↓

Bash

npx prisma migrate dev, npm test

↓

Write + Edit

4 new/modified files (steps 2-5)

↓

Write

3 test files (step 6)

阶段 4：Review

> 使用 code reviewer subagent 审查本次会话中的所有变更。
> 关注：
> 1. 安全：OAuth token 是否安全存储？是否有 CSRF 防护？
> 2. 边界情况：Google 不返回邮箱怎么办？重复账户？
> 3. 测试覆盖：错误路径是否被测试？

审查员 Subagent 分析 diff 并报告：

terminal

审查发现：

安全：
- 问题：OAuth 回调路由缺少 CSRF state 参数验证
  修复：添加 state 参数生成和验证
- 正常：OAuth token 存储在独立表中，有适当加密
- 正常：回调 URL 经白名单验证

边界情况：
- 问题：未处理 Google 账户没有邮箱的情况（罕见但可能）
  修复：当 OAuth 配置中没有邮箱时返回 400 并提供清晰消息
- 正常：重复邮箱检测和账户关联正常工作

测试覆盖：
- 问题：缺少 OAuth token 过期刷新的测试
  修复：添加 token 过期处理的测试用例
- 正常：所有成功和错误路径已测试

刚才发生了什么？（Review 阶段）

Code Reviewer Subagent

Git diff of all session changes

↓

Grep

state parameter in callback routes

↓

Read

tests/auth/ directory

阶段 5：Ship

> 修复审查中的三个问题，然后创建 PR。

Claude 修复问题，最后一次运行测试（48/48 通过），创建 PR：

terminal

$ git add -A
$ git commit -m "Fix OAuth CSRF, missing email handling, and token refresh test"
$ gh pr create --title "Add Google and GitHub OAuth support" \
  --body "## Summary
- Adds OAuth2 login via Google and GitHub
- Account linking for users with matching email
- 25 new tests, all passing
- No changes to existing JWT auth flow

## Security
- CSRF state parameter on all OAuth flows
- OAuth tokens stored in separate encrypted table
- Callback URL whitelist validation

## Test Plan
- [x] Google login flow (8 tests)
- [x] GitHub login flow (8 tests)
- [x] Account linking (6 tests)
- [x] Edge cases: no email, expired tokens, CSRF (3 tests)"

Creating pull request for feature/oauth into main...
https://github.com/myorg/myapp/pull/43

刚才发生了什么？（Ship 阶段）

Edit

3 files with review fixes

↓

Bash

npm test

↓

Bash

git commit and gh pr create

Demo 41: 成本对比

Cost and Quality Comparison Across Approaches

Advanced~10 min

同一任务——"为 Express 应用添加 OAuth"——用四种不同方式执行：

单会话（基线）

terminal

方案：     一个长会话，所有操作串行
Token：   约 180,000 输入 + 约 45,000 输出
成本：     约 $2.70
耗时：     约 25 分钟
通过率：   约 75%（没有审查阶段时有时会遗漏边界情况）

Subagent 隔离

terminal

方案：     研究用 Explore subagent，其余在主 agent 中
Token：   约 120,000 输入 + 约 40,000 输出
成本：     约 $1.90（节省 30%）
耗时：     约 28 分钟（subagent 开销导致略慢）
通过率：   约 85%（研究阶段提前发现更多问题）

Agent Teams（并行）

terminal

方案：     3 个 agent：后端、测试、审查（尽可能并行）
Token：   约 150,000 输入 + 约 50,000 输出（总量更多，但并行）
成本：     约 $2.40
耗时：     约 15 分钟（并行执行）
通过率：   约 90%（独立审查 agent 捕获问题）

GSD Waves

terminal

方案：     Wave 1: schema + 配置，Wave 2: 路由 + 服务，Wave 3: 测试 + 审查
Token：   约 100,000 输入 + 约 35,000 输出
成本：     约 $1.60（最低）
耗时：     约 20 分钟
通过率：   约 92%（每个 wave 全新上下文，上下文卫生最佳）

要点总结

方案	成本	耗时	质量
单会话	$2.70	25 分钟	75% 通过
Subagent 隔离	$1.90	28 分钟	85% 通过
Agent Teams	$2.40	15 分钟	90% 通过
GSD Waves	$1.60	20 分钟	92% 通过

没有普遍"最好"的方案。正确的选择取决于你在优化什么：

最小化成本：GSD Waves（全新上下文 = 更少冗余 token）
最小化时间：Agent Teams（并行执行）
最大化质量：GSD Waves 或 Agent Teams（都包含独立审查）
最小化复杂度：单会话（最简单的配置）

刚才发生了什么？

Single Session

One long conversation

↓

Subagent Isolation

Research in subagent, rest in main

↓

Agent Teams

3 parallel agents

↓

GSD Waves

3 sequential waves with fresh contexts

出错时怎么办

工作流阶段失败

症状：Execute 阶段在中途失败——步骤 3（共 6 步）后测试挂了，Claude 陷入修复死循环。

terminal

步骤 3：Passport 策略
  - 创建 src/middleware/passport.ts
  - npm test: 18/23 通过 -- 5 个失败
  - 尝试修复...
  - npm test: 16/23 通过 -- 7 个失败（更糟了！）
  - 尝试修复...
  - npm test: 12/23 通过 -- 回归

原因：计划存在依赖错误（例如 passport 策略导入了一个尚不存在的文件），或者计划假设了一个库版本并不支持的 API。

修复方法：

立即停止当前阶段。不要让 Claude 继续尝试修复级联失败：

> 停止。不要再做任何修改。
> 运行 git diff 给我看自上次通过的提交以来有什么变化。
> 然后运行 git stash 保存变更，回到上一个好的状态。

返回 Plan 阶段。用你从失败中学到的更新计划：

> 计划在步骤 3 失败了。问题是 passport-google-oauth20 v3
> 改变了回调签名。更新计划以适应 v3 API，
> 如果需要的话重新排序步骤。

从上一个好的检查点恢复 Execute。这就是为什么每步后提交很重要——你总能回滚到已知好的状态。

成本超支

症状：一个你预期花费 $2-3 的任务正在燃烧 $10+ 的 token，看不到尽头。

terminal

# 在 Claude Code 会话中检查 token 使用量
> /cost

Session tokens: 485,000 input / 120,000 output
Estimated cost: $8.40 and counting

原因：Claude 因为上下文被压缩而反复重新读取大文件，失去了对已读内容的追踪。或者任务范围超出了计划。

修复方法：

立即压缩，并明确指定保留什么：

> /compact 只保留：当前计划、已完成的部分（步骤 1-3），
> 以及步骤 4 的具体错误。丢弃所有文件内容——我只会重新读取
> 步骤 4 需要的内容。

检查是否存在重复读取循环：如果 Claude 持续读取相同的文件，说明压缩丢弃了它需要的信息。将关键信息写入文件：

> 写一个 STATUS.md 文件，包含：(1) 已完成什么，(2) 还剩什么，
> (3) 当前错误。然后压缩。压缩后读取 STATUS.md 来恢复。

对机械性步骤切换到 Sonnet：如果剩余工作比较直接（添加类型标注、按模板写测试），换到更便宜的模型：

bash

claude --model claude-sonnet-4-6
> 读取 STATUS.md，从中断处继续迁移。

生产环境中的上下文溢出

症状：在使用 Agent SDK 的 CI/CD 流水线中，Agent 在长时间运行的任务后期开始产出质量较低的输出，或犯正常情况下不会犯的错误。

terminal

# 在你的 CI 日志中：
[Agent] Converting file 38/50...
[Agent] ERROR: Created duplicate function name in user_service.ts
[Agent] ERROR: Import path references old file structure
[Agent] WARNING: Agent attempted to read a file it already read 3 turns ago

原因：上下文窗口已满。自动压缩已启动，正在丢弃 Agent 需要的信息。这在涉及大量文件的迁移任务中特别常见。

SDK 用户的修复方法：将任务拆分为能舒适放入上下文的块：

python

# 不要用一次 query() 调用处理 50 个文件：
files_to_migrate = get_file_list()
chunk_size = 10

for i in range(0, len(files_to_migrate), chunk_size):
    chunk = files_to_migrate[i:i + chunk_size]
    
    # 每个块获得全新的上下文
    async for msg in query(
        prompt=f"""Migrate these files to TypeScript: {chunk}
        
Read MIGRATION_STATUS.md for context on what has been done.
After completing this batch, update MIGRATION_STATUS.md.""",
        options=ClaudeCodeOptions(
            allowed_tools=["Read", "Write", "Edit", "Bash", "Glob", "Grep"],
        ),
    ):
        if msg.type == "text":
            print(msg.text, end="")

Managed Agents 的修复方法：使用第 14 章描述的进度文件模式，将大型任务拆分为多个会话，通过磁盘上的文件显式交接。

框架选择指南

Claude Code 生态系统中有八个主要框架。何时使用哪个：

框架	Stars	适合	核心理念
Everything Claude Code (ECC)	148k	完整参考、安全、评估	47 agents、181 skills、企业治理
gstack	68k	彻底性、努力透明度	"Boil the Lake" + 自动决策逻辑
GSD	50k	并行执行、上下文卫生	Wave 执行、40-60% 黄金区间
BMAD-METHOD	44k	结构化团队工作流	12 个 Agent 角色、规模自适应
HumanLayer	-	大型代码库（100k+ LOC）	RPI 模式、40% 时有意压缩
Codex (OpenAI)	-	架构上的第二意见	gstack 用它做多 AI 决策
Cursor	-	IDE 原生 AI 编码	更紧密的 IDE 集成，不同工具
Claude Code（原生）	-	入门、简单项目	无框架开销

决策树

你的项目低于 10k LOC？
  是 -> 原生 Claude Code 或 gstack（简单模式）
  否 -> 继续

需要跨多文件并行执行？
  是 -> GSD Waves
  否 -> 继续

需要企业治理（审计、合规、角色）？
  是 -> ECC 框架
  否 -> 继续

需要有定义角色的结构化团队工作流？
  是 -> BMAD-METHOD
  否 -> 继续

代码库超过 100k LOC？
  是 -> HumanLayer RPI 模式
  否 -> gstack（涵盖大多数情况）

成本优化策略

策略	Token 节省	如何做
Subagent 上下文隔离	~40%	大文件在 subagent 中读取；只有摘要到达主 Agent
精确的 CLAUDE.md	~15%	更少不相关指令 = 每轮更少 token
Sonnet 做常规任务	~60% 成本	用 `--model claude-sonnet-4-6` 做测试、样板、简单编辑
管道模式（Pipe Mode）	~30%	`git diff \| claude -p "review"` 避免加载整个项目
主动压缩	~20%	50% 时 `/compact` 比 83.5% 自动压缩效果好
GSD Wave 执行	~35%	每个 Wave 全新上下文消除累积噪声
Batches API (SDK)	50% 成本	批量处理按半价 token 计费

每月成本估算（每个开发者）

使用级别	任务/天	预估月成本
轻度（简单编辑、审查）	5-10	$50-100
中度（功能、Bug 修复）	10-20	$150-300
重度（架构、迁移）	20+	$400-800
企业（含 Managed Agents）	视情况	$500-2,000

团队配置模板

一个生产团队的完整 .claude/ 目录配置：

.claude/
├── settings.json          # 权限、hooks、MCP 服务器
├── CLAUDE.md              # 项目规范（提交到 git）
├── agents/
│   ├── explore.md         # 研究 Agent 提示词
│   ├── reviewer.md        # 代码审查 Agent 提示词
│   └── test-writer.md     # 测试生成 Agent 提示词
├── skills/
│   ├── commit.md          # 按规范格式提交
│   ├── pr-review.md       # PR 审查清单
│   └── migrate.md         # 数据库迁移助手
└── hooks/
    ├── agent-shield.py    # 安全运行时过滤
    └── audit-logger.sh    # 追加写入审计追踪

练习

为你的团队设计完整的 Claude Code 部署方案：

编写 .claude/settings.json，包含基于角色的权限（初级/高级/负责人）
编写 CLAUDE.md，包含你项目的编码规范
在 .claude/agents/ 中创建三个 Agent 定义
在 .claude/skills/ 中创建三个 Skill 定义
配置 GitHub Actions 工作流用于自动 PR Review
在一个真实功能上运行完整的 R-P-E-R-S 工作流
追踪 Token 使用量并计算成本

知识检查

为什么 R-P-E-R-S 工作流在 Review 阶段使用独立的 Subagent，而不是让实现代码的 Agent 审查自己的代码？

实现 Agent 已经用了太多 token，无法做更多工作

独立上下文防止实现偏见——审查员以全新视角看代码，不受实现决策的锚定效应影响

Review 阶段需要一个更擅长找 Bug 的不同模型

这只是框架惯例，对输出质量没有实际差异

一个团队报告使用 Claude Code 处理 CRUD 样板任务时达到了 100 倍压缩比。你的团队应该期望什么？

相同的 100 倍比率，因为 CRUD 任务是通用的

大致相似的结果，但具体比率取决于你的代码库复杂度、现有模式以及 CLAUDE.md 对规范的描述完善程度

低得多，因为随着模型变化压缩比会随时间下降

更高，因为更新的模型总是更高效

你的 Agent 在迁移任务中处理到第 38 个文件（共 50 个）时开始犯错（重复命名、错误导入）。最可能的原因和最佳修复方法是什么？

模型不够强大，无法胜任该任务——换一个更大的模型

上下文窗口已满，自动压缩正在丢弃需要的信息。将剩余工作拆分到新会话中，使用全新上下文，通过状态文件交接。

迁移计划从一开始就是错的——回到阶段 2

这是正常的方差——重试相同的命令就会成功

本章小结

R-P-E-R-S（Research、Plan、Execute、Review、Ship）是所有主要框架的通用工作流——跳过阶段的团队产出更差
gstack 的效率表显示压缩比从样板代码的约 100 倍到架构工作的约 8 倍不等（由特定团队报告，你的结果会有所不同）
GSD Wave 执行通过全新上下文中的并行工作最大化质量并最小化成本
HumanLayer 的 RPI 模式通过在 40% 而非等待自动压缩来处理 300k+ LOC 代码库
框架选择取决于项目规模、团队结构和优化优先级
成本优化的核心是上下文卫生：在 Subagent 中隔离读取、主动压缩、为正确的任务使用正确的模型

附录链接：A01 提示词工程涵盖如何在工具调用上下文中编写有效提示词——R-P-E-R-S 每个阶段的基础。A02 上下文工程解释 2025-2026 年从提示词工程到上下文工程的范式转变。A07 Token 经济学提供 Demo 41 中成本对比背后的成本模型和预算优化策略。

研究参考：独立框架（ECC、gstack、GSD、HumanLayer、BMAD）收敛到相同的 Research-Plan-Execute-Review-Ship 模式这一现象值得关注。虽然每个框架的术语和侧重点不同，但底层工作流出奇地一致。Anthropic 的"Building effective agents"博文（2024）提供了理论基础：Agent 在行动前探索、实现前计划、发布前验证时效果最好。R-P-E-R-S 模式就是这一原则在软件工程中的具体操作化。

你已完成全部 15 章。 前往高级大项目构建一个生产级 AI 代码审查流水线，将所有内容串联起来。

Chapter 15: 生产级工作流设计 ​

你将学到 ​

生产工作流 ​

阶段分解 ​

框架模式 ​

gstack 的"Boil the Lake"原则 ​

GSD 的 Wave 执行 ​

HumanLayer 的 RPI 模式 ​

BMAD-METHOD 的 Agent 角色 ​

Demo 40: 完整 R-P-E-R-S 工作流——为 Express 应用添加 OAuth ​

场景 ​

阶段 1：Research ​

刚才发生了什么？（Research 阶段） ​

阶段 2：Plan ​

刚才发生了什么？（Plan 阶段） ​

阶段 3：Execute ​

刚才发生了什么？（Execute 阶段） ​

阶段 4：Review ​

刚才发生了什么？（Review 阶段） ​

阶段 5：Ship ​

刚才发生了什么？（Ship 阶段） ​

Demo 41: 成本对比 ​

单会话（基线） ​

Subagent 隔离 ​

Agent Teams（并行） ​

GSD Waves ​

要点总结 ​

刚才发生了什么？ ​

出错时怎么办 ​

工作流阶段失败 ​

成本超支 ​

生产环境中的上下文溢出 ​

框架选择指南 ​

决策树 ​

成本优化策略 ​

每月成本估算（每个开发者） ​

团队配置模板 ​

练习 ​

知识检查 ​

本章小结 ​

Chapter 15: 生产级工作流设计

你将学到

生产工作流

阶段分解

框架模式

gstack 的"Boil the Lake"原则

GSD 的 Wave 执行

HumanLayer 的 RPI 模式

BMAD-METHOD 的 Agent 角色

Demo 40: 完整 R-P-E-R-S 工作流——为 Express 应用添加 OAuth

场景

阶段 1：Research

刚才发生了什么？（Research 阶段）

阶段 2：Plan

刚才发生了什么？（Plan 阶段）

阶段 3：Execute

刚才发生了什么？（Execute 阶段）

阶段 4：Review

刚才发生了什么？（Review 阶段）

阶段 5：Ship

刚才发生了什么？（Ship 阶段）

Demo 41: 成本对比

单会话（基线）

Subagent 隔离

Agent Teams（并行）

GSD Waves

要点总结

刚才发生了什么？

出错时怎么办

工作流阶段失败

成本超支

生产环境中的上下文溢出

框架选择指南

决策树

成本优化策略

每月成本估算（每个开发者）

团队配置模板

练习

知识检查

本章小结