工学云
150.99MB · 2026-02-11
你是否也有这样的经历：
一个想法在脑子里已经很清楚了，但真正要落成 Demo，却要经历画原型、反复改稿、和研发来回拉扯，最后上线的方案，早就和最初的设想不太一样。
本文将分享一名非技术背景的 B 端产品经理，如何借助 TRAE，把“想法”直接翻译成可交互原型与可讨论方案： 不用等研发、不用反复画图，也不需要精通代码，就能在需求迭代、0-1 项目验证、复杂逻辑对齐中，把效率提升数倍。
这不是一篇简单的工具介绍，而是一套已经在真实工作中反复验证过的实践方法，覆盖从需求验证、原型迭代，到逻辑跑通与文档对齐的全过程。它将告诉你，一个产品经理，如何借助 TRAE 把效率这件事做到极致。
我是一名负责 B 端功能型产品的产品经理，日常处理的是复杂的业务逻辑和后台系统。在接触 TRAE 之前，我的工作路径是：画原型 -> 写文档 -> 等排期 -> 反复调整。
直到我开始尝试，把 TRAE 当成“工作伙伴”而不是“写代码的工具”。本文将围绕产品经理的 3 个核心工作场景展开：
需求迭代的原型设计
0-1 的项目原型 + 逻辑验证
文档的编写与对齐
在深入场景前，我们需要重塑认知：TRAE 的本质是一个高效的“翻译器”。
它无法凭空理解模糊的意图，但只要你能清晰描述逻辑，它就能将想法精准地“翻译”成可交互、高保真的前端应用。这意味着：
解放双手： 从繁琐的“画图”工作中解放，告别像素级的对齐和组件拖拽。
聚焦思考： 精力投入到梳理产品逻辑、定义用户流程和构思交互细节上。
高保真交付： 原型不再是静态线框图，而是动态的、高保真的 HTML 页面 。
这个转变，是后续所有效率提升和能力飞跃的基础。
与 TRAE 协作，最重要的原则是：小步快跑，拒绝一口气吃成胖子。
与其试图用一段冗长而复杂的指令生成完美系统，不如将目标拆解成一个个具体、明确的小步骤，通过持续的、增量式的迭代来逐步完善。这套方法论可以概括为“框架-组件-交互”三步走：
先搭框架： 让 TARE 生成最基础的页面布局和结构。
再填组件： 在框架内逐步添加必要的 UI 组件，如按钮、输入框、列表等。
后调交互： 最后为这些组件注入生命，实现点击、跳转、数据加载等动态交互。
始终记住，每一次与 TRAE 的交互都应该只关注一个具体、明确的目标。这样的“小步快跑”，不仅能保证 TRAE 的理解准确率，也让你能始终掌控项目的进展和方向。
接下来，我将结合一个B端产品经理的日常，通过三个最典型的工作场景，展示 TRAE 是如何颠覆传统工作模式的。每一个场景都附实战案例和可直接复用的技巧，建议收藏备用！
工作流对比：
过去 (Old School)
痛苦画图： 在 Axure/Figma 中反复拖拽，为了一个按钮的对齐纠结半天。产出的是低保真线框图，与最终效果差异巨大。
反复拉扯： 拿着线框图向老板、UI、研发解释，“这里以后是彩色的”、“这个按钮点击后会弹出一个框”… 沟通成本高，信息损耗严重。
时间成本： 2 人天起步。
现在 (TRAE Flow)
“嘴替”编程： 一张截图、一个 Figma 链接，直接“喂”给 TRAE，即刻生成高保真 HTML 页面。
光速定稿： 任何调整，直接用自然语言“告诉”TRAE，半小时内就能看到最终效果，实现“会上决策、当场修改、即时生效”。
时间成本： 0.5 人天，效率提升至少 4 倍。
核心价值：效率提升4 倍，这不仅节省了时间，更将产品经理从重复性劳动中解放出来，回归到创造性思考本身。
TRAE 配置清单：
模型： gemini-3-pro-preview
智能体： Builder with MCP
MCP： Playwright, Figma AI Bridge (可选)
(MCP 配置方式见文末附录)
需求背景： 在 TRAE 的 Profile 页面右侧，增加一个主流的侧边 Agent 聊天面板。
要在一个现有产品上做迭代，首先得让 TRAE “看懂”当前的页面。这里有两种高效的方法：
1. 页面截图法 (截图 + Playwright MCP)
这是最直接的方式。将你要迭代的页面完整截图，然后用这样的提示词喂给 TRAE：
提示词心得：
2. 设计稿还原法 (Figma + AI Bridge)
借助 Builder.io 插件。 它可以复制前端页面的布局，结合它在 Figma 上的插件，能够将前端还原到 Figma 中。
然后再粘贴 Figma 的素材地址，使用 Figma AI Bridge MCP 来还原这个前端页面。
提示词示例：
核心工具：Playwright MCP
在 TRAE 做完了初步的实现以后，多少是会跟我们的参考的网页有些差异。这时候就要用到 Playwright MCP 了。
核心目的： 让 TRAE 能够打开目前已经写出来的网页，获取前端的展示信息，这样 TRAE 就能够对得上它的代码，以及最终的前端呈现。
进阶用途： 你也可以让他打开我们参考的网页，对照参考网页的前端样式实现和样式规范，检查目前它实现的前端页面是否存在哪些地方是没有按照目标实现的。
检查时的提示词示例：
总有些细节，TRAE 可能会反复修改却依然错漏，甚至“嘴硬”说已经改好了。这通常意味着 TRAE 的默认解决路径遇到了障碍。此时，需要我们提供更精准的“导航”。
1、复制 Classname 精准定位
我们可以通过截图，以及复制前端的 classname 的形式，告诉 TRAE 到底哪一块是还做的不到位的，应该要怎么做。
操作技巧：
提示词示例：
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 的启动脚本。这样方便我们后面需要再次启动这个项目时，直接将这个脚本拖拽到终端，回车执行即可启动。
建议加上几个细节：
固定端口： 允许清空占用，再启动。防止端口冲突。
打印地址： 启动后在终端打印访问地址，方便点击。
提示词示例：
②沉淀前端规范文档 (FRONTEND_SPEC.md)
让 TRAE 帮你总结一个前端规范的 md 文档。
后面继续迭代时，在需求前面带上这个文档，让 TRAE 遵守规范，能保证样式风格统一，布局更合理。
建议包含以下维度：
间距系统
颜色系统
字体层级与字号大小
网页布局框架
提示词示例：
当页面还原完毕，我们就可以开始真正的迭代了。还记得我们的需求吗？ 在右侧增加一个侧边的 Agent 聊天面板。
由于做迭代基本是没有设计图参考的，考验的就是我们通过文本来表达交互的能力。
我的方法论：用“用户视角”来描述交互，表达清楚以下5点：
我们希望的交互，它从起始到结束，在什么位置？
通过什么操作？
点击后，会发生什么？
又在哪个位置出现？
会出现什么内容？
️ 记得要携带上我们上面总结的那一份前端规范！
实战提示词示例：
现在我希望在我的页面的右侧区域，增加一个聊天的窗口。
在实现了基础交互后，我又想增加一些效果，比如打字机效果、知识库查询等。同样的，也是依赖上方提出的方法：由用户操作视角出发，描述清楚起始、操作、反馈、位置、内容。
完成效果：最终我们就能够得到一个如下视频所示的一个带前端交互的HTML的可交互式原型。
如果说需求迭代是“术”，那么 0-1 的项目验证则更考验产品经理的“道”——将一个想法，快速落地为可验证的 MVP。
工作流对比：
过去 (Old School)
接口猜谜： 只能对着一堆接口文档干瞪眼，看着字段猜测后端逻辑。验证路径极短，中间过程完全是黑盒。
逻辑盲区： 遇到复杂算法、Agent 交互等，完全不知其所以然。与研发讨论时，因不懂实现细节，难以提出建设性意见，更无法有效把控项目风险。
现在 (TRAE Flow)
白盒掌控： 通过自然语言描述，让 TRAE 把完整逻辑跑通，结合其输出的 Mermaid 流程图，彻底看懂代码背后的业务流转。
反向输出： 你不再只是需求的提出者。现在，你可以直接构建一个逻辑合理、甚至代码可用的方案，“甩”给研发：“照着这个，合到主干代码里去。”
核心价值：这已经不是简单的效率提升，而是产品经理核心能力的飞跃——我们真正获得了定义和验证技术方案的能力。
需求背景： 做一个电商场景的 agent，目标是C端用户。它能够帮我们做基本的商品的搜索，以及让用户直接指定对应的商品。
核心思路与场景一完全一致：小步快跑，增量迭代。
第一步：搭建基础聊天页面
0-1项目启动提示词示例：
为了后续迭代方便，可以补充以下 2 个优化点：
1. 优化 classname
2. 创建 start 脚本
到这一步，我们的第一阶段就做好了：一个基础的前端页面。
这一步开始涉及后端逻辑。如果你对技术实现不熟，没关系，先让 TRAE 成为你的“技术顾问”，让他给你写一份实现文档。并要求在你确认之前，不许动任何代码。
“文档先行”提示词示例：
我现在打算在我的项目里实现真正的ai 对话。并且我使用的是豆包的模型。
实际上，让 TRAE 帮你编写实现文档，能够后续让它实现的更准确。对于实现方案不确定的地方，我们都可以在不断的跟 TRAE 交互的过程中，逐步完善文档。
在 TRAE 完成后，同样使用 playwrightmcp 打开我的项目，并且模拟用户走完整个流程。
然后我们就得到了一个满足了前后端的基础项目实现了。
再继续第三个子任务：为组件实现搜索商品。
思路相同，如果我们自己不清楚要如何实现，就让 TRAE 根据我们的需求，创建一个实现文档。
这里我就快速的直接通过需求进行提问实现了：
即便给出了以上详尽的指令，TRAE 的初版实现也可能存在问题。没关系，继续通过追问来修正。
最终成果：完成一个前后端完整的电商 Agent MVP，后续可以基于这个项目，做一些需求的逻辑验证，或者复杂逻辑的迭代等。
这个过程的价值在于，它让我们像架构师一样思考，将一个复杂的业务流程，拆解为一系列清晰的模块。而 TRAE，则将我们的思考变为现实。
产品经理不仅要创造，更要频繁同步与对齐。无论是与研发对齐方案，还是向老板汇报进展，清晰的文档和逻辑图都是必不可少的。
工作流对比：
过去 (Old School)
结构化地狱： 收集资料容易，整理成逻辑清晰的文档难。在 PPT 里画框架图、流程图，反复调整却总觉得逻辑不通。
无效纠结： 大量时间浪费在调整格式、对齐图形上，核心逻辑反而没时间打磨。
时间成本： 1 人天。
现在 (TRAE Flow)
暴力输出草稿： 想到什么写什么，甚至把参考资料一股脑丢进一个文档，逻辑混乱也无所谓。
降维打击： 将这堆“原料”丢给 TRAE，结合明确的整理方法论，让它瞬间完成结构化和可视化。
时间成本： 0.5 人天，效率提升 2 倍。
核心价值：效率提升 2 倍，告别 PPT 纺织工，回归思考者。
TRAE 配置清单
模型： gemini-3-pro-preview
智能体： Builder with MCP
写完上面那个电商 Agent 的 MVP 后，我需要给研发和业务团队同步方案。我的草稿可能非常随意，我会让 TRAE 按照我的原则，帮我梳理成专业文档。
暴力写下你的草稿（逻辑混乱也没关系）：
让 TRAE 整理成专业文档：
TRAE 会将你的“意识流”草稿，重构成一份结构清晰、图文并茂的正式文档。
这种「随性打草稿」的方法，除了用在项目总结，在做竞品调研的时候也超级好用。
以前做调研，可能还要担心格式乱、信息杂。现在完全不需要束手束脚：
暴力粘贴： 看到觉得有效的信息、文章片段、数据，直接一股脑贴到一个文档里。
AI 整理： 把这堆“杂乱信息”丢给 AI，让它帮你结构化整理，提取核心观点。
可视化输出：
让 AI 输出一张 Mermaid 的框架图，逻辑结构一目了然。
或者让 AI 给你一份可以用于 Nanobanana 的提示词，直接生成一张直观的图片，放在文档里毕格满满。
这种工作流，能确保你的所有精力都花在“收集高价值信息”这一核心环节上，而将所有“整理和排版”的脏活累活都外包给 AI。
回顾全文，我们发现 TRAE 这类 AI IDE 带给产品经理的，不仅是效率工具，更是一套全新的工作范式。
为了让你能更好地消化和应用，我将全文的核心技巧总结如下：
TRAE 是「想法翻译器」：你的逻辑表达越清晰，TRAE 的还原度就越高。
拥抱“小步快跑”： 从框架 -> 组件 -> 细节，增量迭代，永远比一口吃成胖子更稳、更快。
从“画图”到“说话”： 工作产出从静态线框图，升级为高保真、可交互的 HTML。
页面还原双法器：
截图法： 直接截图 + Playwright MCP，简单粗暴
设计稿法： Figma + AI Bridge，设计图直接变代码
Playwright MCP 三妙用： 检查实现效果、对比参考网站、模拟用户测试流程
细节微调四板斧： 复制 classname 精准定位、细致表达需求、指定技术维度、更换模型/重置上下文
Start 脚本： 固定端口启动，自动清理占用，终端打印访问地址
FRONTEND_SPEC.md： 沉淀前端规范，让后续迭代有章可循
用户视角描述法： 从起始→操作→反馈→位置→内容，完整描述交互流程
0-1 项目搭建： 自由度更高，但更需要规范约束
实现文档先行： 不确定实现方案时，先让 AI 写实现文档
增量迭代思维： 基础功能→交互优化→高级功能，循序渐进
自由随性： 没有严格的表达规范，重点是把需求说清楚
信息要给足： 现状、期望、参考信息，一个都不能少
多模态表达： 文字描述 + 截图 + 网页参考，让 TRAE 理解更精准
最后想说的是， TRAE 让我们真正拥有了将想法直接落地的能力。它让我们能够把更多的时间花在思考产品逻辑和用户体验上，而不是纠结于具体的代码实现。
希望我的这些经验分享，能够帮助大家在日常工作中更好地使用 TRAE，提升工作效率。如果你也有类似的使用心得，欢迎在评论区交流讨论！
为了方便你快速上手，我把需要用到的配置都整理在这里了，直接复制粘贴就行。
相关链接
GitHub 仓库： microsoft/playwright-mcp
Chrome 插件下载： [Releases 页面](github.com/microsoft/p…
{
"mcpServers": {
"Playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest",
"--extension"
]
}
}
}
从上面的 Releases 页面 下载最新版本的插件压缩包。
打开 Chrome 的扩展程序管理页面 (chrome://extensions/)。
直接将下载的压缩包拖拽到页面中，即可自动安装。
记得手动将插件固定到工具栏，方便查看连接状态。
如何使用？
示例：“请你使用 playwrightmcp 打开我的项目地址 or 网页...”
这个稍微复杂点，需要填入你的 Figma Token。
{
"mcpServers": {
"Figma AI Bridge": {
"command": "npx",
"args": [
"-y",
"figma-developer-mcp",
"--stdio"
],
"env": {
"FIGMA_API_KEY": "替换为你的 key"
},
"disabled": true
}
}
}
示例： “请你使用 figma ai bridge mcp 来查看我的设计图 {{此处填入你的设计图 url}}...并1:1 还原为前端的 html 页面”
选中你想还原的容器（整个页面选最外层，单个组件选组件容器），右键 -> Copy link -> Copy link to selection。
在 Figma 的 Actions (Cmd/Ctrl + P) 中搜索 Builder.io 并运行。
打开插件后，在 Import 菜单处选择 Paste from Chrome。
为了体验更丝滑，建议检查以下设置：
对话流配置：
自动运行 MCP： 开启 (省得每次都要点确认)
令运行方式： 沙箱运行 (安全第一)
个人白名单范围 (参考)：
python, cd,npm, chmod (根据项目需要灵活调整)
本附录面向参与 AI Coding 的各位，说明常见占位资源（图标、图片）应从何处取得，以及如何在提示词中明确要求，避免图裂或缺图标。
建议做法：在提示词中直接指定使用某一套图标库，让 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 就会从该库选图标，避免留空白或乱码占位。
建议做法：占位图片从 Unsplash 获取与内容相关的免费可商用图片；且必须在采用前验证每个图片链接可访问，避免上线后图裂。
提示词中建议写明：
「占位图片从 Unsplash 上获取与 [主题/关键词] 相关的公共图片。」
「使用 Unsplash 的图片作为占位图，并在代码或脚本中验证每个图片 URL 可访问；若不可访问则替换或跳过，防止图裂。」
重要： 务必让 AI 逐个验证 Unsplash 的图片链接是否可访问（例如用 HEAD/GET 请求或简单的加载测试），再写进页面或资源列表。这样可以避免拿回来的链接已失效导致前后端出现图裂。
小结： 图标指定 icon 库；图片指定 Unsplash + 验证可访问性，即可在 AI Coding 流程中稳定使用这两类占位资源。
