企业官网建设流程全解析

• 文档
• 教程
• AI 技能

在 RPI（Research → Plan → Implement）工作流中，/rpi:plan是承上启下的关键一步：它把 Research 阶段产出的可行性结论，转化为一份包含产品需求、UX 设计、技术规格与分阶段实施路线图的完整规划文档集。本文以本仓库中的 plan.md 命令定义为核心，完整拆解该命令的 8 个执行阶段、子 Agent 委派机制、产出物结构与错误处理策略，并结合仓库中 RPI 工作流总览与其余命令源码，说明如何把"从 vibe coding 到 agentic engineering"的实践落地为可验证、可追溯的工程流程。读完本文，你将掌握如何为任意功能在rpi/{feature-slug}/plan/目录下产出pm.md、ux.md、eng.md、PLAN.md四份规划文档，并为后续/rpi:implement提供可直接执行的蓝图。

RPI 工作流中的定位：Step 3 of 4

RPI 是仓库中 rpi-workflow.md 定义的四步流水线：

Describe → Research → Plan → Implement

• Step 1 Describe：用户提出功能诉求，生成rpi/{feature-slug}/REQUEST.md；
• Step 2 Research：运行/rpi:research，产出research/RESEARCH.md并给出 GO / NO-GO / CONDITIONAL GO / DEFER 结论（见 research.md）；
• Step 3 Plan：即本文主题，运行/rpi:plan {feature-slug}，产出plan/下四份文档；
• Step 4 Implement：运行/rpi:implement，按PLAN.md分阶段执行并逐关校验（见 implement.md）。

每一步都设有校验闸门（validation gate），其核心目的正如工作流总览所述：避免在不具备可行性的功能上浪费精力，并确保文档完备。而/rpi:plan正是从"研究结论"过渡到"实施蓝图"的唯一通道，规划质量直接决定 Implement 阶段的执行顺畅度。

前置条件与输出位置

命令定义在 plan.md 中，其前置条件有两条硬性要求：

• 功能目录已存在：rpi/{feature-slug}/
• 研究已完成且给出 GO 建议：rpi/{feature-slug}/research/RESEARCH.md存在

输出位置：所有规划文档统一写入rpi/{feature-slug}/plan/。

从命令 Frontmatter 可以看出它的调用形态：

description: Create comprehensive planning documentation for a feature argument-hint: "<feature-slug>"

即运行Claude Code中/rpi:plan oauth2-authentication这样的命令时，$ARGUMENTS中传入功能 slug，命令必须解析出该 slug（即rpi/下的目录名）。完整目录结构参见 rpi-workflow.md：

rpi/{feature-slug}/ ├── REQUEST.md # Step 1: Initial feature description ├── research/ │ └── RESEARCH.md # Step 2: GO/NO-GO analysis ├── plan/ │ ├── PLAN.md # Step 3: Implementation roadmap │ ├── pm.md # Product requirements │ ├── ux.md # UX design │ └── eng.md # Technical specification └── implement/ └── IMPLEMENT.md # Step 4: Implementation record

八个阶段：从加载上下文到完成汇报

命令的 Outline 定义了 8 个阶段，本文逐一展开其过程、输出与校验标准。

Phase 0：加载上下文（Load Context）

前置条件：已提供功能 slug。本阶段完成三件事：

1. 校验研究是否完成：检查rpi/{feature-slug}/research/RESEARCH.md是否存在；若研究结论为 NO-GO 或 CONDITIONAL，则给出警告；
2. 读取研究发现：提取产品分析、技术发现、技术可行性评估，并记录风险与约束；
3. 加载项目章程（若存在）：在仓库中查找 constitution 或原则文档，提取相关约束与偏好。

产出：研究摘要、章程上下文（如有）、规划约束。

校验清单：

• Research report exists
• GO recommendation confirmed
• Constitution loaded (if exists)

这一阶段与 research.md 的 Phase 0 遥相呼应：研究命令同样会读取 REQUEST.md 并查找constitution.md、PRINCIPLES.md、.project/constitution.md等常见位置的章程文档，Plan 阶段则把这一上下文继续向前传递，保证规划与项目原则对齐。

Phase 1：理解功能需求（Understand Feature Requirements）

前置条件：Phase 0 完成。本阶段解析需求并界定影响范围：

1. 解析功能描述：从研究报告中提取功能名称、首要目标、目标组件、判断是面向用户还是纯技术型功能、评估复杂度等级；
2. 识别受影响组件：主组件（功能所在）、次组件（集成点）、所需共享工具、外部依赖；
3. 研究现有模式：在代码库中搜索相似功能，审查组件架构与模式，识别可复用代码。

产出：功能范围文档（内部）、受影响组件清单、现有模式目录。

校验清单：功能名称与目标明确、目标组件已识别、复杂度已评估。

Phase 2：分析技术需求（Analyze Technical Requirements）

前置条件：Phase 1 完成。本阶段是技术侧的"排雷"：

1. 审查组件架构：阅读组件 README 与文档、审视现有代码结构、识别架构模式；
2. 识别技术依赖：内部依赖（其他组件、共享工具）、外部依赖（API、服务、库）、数据库/存储需求、认证/授权需求；
3. 评估集成点：需新建或修改的 API、数据库 Schema 变更、事件/消息流、前后端集成；
4. 评估技术风险：对现有功能的破坏性变更、性能影响、安全隐患、数据迁移需求。

产出：技术需求文档（内部）、依赖图、集成点图、风险评估。

校验清单：组件架构已理解、所有依赖已识别、集成点已映射、技术风险已评估。

Phase 3：设计功能架构（Design Feature Architecture）

指定 Agent：senior-software-engineer（自定义 Agent，从.claude/agents/自动识别）。

本阶段完成架构级设计：

1. 设计高层架构：组件/模块结构、数据流图、API 接口、数据库 Schema 变更；
2. 定义实现方案：文件结构与组织、代码组织模式、测试策略、错误处理方案；
3. 规划数据库/存储变更（如适用）：新集合/表、Schema 修改、迁移策略、数据校验规则；
4. 设计 API 契约（如适用）：请求/响应格式、认证要求、错误响应；
5. 规划测试策略：单元测试要求、集成测试场景、端到端测试用例。

产出：架构设计文档（内部）、API 规格、数据库 Schema 设计、测试策略。

校验清单：高层架构已设计、实现方案已定义、数据库变更已规划（如需）、API 契约已明确（如需）、测试策略完整。

Phase 4：拆解实施任务（Break Down Implementation Tasks）

前置条件：Phase 1-3 完成。本阶段把架构蓝图转译为可执行的任务清单：

1. 识别实施阶段：将功能拆分为3-5 个逻辑阶段，每个阶段交付可工作、可测试的功能，且阶段之间渐进式递进；
2. 为每个阶段创建任务拆解：列出具体实施任务、评估复杂度（低/中/高）、标记任务依赖、分配到相应代码区域；
3. 定义成功标准：每个阶段的验收标准、测试要求、文档要求；
4. 识别并行化机会：可并发执行的任务、前后端并行工作、独立模块开发。

产出：分阶段实施计划、带估算的任务拆解、每阶段成功标准、依赖图。

校验清单：功能已拆为 3-5 个逻辑阶段、每阶段有具体任务、所有任务有复杂度估算、依赖已清晰标记、成功标准已定义。

"3-5 个逻辑阶段 + 每阶段可测试"这一约束与 Implement 命令的分阶段执行循环（Code Discovery → Implementation → Self-Validation → Code Review → User Validation Gate → Documentation Update）形成闭环，是保证大型功能可控交付的核心机制。

Phase 5：生成文档（Generate Documentation）

指定 Agent：documentation-analyst-writer（内置 Agent，通过 Task 工具调用，subagent_type="documentation-analyst-writer"）。

本阶段产出四份规划文档，全部保存至rpi/{feature-slug}/plan/：

校验清单：

• All 4 files present (pm, ux, eng, PLAN)
• pm.md covers business requirements
• ux.md addresses user experience
• eng.md provides technical specification
• PLAN.md has phased implementation
• No placeholder text remains
• Markdown formatting is clean

对照仓库中三个自定义 Agent 的交付物定义，可以更精确地理解这四份文档的产出标准：

• product-manager.md 定义pm.md必须包含：Context、users、goals；编号化的功能需求并各自附带验收标准；以及性能、规模、SLO/SLA、隐私、安全、可观测性等 NFR；同时给出 Scope in/out、rollout 计划、风险与开放问题；
• ux-designer.md 定义ux.md必须包含：用户故事与验收标准、流程描述/线框备注及全状态（loading/empty/error/success）、可访问性备注（键盘、标签、对比度）；
• senior-software-engineer.md 则提供架构设计的工程底色："Adopt > adapt > invent；保持变更可逆、可观测；里程碑而非时间线；TDD-first、小提交、边界清晰"。

子 Agent 委派：一个命令如何编排一支虚拟团队

/rpi:plan的一个突出设计是其 Agent 编排表：

调用规则有明确的区分：

• 自定义 Agent（product-manager、senior-software-engineer、ux-designer）：Claude Code 自动从.claude/agents/目录识别，无需 Task 工具调用，直接以自然语言引用，例如 "Acting as the senior-software-engineer agent..."；
• 内置 Agent（documentation-analyst-writer）：必须通过 Task 工具以subagent_type="documentation-analyst-writer"方式调用。

这一编排与 rpi-workflow.md 中命令与 Agent 的对照表一致（/rpi:plan使用 senior-software-engineer、product-manager、ux-designer、documentation-analyst-writer 四类 Agent），也与 Research / Implement 命令的多 Agent 编排风格保持统一。从源码结构看，这套命令体系的本质是：用一份 Markdown 命令定义把产品、UX、工程三类专业 Agent 串成流水线，每个 Agent 负责自己擅长的产出物。

完成报告：让规划结果可审计、可交接

规划完成后，命令要求输出结构化的完成报告，包括：

产出物清单：

• pm.md：产品需求与用户故事（{Y} stories）
• ux.md：用户体验设计（{Z} flows）
• eng.md：技术规格（{A} APIs, {B} schema changes）
• PLAN.md：详细路线图（{C} phases, {D} tasks）

功能摘要：功能名称、目标组件、复杂度（Simple/Medium/Complex）、实施阶段数、总任务数、内部/外部依赖数。

技术概览：架构模式、新增/修改 API 数、数据库变更数、测试套件数、风险等级（Low/Medium/High）。

实施阶段：逐一列出各阶段名称与任务数。

这种带占位符的模板化报告（如{feature-name}、{N} phases）保证了无论功能大小，产出物都有统一的验收口径，便于 Stakeholder 快速审查。

错误处理：规划失败时的降级策略

命令定义了四类典型异常的处置方式：

前两条体现了 RPI 的闸门哲学：Plan 阶段不强制阻断，但对已判 NO-GO 的功能明确提示风险，把决策权交还用户；后两条则体现了鲁棒性优先——即使某个 Agent 失败，工作流也能降级完成，只是明确标注质量妥协。

后续步骤与上下文管理

规划之后的 Next Steps

1. 审阅文档：阅读rpi/{feature-slug}/plan/下的规划文档，重点审阅eng.md技术规格与PLAN.md实施阶段；
2. 与利益相关方确认：产品侧审阅 pm.md、UX 侧审阅 ux.md、技术侧审阅 eng.md；
3. 开始实施：运行/rpi:implement "{feature-slug}"，按 PLAN.md 的阶段推进，在每个阶段完成校验闸门。

关键一步：对话压缩（/compact）

这是命令定义中特别强调的Post-Completion Action：规划工作流消耗了大量上下文，为给实施阶段释放空间，命令要求完成后主动提示用户运行：

/compact

其作用是对对话进行摘要，保留规划决策的同时降低 token 占用。这与 Research、Implement 两个命令的收尾设计完全一致——从 research.md 到 implement.md，每个 RPI 步骤都以 /compact 提示收尾，可见上下文管理被当作工作流的一等公民来对待，这也是长周期 Agentic 工程得以持续运行的关键细节。

最佳实践小结

命令定义在 Notes 中给出了四条规划阶段的实践准则，与本仓库"from vibe coding to agentic engineering"的定位高度契合：

1. 先审研究：确保你理解 Research 阶段的可行性评估；
2. 善用发现：充分利用研究阶段的技术发现（technical discovery）；
3. 务求具体：详尽的计划会让实施更顺畅；
4. 尽早校验：实施前先审阅文档。

从整体看，/rpi:plan是一个"小而完整"的工程化模板：它以固定的目录契约（rpi/{feature-slug}/plan/）承载四份职责分明的文档，以多 Agent 编排替代单人臆断，以校验清单兜底质量，以 /compact 收尾管理上下文。若你的项目需要把"功能想法"稳定地推进到"可执行的实施蓝图"，这套命令定义可以直接复制到仓库.claude/commands/rpi/下使用（安装方式详见 rpi-workflow.md 的 Installation 一节：复制.claude文件夹到仓库根目录并创建rpi/plans目录）。

• 文档
• 教程
• AI 技能