产品经理实战：基于TRAE AI IDE，三步重构高保真原型与复杂逻辑验证工作流

你是否也有这样的经历？

一个想法在脑子里已经很清楚了，但真正要落成 Demo，却要经历画原型、反复改稿、和研发来回拉扯，最后上线的方案，早就和最初的设想不太一样。

本文将分享一名非技术背景的 B 端产品经理，如何借助 TRAE，把“想法”直接翻译成可交互原型与可讨论方案：不用等研发、不用反复画图，也不需要精通代码，就能在需求迭代、0-1 项目验证、复杂逻辑对齐中，把效率提升数倍。

这不是一篇简单的工具介绍，而是一套已经在真实工作中反复验证过的实践方法，覆盖从需求验证、原型迭代，到逻辑跑通与文档对齐的全过程。它将告诉你，一个产品经理，如何借助 TRAE 把效率这件事做到极致。

为什么我要写这篇文章？

我是一名负责 B 端功能型产品的产品经理，日常处理的是复杂的业务逻辑和后台系统。在接触 TRAE 之前，我的工作路径是：画原型 -> 写文档 -> 等排期 -> 反复调整。

直到我开始尝试，把 TRAE 当成“工作伙伴”而不是“写代码的工具”。本文将围绕产品经理的 3 个核心工作场景展开：

1. 需求迭代的原型设计
2. 0-1 的项目原型 + 逻辑验证
3. 文档的编写与对齐

核心认知：TRAE 是「想法翻译器」

在深入场景前，我们需要重塑认知：TRAE 的本质是一个高效的“翻译器”。

它无法凭空理解模糊的意图，但只要你能清晰描述逻辑，它就能将想法精准地“翻译”成可交互、高保真的前端应用。这意味着：

• 解放双手：从繁琐的“画图”工作中解放，告别像素级的对齐和组件拖拽。
• 聚焦思考：精力投入到梳理产品逻辑、定义用户流程和构思交互细节上。
• 高保真交付：原型不再是静态线框图，而是动态的、高保真的 HTML 页面。

这个转变，是后续所有效率提升和能力飞跃的基础。

协作原则：小步快跑，增量迭代

与 TRAE 协作，最重要的原则是：小步快跑，拒绝一口气吃成胖子。

与其试图用一段冗长而复杂的指令生成完美系统，不如将目标拆解成一个个具体、明确的小步骤，通过持续的、增量式的迭代来逐步完善。这套方法论可以概括为“框架-组件-交互”三步走：

1. 先搭框架：让 TRAE 生成最基础的页面布局和结构。
2. 再填组件：在框架内逐步添加必要的 UI 组件，如按钮、输入框、列表等。
3. 后调交互：最后为这些组件注入生命，实现点击、跳转、数据加载等动态交互。

始终记住，每一次与 TRAE 的交互都应该只关注一个具体、明确的目标。这样的“小步快跑”，不仅能保证 TRAE 的理解准确率，也让你能始终掌控项目的进展和方向。

三大核心场景：用 TRAE 重构产品工作流

接下来，我将结合一个 B 端产品经理的日常，通过三个最典型的工作场景，展示 TRAE 是如何颠覆传统工作模式的。每一个场景都附实战案例和可直接复用的技巧。

场景一：需求迭代与原型设计

工作流对比：

• 过去 (Old School)
  • 痛苦画图：在 Axure/Figma 中反复拖拽，为了一个按钮的对齐纠结半天。产出的是低保真线框图，与最终效果差异巨大。
  • 反复拉扯：拿着线框图向老板、UI、研发解释，“这里以后是彩色的”、“这个按钮点击后会弹出一个框”… 沟通成本高，信息损耗严重。
  • 时间成本：2 人天起步。
• 现在 (TRAE Flow)
  • “嘴替”编程：一张截图、一个 Figma 链接，直接“喂”给 TRAE，即刻生成高保真 HTML 页面。
  • 光速定稿：任何调整，直接用自然语言“告诉”TRAE，半小时内就能看到最终效果，实现“会上决策、当场修改、即时生效”。
  • 时间成本：0.5 人天，效率提升至少4倍。

核心价值：效率提升4倍，这不仅节省了时间，更将产品经理从重复性劳动中解放出来，回归到创造性思考本身。

实战案例：给 TRAE 官网加个聊天机器人

TRAE 配置清单：

• 模型：gemini-3-pro-preview
• 智能体：Builder with MCP
• MCP：Playwright, Figma AI Bridge (可选)

需求背景：在 TRAE 的 Profile 页面右侧，增加一个主流的侧边 Agent 聊天面板。

第一步：还原现状，让 TRAE 看懂你的产品

要在一个现有产品上做迭代，首先得让 TRAE “看懂”当前的页面。这里有两种高效的方法：

1. 页面截图法 (截图 + Playwright MCP)

这是最直接的方式。将你要迭代的页面完整截图，然后用这样的提示词喂给 TRAE：

💡 提示词心得：
核心是告诉 TRAE 你的目的和约束。不需要长篇大论，但要包含关键信息。
“根据我给你的这张设计图，帮我1:1 还原一个前端 HTML 页面。这只是一个用于需求沟通的 Demo，不需要连接后端接口。 技术栈使用 React。”

2. 设计稿还原法 (Figma + AI Bridge)

借助 Builder.io 插件。它可以复制前端页面的布局，结合它在 Figma 上的插件，能够将前端还原到 Figma 中。

然后再粘贴 Figma 的素材地址，使用 Figma AI Bridge MCP 来还原这个前端页面。

提示词示例：
请你使用 figma ai bridge mcp，读取我的设计图 https:.... 来帮我1:1 还原一个前端的 html 页面。并且不需要接入后端，因为我的项目是一个仅前端用于需求同步的 demo 项目，页面上的数据，都采取前端写入的方式，不需要用到后端的接口获取。语言使用 react

第二步：还原效果检查

核心工具：Playwright MCP

在 TRAE 做完了初步的实现以后，多少是会跟我们的参考的网页有些差异。这时候就要用到 Playwright MCP 了。

核心目的：让 TRAE 能够打开目前已经写出来的网页，获取前端的展示信息，这样 TRAE 就能够对得上它的代码，以及最终的前端呈现。

进阶用途：你也可以让他打开我们参考的网页，对照参考网页的前端样式实现和样式规范，检查目前它实现的前端页面是否存在哪些地方是没有按照目标实现的。

检查时的提示词示例：
请你用 playwrightmcp 打开你目前实现的前端页面。以及我给你的这个参考网站 https:....；我希望你能够对照你目前的前端页面，与我的参考网站的前端样式。帮我检查还有哪一些模块没有做到 1:1 的还原。因为前面给你的设计图，其实就是来源于这个参考网站的。

在你检查的时候，请你特别注意以下的几个维度是否得到了还原：

• 字号大小的层级关系
• 容器之间的间距与对齐
• 颜色系统

第三步：细节微调，搞定“倔强”的AI

总有些细节，TRAE 可能会反复修改却依然错漏，甚至“嘴硬”说已经改好了。这通常意味着 TRAE 的默认解决路径遇到了障碍。此时，需要我们提供更精准的“导航”。

1、复制 Classname 精准定位

我们可以通过截图，以及复制前端的 classname 的形式，告诉 TRAE 到底哪一块是还做的不到位的，应该要怎么做。

操作技巧：
打开浏览器的检查（右键 -> 检查，或者 F12），通过元素选择器定位到目标元素，在右侧 DOM 树中双击选中目标的 classname 并复制。

提示词示例：
目前我观察到，前端的 {{classname}} 还没有按我的要求还原。也就是我给你发送的页面截图图 1（此处粘贴实现的图片）。我希望你根据图 2 的样式帮我做还原（此处粘贴期望样式的截图）。
你也可以使用 playwrightmcp 打开我的参考网站 https:... 中，查看 {{我参考网站对应组件 classname}} 的实现，并在我的项目中 1:1 的还原它。

2、当 TRAE「死鸭子嘴硬」时怎么办

如果还有一些细节，TRAE 无法还原并反复“嘴硬”说改好了

这时候我基本判断：可能 TRAE 自己习惯的判断或者实现的维度，并不能解决我的问题。分享4个终极手段，亲测有效：

• 细致表达：将你认为一直没有实现的地方，更细致地表达出来（运用 classname、截图、playwright 等）。或者详细地用自然语言表达现状 vs 期望，让 TRAE 帮你根据现状代码猜测原因。
• 指定维度：如果你自己知道大概是什么维度（比如 flex 布局、z-index 层级）可能能够修复这个问题，就让模型往这个维度上去思考。
• 更换模型：看看其他模型（如 GPT-5.2 或 GPT-5.1）对于这个场景下，是否它的习惯性解决方案能够覆盖这个问题。
• 重置上下文：新开对话，看看是否因为上下文过长导致模型存在了临时的「思维定式」。

完成前三步的关键总结：

1、提示词技巧

回顾我还原 TRAE Profile 页面的过程，大概扫一下就可以发现，我跟 TRAE 的交互提示词，主打一个自由随性。

重点其实还是这3点，记牢就能少踩坑：

• 有没有把需求表达清楚？
• 是否给足了 AI 定位问题的参考信息？
• 是否提供了目标实现的参考信息？

给出以上关键信息的手段，可以是文本描述，可以是截图，也可以是利用 Playwright MCP 让 TRAE 自己去做参照。

2、项目规范最佳实践

当项目达到基础可用状态之后，建议大家做2件事：

①编写启动脚本

让 AI 帮你写一个 sh 的启动脚本。这样方便我们后面需要再次启动这个项目时，直接将这个脚本拖拽到终端，回车执行即可启动。

建议加上几个细节：

• 固定端口：允许清空占用，再启动。防止端口冲突。
• 打印地址：启动后在终端打印访问地址，方便点击。

提示词示例：
请你帮我创建一个 sh 的 start 脚本，方便我每次启动项目都只需要在终端执行这个 sh 脚本。并且我希望这个脚本能够每次都固定端口启动，如果遇到端口被占用的情况，需要清理被占用的端口，再使用该端口启动，保证每次都能够固定端口。同时在启动成功后，需要在终端打印出我的访问地址。

②沉淀前端规范文档 (FRONTEND_SPEC.md)

让 TRAE 帮你总结一个前端规范的 md 文档。

后面继续迭代时，在需求前面带上这个文档，让 TRAE 遵守规范，能保证样式风格统一，布局更合理。

建议包含以下维度：

• 间距系统
• 颜色系统
• 字体层级与字号大小
• 网页布局框架

提示词示例：
请你根据当前的样式实现，帮我创建一份前端规范的 md 文档。这一份文档，在后面将会作为我的项目的设计规范使用。在规范里，我认为至少需要包含以下的模块：

• 项目前端页面的基础布局
• 字号大小系统
• 颜色系统
• 间距系统

第四步：需求落地，让原型“动”起来

当页面还原完毕，我们就可以开始真正的迭代了。还记得我们的需求吗？👉 在右侧增加一个侧边的 Agent 聊天面板。

由于做迭代基本是没有设计图参考的，考验的就是我们通过文本来表达交互的能力。

我的方法论：用“用户视角”来描述交互，表达清楚以下5点：

• 我们希望的交互，它从起始到结束，在什么位置？
• 通过什么操作？
• 点击后，会发生什么？
• 又在哪个位置出现？
• 会出现什么内容？

⚠️ 记得要携带上我们上面总结的那一份前端规范！

实战提示词示例：

现在我希望在我的页面的右侧区域，增加一个聊天的窗口。

1. 这个聊天的窗口，是由顶部导航栏右侧区域，claim anniversary 的容器左侧的一个 chat 的 icon 处激活的。
2. 激活聊天面板后，会对应的将右侧的 main 内容容器，往左自适应挤过去。
3. 而这个聊天面板，由 3 个部分组成：
   顶部是聊天窗口的标题
   中间是聊天消息的展示区，分为用户与 agent 的消息，并且不需要头像
   下方是用户发消息的输入框，以及发送按钮区
   在你帮我实现时，需要符合我的 FRONTEND_SPEC.md 规范。

在实现了基础交互后，我又想增加一些效果，比如打字机效果、知识库查询等。同样的，也是依赖上方提出的方法：由用户操作视角出发，描述清楚起始、操作、反馈、位置、内容。

完成效果：最终我们就能够得到一个如下视频所示的一个带前端交互的HTML的可交互式原型。

(视频加载失败，请刷新页面再试)

场景二：0-1 的项目原型与逻辑验证

如果说需求迭代是“术”，那么 0-1 的项目验证则更考验产品经理的“道”——将一个想法，快速落地为可验证的 MVP。

工作流对比：

• 过去 (Old School)
  • 接口猜谜：只能对着一堆接口文档干瞪眼，看着字段猜测后端逻辑。验证路径极短，中间过程完全是黑盒。
  • 逻辑盲区：遇到复杂算法、Agent 交互等，完全不知其所以然。与研发讨论时，因不懂实现细节，难以提出建设性意见，更无法有效把控项目风险。
• 现在 (TRAE Flow)
  • 白盒掌控：通过自然语言描述，让 TRAE 把完整逻辑跑通，结合其输出的 Mermaid 流程图，彻底看懂代码背后的业务流转。
  • 反向输出：你不再只是需求的提出者。现在，你可以直接构建一个逻辑合理、甚至代码可用的方案，“甩”给研发：“照着这个，合到主干代码里去。”

核心价值：这已经不是简单的效率提升，而是产品经理核心能力的飞跃——我们真正获得了定义和验证技术方案的能力。

实战案例：电商 Agent 的 0-1 搭建

TRAE 配置清单

• 模型：gemini-3-pro-preview
• 智能体：Builder with MCP
• MCP：Playwright

需求背景：做一个电商场景的 agent，目标是C端用户。它能够帮我们做基本的商品的搜索，以及让用户直接指定对应的商品。

核心思路与场景一完全一致：小步快跑，增量迭代。

第一步：搭建基础聊天页面

0-1项目启动提示词示例：
我的这个项目是一个对话式的电商 agent。并且是移动端尺寸的。所以请你以移动端iPhone12 的尺寸，帮我创建一个基础的 agent 的聊天页面。前端使用 react 的技术方案

这个聊天页面的结构是，顶部是对话的标题。中间是 agent 与用户的消息记录，并且不需要头像。底部是用户的输入框，以及发送按钮

现在请你帮我实现这个项目的基础页面结构

为了后续迭代方便，可以补充以下 2 个优化点：

1. 优化 classname
请你将我前端页面的 classname 做规范化处理，方便我以后能够直接通过前端页面的 classname 找到对应的代码，而不是用 react 生成的 classname。

2. 创建 start 脚本
请你帮我创建一个 sh 的 start 的脚本，并且固定端口启动，当目标端口被占用时，你可以清理掉被占用的端口进程。然后再进行启动。同时我希望这个脚本再启动后，能够在终端答打印出我项目的路径，方便我后续访问

到这一步，我们的第一阶段就做好了：一个基础的前端页面。

第二步：接入基础对话能力

这一步开始涉及后端逻辑。如果你对技术实现不熟，没关系，先让 TRAE 成为你的“技术顾问”，让他给你写一份实现文档。并要求在你确认之前，不许动任何代码。

“文档先行”提示词示例：
我现在打算在我的项目里实现真正的ai 对话。并且我使用的是豆包的模型。

我希望实现后，能够做大， 用户在输入框内输入文本，点击发送后，能够让豆包在思考后进行回复，就跟现在的很多 agent 产品一样，能够看到折叠的 thinking，以及最终的回复的文案。同时这个 think 默认可能是折叠的状态的。用户可以进行展开，但展开也只是在一定的高度下查看 thinking 的文本。

同时呢，我也希望在用户发送第二条消息后，ai 能够了解我的上下文，并且基于我的上下文，继续来给我进行回复。

请你根据我以上的需求，帮我写一份实现的 md文档，并且在得到我开始研发代码的确认消息前，不要修改我的任何代码文件

实际上，让 TRAE 帮你编写实现文档，能够后续让它实现的更准确。对于实现方案不确定的地方，我们都可以在不断的跟 TRAE 交互的过程中，逐步完善文档。

在 TRAE 完成后，同样使用 playwrightmcp 打开我的项目，并且模拟用户走完整个流程。

然后我们就得到了一个满足了前后端的基础项目实现了。

第三步：实现核心业务逻辑——商品搜索

再继续第三个子任务：为组件实现搜索商品。

思路相同，如果我们自己不清楚要如何实现，就让 TRAE 根据我们的需求，创建一个实现文档。

这里我就快速的直接通过需求进行提问实现了：
现在请你帮我在这个项目中，为这个 agent 实现在对话过程中，能够帮用户做商品搜索的这个能力。

要想实现这个能力，首先你需要帮我创建一个本地的数据库，存储商品的信息。其中需要至少包含商品 id，商品主图，商品标题，商品价格，商品详情描述的信息。商品图片你可以从 usplash 上随机获取可以访问的商品图片就可以了。

那我希望在用户与 agent 的对话交互中，能够识别用户当前的意图是否涉及到商品的搜索。如果涉及到商品搜索，请你调用商品搜索的这个 mcp（这个 mcp 也需要你根据上面要求你创建的数据库来实现），将用户的提问，转换成商品标题搜索的关键词，并通过接口搜索出商品。

在拿到商品的信息后，我要求 agent 需要给我返回一个可交互的商品卡片的消息起泡，并且支持分页，一页 4 个。最多 5 页也就是 20 个商品。

在商品卡片上需要呈现每一个商品的主图，标题，以及价格。同时每一个商品卡片的右上角我希望都有一个文本的追问按钮。

当用户点击了这个追问后，能够在用户的输入框上方有一个呈现了当前正在追问哪个商品的一个交互。

并且当用户在追问状态下发送消息时，在用户的消息气泡中，需要携带上被追问商品的 tag 的交互显示。

同时，我也希望你能够有另一个应对商品追问的 mcp。这个 mcp 在识别到用户的追问后，能够根据用户追问的商品 id，去数据库中查询出这个商品的详情描述信息，并且根据该商品的详情描述信息，给与用户文本描述。

以上的整个流程，为了方便我模拟，我希望所有的商品标题都携带着，风衣这个关键词。并且在你完成代码实现后，我希望你使用 playwrightmcp，以用户在搜索风衣，以及针对某个风衣做追问的场景。帮我完成一轮商品搜索，以及商品追问的交互与逻辑测试，确保你的实现是符合我的需求的

即便给出了以上详尽的指令，TRAE 的初版实现也可能存在问题。没关系，继续通过追问来修正。

我发现了几个问题，请你帮我做出修改

1. 我的项目的页面尺寸，需要严格按照移动端的尺寸。不能够因为消息气泡中内容的长短，而撑开了整个项目页面呈现。
2. 我希望在触发调用工具时，能够有像一般的 agent 产品一样的那种正在调用xx 工具的交互
3. 整体的后端的实现思路，应该是基于 ReAct 的核心理念，也就是会涉及到用户的一条消息，可能会触发多次 ai 的请求。第一次请求可能是ai 判断需要调用工具，而获取工具的结果，第二次请求就是 ai 结合着工具返回的结果，来进行回复。
4. 所以既然后端的实现思路基于 ReAct 的单任务多轮思考请求的思路，所以对应的前端的配套交互也需要帮我做出对应的调整与优化

最终成果：完成一个前后端完整的电商 Agent MVP，后续可以基于这个项目，做一些需求的逻辑验证，或者复杂逻辑的迭代等。

(视频加载失败，请刷新页面再试)

这个过程的价值在于，我们像架构师一样思考，将一个复杂的业务流程，拆解为一系列清晰的模块。而 TRAE，则将我们的思考变为现实。

场景三：文档的编写与对齐

产品经理不仅要创造，更要频繁同步与对齐。无论是与研发对齐方案，还是向老板汇报进展，清晰的文档和逻辑图都是必不可少的。

工作流对比：

• 过去 (Old School)
  • 结构化地狱：收集资料容易，整理成逻辑清晰的文档难。在 PPT 里画框架图、流程图，反复调整却总觉得逻辑不通。
  • 无效纠结：大量时间浪费在调整格式、对齐图形上，核心逻辑反而没时间打磨。
  • 时间成本：1 人天。
• 现在 (TRAE Flow)
  • 暴力输出草稿：想到什么写什么，甚至把参考资料一股脑丢进一个文档，逻辑混乱也无所谓。
  • 降维打击：将这堆“原料”丢给 TRAE，结合明确的整理方法论，让它瞬间完成结构化和可视化。
  • 时间成本：0.5 人天，效率提升2倍。

核心价值：效率提升 2 倍，告别 PPT 纺织工，回归思考者。

实战案例：用 TRAE 辅助编写项目文档

TRAE 配置清单

• 模型：gemini-3-pro-preview
• 智能体：Builder with MCP

1、用于项目文档与研发对齐

写完上面那个电商 Agent 的 MVP 后，我需要给研发和业务团队同步方案。我的草稿可能非常随意，我会让 TRAE 按照我的原则，帮我梳理成专业文档。

暴力写下你的草稿（逻辑混乱也没关系）：
我想要跟研发团队同步，以及业务团队同步我的这个电商的 agent 是用来干什么的

它其实是给 C 端用户用的，能够让用户在对话的情况下就能够完成下单。目前支持的场景就是有搜索商品

以后可能还会支持下单，做售后等的场景

所以这个后面除了要对接商品库以外，还要对接售后的接口

然后这个 agent 会自己意图识别用户想要干什么，然后再去调用不同的工具，来帮用解决问题
balabala（这里我就不继续写了）

让 TRAE 整理成专业文档：

请你根据我下方给你的我的草稿，以及我当前的项目的实现，帮我写一面方便我跟其他同事同步的一个 md 文档

在这个 md 文档里面， 我希望你整体以总分的结构进行编写，先通过总结让读者读懂我们的这个文档要表达什么内容。再分别展开每个模块。尽可能简单表达，小白就能够一眼看懂。

然后关于 ai 的实现方面，需要你输出一个mermaid 的框架图，与时序图，方便我与开发同步这里面的实现逻辑，以及未来可能需要去对接不同的数据库，或者 api 能力范围是什么

以下是我的文档草稿：

我想要跟研发团队同步，以及业务团队同步我的这个电商的 agent 是用来干什么的

它其实是给 C 端用户用的，能够让用户在对话的情况下就能够完成下单。目前支持的场景就是有搜索商品

以后可能还会支持下单，做售后等的场景

所以这个后面除了要对接商品库以外，还要对接售后的接口

然后这个 agent 会自己意图识别用户想要干什么，然后再去调用不同的工具，来帮用解决问题

TRAE 会将你的“意识流”草稿，重构成一份结构清晰、图文并茂的正式文档。

2、用于竞品分析与市场洞察

这种「随性打草稿」的方法，除了用在项目总结，在做竞品调研的时候也超级好用。

以前做调研，可能还要担心格式乱、信息杂。现在完全不需要束手束脚：

• 暴力粘贴：看到觉得有效的信息、文章片段、数据，直接一股脑贴到一个文档里。
• AI 整理：把这堆“杂乱信息”丢给 AI，让它帮你结构化整理，提取核心观点。
• 可视化输出：
  让 AI 输出一张 Mermaid 的框架图，逻辑结构一目了然。
  或者让 AI 给你一份可以用于 Nanobanana 的提示词，直接生成一张直观的图片，放在文档里逼格满满。

这种工作流，能确保你的所有精力都花在“收集高价值信息”这一核心环节上，而将所有“整理和排版”的脏活累活都外包给 AI。

写在最后：产品经理的 AI 生存法则

回顾全文，我们发现 TRAE 这类 AI IDE 带给产品经理的，不仅是效率工具，更是一套全新的工作范式。

为了让你能更好地消化和应用，我将全文的核心技巧总结如下：

核心认知

• TRAE 是「想法翻译器」：你的逻辑表达越清晰，TRAE 的还原度就越高。
• 拥抱“小步快跑”：从框架 -> 组件 -> 细节，增量迭代，永远比一口吃成胖子更稳、更快。
• 从“画图”到“说话”：工作产出从静态线框图，升级为高保真、可交互的 HTML。

实战技巧

• 页面还原双法器：
  截图法：直接截图 + Playwright MCP，简单粗暴
  设计稿法：Figma + AI Bridge，设计图直接变代码
• Playwright MCP 三妙用：检查实现效果、对比参考网站、模拟用户测试流程
• 细节微调四板斧：复制 classname 精准定位、细致表达需求、指定技术维度、更换模型/重置上下文

项目规范

• Start 脚本：固定端口启动，自动清理占用，终端打印访问地址
• FRONTEND_SPEC.md：沉淀前端规范，让后续迭代有章可循
• 用户视角描述法：从起始→操作→反馈→位置→内容，完整描述交互流程

进阶应用

• 0-1 项目搭建：自由度更高，但更需要规范约束
• 实现文档先行：不确定实现方案时，先让 AI 写实现文档
• 增量迭代思维：基础功能→交互优化→高级功能，循序渐进

Prompt 心得

• 自由随性：没有严格的表达规范，重点是把需求说清楚
• 信息要给足：现状、期望、参考信息，一个都不能少
• 多模态表达：文字描述 + 截图 + 网页参考，让 TRAE 理解更精准

最后想说的是， TRAE 让我们真正拥有了将想法直接落地的能力。它让我们能够把更多的时间花在思考产品逻辑和用户体验上，而不是纠结于具体的代码实现。

希望我的这些经验分享，能够帮助大家在日常工作中更好地使用 TRAE，提升工作效率。如果你也有类似的使用心得，欢迎在 云栈社区 交流讨论！

附录1：TRAE & MCP 配置指南

为了方便你快速上手，我把需要用到的配置都整理在这里了，直接复制粘贴就行。

1. Playwright 配置

相关链接

• GitHub 仓库：microsoft/playwright-mcp
• Chrome 插件下载：Releases 页面

步骤一：配置 MCP

{
  "mcpServers": {
    "Playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--extension"
      ]
    }
  }
}

步骤二：安装浏览器插件

• 从上面的 Releases 页面 下载最新版本的插件压缩包。
• 打开 Chrome 的扩展程序管理页面 (chrome://extensions/)。
• 直接将下载的压缩包拖拽到页面中，即可自动安装。
• 记得手动将插件固定到工具栏，方便查看连接状态。

如何使用？

在对话中，明确提出让 AI 使用 playwrightmcp 即可触发。

示例：“请你使用 playwrightmcp 打开我的项目地址 or 网页...”

2. Figma AI Bridge 配置

这个稍微复杂点，需要填入你的 Figma Token。

{
  "mcpServers": {
    "Figma AI Bridge": {
      "command": "npx",
      "args": [
        "-y",
        "figma-developer-mcp",
        "--stdio"
      ],
      "env": {
        "FIGMA_API_KEY": "替换为你的 key"
      },
      "disabled": true
    }
  }
}

如何获取 Figma Key？

登录 Figma 网页版 -> 点击头像 -> Settings -> Personal access tokens -> Generate new token。

如何使用？

在对话中，明确提出让 AI 使用 figma ai bridge mcp 即可触发。

示例：“请你使用 figma ai bridge mcp 来查看我的设计图 {{此处填入你的设计图 url}}...并1:1 还原为前端的 html 页面”

如何获取设计图 URL？

选中你想还原的容器（整个页面选最外层，单个组件选组件容器），右键 -> Copy link -> Copy link to selection。

配套神器：Builder.io 插件 (网页转设计图)

在 Figma 的 Actions (Cmd/Ctrl + P) 中搜索 Builder.io 并运行。
打开插件后，在 Import 菜单处选择 Paste from Chrome。

贴入使用它配套 Chrome 插件复制的前端代码 JSON，就能在 Figma 中拿到对应的设计图了。

3. 其他建议配置

为了体验更丝滑，建议检查以下设置：

对话流配置：
自动运行 MCP：开启 (省得每次都要点确认)
令运行方式：沙箱运行 (安全第一)

个人白名单范围 (参考)：
python, cd, npm, chmod (根据项目需要灵活调整)

附录2 ：常见资源占位 — AI 从哪里获取

本附录面向参与 AI Coding 的各位，说明常见占位资源（图标、图片）应从何处取得，以及如何在提示词中明确要求，避免图裂或缺图标。

1. 图标 (Icon) 占位

建议做法：在提示词中直接指定使用某一套图标库，让 AI 用现成组件而非自绘或占位文字。

可选来源（任选其一即可，在提示词里提一嘴即可）：

• React 生态常用：react-icons（如 react-icons/fa、react-icons/hi 等）
• 组件库自带：若项目已用 Ant Design、Material-UI、Chakra UI 等，可写明「使用 Ant Design 的 Icon 组件」「使用 MUI 的 Icons」等

提示词示例：

• 「页面里的图标请用 react-icons，从里面选合适的图标即可。」
• 「我们项目用 Ant Design，图标统一用 Ant Design 的 Icon 组件。」

只要在需求或提示词中明确写出「用 xx 的 icon 库」，AI 就会从该库选图标，避免留空白或乱码占位。

2. 图片 (Image) 占位

建议做法：占位图片从 Unsplash 获取与内容相关的免费可商用图片；且必须在采用前验证每个图片链接可访问，避免上线后图裂。

• 来源：Unsplash 提供可免费使用的图片，适合原型与占位。
• 提示词中建议写明：
  • 「占位图片从 Unsplash 上获取与 [主题/关键词] 相关的公共图片。」
  • 「使用 Unsplash 的图片作为占位图，并在代码或脚本中验证每个图片 URL 可访问；若不可访问则替换或跳过，防止图裂。」
• 重要：务必让 AI 逐个验证 Unsplash 的图片链接是否可访问（例如用 HEAD/GET 请求或简单的加载测试），再写进页面或资源列表。这样可以避免拿回来的链接已失效导致前后端出现图裂。

小结：图标指定 icon 库；图片指定 Unsplash + 验证可访问性，即可在 AI Coding 流程中稳定使用这两类占位资源。