一、真实痛点：需求评审结束了，前端任务还是一团乱
我是前端开发，负责公司 B 端管理后台。上周接到一个「订单履约看板」需求，产品同学说「不复杂，这周能上完吧？」
但材料发过来之后，我头都大了：
| 材料 | 实际情况 |
|---|---|
| 产品 PRD | 3800 字，3 处描述互相矛盾（筛选条件是单选还是多选？） |
| Figma 设计稿 | 12 个页面，47 条 scattered 注释（有的写在组件上，有的写在空白处） |
| 接口文档 | 后端只给了 2 个接口，列表字段和 PRD 对不上 |
| 群聊补充 | 产品又补了 6 条「上次忘说了」 |
按老流程，我要：
- 通读 PRD，手动标不确定点（40 分钟）
- 逐页看 Figma 注释，和 PRD 对照（50 分钟）
- 拆组件、列接口依赖、标交互细节（45 分钟）
- 整理成 Jira/飞书任务，和前后端对齐（30 分钟）
合计 2.5～3 小时，还常常漏边界情况------上线前才发现「空状态没设计」「导出按钮权限没说清」。
这类场景前端同学每周都在经历：不是不会写，是信息太散、太乱、太依赖口头补充。
二、实操过程：4 轮对话，把「散」变「可排期」
我没有让 TRAE Work 替我估工时或写代码，而是让它做信息对齐、结构化拆解------不确定的地方我人工标注，它负责整理成清单。
第 1 步：PRD + 设计注释 → 统一「需求条目表」
我的指令：
diff
你是资深前端 Tech Lead 助理。以下是「订单履约看板」的产品 PRD 摘要和 Figma 设计注释汇总。
请合并成一份「需求条目表」，每行包含：
- 功能点名称
- PRD 描述（原文摘要）
- 设计稿要求（来自 Figma 注释）
- 矛盾/缺失项（PRD 与设计不一致、或两者都未说明的地方，标 ⚠️）
不要猜测结论；矛盾项并列展示，不做裁决。
输出 Markdown 表格。
【粘贴 PRD 摘要 + Figma 注释】TRAE Work 输出亮点：
- 自动识别 3 处 PRD 内部矛盾（筛选器单选/多选、日期默认范围、导出权限）
- 把 47 条 Figma 注释按页面归组，不再逐条翻设计稿
- 标出 7 个缺失项：空状态、加载失败、无权限、大数据量分页策略等
第 2 步：需求条目 → 前端组件 & 接口依赖清单
第二轮指令：
markdown
基于上一轮需求条目表，输出「前端开发拆解清单」，包含：
1. 页面/路由清单
2. 每个页面需要的组件（区分：已有组件库可复用 / 需新开发）
3. 每个功能点依赖的后端接口（已知接口标注文档字段，未知接口标 [待后端补充]）
4. 交互细节清单（hover、loading、防抖、表单校验规则）
5. 建议开发顺序（先主链路、后边界态）
项目栈：Vue 3 + Element Plus + Pinia。不要写具体代码，只输出任务清单。流程调整要点：
- 我在输入里补充了一句：「表格组件复用
@/components/DataTable，筛选区复用FilterBar」------复用信息人来做，拆解 AI 来做 - TRAE Work 把 12 个设计页收敛成 3 个路由 + 9 个组件任务，并建议「先打通列表+详情主链路，再补导出和异常态」
第 3 步：生成「待确认问题清单」，一键发群对齐
第三轮我没有继续拆任务，而是先把坑问清楚：
diff
把上一轮所有 ⚠️ 和 [待后端补充] 项，整理成「需求澄清清单」，格式：
- 问题描述
- 影响范围（阻塞开发 / 可并行 / 仅影响边界态）
- 建议找谁确认（产品 / 设计 / 后端）
- 建议确认截止时间（按 P0/P1/P2）
便于我直接复制到飞书群 @ 对应同事。结果： 14 条澄清问题，我复制到群里，产品 30 分钟内回了 11 条，剩下 3 条标成「不阻塞主链路」------当天就能开工，不用干等。
第 4 步：澄清结果回填 → 最终可排期任务表
产品回复后，我把结论粘贴回去，第四轮指令：
markdown
以下是需求澄清结论，请更新前端开发拆解清单：
1. 筛选器改为多选；日期默认近 7 天
2. 导出仅管理员可见；空状态用设计稿第 8 页
3. 列表接口字段以后端 v2 文档为准
输出最终版：
- 前端任务表（含优先级 P0/P1/P2、建议人天区间）
- 联调依赖说明（哪些任务依赖后端接口就绪）
- 测试验收要点（给 QA 看的 5～8 条）
不要写代码。
三、落地成果：从 3 小时到 25 分钟，还少漏 2 个边界态
| 环节 | 传统方式 | TRAE Work 方式 |
|---|---|---|
| PRD + 设计注释对齐 | 90 分钟 | 8 分钟 |
| 组件/接口/交互拆解 | 45 分钟 | 7 分钟 |
| 澄清问题整理 & 发群 | 30 分钟 | 5 分钟 |
| 回填结论 + 排期任务表 | 35 分钟 | 5 分钟 |
| 合计 | 约 3 小时 | 约 25 分钟 |
最终交付物：
- 《订单履约看板 · 需求条目表》------PRD 与设计对齐，矛盾项已标注
- 《前端开发拆解清单》------3 路由 / 9 组件 / 6 接口依赖
- 《需求澄清清单》------14 问，已闭环 11 问
- 《可排期任务表 + 联调说明 + QA 验收要点》------直接贴进飞书文档和 Jira
评审会上，组长说：「这次前端评估最清楚，边界态提前说了。」以往类似需求，我们经常在联调阶段才冒出「空状态谁做」「导出权限呢」。
四、复用经验：前端同学可直接照搬（重点）
✅ 4 套通用指令模板
模板 1：PRD + 设计注释 → 需求条目表
scss
合并 PRD 与设计注释为需求条目表：
功能点 | PRD描述 | 设计要求 | 矛盾/缺失(⚠️)
矛盾项并列，不要裁决。
【粘贴材料】模板 2：需求条目 → 前端拆解清单
scss
输出前端开发拆解：路由/组件(复用vs新建)/接口依赖/交互细节/开发顺序
技术栈：[Vue3/React等]。不写代码，只出任务清单。模板 3：待确认项 → 澄清清单
css
把所有 ⚠️ 和 [待补充] 整理成澄清清单：
问题 | 影响范围 | 找谁 | 优先级
便于复制发群。模板 4：澄清结论回填 → 排期任务表
scss
根据以下澄清结论更新清单，输出：
前端任务表(P0/P1/P2+人天区间) / 联调依赖 / QA验收要点
【粘贴澄清结果】⚠️ 5 个避坑技巧
- 先对齐再拆解：不要跳过「需求条目表」，直接拆组件容易带着矛盾往下走
- 复用组件信息要人工喂：告诉 TRAE 你们项目里已有的组件名，否则它会按「全新开发」估任务
- 接口文档不全时标 待补充 ：不要让 AI 编造字段，排期时把联调依赖单列
- 边界态单独成组：空状态、无权限、超时、大数据量------让 AI 单独列一节，漏项会少很多
- 人天区间仅供参考：AI 给的估时用来排序优先级，最终工时自己拍板
🔄 推荐工作流
PRD+设计注释导出 → TRAE出需求条目表 → TRAE出前端拆解清单
→ TRAE出澄清清单发群 → 人工等回复 → TRAE回填出排期任务表 → 贴Jira五、写在最后
前端很多「难」不在写代码，而在开工之前：材料散、口径乱、边界态全靠猜。TRAE Work 帮我把最耗耐心的整理和对齐接了过去，我只需要做判断------哪些能复用、哪些要问产品、哪些可以后补。
如果你也是「需求评审听完了，回来还要花半天理材料」的前端同学，建议从下一个小需求开始试。4 轮对话、4 套模板，基本一次就能出可排期的任务清单。