技能介绍

要解决的具体问题

很多团队把需求、验收标准、排期都写进 Notion 文档，但当真正进入开发时，规格与执行往往是割裂的：需求评审后，文档停在 Notion 里，实施计划散落在 Jira、Linear 或另一个页面；任务拆解靠人工搬运，边界条件、阻塞项和验收标准容易在迁移中丢失；进度更新则依赖每个人手动改状态，评论里的讨论很难沉淀为可追踪的记录。结果就是，"我们在哪一步""下一步谁负责""某个改动是否覆盖了原规格"往往要翻评论、问 PM，再对照原文确认。

技能如何工作

这个技能的价值在于，把 Notion 规格变成一条可执行的链路，而不是让团队在多个工具间反复搬运信息。

读取 Notion 规格：通过 Notion MCP 连接，拉取指定页面或数据库中的规格内容，保留原文结构与要点。
需求梳理与歧义登记：识别需求项、依赖关系、约束条件，同时把缺失信息、冲突描述、未决问题集中登记为待澄清项，避免带着模糊判断进入开发。
生成实施计划：把需求拆成阶段与里程碑，标注关键路径、依赖关系与风险点，让计划本身成为可追踪的对象。
任务拆解与关联：把实施计划转成可执行任务，明确负责人、验收标准、优先级与先后顺序，并将任务与原始规格条目建立链接，回溯时不会断链。
进度跟踪结构：在 Notion 中创建或更新进度跟踪结构，用状态字段、时间线视图和关联链接，记录每个任务当前状态、阻塞原因和变更历史。
与 Notion MCP 配合：所有创建与更新都通过 Notion MCP 完成，目标工作区与任务数据库需要提前授权；返回结果会落到 Notion 页面，便于团队直接协作。

适用边界与注意点

它适合规格已经写清楚、但执行计划尚未结构化，或者团队希望把 Notion 作为单一数据源的场景。依赖 Codex、Notion MCP connection，以及对目标工作区和任务数据库的访问权限。不要把它当作 PM 决策器：优先级判断、资源分配、对外承诺仍需要人来确认。若规格本身缺少验收标准，生成的计划需要补充人工评审后再使用；敏感流程里，建议先在测试工作区验证，确认字段与权限符合团队约定后再推广。