每次拿到 PRD第一步都是翻译——把产品语言翻译成技术语言把模糊描述变成具体改动点。这个过程以前靠脑子容易遗漏。我给 AI 写了一个 Prompt 模板输入 PRD 文本输出结构化的开发任务清单。从此再也不会漏需求点。以前的问题产品写的 PRD 用户点击上线按钮后需要先签约签约成功后自动上线 我脑子里翻译 ├── 加个签约弹窗 ├── 对接签约接口 └── 上线接口加签约状态校验 实际遗漏了 ├── 签约失败的提示和重试 ├── 已签约用户点击上线的分支不弹窗直接上线 ├── 签约中的 loading 状态 ├── 签约状态的轮询/回调 ├── 签约协议内容从哪里获取 └── 这些都是提测后 QA 反馈才补的Prompt 模板你是一个前端开发工程师请分析以下 PRD 需求输出 ## 分析要求 1. **功能点清单**每个用户可见的交互/UI 变化 2. **接口清单**需要新增或修改的 API 调用 3. **状态流转**涉及的状态变化和分支 4. **边界情况**异常、空状态、并发、权限 5. **改动范围**需要修改的文件/模块 6. **风险点**可能被遗漏或理解错误的地方 7. **待确认项**PRD 中描述模糊需要和产品确认的 ## PRD 内容 [粘贴 PRD 文本] ## 项目上下文 - 技术栈React TypeScript Ant Design - 请求层axios 封装统一错误处理 - 状态管理Rematch - 路由React Router 6 HashRouter实际效果对比输入之前那个上线签约的 PRDAI 输出## 功能点清单 1. 上线按钮点击 → 判断签约状态 2. 未签约 → 弹出签约弹窗含协议内容 3. 签约弹窗 → 确认签约 → loading → 成功/失败 4. 签约成功 → 自动触发上线流程 5. 已签约用户 → 直接上线跳过签约 6. 签约失败 → 错误提示 重试按钮 ## 接口清单 - GET /contract/status 查询签约状态 - GET /contract/content 获取协议内容 - POST /contract/sign 发起签约 - POST /store/online 上线接口 ## 状态流转 未签约 → 签约中 → 签约成功 → 上线中 → 已上线 → 签约失败 → 可重试 ## 边界情况 - 网络中断时签约状态如何恢复 - 多人同时操作同一个门店 - 签约接口超时等 30s 还没响应 - 协议内容加载失败 - 用户在签约过程中关闭弹窗 ## 待确认项 ⚠️ 签约后多久生效是同步还是异步 ⚠️ 协议内容是固定文本还是动态接口获取 ⚠️ 签约是门店维度还是商户维度 ⚠️ 上线失败后签约状态是否保留待确认项是最有价值的部分。以前这些问题是在开发过程中才发现然后去问产品一来一回耽误半天。现在需求评审时就能提出来。进阶结合项目代码分析改动范围## 追加分析 结合以下文件结构列出具体需要新增/修改的文件 路由配置src/route/routes/selfCatering/ 视图目录src/view/selfCatering/storeSetup/ 服务目录src/services/selfCatering/AI 输出## 改动范围 新增文件 ├── 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.5h1天实际项目中的使用频率使用统计近 1 个月 ├── 新需求分析12 次 ├── 提前发现遗漏点平均每个需求 3-4 个 ├── 减少补需求次数从 5 次/需求降到 1 次 └── 需求评审效率提升能在评审会上直接提出技术问题和 AI IDE 结合的工作流完整流程 1. 收到 PRD → 用需求翻译器 prompt 分析 ↓ 2. 带着待确认项去需求评审 ↓ 3. 评审后更新 PRD → 再跑一次确认无遗漏 ↓ 4. 开始开发 → 按功能点清单逐个实现 ↓ 5. 自测 → 对着边界情况逐个验证 ↓ 6. 提测 → 功能点清单直接变提测文档的功能列表每一步的输出都是下一步的输入形成闭环。局限性AI 分析得好的 ├── 明确描述的功能点 ├── 通用的交互模式弹窗、表单、列表 ├── 标准的状态流转 └── 常见的边界情况 AI 分析不到的 ├── 公司内部的业务规则如周末不能上线 ├── 历史遗留约定如这个接口其实已经废弃了 ├── 跨系统依赖如上线要先通知运营群 └── 政策合规要求如协议文本需要法务审核所以 AI 的分析是起点不是终点——它帮你列出 80% 的确定性事项剩下 20% 靠你的业务经验补充。 你们拿到 PRD 后的第一步是什么有没有固定的翻译流程完整 Skills 源码已开源github.com/sleepyccat/ai-native-workflow欢迎 Star ⭐ 和 PR。