notion-spec-to-implementation（Notion规格转实施计划）Skill 是什么？

Notion规格转实施计划：把 PRD 自动拆成可执行任务与进度看板

它做的事很聚焦：定位并读取 Notion 里的规格文档，解析需求与验收标准，再生成实施计划页面和任务条目，并持续回写状态。
两种计划深度：简单改动走「快速计划」，多阶段功能或数据迁移走「标准计划」，避免小需求被过度拆解、大需求被草草带过。
任务粒度有明确规范：单个任务控制在 1–2 天，标题用动作动词，附上下文、目标、验收标准、依赖与资源。
全链路可追溯：规格 ↔ 计划 ↔ 任务三者互相关联，规格页还能回写一段「实施」指向说明。
前置条件是 Notion MCP：技能通过 Notion MCP 调用 notion-search、notion-fetch、notion-create-pages、notion-update-page 等能力，需先完成一次授权登录。

该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能中文名：Notion规格转实施计划Skill 技能英文名：notion-spec-to-implementation 技能ID：12026

它解决的是一个非常具体的「最后一公里」问题：产品经理把 PRD、功能规格、验收标准写在了 Notion 里，但这份文档到「能开工」之间还隔着一次成本很高的人工转化——研发负责人要通读全文、判断歧义、划分阶段、拆任务、估工作量、找任务数据库、建页面、设属性、再补链接。这一套动作重复、耗时，而且容易漏掉验收标准或依赖关系。该技能把这一整套流程固化下来，从读取规格到创建任务再到进度跟踪，形成一条可复用的链路。

关于「一键安装」，需要说明它的真实形态：这个技能不是一个独立安装包，而是一套基于 Notion MCP 的能力编排。所以「一键」指的是把 Notion 接入 AI 环境这一步尽量简化，之后技能即可直接调用。按技能详情给出的流程，启用顺序如下：

添加 Notion MCP（前提：已具备支持 MCP 的 Codex 环境，并拥有目标 Notion 工作区的访问权限）：
```
codex mcp add notion --url https://mcp.notion.com/mcp
```
启用远程 MCP 客户端，二选一：
- 在 config.toml 中设置 [features].rmcp_client = true；
- 或直接以命令行参数启动：codex --enable rmcp_client。
完成 OAuth 登录：
```
codex mcp login notion
```
重启 codex。技能详情中明确提示：登录成功后需要重启，然后再从步骤 1 继续执行任务。
验证是否生效：让技能执行一次 Notion:notion-search 搜索目标规格页面，再用 Notion:notion-fetch 读取正文。如果能正常返回页面内容，说明 MCP 通路已经打通，后续的计划创建、任务创建、状态更新都能正常调用。

技能本身还有一个贴心的兜底设计：任何 MCP 调用因为 Notion MCP 未连接而失败时，它会主动暂停并给出上述设置步骤，而不是抛出一堆报错让用户自己排查。至于该技能的具体获取入口与安装命令，以官方说明为准。

该技能的主要功能和特点

规格定位与读取：先用 Notion:notion-search 搜索规格页；如果命中多个结果，会主动询问用户使用哪一个，避免读错文档。确认后用 Notion:notion-fetch 拉取正文。
结构化需求解析：依据 reference/spec-parsing.md 中的提取模式，扫描需求、验收标准、约束条件和优先级，并把识别到的信息缺口与假设集中记录在「澄清块」里，而不是默默假设。
双档计划深度：简单改动使用 reference/quick-implementation-plan.md；多阶段功能或数据迁移使用 reference/standard-implementation-plan.md。计划页包含概述、规格链接、需求摘要、阶段划分、依赖与风险、成功标准，并回链原始规格。
任务拆解有标准模板：单个任务控制在 1–2 天，内容模板来自 reference/task-creation-template.md，包含上下文、目标、验收标准、依赖、资源五要素；属性上要求标题使用动作动词，并设置状态、优先级、与规格和计划的关系，若规格中提供了截止日期、故事点、分配人则一并写入。
数据库模式自适应：会先找到任务数据库，用 notion-fetch 确认数据源与必需属性，再通过数据库的 data_source_id 调 notion-create-pages 建任务，因此能适配团队已有的任务库结构，而不是另起一套。
工件互链：计划链接到规格，任务链接到计划和规格；还可以选择用 notion-update-page 在规格页补一段简短的「实施」小节，指向计划与任务。
进度跟踪机制：按 reference/progress-tracking.md 的节奏推进，用 reference/progress-update-template.md 发布进度更新，用 reference/milestone-summary-template.md 收口阶段；同步计划与任务中的检查清单和状态字段，并记录阻碍与决策。
自带参考与示例库：reference/ 下有解析模式、计划与任务模板、进度节奏；examples/ 下有端到端演练，包括 ui-component.md、api-feature.md、database-migration.md。

和普通「让 AI 写个计划」相比，它的差异点很明确：它读的是你工作区里真实存在的那份规格，写回的是你真实在用的那套任务数据库，中间还建立了可追溯的关联关系。普通工具给一份文本，它给一套结构化的、带链接关系的工件。

如何使用该技能？

第 1 步：定位并读取规格 直接告诉技能目标，例如「把《用户头像上传功能规格》这份 PRD 转成实施计划」。技能会执行 Notion:notion-search 检索；若出现多个同名页面，它会列出候选让你选；确认后调 Notion:notion-fetch 读取全文。

第 2 步：确认解析结果与计划深度 技能会输出需求摘要、验收标准、约束与优先级，并把歧义点整理进澄清块。此时你回答两个问题：一是澄清块里的假设是否正确，二是这次走快速计划还是标准计划。判断标准很直接——单点小改动选快速，涉及多阶段、跨模块或数据迁移选标准。

第 3 步：生成计划页 技能调 Notion:notion-create-pages 创建计划页面，内容包含概述、规格链接、需求摘要、阶段、依赖与风险、成功标准。

第 4 步：创建任务 技能先搜索任务数据库并确认识别到的属性结构，然后把每个任务按 1–2 天粒度拆好，用 data_source_id 批量创建页面。例如一个「头像上传」功能，可能被拆成「编写头像裁剪组件」「接入对象存储上传接口」「补充失败重试与格式校验」「编写端到端测试」等条目，每条都带上下文、目标、验收标准、依赖项。

第 5 步：检查链接与回写 确认计划已链接规格、任务已链接计划与规格。如果希望规格页也能体现落地情况，可让技能在规格中补一段「实施」说明。

第 6 步：跟踪进度 进入迭代后，让技能按节奏发布进度更新、同步任务状态、记录阻碍与决策，阶段结束时输出里程碑总结。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
Notion规格转实施计划Skill	规格到执行的转换器	读取 Notion 规格、解析需求、生成计划页、按 1–2 天粒度创建任务、互链与进度跟踪	需配置 Notion MCP 并完成 OAuth 登录，首次配置有一定门槛	规格已沉淀在 Notion、需要快速落成任务清单的团队	优势：全链路可追溯、沿用团队既有任务数据库、模板与示例齐全；不足：强依赖 Notion 生态，非 Notion 用户无法直接受益
人工阅读 PRD 后手动拆解	传统项目管理做法	通读文档、口头对齐、手工建任务	无需额外工具，但消耗人力时间	规格简短、团队规模小	优势：理解上下文最充分；不足：重复劳动多、易漏验收标准、无标准化输出
直接在对话中粘贴 PRD 让大模型生成计划	通用 AI 辅助	一次性输出计划文本	极低，复制粘贴即可	临时性、一次性梳理	优势：上手最快；不足：结果停留在聊天窗口，不落到工作区、无链接关系、无法持续跟踪状态
项目管理工具原生自动化规则	流程自动化	基于状态变更触发通知、字段联动	需配置规则与字段，通常不支持文档语义解析	已有成熟流程的团队	优势：稳定可预期；不足：本质是规则引擎，不能「读懂」规格内容并做语义拆解

该技能的典型应用场景与实际体验情况

场景一：研发负责人接到一份新 PRD 产品经理在 Notion 写完功能规格，研发负责人需要在一个上午内给出排期。痛点是通读加拆解往往要花 2–3 小时，还容易在第 3 天发现漏了验收标准。使用方式：让技能读取规格并生成标准计划，再逐条复核任务粒度与依赖。实际体验上，上手难度不高，只要 MCP 已登录，第一轮就能跑通；效果主要体现在「结构不会漏」——验收标准、依赖、风险都被强制填进模板。注意点是澄清块一定要看，技能会把不确定的地方显式列出来，直接确认比事后返工划算。

场景二：独立开发者做小功能迭代 需求很小，比如加一个筛选器。痛点是懒得为这点改动专门建计划。使用方式：选快速计划模板，让技能产出一页轻量计划和三五个任务。体验上，快速路径确实快，不会像标准模板那样要求填一长串阶段划分。注意点是任务粒度控制在 1–2 天这条规则在小需求上也生效，如果拆出来只有一条任务，可以直接在任务里补验收标准，不必强行凑数量。

场景三：数据库迁移这类多阶段工程 迁移类工作对「依赖与风险」特别敏感，顺序错一步就要回滚。技能详情中的 examples/database-migration.md 正是为此准备的端到端演练。使用方式：走标准计划，明确阶段划分和依赖关系，任务按阶段挂到计划下。体验上，阶段收口时的里程碑总结模板比较实用，能把「迁移完成 80%」这类模糊表述变成可核查的清单状态。注意点是迁移类任务要主动提供截止日期与分配人，否则这些属性不会被写入。

场景四：迭代中期的进度同步 任务建完之后，真正的麻烦是状态不同步。使用方式：让技能按进度节奏发布更新，同步检查清单与状态字段，记录阻碍与决策。体验上，价值在于「一份规格、一个计划、一组任务」始终指向同一处真相，站会时不用在三个地方对数字。注意点是进度跟踪依赖人工触发，需要养成固定节奏去调用，否则状态还是会滞后。

该技能能为用户带来的价值

把隐性工时变成显性产出。 从规格到任务清单原本是分散在多个时间段里的隐性工作，现在被压缩成一次可复用的流程，产出的是一套结构化、可追溯的工件。

降低对「经验」的依赖。 任务该拆多大、标题该怎么写、需要哪些字段、验收标准放哪里——这些原本靠资深成员的经验判断，现在由模板和规范兜底，新成员也能产出格式一致的拆解结果。

消除信息断点。 规格、计划、任务三者互链，这在长期项目中价值最大：三个月后回头看某个任务为什么存在，沿着链接一路点回去就能找到原始需求段落，而不是靠记忆或聊天记录考古。

适配而非替换现有流程。 它会先确认任务数据库的模式再创建页面，意味着团队不需要为了用这个技能而重构已有的项目管理结构，迁移成本接近于零。

进度跟踪的连续性。 从计划创建到阶段收口是一条完整的链，里程碑总结让阶段性成果可被复核，而不是每次都要重新描述「我们做到哪了」。

常见问题 FAQ

Q1：这个技能怎么安装？需要提前准备什么？ 它不是独立安装包，而是通过 Notion MCP 接入。核心三步是：codex mcp add notion --url https://mcp.notion.com/mcp 添加 MCP，在 config.toml 设置 [features].rmcp_client = true 或启动时加 --enable rmcp_client，再用 codex mcp login notion 完成 OAuth 登录，登录后重启 codex。另外需要目标 Notion 工作区的访问权限。具体入口以官方说明为准。

Q2：收费吗？ 技能详情中没有涉及定价信息，是否需要付费取决于你所使用的 AI 环境与 Notion 账号自身的订阅方案，以官方说明为准。

Q3：适合谁用？ 最适合规格文档已经沉淀在 Notion 里的产品经理、研发负责人和技术 lead；独立开发者做小迭代时用快速计划路径也很顺手。如果你的团队用别的文档工具，或者任务不在 Notion 里管理，这个技能的收益会大打折扣。

Q4：它会不会把我的任务库结构搞乱？ 从技能逻辑看不会。它会先搜索任务数据库，用 notion-fetch 确认数据源和必需属性，再按现有模式创建页面，属于「适配」而不是「重建」。稳妥的做法是第一次先在一个测试数据库上跑一遍。

Q5：和直接把 PRD 粘给大模型让它写计划有什么区别？ 最大区别在落地与追溯。通用对话产出的是聊天窗口里的一段文本，需要人工搬运；这个技能直接在你的工作区创建计划页和任务，建立规格 ↔ 计划 ↔ 任务的双向链接，还能持续回写状态。代价是需要一次性完成 MCP 配置。