我用 AI 写了一个"需求翻译器"，产品的 PRD 直接变成开发任务清单

每次拿到 PRD，第一步都是"翻译"------把产品语言翻译成技术语言，把模糊描述变成具体改动点。这个过程以前靠脑子，容易遗漏。

我给 AI 写了一个 Prompt 模板，输入 PRD 文本，输出结构化的开发任务清单。从此再也不会漏需求点。

以前的问题

arduino 复制代码

产品写的 PRD：
"用户点击'上线'按钮后，需要先签约，签约成功后自动上线"

我脑子里翻译：
├── 加个签约弹窗
├── 对接签约接口
└── 上线接口加签约状态校验

实际遗漏了：
├── 签约失败的提示和重试
├── 已签约用户点击上线的分支（不弹窗直接上线）
├── 签约中的 loading 状态
├── 签约状态的轮询/回调
├── 签约协议内容从哪里获取
└── 这些都是提测后 QA 反馈才补的

Prompt 模板

markdown 复制代码

你是一个前端开发工程师，请分析以下 PRD 需求，输出：

## 分析要求
1. **功能点清单**：每个用户可见的交互/UI 变化
2. **接口清单**：需要新增或修改的 API 调用
3. **状态流转**：涉及的状态变化和分支
4. **边界情况**：异常、空状态、并发、权限
5. **改动范围**：需要修改的文件/模块
6. **风险点**：可能被遗漏或理解错误的地方
7. **待确认项**：PRD 中描述模糊需要和产品确认的

## PRD 内容
[粘贴 PRD 文本]

## 项目上下文
- 技术栈：React + TypeScript + Ant Design
- 请求层：axios 封装，统一错误处理
- 状态管理：Rematch
- 路由：React Router 6 HashRouter

实际效果对比

输入之前那个"上线签约"的 PRD，AI 输出：

markdown 复制代码

## 功能点清单
1. 上线按钮点击 → 判断签约状态
2. 未签约 → 弹出签约弹窗（含协议内容）
3. 签约弹窗 → 确认签约 → loading → 成功/失败
4. 签约成功 → 自动触发上线流程
5. 已签约用户 → 直接上线（跳过签约）
6. 签约失败 → 错误提示 + 重试按钮

## 接口清单
- GET  /contract/status     查询签约状态
- GET  /contract/content    获取协议内容
- POST /contract/sign       发起签约
- POST /store/online        上线接口

## 状态流转
未签约 → 签约中 → 签约成功 → 上线中 → 已上线
                 → 签约失败 → 可重试

## 边界情况
- 网络中断时签约状态如何恢复？
- 多人同时操作同一个门店？
- 签约接口超时（等 30s 还没响应）？
- 协议内容加载失败？
- 用户在签约过程中关闭弹窗？

## 待确认项
⚠️ 签约后多久生效？是同步还是异步？
⚠️ 协议内容是固定文本还是动态接口获取？
⚠️ 签约是门店维度还是商户维度？
⚠️ 上线失败后签约状态是否保留？

"待确认项"是最有价值的部分。 以前这些问题是在开发过程中才发现，然后去问产品，一来一回耽误半天。现在需求评审时就能提出来。

进阶：结合项目代码分析改动范围

markdown 复制代码

## 追加分析
结合以下文件结构，列出具体需要新增/修改的文件：

路由配置：src/route/routes/selfCatering/
视图目录：src/view/selfCatering/storeSetup/
服务目录：src/services/selfCatering/

AI 输出：

bash 复制代码

## 改动范围
新增文件：
├── src/view/selfCatering/storeSetup/SignContractModal.tsx
├── src/services/selfCatering/contract.ts
└── src/view/selfCatering/storeSetup/components/ContractContent.tsx

修改文件：
├── src/view/selfCatering/storeSetup/index.tsx（加签约判断逻辑）
└── src/services/selfCatering/store.ts（上线接口加签约参数）

预估工作量：
├── 新增弹窗组件：2h
├── 接口对接：1h
├── 状态流转逻辑：1.5h
├── 边界处理 + 联调：2h
└── 总计：约 6.5h（1天）

实际项目中的使用频率

arduino 复制代码

使用统计（近 1 个月）：
├── 新需求分析：12 次
├── 提前发现遗漏点：平均每个需求 3-4 个
├── 减少"补需求"次数：从 5 次/需求降到 1 次
└── 需求评审效率提升：能在评审会上直接提出技术问题

和 AI IDE 结合的工作流

arduino 复制代码

完整流程：

1. 收到 PRD → 用"需求翻译器" prompt 分析
                    ↓
2. 带着"待确认项"去需求评审
                    ↓
3. 评审后更新 PRD → 再跑一次，确认无遗漏
                    ↓
4. 开始开发 → 按"功能点清单"逐个实现
                    ↓
5. 自测 → 对着"边界情况"逐个验证
                    ↓
6. 提测 → "功能点清单"直接变提测文档的功能列表

每一步的输出都是下一步的输入，形成闭环。

局限性

arduino 复制代码

AI 分析得好的：
├── 明确描述的功能点
├── 通用的交互模式（弹窗、表单、列表）
├── 标准的状态流转
└── 常见的边界情况

AI 分析不到的：
├── 公司内部的业务规则（如"周末不能上线"）
├── 历史遗留约定（如"这个接口其实已经废弃了"）
├── 跨系统依赖（如"上线要先通知运营群"）
└── 政策合规要求（如"协议文本需要法务审核"）

所以 AI 的分析是起点不是终点------它帮你列出 80% 的确定性事项，剩下 20% 靠你的业务经验补充。

💬 你们拿到 PRD 后的第一步是什么？有没有固定的"翻译"流程？

🔗 完整 Skills 源码已开源 ：github.com/sleepyccat/...，欢迎 Star ⭐ 和 PR。