出稿慢、还原差？Ardot × CodeBuddy 如何提速不走样
打破"出稿周期长、还原偏差大"的困局
设计师完成一套多页面方案以后，团队离真实体验仍有一段距离。前端需要重新理解设计稿，逐页写出界面，再补全页面跳转和状态变化。页面完成实现后，设计师才能开始走查，发现偏差以后需要反复沟通、修改。
按以往的经验，这种依靠开发后走查的传统流程，存在两个明显的卡点：
场景易遗漏，出稿周期长
空状态、Loading 和各种 Hover 状态虽然是边角场景，但在真实页面上却一个都躲不开。为了补齐这些边边角角的状态，设计师在设计初期要耗费大量精力沟通补齐，容易挤压打磨核心页面的时间。
走查返工多，还原偏差大
设计定稿并进入开发后，由于双方理解存在偏差，出来的第一版页面还原度往往只有七八成。来回一走查，反馈修改又要耗上小半周，验证成本很高。
为了打破这种困局，我们换了个做法。通过 Ardot × CodeBuddy，仅用 2 天时间就完成了原型的快速搭建。在进入正式开发前，先把设计变成可体验预览的 Demo，让团队直接体验页面状态变化和关键交互流程。
虽然它还不能直接上线，但已经能串联起完整的使用流程，足够支撑设计、产品和研发一起讨论方案，节约了大量的沟通走查成本。
| 对比维度 | 过去的方式 | 这次实践 |
|---|---|---|
| 交付效率 | 2 周，交互稿 + 视觉稿 | 2 天，可交互的前端原型 |
| 视觉还原度 | 七八成，靠走查反馈补齐 | 95% 以上，不用逐像素返工 |
| 代码复用率 | 前端从零搭界面，设计稿不产出可用代码 | 界面层代码可直接沿用，省去大部分搭建工作 |
| 前端投入 | 界面搭建和数据对接两段活 | 界面搭建基本免除，精力集中在数据对接 |
| 沟通效率 | 对着静态图解释流程，沟通与走查耗时约 120 分钟 | 三方体验同一个可交互 Demo，沟通走查约耗时 20 分钟，效率提升 83% |
| 问题暴露时机 | 开发完成后走查 | 方案阶段暴露问题并修改 |
| 迭代粒度 | 问题积累后集中沟通 | 单模块小步提交，可检查可回退 |
用 Ardot × CodeBuddy 让原型"快速输出"
这套流程不追求一键生成最终页面，而是让设计上下文能够准确、快速、可控地传递到开发环节。
在这次实践中，设计师先在 Ardot 内完成关键页面和核心体验的设计，为后续页面建立明确的设计规则；CodeBuddy 根据已有的设计规则补齐其余场景。借助 Ardot × CodeBuddy，原本需要约两周完成的交互与视觉工作，最终两天就输出了可交互的原型。具体的协作过程可以分为四步。
第一步：在 Ardot 中整理可定位的设计上下文
我们先在 Ardot 中准备关键页面和核心状态，并整理头像、图标等设计资源。同时，需要明确实现边界，哪些视觉效果必须保留，哪些交互不能简化。
准备的设计稿虽然不必一次覆盖所有页面，但需要层级清楚、命名明确、节点可以定位。这样，Ardot 既提供生成时需要的设计输入，也能负责后续每一轮的交互视觉校准。
第二步：在已有业务规范上快速建立规范 DNA
设计稿准备好以后，CodeBuddy 通过 MCP 直接读取 Ardot 设计文件，获取布局、样式、颜色和字体，也能读到变量定义与组件描述。输入里带着具体节点，后续修改可以落到对应组件上。
接下来要把设计稿中反复出现的规律整理出来。
Design_DNA.json：保存颜色、字号、间距、圆角和阴影等 Token，在 CodeBuddy 可以直接引用。Big_Data_DESIGN.md：说明视觉原则、组件规格与使用禁忌，帮助 CodeBuddy 判断这些 Token 应该放在哪里。
我们把这套规则统称为设计规范。每次生成前，CodeBuddy 都要先读取规范，再开始编写代码。这个过程无法保证所有规范都被准确实现，但能为代码生成提供明确依据，减少 AI 猜测意图带来的偏差。
第三步：用 CodeBuddy 生成并串联核心流程
通过 MCP 接通 Ardot 与 CodeBuddy 后，我们将 Ardot 中对应页面的设计稿链接直接发送给 CodeBuddy，并用自然语言补充页面之间的衔接关系、关键操作步骤和预期结果。
同时，我们把 Ardot 现有组件库设计稿链接提供给 CodeBuddy，帮它明确组件选型与实现规范。这样，CodeBuddy 就能同时理解页面视觉、交互逻辑和组件约束，并据此生成第一版可交互原型。对于设计稿中容易被忽略的极限状态、各个组件的点击、hover 状态，它也会结合现有页面结构和组件库规范补充对应实现，使原型在串联核心流程的同时，覆盖更完整的使用状态。
第四步：通过预览验证把反馈带回下一轮
随后，我们将原型发布为可访问的链接，让产品、设计和研发基于同一版本进行体验和反馈。如果发现设计方案存在问题，就回到 Ardot 调整设计；如果原型实现脱离设计稿，则交给 CodeBuddy 修改。修改完成后再次预览和验证，持续迭代，直到关键流程和页面表现达到预期。
用 Ardot × CodeBuddy 让原型"精准还原"
通过 Ardot MCP 读取设计稿和组件库后，结构相对简单的列表页通常可以精准生成。但信息密度更高、布局关系更复杂的页面仍然需要设计师持续校准。在 DataTeam 这次实践中，复杂页面的还原度经过多轮优化，从七八成逐步提升至 95% 以上。
围绕反复出现的问题，我们沉淀出了下面三条经验。
1. 用 Skill 固化反复出错的场景规则
在还原 DataTeam 项目的对话流页面时，最让人头痛的是那些"差一口气"的视觉细节。两个区域贴得太近，标题行总对不齐，该错开的地方也会忽宽忽窄。这轮刚调好，换个页面又冒出来。相同的话说了几次，AI 每一轮都像重新听见。
这些问题集中在对话流场景中，把规则直接写进面向所有页面的 Design_DNA.json 和 Big_Data_DESIGN.md，可能干扰其他页面的生成。因此，我们保留这两份通用规范不动，另外为这个场景整理专项规则。
首先，我把反复出错的界面设计稿通过 MCP 交给 CodeBuddy，让它读取相关节点，归纳对话流中的间距和对齐规律。我们确认规则有效后，再将它们整理成 Conversation_Flow_Spacing 专项校准 Skill，并为 Skill 写明适用场景和触发条件。当 CodeBuddy 识别到对话流页面任务时，会首先加载这套规则，再开始生成或修改。这样，已经校准过的细节便能在同类任务中持续复用。
后来我们形成了一个很实用的判断：同一个问题说到第三次还发生，就该停下来改规则。 Skill 不会让 AI 突然变聪明，但能让这一次的纠正留到下一次任务里。
2. 把口头描述换成精准定位
设计稿中有一些 hover 状态、展开、弹窗和跳转问题只会在特定情况下出现，很难通过自然语言准确描述要怎么改。对着 AI 说"右边这块浮窗出现时机不对"，CodeBuddy 很难判断具体元素和对应代码。
这时可以用 Ardot MCP 直接把设计稿里对应的 frame 或元素链接给到 CodeBuddy，让它照着目标状态还原。就算还原后仍有误差，也能通过浏览器的元素名称来回校准，指到哪就改到哪。
这里有三个不同的定位对象：
- Ardot 的 Frame 或元素链接——指出设计侧的目标节点和目标状态；
- 前端仓库中的组件与 Token——CodeBuddy 实际复用或修改的代码对象；
- 浏览器中的元素名称——用于找到运行页面里的实际元素，并在修改后验证结果。
把这三个对象说明清楚后，反馈便能落到具体位置。
3. 用小步提交控制多轮修改的风险
复杂的原型界面同时调整布局、交互和动效，很容易产生副作用。Ardot 设计稿始终作为视觉验收基准，CodeBuddy 一次只解决一个功能模块问题。静态还原、交互与动效分开处理，每完成一步就提交代码。较大的修改放进独立分支，提交前完成类型检查和构建验证，确认效果之后再部署。
多次提交把每次修改限制在明确范围内。方向出现偏差时，我们也能迅速退回上一个稳定版本。经过这些校准，原型保留了可供后续开发使用的页面结构、样式和完整交互。研发就可以在此基础上完成组件封装和数据接入，再补齐权限控制、异常状态与性能要求。
以下视频完整展示使用 CodeBuddy 结合 Ardot MCP 的开发过程，以及最终 Demo 与设计稿的效果对比。
小结
过去的工作流是一条直线，设计稿做完 → 交给开发 → 研发做完 → 设计师开始走查找问题。每个环节都在等人，时间往往消耗在反复解释与修改上。而 Ardot × CodeBuddy 把这场接力变成了并行协作。
Ardot 负责把设计上下文说清楚。页面应该长什么样、元素放在哪里、层级怎么组织，都沉淀在同一个设计源里。设计师不用等页面开发完成后再集中找问题，而是可以从方案阶段开始，持续对照实际效果调整方向。CodeBuddy 基于这些信息生成可运行的页面。研发接手时，面对的不再是一张需要重新理解的静态稿，而是一个已经跑起来的原型。接下来可以把精力放在组件封装、数据接入和性能优化上，而不是反复确认间距、样式和交互意图。
Ardot × CodeBuddy 联合起来，设计验证被提前到了方案阶段。设计、产品和研发可以围绕同一个可交互原型讨论问题，及时发现设计与实现之间的偏差，减少开发过程中的反复沟通返工，更多的时间用来打磨关键页面的使用体验。
设计也从交付的终点，变成了推动产品持续演进的起点。