TRAE 工作流：产品需求到前端原型

TRAE 工作流：产品需求到前端原型

如果手里已经有一版产品需求，想直接往前推到可预览的前端原型，TRAE 这类 AI IDE 更适合做中间那一段衔接工作。官网首页把它的能力描述成“Understand. Execute. Deliver.”，同时又写了支持上传图片澄清需求、支持 Builder 自动拆任务、支持从代码仓库和文档里理解上下文。把这些能力放到一个实际流程里看，它比较适合接在“需求已经有了，但还没变成可运行页面”的阶段。这个阶段既需要读材料，也需要落代码，还要一边改一边看结果，所以只用聊天窗口或者只用图形原型工具，往往都不太够。

第一步先整理输入，不要一进编辑器就直接说“帮我做个页面”。产品需求到原型这类任务，真正要交给 TRAE 的材料通常有四类：需求说明、参考页面截图、设计约束，以及当前仓库里已经存在的组件或样式系统。官网写了它支持图片、代码仓库、搜索和文档，这里正好把这些入口接起来。你可以把 PRD 的核心段落贴进去，再配两三张参考图，同时把站内已有组件目录和设计 token 也带上。材料准备得越集中，后面每一轮来回修改就越少。

第二步再让 Builder 去拆需求。TRAE 官网对 Builder 的描述是会自动拆解并执行多步骤任务，同时保留预览和控制，这个能力放在原型阶段很合适，因为一页页面往往本来就有多步。你可以先让它把需求拆成页面结构、信息区块、交互动作和依赖数据，再确认一次顺序是否合理。这样做是为了防止它一开始就冲进代码细节，最后区块顺序、组件关系和数据来源都没先说清。

接下来才轮到 Context 和 Rules 真正发挥作用。Context 这时候要承担的是“让 TRAE 知道手里已经有什么”，所以更适合把项目里的现成组件、接口约束和样式规则一并给进去。Rules 则要承担“让 TRAE 别写成另一套东西”，内容可以直接落在命名方式、布局习惯、不要新造哪些基础组件、哪些交互只能复用现有实现。很多页面原型到最后会返工，原因常常是它新写了一套和原项目不兼容的结构。前面把这两层写清楚，后面就不会一直绕回去改基础层。

页面开始生成以后，比较省时间的做法可以按“骨架、状态、细节”的顺序往下推。先看页面区块和主次关系，再看按钮、弹层、校验和空状态，最后再补拷贝、微调留白和图标。TRAE 的优势在于它待在 IDE 里，可以边看代码边继续追问，也可以继续补充图片和说明。这个过程更像在带一个会写代码的协作者，不需要把一句话丢进去就等最终稿。

如果项目里已经开始出现一些重复工作，例如每次都要把 PRD 改写成 React 页面骨架，或者每次都要按固定的设计规范先搭一版表单页，这时再考虑单独做一个 @Agent 会更合适。它可以专门接产品文档和截图，再按固定的规则吐出页面结构和组件拆分建议。这样安排的好处，是让 Builder 继续负责较大的多步任务，把那部分重复出现的工作交给一个更窄的 agent 去做，后面每次起新页面时也更快。

这条工作流真正节省时间的地方，不在于让 TRAE 一口气写完整个页面，而在于它把需求理解、原型拆解、代码生成和继续修改放在了同一个编辑器现场里。你前面已经给过的上下文、截图和规则不会每次重来，页面一旦跑起来，后面继续迭代也都还在同一处。对产品需求到前端原型这类任务，这种连续性本身就很重要。