产品经理甩来一份五页的 PRD，密密麻麻全是"用户希望""系统应当"，你作为开发第一反应是：这到底要我先做哪块？用 Claude 把这份文档变成一张张能直接进看板的任务卡，比自己硬读省一半时间，还能顺手揪出需求里的坑。
准备清单：一个 Claude 对话（网页版或客户端），以及 PRD 的电子版文本——Word、网页、PDF 都行，直接把正文复制出来，别带太多排版噪声。
第一步，把 PRD 正文粘贴进新对话，后面跟一段角色指令：
你是一名资深技术负责人。请基于以上 PRD，输出一份开发任务清单：1) 按 Must/Should/Could 三级标注优先级；2) 每张任务卡含"目标、验收标准、预估工作量(人日)"；3) 标出需求中模糊、需向产品确认的点；4) 列出任务间的依赖关系。用中文、markdown 表格输出。
这段指令的精髓是逼它结构化：优先级帮你排期，验收标准防止"做完了产品说不是我要的"，模糊点清单则是你明天站会上该追问产品的问题。不写"标出模糊点"，模型往往只会乖乖执行，把坑埋进代码里。
第二步，拿到清单后别全信。重点看它标的"需确认"那几行——比如"登录方式未说明，默认按手机号实现"，这种就是埋雷处。把这几条截给产品，比问"你这文档啥意思"专业得多。第三步，把 Must 级任务直接搬进看板开干，Should/Could 进待定池。
验收：你能在十分钟内对着清单讲清"这 sprint 做哪几张卡、为什么这个先做、哪几个等产品的回复"。讲得顺，说明拆解到位；讲不顺，多半是 PRD 本身就有洞，那就该退回上游而不是硬扛。
进阶：把你们团队的技术栈和代码规范写进一段常驻提示词，每次贴新 PRD 都带上，Claude 拆出来的任务会更贴近你们真实的实现成本，估人日也比泛泛而谈准。
再给一个避坑提醒：PRD 里最危险的是"等等"和"大概"这类词——"登录方式待定""数据来源后续补充"。这些模糊点恰恰决定工作量差出几倍，别让模型替你默认一个答案然后默默开工。我习惯在贴 PRD 时额外加一句"遇到不确定的需求点，列出清单而不是替我假设"，这样它拆出来的清单里会专门有一栏"待确认"，你拿着这栏去对齐产品，比闷头做再返工省太多。说到底，Claude 是加速器，不是替你背需求责任的同事——它把活拆清楚，该问的产品问题，还是得你亲自去问。