把需求文档变成可执行的技术方案：Claude Code 的 PRD 转译流程

PM 写的需求文档和工程师需要的技术规格之间通常有一条鸿沟。Claude Code 可以帮你系统性地跨越这条鸿沟。

第一步：发现需求里的歧义

claude "阅读这份需求文档（prd.md）。
列出所有技术实现时需要澄清的歧义点：
1. 缺少具体数值的地方（例如：'支持大量用户'是多少？）
2. 边界情况没有覆盖的地方（用户取消操作怎么处理？）
3. 不同需求点之间的潜在矛盾
4. 依赖其他系统但没有说明接口的地方

不要提解决方案，只列出问题，让我去和 PM 确认。"

第二步：转化为工程任务

claude "把这份已经澄清的需求，转化为 GitHub Issues 格式的工程任务：

要求：
- 每个任务聚焦一个可独立测试的功能点
- 包含：背景、验收标准、技术考量
- 标注依赖关系（哪个任务必须先完成）
- 预估工作量等级（S/M/L/XL）

输出格式可以直接粘贴创建 Issues。"

第三步：技术方案 Pre-mortem

claude "假设我们按这个技术方案实现，
6 个月后发现实现失败了。
最可能的失败原因是什么？

分析：
1. 技术风险（哪些假设可能错误？）
2. 规模风险（哪里会成为瓶颈？）
3. 依赖风险（哪些外部依赖可能出问题？）
4. 理解风险（哪些需求理解可能有偏差？）"

第四步：生成技术规格文档

claude "基于这份需求，生成技术规格文档（Tech Spec）：

包含：
1. 背景和目标（一段话）
2. 不做什么（Out of Scope，很重要）
3. 技术方案（主要组件、数据模型、API 接口）
4. 关键决策和权衡（为什么选 A 不选 B）
5. 风险和缓解措施
6. 验收标准

用 Markdown 格式，大约 500-800 字，不要过度设计。"

第五步：估算工作量

claude "基于这份技术规格，估算工作量：

团队情况：
- 2 名后端工程师（Go）
- 1 名前端工程师（React）
- 无专职 QA

请估算：
1. 各阶段工时（设计/开发/测试/上线准备）
2. 关键路径（什么决定了最早上线时间）
3. 哪些地方我可能低估了复杂度
4. 推荐的 MVP 范围（最小化功能但满足核心价值）"

把这个流程标准化之后，技术 Lead 和 PM 的沟通成本会显著下降——不是因为减少了沟通，而是每次沟通都更聚焦在真正重要的决策上。