文档教程AI 技能【免费下载链接】claude-code-best-practicefrom vibe coding to agentic engineering - practice makes claude perfect项目地址https://gitcode.com/GitHub_Trending/cl/claude-code-best-practice点击查看免费下载在 RPIResearch → 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 4RPI 是仓库中 rpi-workflow.md 定义的四步流水线Describe → Research → Plan → ImplementStep 1 Describe用户提出功能诉求生成rpi/{feature-slug}/REQUEST.mdStep 2 Research运行/rpi:research产出research/RESEARCH.md并给出 GO / NO-GO / CONDITIONAL GO / DEFER 结论见 research.mdStep 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.mdrpi/{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。本阶段完成三件事校验研究是否完成检查rpi/{feature-slug}/research/RESEARCH.md是否存在若研究结论为 NO-GO 或 CONDITIONAL则给出警告读取研究发现提取产品分析、技术发现、技术可行性评估并记录风险与约束加载项目章程若存在在仓库中查找 constitution 或原则文档提取相关约束与偏好。产出研究摘要、章程上下文如有、规划约束。校验清单Research report existsGO recommendation confirmedConstitution loaded (if exists)这一阶段与 research.md 的 Phase 0 遥相呼应研究命令同样会读取 REQUEST.md 并查找constitution.md、PRINCIPLES.md、.project/constitution.md等常见位置的章程文档Plan 阶段则把这一上下文继续向前传递保证规划与项目原则对齐。Phase 1理解功能需求Understand Feature Requirements前置条件Phase 0 完成。本阶段解析需求并界定影响范围解析功能描述从研究报告中提取功能名称、首要目标、目标组件、判断是面向用户还是纯技术型功能、评估复杂度等级识别受影响组件主组件功能所在、次组件集成点、所需共享工具、外部依赖研究现有模式在代码库中搜索相似功能审查组件架构与模式识别可复用代码。产出功能范围文档内部、受影响组件清单、现有模式目录。校验清单功能名称与目标明确、目标组件已识别、复杂度已评估。Phase 2分析技术需求Analyze Technical Requirements前置条件Phase 1 完成。本阶段是技术侧的排雷审查组件架构阅读组件 README 与文档、审视现有代码结构、识别架构模式识别技术依赖内部依赖其他组件、共享工具、外部依赖API、服务、库、数据库/存储需求、认证/授权需求评估集成点需新建或修改的 API、数据库 Schema 变更、事件/消息流、前后端集成评估技术风险对现有功能的破坏性变更、性能影响、安全隐患、数据迁移需求。产出技术需求文档内部、依赖图、集成点图、风险评估。校验清单组件架构已理解、所有依赖已识别、集成点已映射、技术风险已评估。Phase 3设计功能架构Design Feature Architecture指定 Agentsenior-software-engineer自定义 Agent从.claude/agents/自动识别。本阶段完成架构级设计设计高层架构组件/模块结构、数据流图、API 接口、数据库 Schema 变更定义实现方案文件结构与组织、代码组织模式、测试策略、错误处理方案规划数据库/存储变更如适用新集合/表、Schema 修改、迁移策略、数据校验规则设计 API 契约如适用请求/响应格式、认证要求、错误响应规划测试策略单元测试要求、集成测试场景、端到端测试用例。产出架构设计文档内部、API 规格、数据库 Schema 设计、测试策略。校验清单高层架构已设计、实现方案已定义、数据库变更已规划如需、API 契约已明确如需、测试策略完整。Phase 4拆解实施任务Break Down Implementation Tasks前置条件Phase 1-3 完成。本阶段把架构蓝图转译为可执行的任务清单识别实施阶段将功能拆分为3-5 个逻辑阶段每个阶段交付可工作、可测试的功能且阶段之间渐进式递进为每个阶段创建任务拆解列出具体实施任务、评估复杂度低/中/高、标记任务依赖、分配到相应代码区域定义成功标准每个阶段的验收标准、测试要求、文档要求识别并行化机会可并发执行的任务、前后端并行工作、独立模块开发。产出分阶段实施计划、带估算的任务拆解、每阶段成功标准、依赖图。校验清单功能已拆为 3-5 个逻辑阶段、每阶段有具体任务、所有任务有复杂度估算、依赖已清晰标记、成功标准已定义。3-5 个逻辑阶段 每阶段可测试这一约束与 Implement 命令的分阶段执行循环Code Discovery → Implementation → Self-Validation → Code Review → User Validation Gate → Documentation Update形成闭环是保证大型功能可控交付的核心机制。Phase 5生成文档Generate Documentation指定 Agentdocumentation-analyst-writer内置 Agent通过 Task 工具调用subagent_typedocumentation-analyst-writer。本阶段产出四份规划文档全部保存至rpi/{feature-slug}/plan/文件内容要点pm.md产品需求功能描述与用户故事、章程对齐如适用、商业价值与成功指标、用户画像与用例、验收标准、超出范围项ux.mdUX 设计界面原型文字描述、用户流程与交互、可访问性考虑、错误状态与边界情况eng.md技术规格架构设计、API 规格、数据库 Schema 变更、技术栈、技术风险与缓解PLAN.md实施路线图分阶段拆解、每阶段任务清单与估算、依赖与顺序、每阶段成功标准、测试要求、校验检查点校验清单All 4 files present (pm, ux, eng, PLAN)pm.md covers business requirementsux.md addresses user experienceeng.md provides technical specificationPLAN.md has phased implementationNo placeholder text remainsMarkdown 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 编排表PhaseAgentTypePurposePhase 3senior-software-engineerCustomArchitecture designPhase 5product-managerCustomProduct requirements (pm.md)Phase 5ux-designerCustomUser experience (ux.md)Phase 5senior-software-engineerCustomTechnical spec (eng.md)Phase 5documentation-analyst-writerBuilt-inDocumentation synthesis调用规则有明确的区分自定义 Agentproduct-manager、senior-software-engineer、ux-designerClaude Code 自动从.claude/agents/目录识别无需 Task 工具调用直接以自然语言引用例如 Acting as the senior-software-engineer agent...内置 Agentdocumentation-analyst-writer必须通过 Task 工具以subagent_typedocumentation-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} storiesux.md用户体验设计{Z} flowseng.md技术规格{A} APIs, {B} schema changesPLAN.md详细路线图{C} phases, {D} tasks功能摘要功能名称、目标组件、复杂度Simple/Medium/Complex、实施阶段数、总任务数、内部/外部依赖数。技术概览架构模式、新增/修改 API 数、数据库变更数、测试套件数、风险等级Low/Medium/High。实施阶段逐一列出各阶段名称与任务数。这种带占位符的模板化报告如{feature-name}、{N} phases保证了无论功能大小产出物都有统一的验收口径便于 Stakeholder 快速审查。错误处理规划失败时的降级策略命令定义了四类典型异常的处置方式场景动作提示信息研究报告不存在停止并告知用户Research report not found. Run/rpi:researchfirst.研究结论为 NO-GO警告但允许继续Research recommended NO-GO. Proceed anyway? (y/n)目标组件不存在与用户确认是否为新组件Component not found. Is this a new component?文档 Agent 失败直接生成文档Documentation may not fully adhere to standards前两条体现了 RPI 的闸门哲学Plan 阶段不强制阻断但对已判 NO-GO 的功能明确提示风险把决策权交还用户后两条则体现了鲁棒性优先——即使某个 Agent 失败工作流也能降级完成只是明确标注质量妥协。后续步骤与上下文管理规划之后的 Next Steps审阅文档阅读rpi/{feature-slug}/plan/下的规划文档重点审阅eng.md技术规格与PLAN.md实施阶段与利益相关方确认产品侧审阅 pm.md、UX 侧审阅 ux.md、技术侧审阅 eng.md开始实施运行/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的定位高度契合先审研究确保你理解 Research 阶段的可行性评估善用发现充分利用研究阶段的技术发现technical discovery务求具体详尽的计划会让实施更顺畅尽早校验实施前先审阅文档。从整体看/rpi:plan是一个小而完整的工程化模板它以固定的目录契约rpi/{feature-slug}/plan/承载四份职责分明的文档以多 Agent 编排替代单人臆断以校验清单兜底质量以 /compact 收尾管理上下文。若你的项目需要把功能想法稳定地推进到可执行的实施蓝图这套命令定义可以直接复制到仓库.claude/commands/rpi/下使用安装方式详见 rpi-workflow.md 的 Installation 一节复制.claude文件夹到仓库根目录并创建rpi/plans目录。赞分享文档教程AI 技能【免费下载链接】claude-code-best-practicefrom vibe coding to agentic engineering - practice makes claude perfect项目地址https://gitcode.com/GitHub_Trending/cl/claude-code-best-practice点击查看免费下载相关推荐agentic-awesome-skills 中的 REST API 设计最佳实践从 URL 规范到生产级 FastAPI 落地agentic awesome skills 中的 REST API 设计最佳实践从 URL 规范到生产级 FastAPI 落地 本指南以 agentic aAI 技能AI 插件用 Claude Code 的 create-plan 命令为 liam 项目生成 PLANS.md 执行计划文档用 Claude Code 的 create plan 命令为 liam 项目生成 PLANS.md 执行计划文档 本指南讲解如何解读与使用 liam 仓库中的数据可视化数据库前端CLIdotnet/runtime 源码生成器工程指南仓库规范、最佳实践与实战落地dotnet/runtime 源码生成器工程指南仓库规范、最佳实践与实战落地 导读 本文以 docs/coding guidelines/source gen语言运行时标准库JIT编译编译器上一篇探索c4项目用四个函数实现的极简C编译器下一篇PTT BBS 项目常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考