技能介绍

问题：把 PRD 直接丢给 AI，实现范围会失控

把一份 PRD 粘贴进对话，让 AI「开始实现」，看起来省事，实际很容易崩：模型一边读需求一边临时决定要改哪些文件，前一个改动和后一个改动之间没有显式依赖，做到一半才发现漏了数据模型或者接口契约。更常见的是范围悄悄膨胀——顺手加个缓存、重构一下模块、补个没要求的后台，最后 git diff 里全是没人评审过的代码。

这类问题的根源不是模型能力不够，而是没有把「要做什么」和「正在做什么」分开。计划留在聊天记录里，实现动作却散落在工作区里，两者随时脱节。

这个技能做了什么

核心是把 PRD 转成一张依赖感知的任务图，再用 Task Master AI 把后续实现工作绑在显式计划上，而不是让 agent 在聊天里即兴发挥。

解析 PRD：抽出功能性需求、边界条件和隐含约束，而不是只抓用户故事标题。
拆解并建图：生成任务节点，标出前置依赖、可并行分支和里程碑，形成可遍历的有向图。
按需展开：对粒度过大的任务继续分解；对不在范围内的需求明确收缩，避免顺手实现。
锚定实现：agent 每次动手前回到任务图确认当前节点、已完成项和待验证项，而不是从对话上下文里回忆目标。

适用边界

这个技能不负责写业务代码本身，也不替代架构决策。它假设你已经有一份相对完整的 PRD，并且能接受「先有计划、后有实现」的工作流。

需要先配好 Task Master AI，以及它依赖的模型凭据；上游明确要求主模型、研究模型、兜底模型三类，各自要有对应 provider 的 API key，缺了就会在某个命令上直接失败。
想省掉 API key，可以用 Claude Code，但前提是已经装了 CLI 并可用，这不是免费的通用解法。
任务图的质量上限取决于 PRD 的清晰度。需求含糊时，图里会留下大量猜测出来的依赖边，后续反而更难维护。
对一次性原型或单文件小改动，建图的收益可能抵不过开销。