用 TRAE Work 把 产品经理交付的PRD + 原型，变成带截图的需求功能清单
本文参与 TRAE Work 实战帮 征文活动。
每次版本迭代前，前端总会有个活：把 PRD 里的需求变更，逐条整理成一份需求功能清单，跟产品一一对齐需求。
作为一个前端，这活谈不上难，但就是费时间。打开 PRD 文档，一条一条摘需求要点，打开原型页面截图，打开 Excel 模板，把文字粘进去、把图片插进去、调格式、调列宽、调行高......一条需求搞下来七八分钟，六个变更弄完一个小时就过去了。
这次我试了用 TRAE Work 来做这件事。从发出指令到拿到成品，25 分钟。而且产出比我手动整理的更完整------因为 AI 不会漏掉 PRD 里任何一条规则。
最后顺手还让它沉淀了一个可复用的 Skill，以后换个项目直接套。
先说说以前怎么做的
手动梳理需求清单的流程大概是这样的：
先打开 PRD 文档，通读一遍需求变更，在脑子里记住有哪些条目。然后打开原型 HTML，一个场景一个场景地截图------有时候原型页面比较长，还得截两张拼起来。接着打开 Excel 模板，对照模板的列结构，把需求标题、描述、规则、接口、备注逐条填进去。最后检查一遍格式，确保和模板一致。
这个过程有几个问题：
第一，容易漏。 PRD 里一条需求往往包含摘要、规则、操作步骤、验收标准好几块内容，手动摘的时候经常会只写个标题和简短描述，规则细节和验收标准就略过了。等想起细节，还得翻回 PRD 去找。作为前端，最怕的就是漏了交互规则，写代码的时候才发现 PRD 里明明写了，自己当时没记下来。
第二，只有自己看得懂。 手动写的需求描述往往是缩写和简写，自己当时明白，过两天自己都忘了具体指什么。
第三，截图是个体力活。 六个原型场景，每个都要打开浏览器、导航到对应页面、截图、裁剪、插入 Excel。原型是 HTML 格式的，场景之间靠 URL 参数切换，手动一个个点、一个个截，枯燥且容易出错。
这次怎么做的
第一步：把文件放好，说清楚要什么
我在桌面上建了个文件夹，把三样东西扔进去：PRD 文档（HTML 格式）、交互原型（HTML 格式）、需求功能清单模板（xlsx 格式）。
三个输入文件：PRD 文档、交互原型、Excel 模板
然后打开 TRAE Work，选好这个文件夹作为工作目录，输入指令：
css
读取文件夹里面的产品文档，根据文件夹里面的需求功能清单模板，
生成一份复盘宝v1.2需求功能清单。
要求：
1、需要有原型截图，可以自行运行html文件截图。
2、严格按照模板风格输出文件。
3、注意需求细节和变更内容。
指令很简单，关键是把要求说清楚
指令本身没什么技巧，就是把要做的事和约束条件列清楚。但有几个点我觉得挺重要："严格按照模板风格"------这让它不会自由发挥格式；"注意需求细节和变更内容"------让它去挖 PRD 里的完整规则，而不是只写个标题。
第二步：AI 读文档，提取需求
指令发出去之后，TRAE Work 先扫描了文件夹，识别出三个文件的用途。然后它读了 PRD HTML，每条需求有编号、标题、摘要、规则列表、操作步骤、验收标准等字段。
这一步它做得很快，大概两三分钟就把 6 条需求变更的结构化数据全部提取出来了。每条的完整规则和操作步骤都抓到了。
第三步：分析模板结构（这里卡了一阵）
提取完需求数据后，TRAE Work 需要分析 Excel 模板的结构------列宽、字体、表头颜色、合并单元格、已有图片的位置和尺寸。这一步花的时间最长，也是整个过程里最大的弯路。
解析 xlsx 模板时走了不少弯路，红框标注的是反复尝试的步骤
问题出在环境里没有 Python。TRAE Work 先试了调用 Python 的 openpyxl 库------没装。又试了 MCP 工具------也不行。最后回退到用 PowerShell 解压 xlsx 文件（xlsx 本质是个 ZIP 压缩包），直接读里面的 XML 文件来提取样式信息。中间还踩了一个中文路径的坑：PowerShell 的 .NET 方法处理中文路径时报错，只好先把文件复制到纯英文路径下再解析。
作为开发，我理解这种在受限环境里找替代方案的感觉。xlsx 文件本质就是 Open XML 格式，解压后里面有 sharedStrings.xml（共享字符串）、styles.xml（样式定义）、xl/drawings/（图片位置）等文件，用 PowerShell 的 System.IO.Compression 直接读 XML 节点确实能拿到所有信息，只是写起来比 openpyxl 麻烦不少。
这一来一回，光读模板就花了好几分钟。
第四步：自动截图原型
这一步是整个过程中最让我意外的。TRAE Work 自己想出了一套截图方案：
它先启动了一个本地 HTTP 服务器来托管原型 HTML 文件。然后通过 PRD 里的场景 ID，构造 URL 参数（?prd-scene=file-sync-settings 这种），用浏览器逐个访问每个原型场景，等待页面加载完成后自动截图。
AI 自动启动 HTTP 服务器、导航到原型场景、截图，右侧是正在被操控的原型页面
六个场景的截图，大概用了三四分钟。
第五步：生成最终文件
数据和图片都准备好之后，TRAE Work 用 Excel COM 自动化来生成最终文件。
从发出指令到拿到成品，总共 25 分钟。11:14 开始，11:39 结束。
任务完成，右侧待办全部打勾，产出文件已生成。Token 消耗 191.44
实际效果和时间对比
| 手动梳理 | TRAE Work |
|---|---|
| 60min | 25min |
| 约1小时 | 14分→39分 |
时间节省 58%
时间只是一个维度。更重要的是产出质量的差异：
| 对比项 | 手动梳理 | TRAE Work |
|---|---|---|
| 需求条目数 | 只梳理5条 | 完整提取全部 6 条变更 |
| 规则细节 | 只写概要，细节省略 | 完整保留 PRD 中所有规则原文 |
| 操作步骤 | 通常不写 | 每条需求附带关键交互说明 |
| 原型截图 | 手动截图，容易漏场景 | 自动导航到正确场景并截图 |
| 可读性 | 简写为主，只有自己看得懂 | 结构化描述，团队成员可直接理解 |
| 格式一致性 | 每次手动调格式，总有偏差 | 严格复刻模板格式，完全一致 |
说实话，时间从 1 小时压到 25 分钟，这个数字已经很可观了。但对我帮助更大的是第三点------产出的完整性。以前手动写需求清单，写着写着后面的质量明显下降。AI 不会犯困，所有内容详细程度一模一样。
作为前端，需求清单写得越清楚，后面写代码的时候返工就越少。以前经常是写到一半发现 PRD 里某个交互规则没记下来，又得回去翻文档，打断思路。现在一次性把所有规则、操作步骤、验收标准都列清楚，开发的时候照着清单写就行。
顺手做了个可复用的 Skill
任务完成后，我想到一个问题：这套流程下次换个项目还能用吗？PRD 格式可能不一样，模板可能不一样，但工作流程是一样的------读文档、提取需求、截图、按模板生成清单。
于是我又给 TRAE Work 发了一条指令，让它把刚才的流程沉淀成一个 Skill：
让 AI 把流程沉淀成可复用的 Skill
5 分钟后，它生成了一个完整的 Skill 包：
Skill 创建完成，包含主指令文件和 5 个参考脚本
Skill 的结构是这样的：
bash
.trae/skills/requirement-list-generator/
├── SKILL.md # 主技能指令（6阶段工作流）
└── references/
├── http_server.ps1 # 本地HTTP服务器（解决file://被浏览器拦截）
├── parse_xlsx_template.ps1 # xlsx模板结构解析（无需Python）
├── crop_screenshots.ps1 # 截图裁剪与缩放
├── generate_xlsx.ps1 # Excel COM自动化生成xlsx
└── data_template.json # JSON数据格式模板（编码安全）这个 Skill 不只是把刚才的操作步骤记下来，它还做了两层设计：通用层 适用于任何产品文档场景（支持 HTML/Markdown/Word/PDF 格式的 PRD），增强层专门针对 HTML 文档 + xlsx 模板的场景做了优化（比如自动检测 PRD 里的 JavaScript 数据结构、识别原型场景导航参数、用 PowerShell 解析 xlsx 内部 XML）。
以后换个项目，只要把 Skill 目录复制过去，遇到"生成需求功能清单"的任务时 TRAE Work 会自动触发这个流程。不用每次重新写指令。
缺陷
整个过程有两个明显的缺陷：
一：读 xlsx 文件花的时间太长
TRAE Work 在解析 Excel 模板时走了不少弯路。先试 Python 的 openpyxl------环境里没装。再试 MCP 工具------也不行。最后回退到 PowerShell 解压 xlsx 读 XML，中间又碰到中文路径编码问题。光这一步就花了好几分钟，占整个流程将近三分之一的时间。
二：截图底部不完整
原型截图的底部被截掉了一块。猜测原因是 TRAE Work 在浏览器里运行原型 HTML 时，底部有一个"控制台日志"栏遮挡了页面内容，导致截图少了最下面的一部分。
写在最后
需求功能清单这个活，以前我觉得是"不得不做但又没有技术含量"的工作。用 TRAE Work 做了一遍之后，我的感受是：这种体力活就该交给工具来做，前端的时间应该花在写代码和调交互上，不是花在复制粘贴和调格式上。
25 分钟 vs 1 小时，数字上看是省了一半多。但真正的价值不只是省时间------是产出的完整性和可读性上了一个台阶。以前我写的需求清单只有自己看得懂，现在团队成员拿到就也能直接用。
最后沉淀的那个 Skill，才是我觉得最有价值的部分换个项目、换个产品，只要文件格式差不多，直接复用就行。