CMS后端前端【免费下载链接】webiny-jsOpen-source, self-hosted CMS platform on AWS serverless (Lambda, DynamoDB, S3). TypeScript framework with multi-tenancy, lifecycle hooks, GraphQL API, and AI-assisted development via MCP server. Built for developers at large organizations.项目地址https://gitcode.com/gh_mirrors/we/webiny-js点击查看免费下载本文介绍 Webiny 仓库内置的prd-to-planClaude Skill.claude/skills/prd-to-plan/SKILL.md它定义了一套PRD → 多阶段实施计划的标准工作流核心思想是用tracer-bullet曳光弹垂直切片把产品需求逐层打穿 schema、API、UI 与测试最终产出可独立演示、可逐阶段验收的本地 Markdown 计划文件。读完本文你将掌握这套技能的六步操作流程、垂直切片的分割原则、与用户的评审方法、计划文件的模板结构并能结合仓库中真实的 PRD 与计划实例如 ai-context/plans/admin-list-module.md直接上手使用。一、技能定位它解决什么问题在 Webiny 这类大型 TypeScript 单体仓库中一次功能开发往往横跨 GraphQL API、数据访问、React 前端与测试等多层代码。如果没有统一方法PRD 很容易被直接翻译成一长串水平切片式任务清单如先做数据库表、再做 API、最后做 UI导致每一层完成时都无法独立验证问题被推迟到集成阶段才暴露阶段性交付物不可演示用户与开发者对进度认知脱节计划中过早写死文件名、函数名等易变细节后续阶段一改就大面积失效。prd-to-plan技能的触发条件写在它的 frontmatter 中当用户想要把 PRD 拆解成实施计划implementation plan、按阶段规划plan phases from a PRD或提到tracer bullets时应调用本技能。它的产出是一份保存在./ai-context/plans/SKILL 正文第 8 行声明下的本地 Markdown 文件。二、六步工作流总览SKILL.md 的 Process 一节给出了完整流程共六个步骤步骤动作产出1确认 PRD 已在对话上下文中PRD 全文可用2探索代码库理解现状架构、既有模式与集成层3识别 durable architectural decisions持久架构决策计划头部的全局决策清单4起草 vertical slices垂直切片待评审的 tracer-bullet 阶段拆分5与用户评审quiz the user用户批准的分阶段方案6写出计划文件./plans/或./ai-context/plans/下的 Markdown 计划下面逐步骤展开。1. 确认 PRD 在上下文中技能明确要求The PRD should already be in the conversation. If it isnt, ask the user to paste it or point you to the file.即不允许在 PRD 缺席的情况下直接开拆。如果 PRD 不在当前对话中应请用户粘贴文本或指明文件路径。这一步保证了后续所有切片都有明确的需求来源避免凭空发挥。2. 探索代码库如果尚未探索过代码库请先探索以理解当前架构、既有模式和集成层。Webiny 仓库本身就为此提供了结构化资料例如 ai-context/prds/admin-list-module/list-module-prd.md 这类 PRD 文档以及 ai-context/code-style 下的编码规范如 one-class-per-file、no-stateless-private-methods 等。探索的目标不是通读全部代码而是回答三个问题新增功能要穿过哪些集成层GraphQL schema、repository/数据层、React 视图、测试仓库中有哪些既有模式可复用如 Webiny 的 presenter/repository 分层、react-properties 配置模式哪些边界接口第三方服务、权限系统会约束实现这直接服务于下一步的持久决策识别。3. 识别 durable architectural decisions持久架构决策在动手切片之前先识别贯穿整个实现过程、不太可能改变的高层决策。SKILL.md 给出的清单是Route structures / URL patterns路由结构 / URL 模式Database schema shape数据库 schema 形态Key data models关键数据模型Authentication / authorization approach认证 / 授权方案Third-party service boundaries第三方服务边界这些决策之所以重要是因为它们go in the plan header so every phase can reference them——会被写入计划头部供每个阶段引用。如果切片阶段发现某条决策被反复推翻说明该决策本身还不够 durable值得在进入实现前先定死。仓库实例可以佐证这一点ai-context/plans/admin-list-module.md 的Architectural decisions一节就列出了包归属packages/app-admin、状态管理MobXmakeAutoObservable、DI 方案React Context createListModule()工厂、UI 声明方式JSX react-properties、关键模型名ListGatewayTDto, TParams、ListMapperTDto, TEntity、ListViewModelTEntity、ListActionsTParams以及分页方案cursor-based。这些都是后续 7 个阶段共同依赖的地基。4. 起草垂直切片tracer bullet 阶段这是整个技能的灵魂。SKILL.md 用一段可复用的规则块vertical-slice-rules约束切片质量每个切片是一条狭窄但完整的端到端路径穿过所有集成层schema、API、UI、tests——是垂直切片不是某一层的水平切片完成的切片可以独立演示或验证demoable or verifiable on its own宁多切薄片不切厚片Prefer many thin slices over few thick ones不要包含具体文件名、函数名或实现细节——这些很可能在后续阶段构建时变化一定要包含持久决策路由路径、schema 形态、数据模型名称。换句话说tracer bullet 的精神是第一个阶段就用最窄的路径把数据从 GraphQL 一路流到 React 组件这件事跑通并点亮之后再逐步叠加搜索、排序、筛选、分页等功能。每个阶段完成时用户都能看到或验证一个真实可用的东西而不是一堆半成品中间件。5. 与用户评审Quiz the user起草完成后必须把拆分方案呈现给用户评审不能直接写文件。呈现方式是编号列表每个阶段展示两项Title简短描述性名称User stories covered该阶段覆盖 PRD 中的哪些用户故事随后向用户提出评审问题粒度是否合适太粗 / 太细某些阶段应该合并或进一步拆分吗迭代直到用户批准拆分方案Iterate until the user approves the breakdown。这一步把计划从单向产出变成双向共识过程也是技能名中 quiz盘问/评审一词的由来。6. 写出计划文件评审通过后落地成文如./plans/不存在则创建计划文件命名为功能名例如./plans/user-onboarding.md使用下方模板。需要指出的是SKILL.md 内部存在两处目录表述正文开头的Output is a Markdown file in./ai-context/plans/与步骤 6 的Create./plans/。在仓库中两个目录都实际存在且都在存放计划类文档根级 plans 目录下有 plans/breadcrumbs.md、plans/command-palette.md 等而 ai-context/plans 目录下则有 20 余份与ai-context/prds对应的计划文件。使用时以团队约定的目录为准保持 PRDai-context/prds/与计划ai-context/plans/或plans/配套存放即可。三、计划模板逐字段拆解SKILL.md 内嵌了plan-template模板结构如下# Plan: Feature Name Source PRD: brief identifier or link ## Architectural decisions 跨所有阶段生效的持久决策Routes / Schema / Key models ... --- ## [ ] Phase 1: Title **User stories**: list from PRD ### What to build 描述这条垂直切片的端到端行为而非逐层实现细节 ### Acceptance criteria - [ ] Criterion 1 - [ ] ... --- ## [ ] Phase 2: Title ...各要素的含义# Plan: Feature Name计划标题直接以功能命名 Source PRD以引用形式标注来源 PRD标识符或链接保证需求可回溯## Architectural decisions计划头部固化步骤 3 识别的持久决策供所有阶段引用## [ ] Phase N: Title每个阶段是一个待办复选框标题为简短描述名**User stories**列出该阶段覆盖的 PRD 用户故事### What to build描述这条垂直切片的端到端行为Describe the end-to-end behavior, not layer-by-layer implementation——刻意避免逐层展开### Acceptance criteria可勾选的验收标准清单是阶段完成的客观判据末尾以注释!-- Repeat for each phase --提示为每个阶段重复该结构。四、仓库实例模板的真实落地ai-context/plans/admin-list-module.md 是该模板在仓库中的真实实例共 200 行7 个阶段其头部完整复刻了模板Source PRD:ai-context/plans/list-module/list-module-plan.md对应 PRD 文档可参见 ai-context/prds/admin-list-module/list-module-prd.md。随后是 Architectural decisions包归属、MobX、DI、UI shape、关键模型、cursor 分页、BaseListParams基础类型然后按模板展开 7 个 tracer-bullet 阶段阶段标题核心内容Phase 1MVP — Full-Stack Data Load从 GraphQL 响应到 React 组件的最薄端到端数据链路定义BaseListParams、ListResponseTDto、ListGateway、ListMapper、ListViewModel实现ListQueryParamsRepository、ListDataRepository、LoadingRepository与GenericListPresenter、createListModule()工厂、useListModulehook并用PagesGatewayPageMapper示例模块验证Phase 2Search在 Phase 1 地基上叠加SearchFeature可配置防抖默认 300ms搜索变更重置 cursorPhase 3SortSortFeature的 none → asc → desc → none 循环切换Phase 4Filters类型安全的FilterFeatureset/clear/clearAll/replace以及hasActiveFilters、isEmptyWithFilters状态Phase 5Pagination (Load More)基于 cursor 的LoadMoreFeature追加而非替换 items重复调用防重入Phase 6Selection Bulk ActionsSelectionRepository/SelectionFeature/BulkActionsFeature选择跨页持久通过config.selection.enabled可关闭Phase 7Error HandlingListError { code, message, retryable }结构化错误、重试逻辑、空态区分isEmptyvsisEmptyWithFilters注意每个阶段的 What to build 都采用端到端行为描述而不写死具体文件路径Acceptance criteria 全部是可勾选、可验证的行为断言如 Phase 1 的createListModule({ name, gateway, mapper, config })无需其他配置即返回可用 hook、卸载组件即 dispose presenter无内存泄漏。这正是 SKILL.md 中不要包含易变文件名/函数名、要包含持久决策两条规则的直接体现。五、tracer-bullet 原则的仓库佐证Webiny 仓库中能观察到这一方法论在真实功能上的痕迹plans/breadcrumbs.md记录了面包屑功能从DIBreadcrumb抽象回退到 React Config API 的决策过程——它明确写到 DI 方案being root-resolved synchronous, couldnt produce dynamic labels ... which was the whole wall最终确认 Config API 才是正确方案。这正说明 durable 决策这里指面包屑是纯展示、走 Config API 而非 DI在实现前就应被识别并固化避免后期推倒重来。ai-context/plans/admin-list-module.md的 Phase 1 先打通 GraphQL response → React component 全链路gateway → mapper → repositories → presenter → hook → 组件正是 tracer bullet 的教科书式切片第一步就以最窄路径打穿所有集成层。配套技能.claude/skills/write-a-prd/SKILL.md在 PRD 阶段就刻意不包含具体文件路径或代码片段They may end up being outdated very quickly与 prd-to-plan 的切片不含易变实现细节一脉相承两条规则共同保证文档的时效性。从源码结构看这种小而完整、可独立验证的切片原则也与 Webiny 各包分层GraphQL API 包、数据访问包、前端 app 包、配套测试天然匹配每个切片都落在同一水平上对应包之间因而任何阶段都可独立演示。六、技能协作闭环write-a-prd → prd-to-plan → grill-meprd-to-plan并不是孤立的它处于 Webiny 的 AI 开发技能流水线中段write-a-prd通过用户访谈 代码库探索 模块设计产出 PRD落盘到./ai-context/prds/其中明确要求只写用户故事、实现决策、测试决策与 Out of Scope不写具体文件路径prd-to-plan本文主题消费上一步的 PRD产出多阶段实施计划grill-me对已有计划/设计进行拷问式评审——一次只问一个问题沿决策树的每个分支逐条解决依赖并为每个问题给出推荐答案如果一个问题能通过探索代码库回答就先去探索。这三个技能恰好构成写需求 → 拆计划 → 评审打磨的闭环也是 SKILL.md 步骤 5quiz the user与 grill-me 一脉相承的以对话收敛设计的方法论底色。仓库中还有 preflight、tester 等技能可在计划执行的不同环节继续接力。七、使用要点与最佳实践综合 SKILL.md 与仓库实例落地使用时有几点值得注意PRD 先于计划没有 PRD 就不要开拆第一步就是确认需求在上下文中PRD 存放于ai-context/prds/计划存放于ai-context/plans/或plans/两者通过计划头部的 Source PRD建立回溯关系。持久决策先行路由、schema、数据模型、认证授权、第三方服务边界这五类决策在切片前定死写入计划头部阶段内部只讨论行为不写将过时的实现细节。薄切片优于厚切片宁可多切几个一个功能点 全链路打通的薄片也不要一个跨多层的大阶段每个切片结束时都应有可演示或可验证的产出。评审是流程的一部分把拆分方案以Title User stories covered的编号列表呈现明确询问粒度是否合适、是否需要合并/拆分迭代到用户批准为止——不要跳过评审直接写文件。验收标准可勾选每个阶段的 Acceptance criteria 必须是客观、可验证的行为断言如某状态为true/false、某调用产生可观察结果并配合仓库既有的测试策略落地如__tests__目录下的单元/集成测试。遵循这套流程一个 PRD 会被拆成一组彼此独立、端到端可验证、且每个阶段都有明确用户故事和验收标准的实施计划——这正是 Webiny 大规模多包仓库中保持功能迭代节奏与质量可控的关键工作方法。赞分享CMS后端前端【免费下载链接】webiny-jsOpen-source, self-hosted CMS platform on AWS serverless (Lambda, DynamoDB, S3). TypeScript framework with multi-tenancy, lifecycle hooks, GraphQL API, and AI-assisted development via MCP server. Built for developers at large organizations.项目地址https://gitcode.com/gh_mirrors/we/webiny-js点击查看免费下载相关推荐ECC product-capability 技能实战把 PRD 变成可实现的能力契约PRD-to-SRS 通道ECC product capability 技能实战把 PRD 变成可实现的能力契约PRD to SRS 通道 本文基于 ECCThe agent h人工智能AI 技能AI 插件AI 评测Agent 评测MCP Clients开发工具CCPM Plan 阶段实战从头脑风暴到 PRD再到可分解的技术 EpicCCPM Plan 阶段实战从头脑风暴到 PRD再到可分解的技术 Epic Plan规划是 CCPMClaude Code Project ManagAI AgentAgent 工作流开发工具用 ECC 产品能力模板把 PRD 意图固化为可实施的能力契约用 ECC 产品能力模板把 PRD 意图固化为可实施的能力契约 产品需求PRD、Roadmap 或产品讨论往往只回答了要做什么却把实现前必须成立的大量人工智能AI 技能AI 插件AI 评测Agent 评测MCP Clients开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Webiny 开发流程：用 prd-to-plan 技能把 PRD 拆解为 tracer-bullet 多阶段实施计划
CMS后端前端【免费下载链接】webiny-jsOpen-source, self-hosted CMS platform on AWS serverless (Lambda, DynamoDB, S3). TypeScript framework with multi-tenancy, lifecycle hooks, GraphQL API, and AI-assisted development via MCP server. Built for developers at large organizations.项目地址https://gitcode.com/gh_mirrors/we/webiny-js点击查看免费下载本文介绍 Webiny 仓库内置的prd-to-planClaude Skill.claude/skills/prd-to-plan/SKILL.md它定义了一套PRD → 多阶段实施计划的标准工作流核心思想是用tracer-bullet曳光弹垂直切片把产品需求逐层打穿 schema、API、UI 与测试最终产出可独立演示、可逐阶段验收的本地 Markdown 计划文件。读完本文你将掌握这套技能的六步操作流程、垂直切片的分割原则、与用户的评审方法、计划文件的模板结构并能结合仓库中真实的 PRD 与计划实例如 ai-context/plans/admin-list-module.md直接上手使用。一、技能定位它解决什么问题在 Webiny 这类大型 TypeScript 单体仓库中一次功能开发往往横跨 GraphQL API、数据访问、React 前端与测试等多层代码。如果没有统一方法PRD 很容易被直接翻译成一长串水平切片式任务清单如先做数据库表、再做 API、最后做 UI导致每一层完成时都无法独立验证问题被推迟到集成阶段才暴露阶段性交付物不可演示用户与开发者对进度认知脱节计划中过早写死文件名、函数名等易变细节后续阶段一改就大面积失效。prd-to-plan技能的触发条件写在它的 frontmatter 中当用户想要把 PRD 拆解成实施计划implementation plan、按阶段规划plan phases from a PRD或提到tracer bullets时应调用本技能。它的产出是一份保存在./ai-context/plans/SKILL 正文第 8 行声明下的本地 Markdown 文件。二、六步工作流总览SKILL.md 的 Process 一节给出了完整流程共六个步骤步骤动作产出1确认 PRD 已在对话上下文中PRD 全文可用2探索代码库理解现状架构、既有模式与集成层3识别 durable architectural decisions持久架构决策计划头部的全局决策清单4起草 vertical slices垂直切片待评审的 tracer-bullet 阶段拆分5与用户评审quiz the user用户批准的分阶段方案6写出计划文件./plans/或./ai-context/plans/下的 Markdown 计划下面逐步骤展开。1. 确认 PRD 在上下文中技能明确要求The PRD should already be in the conversation. If it isnt, ask the user to paste it or point you to the file.即不允许在 PRD 缺席的情况下直接开拆。如果 PRD 不在当前对话中应请用户粘贴文本或指明文件路径。这一步保证了后续所有切片都有明确的需求来源避免凭空发挥。2. 探索代码库如果尚未探索过代码库请先探索以理解当前架构、既有模式和集成层。Webiny 仓库本身就为此提供了结构化资料例如 ai-context/prds/admin-list-module/list-module-prd.md 这类 PRD 文档以及 ai-context/code-style 下的编码规范如 one-class-per-file、no-stateless-private-methods 等。探索的目标不是通读全部代码而是回答三个问题新增功能要穿过哪些集成层GraphQL schema、repository/数据层、React 视图、测试仓库中有哪些既有模式可复用如 Webiny 的 presenter/repository 分层、react-properties 配置模式哪些边界接口第三方服务、权限系统会约束实现这直接服务于下一步的持久决策识别。3. 识别 durable architectural decisions持久架构决策在动手切片之前先识别贯穿整个实现过程、不太可能改变的高层决策。SKILL.md 给出的清单是Route structures / URL patterns路由结构 / URL 模式Database schema shape数据库 schema 形态Key data models关键数据模型Authentication / authorization approach认证 / 授权方案Third-party service boundaries第三方服务边界这些决策之所以重要是因为它们go in the plan header so every phase can reference them——会被写入计划头部供每个阶段引用。如果切片阶段发现某条决策被反复推翻说明该决策本身还不够 durable值得在进入实现前先定死。仓库实例可以佐证这一点ai-context/plans/admin-list-module.md 的Architectural decisions一节就列出了包归属packages/app-admin、状态管理MobXmakeAutoObservable、DI 方案React Context createListModule()工厂、UI 声明方式JSX react-properties、关键模型名ListGatewayTDto, TParams、ListMapperTDto, TEntity、ListViewModelTEntity、ListActionsTParams以及分页方案cursor-based。这些都是后续 7 个阶段共同依赖的地基。4. 起草垂直切片tracer bullet 阶段这是整个技能的灵魂。SKILL.md 用一段可复用的规则块vertical-slice-rules约束切片质量每个切片是一条狭窄但完整的端到端路径穿过所有集成层schema、API、UI、tests——是垂直切片不是某一层的水平切片完成的切片可以独立演示或验证demoable or verifiable on its own宁多切薄片不切厚片Prefer many thin slices over few thick ones不要包含具体文件名、函数名或实现细节——这些很可能在后续阶段构建时变化一定要包含持久决策路由路径、schema 形态、数据模型名称。换句话说tracer bullet 的精神是第一个阶段就用最窄的路径把数据从 GraphQL 一路流到 React 组件这件事跑通并点亮之后再逐步叠加搜索、排序、筛选、分页等功能。每个阶段完成时用户都能看到或验证一个真实可用的东西而不是一堆半成品中间件。5. 与用户评审Quiz the user起草完成后必须把拆分方案呈现给用户评审不能直接写文件。呈现方式是编号列表每个阶段展示两项Title简短描述性名称User stories covered该阶段覆盖 PRD 中的哪些用户故事随后向用户提出评审问题粒度是否合适太粗 / 太细某些阶段应该合并或进一步拆分吗迭代直到用户批准拆分方案Iterate until the user approves the breakdown。这一步把计划从单向产出变成双向共识过程也是技能名中 quiz盘问/评审一词的由来。6. 写出计划文件评审通过后落地成文如./plans/不存在则创建计划文件命名为功能名例如./plans/user-onboarding.md使用下方模板。需要指出的是SKILL.md 内部存在两处目录表述正文开头的Output is a Markdown file in./ai-context/plans/与步骤 6 的Create./plans/。在仓库中两个目录都实际存在且都在存放计划类文档根级 plans 目录下有 plans/breadcrumbs.md、plans/command-palette.md 等而 ai-context/plans 目录下则有 20 余份与ai-context/prds对应的计划文件。使用时以团队约定的目录为准保持 PRDai-context/prds/与计划ai-context/plans/或plans/配套存放即可。三、计划模板逐字段拆解SKILL.md 内嵌了plan-template模板结构如下# Plan: Feature Name Source PRD: brief identifier or link ## Architectural decisions 跨所有阶段生效的持久决策Routes / Schema / Key models ... --- ## [ ] Phase 1: Title **User stories**: list from PRD ### What to build 描述这条垂直切片的端到端行为而非逐层实现细节 ### Acceptance criteria - [ ] Criterion 1 - [ ] ... --- ## [ ] Phase 2: Title ...各要素的含义# Plan: Feature Name计划标题直接以功能命名 Source PRD以引用形式标注来源 PRD标识符或链接保证需求可回溯## Architectural decisions计划头部固化步骤 3 识别的持久决策供所有阶段引用## [ ] Phase N: Title每个阶段是一个待办复选框标题为简短描述名**User stories**列出该阶段覆盖的 PRD 用户故事### What to build描述这条垂直切片的端到端行为Describe the end-to-end behavior, not layer-by-layer implementation——刻意避免逐层展开### Acceptance criteria可勾选的验收标准清单是阶段完成的客观判据末尾以注释!-- Repeat for each phase --提示为每个阶段重复该结构。四、仓库实例模板的真实落地ai-context/plans/admin-list-module.md 是该模板在仓库中的真实实例共 200 行7 个阶段其头部完整复刻了模板Source PRD:ai-context/plans/list-module/list-module-plan.md对应 PRD 文档可参见 ai-context/prds/admin-list-module/list-module-prd.md。随后是 Architectural decisions包归属、MobX、DI、UI shape、关键模型、cursor 分页、BaseListParams基础类型然后按模板展开 7 个 tracer-bullet 阶段阶段标题核心内容Phase 1MVP — Full-Stack Data Load从 GraphQL 响应到 React 组件的最薄端到端数据链路定义BaseListParams、ListResponseTDto、ListGateway、ListMapper、ListViewModel实现ListQueryParamsRepository、ListDataRepository、LoadingRepository与GenericListPresenter、createListModule()工厂、useListModulehook并用PagesGatewayPageMapper示例模块验证Phase 2Search在 Phase 1 地基上叠加SearchFeature可配置防抖默认 300ms搜索变更重置 cursorPhase 3SortSortFeature的 none → asc → desc → none 循环切换Phase 4Filters类型安全的FilterFeatureset/clear/clearAll/replace以及hasActiveFilters、isEmptyWithFilters状态Phase 5Pagination (Load More)基于 cursor 的LoadMoreFeature追加而非替换 items重复调用防重入Phase 6Selection Bulk ActionsSelectionRepository/SelectionFeature/BulkActionsFeature选择跨页持久通过config.selection.enabled可关闭Phase 7Error HandlingListError { code, message, retryable }结构化错误、重试逻辑、空态区分isEmptyvsisEmptyWithFilters注意每个阶段的 What to build 都采用端到端行为描述而不写死具体文件路径Acceptance criteria 全部是可勾选、可验证的行为断言如 Phase 1 的createListModule({ name, gateway, mapper, config })无需其他配置即返回可用 hook、卸载组件即 dispose presenter无内存泄漏。这正是 SKILL.md 中不要包含易变文件名/函数名、要包含持久决策两条规则的直接体现。五、tracer-bullet 原则的仓库佐证Webiny 仓库中能观察到这一方法论在真实功能上的痕迹plans/breadcrumbs.md记录了面包屑功能从DIBreadcrumb抽象回退到 React Config API 的决策过程——它明确写到 DI 方案being root-resolved synchronous, couldnt produce dynamic labels ... which was the whole wall最终确认 Config API 才是正确方案。这正说明 durable 决策这里指面包屑是纯展示、走 Config API 而非 DI在实现前就应被识别并固化避免后期推倒重来。ai-context/plans/admin-list-module.md的 Phase 1 先打通 GraphQL response → React component 全链路gateway → mapper → repositories → presenter → hook → 组件正是 tracer bullet 的教科书式切片第一步就以最窄路径打穿所有集成层。配套技能.claude/skills/write-a-prd/SKILL.md在 PRD 阶段就刻意不包含具体文件路径或代码片段They may end up being outdated very quickly与 prd-to-plan 的切片不含易变实现细节一脉相承两条规则共同保证文档的时效性。从源码结构看这种小而完整、可独立验证的切片原则也与 Webiny 各包分层GraphQL API 包、数据访问包、前端 app 包、配套测试天然匹配每个切片都落在同一水平上对应包之间因而任何阶段都可独立演示。六、技能协作闭环write-a-prd → prd-to-plan → grill-meprd-to-plan并不是孤立的它处于 Webiny 的 AI 开发技能流水线中段write-a-prd通过用户访谈 代码库探索 模块设计产出 PRD落盘到./ai-context/prds/其中明确要求只写用户故事、实现决策、测试决策与 Out of Scope不写具体文件路径prd-to-plan本文主题消费上一步的 PRD产出多阶段实施计划grill-me对已有计划/设计进行拷问式评审——一次只问一个问题沿决策树的每个分支逐条解决依赖并为每个问题给出推荐答案如果一个问题能通过探索代码库回答就先去探索。这三个技能恰好构成写需求 → 拆计划 → 评审打磨的闭环也是 SKILL.md 步骤 5quiz the user与 grill-me 一脉相承的以对话收敛设计的方法论底色。仓库中还有 preflight、tester 等技能可在计划执行的不同环节继续接力。七、使用要点与最佳实践综合 SKILL.md 与仓库实例落地使用时有几点值得注意PRD 先于计划没有 PRD 就不要开拆第一步就是确认需求在上下文中PRD 存放于ai-context/prds/计划存放于ai-context/plans/或plans/两者通过计划头部的 Source PRD建立回溯关系。持久决策先行路由、schema、数据模型、认证授权、第三方服务边界这五类决策在切片前定死写入计划头部阶段内部只讨论行为不写将过时的实现细节。薄切片优于厚切片宁可多切几个一个功能点 全链路打通的薄片也不要一个跨多层的大阶段每个切片结束时都应有可演示或可验证的产出。评审是流程的一部分把拆分方案以Title User stories covered的编号列表呈现明确询问粒度是否合适、是否需要合并/拆分迭代到用户批准为止——不要跳过评审直接写文件。验收标准可勾选每个阶段的 Acceptance criteria 必须是客观、可验证的行为断言如某状态为true/false、某调用产生可观察结果并配合仓库既有的测试策略落地如__tests__目录下的单元/集成测试。遵循这套流程一个 PRD 会被拆成一组彼此独立、端到端可验证、且每个阶段都有明确用户故事和验收标准的实施计划——这正是 Webiny 大规模多包仓库中保持功能迭代节奏与质量可控的关键工作方法。赞分享CMS后端前端【免费下载链接】webiny-jsOpen-source, self-hosted CMS platform on AWS serverless (Lambda, DynamoDB, S3). TypeScript framework with multi-tenancy, lifecycle hooks, GraphQL API, and AI-assisted development via MCP server. Built for developers at large organizations.项目地址https://gitcode.com/gh_mirrors/we/webiny-js点击查看免费下载相关推荐ECC product-capability 技能实战把 PRD 变成可实现的能力契约PRD-to-SRS 通道ECC product capability 技能实战把 PRD 变成可实现的能力契约PRD to SRS 通道 本文基于 ECCThe agent h人工智能AI 技能AI 插件AI 评测Agent 评测MCP Clients开发工具CCPM Plan 阶段实战从头脑风暴到 PRD再到可分解的技术 EpicCCPM Plan 阶段实战从头脑风暴到 PRD再到可分解的技术 Epic Plan规划是 CCPMClaude Code Project ManagAI AgentAgent 工作流开发工具用 ECC 产品能力模板把 PRD 意图固化为可实施的能力契约用 ECC 产品能力模板把 PRD 意图固化为可实施的能力契约 产品需求PRD、Roadmap 或产品讨论往往只回答了要做什么却把实现前必须成立的大量人工智能AI 技能AI 插件AI 评测Agent 评测MCP Clients开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
