Claude Code PRP 工作流详解

ECC（Everything Claude Code）插件提供的「产品需求 → 实施 → 提交」全自动化流水线。

核心概念

PRD（Product Requirements Document）

产品需求文档，传统软件工程中的标准产物，回答 5 个核心问题：

维度	内容
Who	谁有这个问题（具体角色，不是「用户」）
What	他们面临什么可观察的痛点
Why	为什么现在解决不了 / 现有方案为什么失败
Why now	为什么这个时间点值得做
How	怎么衡量做成功了（成功指标）

给谁看：产品经理、工程师、设计师等人类协作者。

PRP（Product Requirement Prompt）

ECC 独创概念，灵感来自开源项目 PRPs-agentic-eng（作者 Wirasm）。

核心思想：

PRD 写给人看，PRP 写给 AI agent 看。
一份合格的 PRP 应包含足够上下文，让 AI 一次性把功能实现到位，无需中途反复查文档、问问题或猜测。

PRP 的本质：

PRP = PRD（要做什么）
    + 代码模式提取（怎么写才像现有代码）
    + 验证命令（怎么验证写对了）
    + GOTCHA 清单（已知坑点）
    + 任务级 ACTION / IMPLEMENT / MIRROR / VALIDATE 四元组

PRD vs PRP 对比

维度	PRD	PRP
目标读者	人类	AI Agent
写作风格	自然语言、可留白	结构化、自包含、零留白
是否含代码片段	通常不含	必须包含真实代码模式引用
是否含验证命令	不含	必须包含（lint/test/build）
实施时是否需查码	需要	不需要——所有上下文已嵌入
文档长度	短（几页）	长（几百行）

命令全景图

ECC 提供 5 个 PRP 系列命令，串成完整流水线：

┌──────────────┐   ┌──────────────┐   ┌─────────────────┐   ┌──────────────┐   ┌──────────┐
│  /prp-prd    │ → │  /prp-plan   │ → │  /prp-implement │ → │  /prp-commit │ → │  /prp-pr │
│  写 PRD      │   │  写实施计划  │   │  按计划实施     │   │  分组提交    │   │  开 PR   │
│  (问答式)    │   │  (扫码库)    │   │  (持续验证)     │   │              │   │          │
└──────────────┘   └──────────────┘   └─────────────────┘   └──────────────┘   └──────────┘
       ↓                  ↓                    ↓                    ↓                ↓
    prd.md             plan.md             实际代码改动           git commits      GitHub PR

关键特性：每个命令都可以单独使用或跳过任意环节：

已有 PRD → 直接 /prp-plan
已有 plan.md → 直接 /prp-implement
只想要轻量规划 → 用 /plan（不进入 PRP 流程）

五个核心命令详解

`/prp-prd` — 交互式 PRD 生成器

调用方式：

/prp-prd 我想做一个市场行情通知系统
/prp-prd                              # 留空会先问你想做什么

工作流程（问答式 6 阶段）：

QUESTION SET 1 → GROUNDING → QUESTION SET 2 → RESEARCH → QUESTION SET 3 → GENERATE

核心姿态（来自命令源码）：

You are a sharp product manager who:
Starts with PROBLEMS, not solutions
Demands evidence before building
Thinks in hypotheses, not specs
Asks clarifying questions before assuming

反模式警告：

Don't fill sections with fluff. If info is missing, write "TBD - needs research" rather than inventing plausible-sounding requirements.

产出：一份结构化的 PRD 文档，含问题陈述、用户故事、成功指标、Implementation Phases。

`/prp-plan` — 工程化实施计划生成器

调用方式：

/prp-plan <feature 描述>
/prp-plan path/to/prd.md            # 也可基于 PRD 文件生成

工作流程（7 阶段）：

阶段	任务
Phase 0 DETECT	检测输入类型（PRD / 自由文本）
Phase 1 PARSE	提取 What / Why / Who / Where + User Story + 复杂度评估
Phase 2 EXPLORE	代码库 8 大类深度搜索 + 5 类执行追踪
Phase 3 RESEARCH	必要时查外部库文档与已知坑
Phase 4 DESIGN	UX before / after 状态对比
Phase 5 ARCHITECT	策略设计 + Scope / NOT Building
Phase 6 GENERATE	用模板生成最终 plan.md

Phase 2 的 8 类代码搜索（核心价值）：

Similar Implementations（相似实现）
Naming Conventions（命名约定）
Error Handling（错误处理）
Logging Patterns（日志模式）
Type Definitions（类型定义）
Test Patterns（测试模式）
Configuration（配置）
Dependencies（依赖）

Phase 2 的 5 类执行追踪：

Entry Points（入口点）
Data Flow（数据流）
State Changes（状态变化）
Contracts（契约）
Patterns（架构模式）

产出位置：.claude/PRPs/plans/<feature>.plan.md

plan.md 关键章节：

Mandatory Reading：实施前必读的文件清单（含优先级 P0/P1/P2）
Patterns to Mirror：代码模式表（含真实代码片段）
Files to Change：CREATE / UPDATE 文件清单
NOT Building：明确写出「不做什么」，防止 scope creep
Step-by-Step Tasks：每个 task 含 6 元组：

- ACTION:    做什么
- IMPLEMENT: 具体写什么代码
- MIRROR:    镜像哪个现有 pattern
- IMPORTS:   需要哪些 import
- GOTCHA:    避免哪个坑
- VALIDATE:  如何验证此 task 完成

Confidence Score：plan 末尾会输出 1-10 分自评，评估「一次性实施成功」的可能性。

`/prp-implement` — 执行实施计划

调用方式：

/prp-implement .claude/PRPs/plans/<feature>.plan.md

核心铁律：

Golden Rule: 验证失败立即修，绝不累积坏状态。

工作流程（5 阶段）：

Phase 0 — DETECT（探测包管理器）

文件	包管理器	Runner
`bun.lockb`	bun	`bun run`
`pnpm-lock.yaml`	pnpm	`pnpm run`
`yarn.lock`	yarn	`yarn`
`package-lock.json`	npm	`npm run`
`pyproject.toml` / `requirements.txt`	uv / pip	`uv run`
`Cargo.toml`	cargo	`cargo`
`go.mod`	go	`go`

Phase 1 — LOAD

读取 plan.md，提取：Summary / Patterns to Mirror / Files to Change / Tasks / Validation Commands / Acceptance Criteria。

Phase 2 — PREPARE（git 状态准备）

当前状态	行为
在 feature 分支	直接用
在 main，工作区干净	自动建分支：`git checkout -b feat/{plan-name}`
在 main，工作区脏	STOP —— 让你先 stash 或 commit
在 worktree	用 worktree

Phase 3 — EXECUTE（逐 task 执行）

每个 task 的处理循环：

1. 读 MIRROR 引用的文件 → 理解模式
2. 写代码 → 严格遵循 GOTCHA 与 IMPORTS
3. 立即 type-check → 失败必须立即修
4. 标记 [done] Task N

Phase 4+ — VERIFY（全套验证）

跑 plan 里写明的所有 validation commands（lint / test / build），全绿才算完成。

`/prp-commit` — 智能提交

用途：把当前未提交的改动按文件语义分组，生成多个原子 commit。

调用方式：

/prp-commit                                    # 默认按文件语义自动分组
/prp-commit 把 service 层和 handler 层分开提交  # 自然语言指定分组

特点：会自动写 conventional commits 格式（feat / fix / refactor 等）。

`/prp-pr` — 创建 GitHub PR

用途：基于当前分支已推送的 commits 自动开 PR。

工作流：

发现项目 PR 模板（.github/PULL_REQUEST_TEMPLATE.md）
分析 base...HEAD 全部改动（不只是最新 commit）
自动 push 未推送的 commits
调用 gh pr create 创建 PR

与 `/plan` / `/multi-plan` 的对比

维度	`/plan`	`/multi-plan`	`/prp-plan`
本质	单模型对话式规划	双模型协同规划	PRD 驱动的工程化规划
执行者	Claude（planner agent）	Codex（后端）+ Gemini（前端）+ Claude	Claude 深度扫码
产物	仅消息中展示	`.claude/plan/<feature>.md`	`.claude/PRPs/plans/<feature>.plan.md`
代码库分析深度	浅	中	极深（8 类搜索 + 5 类追踪）
配套依赖	无	需 Codex / Gemini wrapper + ace-tool MCP	无
配套命令	`/tdd` / `/code-review`	`/ccg:execute`	`/prp-prd` → `/prp-plan` → `/prp-implement`
输出长度	短（消息级）	中（plan.md）	长（含 Mandatory Reading / Patterns to Mirror / 任务级 6 元组）
主要价值	快速澄清需求	多 LLM 交叉验证	自包含工程蓝图，可被 agent 全自动实施

一句话定位：

/plan：日常 80% 场景的轻量对话式规划。
/multi-plan：跨前后端、想要多 LLM 评审时使用。
/prp-plan：复杂特性 + 想交给 agent 自动实施时使用。

何时用 PRP 工作流

决策树

任务复杂度
 ├─ 小改动 / bug fix              → 不用 plan，直接干
 ├─ 单包功能（单文件 / 单 subtask）→ /plan
 ├─ 跨前后端 + 不确定方向          → /multi-plan
 └─ 大特性 + 想自动实施            → /prp-plan + /prp-implement
     └─ 全新模块且需求不清         → 完整 /prp-prd → /prp-plan → /prp-implement

适合 PRP 的典型场景

全新模块 / 大重构（比如新增 SPOv4、重写 task engine）
需要交付给其他 agent 自动实施
团队有新人入坑，需要「傻瓜式实施手册」
跨多个文件、需求边界容易飘的特性

不适合 PRP 的典型场景

一行代码改动 / typo 修复
探索式开发（边写边发现需求）
改动局部且模式已经清晰
时间紧、原型阶段

实战示例（Go 后端项目）

假设要在 aiseo-api 里新增一个 SiteOppV3 任务类型。

步骤 1：生成 plan

bash

/prp-plan 新增 SiteOppV3 任务类型，类似 SiteOppV2 但增加竞品对比维度

/prp-plan 会自动：

扫描 task/siteoppv2/ 目录，提取所有命名约定、subtask 结构
找到 state.go / pipeline.go / subtask_names.go 的模式
在 plan 里给出「必读文件清单」和「必须镜像的代码模式」

步骤 2：审阅 plan.md

打开 .claude/PRPs/plans/site-opp-v3.plan.md，重点检查：

NOT Building 章节是否覆盖了你不想做的部分
Patterns to Mirror 引用的代码片段是否真实
Confidence Score 是否 ≥ 7（低于 7 说明上下文不足，需要补充）

步骤 3：执行实施

bash

/prp-implement .claude/PRPs/plans/site-opp-v3.plan.md

会自动：

在干净的工作区下建 feat/site-opp-v3 分支
逐 task 执行，每改一个 .go 文件立刻跑 go vet ./...
失败立即修复，不累积错误
全部完成后跑 go test ./... 验证

步骤 4：提交 + 开 PR

bash

/prp-commit              # 自动按 task / handler / repository 分组提交
/prp-pr                  # 自动创建 PR，含完整改动总结

常见误区与注意事项

误区 1：把 PRP 当成「更详细的 PRD」

错。PRP 不是为了「更详细」，而是为了让 AI 不再需要翻代码就能实施。如果写的「PRP」里没有真实代码片段引用、没有 GOTCHA、没有验证命令，那只是一份「长一点的 PRD」。

误区 2：所有任务都走 PRP 流程

错。PRP 流程很重（plan.md 通常 300+ 行）。日常 80% 任务用 /plan 即可。只有当你**真的需要「自动化、可移交、零提问」**时才用 PRP。

误区 3：跳过 `/prp-plan` 直接 `/prp-implement`

错。/prp-implement 强依赖 plan.md 的结构（Tasks / Patterns to Mirror / Validation Commands）。手写一份非标准格式的「实施清单」扔进去，会导致 implement 阶段验证失败。

注意 1：plan.md 的 Confidence Score

/prp-plan 会给一个 1-10 的自评分。

≥ 8：可以放心 /prp-implement
5-7：建议人工补充缺失上下文后再实施
< 5：plan 里有太多假设，重新跑 /prp-plan

注意 2：`/prp-implement` 的工作区要求

如果当前在 main 且工作区脏（有未提交改动），/prp-implement 会停下来要求你先 stash 或 commit。这是设计上的安全保护，不要绕过。

注意 3：与 ECC 其他流程的协同

与什么搭配	怎么搭配
`/tdd`	在 plan 的 Validation Commands 里加测试命令
`/code-review`	implement 完成后跑一次
`/santa-method`	复杂任务可以接 santa-loop 做对抗式审核
`/eval-harness`	想做更严格的质量验证时启用

参考资料

PRPs-agentic-eng（PRP 概念发源地，作者 Wirasm）
ECC 插件源码路径：~/.claude/plugins/marketplaces/everything-claude-code/commands/prp-*.md
plan.md 输出位置：.claude/PRPs/plans/
PRD 输出位置：.claude/PRPs/

命令速查表

命令	输入	产出	何时用
`/prp-prd`	想法 / 留空	PRD 文档	需求未明、要先做产品定义
`/prp-plan`	描述 / PRD 文件	`.claude/PRPs/plans/<feature>.plan.md`	已知做什么，要生成实施蓝图
`/prp-implement`	plan 文件路径	实际代码改动 + 持续验证	已有 plan，要让 agent 自动实施
`/prp-commit`	自然语言 / 留空	多个原子 commit	改动完成，要分组提交
`/prp-pr`	留空	GitHub PR	commits 已推，要开 PR

文档基于 ECC v1.10.0 源码整理

Claude Code PRP 工作流详解 ​

核心概念 ​

PRD（Product Requirements Document） ​

PRP（Product Requirement Prompt） ​

PRD vs PRP 对比 ​

命令全景图 ​

五个核心命令详解 ​

/prp-prd — 交互式 PRD 生成器 ​

/prp-plan — 工程化实施计划生成器 ​

/prp-implement — 执行实施计划 ​

Phase 0 — DETECT（探测包管理器） ​

Phase 1 — LOAD ​

Phase 2 — PREPARE（git 状态准备） ​

Phase 3 — EXECUTE（逐 task 执行） ​

Phase 4+ — VERIFY（全套验证） ​

/prp-commit — 智能提交 ​

/prp-pr — 创建 GitHub PR ​

与 /plan / /multi-plan 的对比 ​

何时用 PRP 工作流 ​

决策树 ​

适合 PRP 的典型场景 ​

不适合 PRP 的典型场景 ​

实战示例（Go 后端项目） ​

步骤 1：生成 plan ​

步骤 2：审阅 plan.md ​

步骤 3：执行实施 ​

步骤 4：提交 + 开 PR ​

常见误区与注意事项 ​

误区 1：把 PRP 当成「更详细的 PRD」 ​

误区 2：所有任务都走 PRP 流程 ​

误区 3：跳过 /prp-plan 直接 /prp-implement ​

注意 1：plan.md 的 Confidence Score ​

注意 2：/prp-implement 的工作区要求 ​

注意 3：与 ECC 其他流程的协同 ​

参考资料 ​

命令速查表 ​

Claude Code PRP 工作流详解

核心概念

PRD（Product Requirements Document）

PRP（Product Requirement Prompt）

PRD vs PRP 对比

命令全景图

五个核心命令详解

`/prp-prd` — 交互式 PRD 生成器

`/prp-plan` — 工程化实施计划生成器

`/prp-implement` — 执行实施计划

Phase 0 — DETECT（探测包管理器）

Phase 1 — LOAD

Phase 2 — PREPARE（git 状态准备）

Phase 3 — EXECUTE（逐 task 执行）

Phase 4+ — VERIFY（全套验证）

`/prp-commit` — 智能提交

`/prp-pr` — 创建 GitHub PR

与 `/plan` / `/multi-plan` 的对比

何时用 PRP 工作流

决策树

适合 PRP 的典型场景

不适合 PRP 的典型场景

实战示例（Go 后端项目）

步骤 1：生成 plan

步骤 2：审阅 plan.md

步骤 3：执行实施

步骤 4：提交 + 开 PR

常见误区与注意事项

误区 1：把 PRP 当成「更详细的 PRD」

误区 2：所有任务都走 PRP 流程

误区 3：跳过 `/prp-plan` 直接 `/prp-implement`

注意 1：plan.md 的 Confidence Score

注意 2：`/prp-implement` 的工作区要求

注意 3：与 ECC 其他流程的协同

参考资料

命令速查表