把时间锚定在 2026-03-28 UTC，AI-China 里一个很值得盯住的工作流，已经不再只是笼统的“AI 编程”，而是设计稿进入前端代码库之前那段更慢、也更容易耗损团队精力的交接过程。

真正消耗团队时间的部分，不在第一版 JSX 或 HTML 能否快速生成，而在交接链路是否反复断裂：打开设计稿、复制链接、切回 IDE、重新解释页面意图、生成代码、预览、发现间距或层级问题、再回到设计工具、再执行一轮。百度当前这组 Comate 材料，所指向的正是这条循环的闭合方式。[1][2][3][4]

这件事的重要性在于，收拢这条循环，比再增加一个代码补全面板更有持续价值。预览、元素选取、智能体规划、规则与工具访问如果都落在同一个工作台里，产品争夺的就不再是零散 prompt，而是整个前端交接动作本身。

图片说明：题图采用 Wikimedia Commons 上的百度北京 ZPark 园区实景照片。这里使用真实摄影，把讨论放回一个已经落地的软件交付工作台，并让论述始终停留在可验证的产品现实里。[5]

这个用例为何成本高：设计交接真正流失的是上下文

百度在 2025 年 9 月关于 Figma2Code 推理升级的文章，把这个问题讲得很直白。旧流程里，开发者需要在 IDE 里写代码、再切回 Figma 看设计、再回来调整；文本和图片素材转成可用前端结果时，也会带来额外摩擦。[2]

顺着这层表述看，问题焦点就从“模型能不能生成页面”转到了团队真正感受到的那件事上：当细节不断变化时，交接过程能不能保持连贯。

对前端工程师来说，最脆弱的部分通常出现在第一轮成型之后的第二轮、第三轮修正。工程师要核一小块区域，重做某一段结构，保留周边逻辑，还要让最新设计意图继续贴在修改动作上。如果工具留不住这一层局部上下文，交接就会重新退回截图、链接和口头解释。

百度在 Comate 里真正推出了什么

F2C 用户手册把百度想让用户采用的路径写得很具体。在 Comate AI IDE 里，推荐方式是先在内置预览面板打开设计稿，点击 Figma 图标，再把整张设计稿或局部区域送进对话，由 Figma2Code 智能体处理。[1] 同一份手册还写到，这项能力既可以从 Figma 设计稿生成前端代码，也支持 URL、本地图片与截图输入，输出目标覆盖 HTML、React 和 Vue。[1]

这已经不再是一次性“帮我画个页面”的小功能，而是一条工作台化主张。源设计、预览界面、局部选区、对话与生成结果，都被要求留在同一个编辑环境里。

百度在 2025 年 7 月关于 Comate AI IDE 的发布文章，又把这层方向往产品侧推进了一步。文中把 Comate AI IDE 描述为国内首个多模态、多智能体协同 AI IDE，强调它支持导入原 IDE 配置与 .vsix 插件，并将其定义为工程师专用的 AI 原生开发环境。[3] 文中还有一项披露，说开发者使用 Comate AI IDE 后，日新增代码里可由 AI 生成的部分达到 43%。这个数字属于厂商自报，不宜直接当成独立验证结论，但它把产品野心说得很清楚。[3]

接着看更新日志，围绕这条工作流的外围控制层也在补齐。百度在 2025 年的插件更新里加入了 Figma 设计稿生成前端代码效果优化、AI IDE 内精选 MCP Server 列表、对既有 Cursor Rules 配置的兼容、开放模式下 Claude 与 Gemini 的模型切换，以及后续跨工作区的全局 MCP 配置。[4] 这些细节之所以重要，是因为设计交接出现问题时，驱动因素常落在流程层：规则、工具、预览与团队约束没有被同时纳入。当规则、MCP、预览和模型切换都贴在 F2C 流程边上，这条交接链路才更接近一条可重复使用的团队路径。

为什么这条路径更容易形成黏性

顺着这些材料继续展开，可以得到一个判断：百度真正试图维持住的产品边界，落在 IDE 这一层工作台。[1][2][3][4]

一个只输出标记代码的插件，仍会把大量协调工作留在工具外。IDE 内部闭环的差异在于，开发者可以把设计预览持续挂载，框选组件，对局部区域重生成，叠加本地规则，再通过 MCP 调用工具，整个过程都留在同一个 workspace。产品争夺的焦点，由一次演示效果，转向每天反复发生的交接动作。

这也是更关键的商业落点。前端交接发生频率高，痛点细碎，覆盖的是大量普通工程师。能够持续压低这些细碎断点的产品，更容易沉淀为团队习惯。

迁移成本这一层，又把这个判断进一步坐实。百度发布文章强调的是把原 IDE 配置与 .vsix 插件带入 Comate AI IDE，并通过兼容路径承接既有工作习惯。[3] 当迁移摩擦下降、工作流连贯度上升，产品分发开始发生在工作台层，并延伸到模型调用层之上。

这件事的边界

公开证据目前仍以厂商材料为主：手册、发布说明、更新日志。这足以说明产品方向，还不足以单独证明跨团队、跨项目的长期效率收益。

如果下面三件事一起发生，这篇文章的判断就要收紧：

到了那一步，Comate 依然会是有用助手，但还谈不上真正的交接工作台。

接下来该看什么

下一个产品周期里，有三条信号最值得继续盯。

第一，看百度是否继续强化局部重生成，并同步提升首轮页面代码生成之外的修正能力。[1][2] 设计交接最具黏性的价值，主要落在第二轮修改这一高频环节。

第二，看 AI IDE 周边控制层会不会继续加深，尤其是 MCP、规则兼容与和预览绑定的调试能力。[3][4] 真正把 demo 变成流程的，正是这些配套层。

第三，看百度会不会继续压低从既有 IDE 习惯迁移过来的摩擦。[3] 工程师如果能带着配置、插件和规则一起迁移，工作台才更有机会取代碎片化的标签页往返。

结论

百度 Comate 的 Figma-to-code 叙事，放在工作流层面去看，比放在生成能力层面去看更有意思。

真正具备持续价值的，是百度正试图把整条交接循环，从预览、元素选取到智能体执行、规则与工具访问，都收进同一个 AI IDE。只要这条闭环稳定下来，Comate 提供的就不只是编码辅助，而是前端工程高频协调动作的新默认工作台。

来源

  1. 百度智能云 COMATE 文档，《F2C 用户手册》（Comate AI IDE 推荐路径、预览面板、Figma 图标、局部选取，以及 HTML/React/Vue 输出目标）。
  2. 百度智能云文章，《Figma2Code 推理升级》（旧流程里 IDE 与 Figma 之间的反复切换，以及预览与元素选取层面的改进）。
  3. 百度智能云文章，《Comate AI IDE发布：首个多模态、多智能体协同AI IDE》（2025 年 6 月发布语境、AI 原生开发环境、.vsix 导入，以及厂商自报的 43% 日新增代码占比）。
  4. 百度智能云 COMATE 文档，《VS端插件更新日志》（Figma-to-code 效果优化、精选 MCP Server 列表、Cursor Rules 兼容、模型切换与全局 MCP 支持）。
  5. Wikimedia Commons，《Baidu Technology Park at ZPark Phase II (20220502113543).jpg》（题图照片来源页）。