★ FEATURED ARTICLE 1. 设计到代码的闭环为什么突然成了焦点1.1 从“切图仔”到“Agent 编排者”的角色转变做了七八年设计工具链相关的工作我最大的感受是设计稿和代码之间的那道墙从来不是靠某一个工具推倒的而是靠工作流的重构慢慢磨掉的。早些年我们讲“设计规范落地”本质上还是人肉翻译——设计师出稿前端照着量、照着切、照着还原中间靠标注工具和口头沟通补位。后来出现了设计令牌Design Token和组件库同步的方案算是把“样式”这一层做了半自动化但布局逻辑、交互状态、响应式规则这些真正吃时间的东西依然得靠人写。现在的情况变了。大模型驱动的代码生成能力成熟之后整个链路的重心从“怎么把样式搬过去”变成了“怎么让 Agent 理解设计意图并自主完成实现”。这就是标题里说的“设计-代码闭环”——它不是单向的导出而是一个可以来回校验、自动修正的循环。设计侧改一个间距代码侧能感知代码侧发现某个断点下布局塌了设计侧能收到反馈。听起来像科幻但拆开看每一步都有对应的技术支撑。我之所以关注这个方向是因为它直接决定了一件事前端工程师和设计师的协作模式会被重新定义。以前是“你设计我实现”以后是“我定义规则Agent 执行我验收”。这个转变对个人能力的要求不是降低了而是转移了——从写样式的手速转移到对设计系统、组件契约、生成约束的理解深度上。1.2 为什么是现在三个前提条件同时成熟这个闭环能在这个时间点被拿出来讨论不是偶然。我梳理了一下至少有三个条件同时到位了。第一个是设计工具的结构化程度足够高。以 Figma 为代表的工具早就不是单纯的矢量绘图软件了。它的底层数据模型里有完整的节点树、样式引用、组件实例、变体Variant和自动布局Auto Layout信息。这些东西如果只是给人看那它就是一张图但如果给程序读它就是一份结构化的 UI 描述文件。自动布局尤其关键它把“间距”“对齐”“填充”这些原本靠肉眼判断的东西变成了明确的约束关系Agent 可以直接解析成 Flexbox 或 Grid 的配置。第二个是代码生成模型对 UI 语义的理解能力上来了。早期的代码生成基本是模板填充你给它一个按钮的截图它给你一段写死宽高的 div。现在不一样了模型能识别出“这是一个带图标的次要按钮处于禁用态”然后生成符合组件库规范的代码。这个进步的核心不在于模型参数变大了而在于训练数据里有了大量“设计稿-代码”的配对样本以及模型对设计系统语义的建模能力。第三个是Agent 框架让“闭环”有了执行主体。单纯的代码生成只是一次性动作闭环需要有人去比对、去发现差异、去决定下一步改哪里。Agent 的价值就在这里它可以拿着设计稿的预期结果和代码的实际渲染结果做对比定位差异然后自主决定是调整样式、修改结构还是反馈给设计侧。这个“感知-决策-执行”的循环才是闭环的真正含义。注意这里说的 Agent 不是指某个具体产品而是一种架构模式。任何能完成“读取设计数据、生成代码、渲染验证、比对差异、迭代修正”这一串动作的系统都可以叫设计-代码闭环 Agent。2. 拆解闭环的核心环节从设计数据到可运行代码2.1 设计数据的结构化提取不只是导出 JSON很多人以为把 Figma 文件导出成 JSON 就完事了实际上远没有那么简单。Figma 的 API 返回的节点树非常庞大一个中等复杂度的页面动辄几千个节点里面混杂着分组、蒙版、辅助线、隐藏图层这些对代码生成毫无价值的信息。直接丢给模型token 消耗巨大不说生成的代码也会被噪音干扰。我实际操作下来的经验是提取阶段至少要做三层过滤。第一层是语义过滤。把纯装饰性的节点比如背景渐变层、阴影层和结构性节点比如容器、文本、按钮区分开。判断依据可以看节点名称的命名规范也可以看它是否绑定了组件或样式。如果一个节点既没有子节点、又没有绑定任何样式、还不在自动布局的约束体系里大概率是装饰元素可以合并到父级的样式描述里。第二层是层级压缩。Figma 里设计师习惯用大量分组来组织图层但代码里不需要那么多嵌套的 div。我的做法是如果某个分组没有自己的布局属性比如没有设置自动布局、没有独立的背景或边框就把它拍平把子节点直接提升到上一层。这样能把节点数量压缩 40% 到 60%。第三层是约束提取。自动布局的信息要完整保留包括方向、间距、内边距、对齐方式、是否换行。这些直接对应到 Flexbox 的属性。对于非自动布局的绝对定位元素要记录它的坐标和尺寸生成绝对定位代码或者提示需要人工介入。// 一个简化的节点过滤逻辑示意 function shouldKeepNode(node) { // 保留有组件引用的节点 if (node.componentId) return true; // 保留有文本内容的节点 if (node.type TEXT node.characters) return true; // 保留有自动布局的容器 if (node.layoutMode node.layoutMode ! NONE) return true; // 保留有样式绑定的节点 if (node.styles Object.keys(node.styles).length 0) return true; // 其余视为装饰或冗余分组 return false; }这段逻辑不是万能的但能过滤掉大部分噪音。实际用的时候还要结合具体项目的设计规范做调整比如有些团队会把图标做成组件那就应该保留有些团队用矢量图形直接画图标那就需要判断是否要转成 SVG 还是用图标库替代。2.2 代码生成策略模板、模型与混合方案的选择拿到结构化的设计数据之后下一步是生成代码。这里有三条路线各有各的适用场景。纯模板方案是最可控的。你预先定义好组件映射规则比如“Figma 里叫 Button/Primary 的组件对应代码里的Button variantprimary”。然后写一个转换器把设计节点的属性映射到组件 props 上。这种方案生成速度快、结果稳定但灵活性差遇到设计稿里没有对应组件的情况就抓瞎。纯模型方案是把设计数据序列化成文本描述直接让大模型生成代码。好处是灵活能处理各种奇怪的设计稿坏处是不稳定同一个设计稿生成两次可能得到不同的代码而且容易产生幻觉比如引用不存在的组件或属性。我现在用的是混合方案核心思路是“模板保底模型补位”。具体来说对于设计系统里已有的组件走模板映射保证生成的代码符合团队规范。对于设计系统覆盖不到的部分比如一些一次性的营销页面布局走模型生成但生成结果要经过一层校验检查它引用的组件和样式是否存在。对于布局结构优先用自动布局信息生成 Flexbox 代码模型只负责填充内容和处理边界情况。这个策略的关键在于组件映射表的维护。我建议把它做成一个独立的配置文件设计侧的组件名和代码侧的组件路径一一对应新增组件时两边同步更新。这个表越完善模板方案的覆盖率就越高整体稳定性就越好。方案类型生成速度稳定性灵活性适用场景纯模板快高低设计系统覆盖度高的常规页面纯模型慢低高一次性活动页、探索性设计混合方案中等较高较高大多数生产环境2.3 渲染验证与差异比对闭环的“感知”环节代码生成出来只是第一步真正让闭环转起来的是验证环节。我的做法是把生成的代码在一个无头浏览器里渲染出来截图然后和设计稿的截图做像素级比对。听起来很粗暴但实际效果出奇地好。比对的时候不能只看整体差异率那样只能告诉你“像不像”不能告诉你“哪里不像”。我用的方法是分区域比对把页面按照设计稿的节点树切分成若干个区域每个区域单独比对然后按差异程度排序。差异最大的区域优先处理这样 Agent 的修正动作就有了明确的优先级。差异的类型也要分类。我大致分成四种布局差异元素位置偏移、尺寸不对、换行行为不一致。这类差异通常对应 Flexbox 属性配置错误修正起来最直接。样式差异颜色、字体、圆角、阴影对不上。这类差异往往是设计令牌映射出了问题需要检查令牌配置。内容差异文本内容缺失或错误。这类差异一般是数据绑定问题需要检查数据源。结构差异元素缺失或多余。这类差异最麻烦可能是节点过滤逻辑有误也可能是组件映射缺失。分类之后Agent 就可以针对不同类型的差异采取不同的修正策略。布局差异直接调整样式代码样式差异回查设计令牌内容差异检查数据填充逻辑结构差异则需要重新审视设计数据的提取过程。实操心得像素级比对对字体渲染的差异非常敏感。不同操作系统、不同浏览器的字体抗锯齿策略不一样会导致大量误报。我的解决办法是在比对前对截图做一次高斯模糊把 1-2 像素的差异抹掉只关注结构性的偏移。这个阈值需要根据项目实际情况调太严了误报多太松了漏报多。3. 实操落地搭建一个最小可用的闭环原型3.1 环境准备与工具链选型要跑通这个闭环不需要一上来就搞得很复杂。我用的是一个最小化的工具链核心就四样东西设计数据导出脚本、代码生成模块、无头浏览器渲染环境、差异比对工具。设计数据导出用 Figma 的 REST API 或者插件 API 都行。REST API 的好处是不依赖 Figma 客户端可以跑在服务器上插件 API 的好处是能拿到一些 REST API 拿不到的运行时信息。我选的是 REST API因为闭环流程里需要定时拉取最新设计稿插件方式做不到自动化。代码生成模块我用 Node.js 写因为前端生态的解析工具最全。核心依赖就两个一个用来解析设计节点树一个用来生成代码字符串。生成代码的时候我推荐用 AST抽象语法树的方式而不是字符串拼接。AST 的好处是生成的代码结构可控而且可以反向解析回来做校验。字符串拼接看起来快但后期维护是噩梦。无头浏览器我用的是 Playwright因为它对多种浏览器的支持比较均衡截图 API 也稳定。启动一个浏览器实例加载生成的页面等网络空闲后截图整个流程大概 3 到 5 秒。如果页面有动画需要额外等待动画结束或者禁用动画。差异比对我用的是 pixelmatch 这个库轻量、快、可配置阈值。它输出一张差异图和一个差异像素比例够用了。如果要更精细的分析可以配合 OpenCV 做轮廓检测但那是后期优化的事了。# 最小依赖安装 npm install playwright pixelmatch pngjs # 如果要用 Figma REST API npm install axios环境准备好之后整个闭环的目录结构大概是这样的design-code-loop/ ├── config/ │ ├── component-map.json # 组件映射表 │ └── token-map.json # 设计令牌映射表 ├── src/ │ ├── fetch-design.js # 拉取设计数据 │ ├── filter-nodes.js # 节点过滤与压缩 │ ├── generate-code.js # 代码生成 │ ├── render.js # 渲染截图 │ └── compare.js # 差异比对 ├── output/ │ ├── design-snapshot.png # 设计稿截图 │ ├── render-snapshot.png # 渲染截图 │ └── diff.png # 差异图 └── index.js # 主流程入口这个结构不复杂但每个环节的细节决定了闭环能不能真正跑通。3.2 关键步骤拆解从拉取设计稿到生成差异报告整个流程我拆成六步每一步都有踩过的坑。第一步拉取设计数据。通过 Figma REST API 的/v1/files/:key接口拿到整个文件的节点树。这里要注意如果文件很大接口返回的数据可能超过几兆需要做分页或者只拉取特定页面。我的做法是在请求参数里指定ids只拉取当前需要转换的那个 Frame减少数据量。第二步节点过滤与压缩。前面说的三层过滤在这里执行。过滤完之后我会把节点树转成一种中间格式我管它叫“UI 描述对象”。这个对象里只保留对代码生成有用的信息节点类型、布局属性、样式引用、文本内容、组件引用。其他的一律丢掉。第三步代码生成。遍历 UI 描述对象对每个节点生成对应的代码片段。容器节点生成布局代码文本节点生成文本组件组件实例生成对应的组件调用。生成过程中要维护一个上下文记录当前的缩进层级和父级布局方向因为 Flexbox 的某些属性比如align-items是继承自父级的。第四步渲染截图。把生成的代码写到一个临时文件里用 Playwright 加载。这里有个细节生成的代码可能依赖项目里的组件库和样式文件所以临时页面要能正确引用这些依赖。我的做法是在项目根目录下建一个沙箱页面动态 import 生成的代码模块这样依赖解析和正常开发时一致。第五步差异比对。把设计稿截图和渲染截图对齐后做像素比对。对齐这一步很关键如果两张图的尺寸不一致比对结果全是噪音。我的做法是强制把两张图缩放到相同的宽度高度按比例缩放然后以顶部左对齐的方式裁剪到相同高度。第六步生成差异报告。比对结果不能只是一个数字要能指导下一步动作。我的报告里包含整体差异率、差异区域列表按差异程度排序、每个区域的差异类型分类、以及建议的修正方向。这个报告既是给 Agent 看的也是给人看的。// 差异报告的数据结构示意 { overallDiffRate: 0.032, regions: [ { id: header-nav, diffRate: 0.15, type: layout, suggestion: 检查导航项的间距配置设计稿为 24px渲染结果疑似为 16px }, { id: hero-title, diffRate: 0.08, type: style, suggestion: 字体权重不匹配设计稿为 600渲染结果疑似为 700 } ] }这个报告出来之后Agent 就可以根据type和suggestion决定下一步动作。布局问题改样式代码样式问题查令牌映射结构问题回退到节点过滤阶段重新处理。3.3 参数调优差异阈值与迭代次数的平衡闭环跑起来之后最需要调的就是两个参数差异阈值和最大迭代次数。差异阈值决定了“多大的差异算通过”。设得太高生成的代码质量差设得太低Agent 会陷入无限微调的循环。我的经验值是整体差异率低于 2% 可以认为通过单个区域的差异率低于 5% 可以接受。但这个值不是固定的文本密集的页面阈值可以放宽到 3%因为字体渲染差异很难完全消除图形密集的页面阈值要收紧到 1%因为形状和颜色的差异更容易被用户感知。最大迭代次数决定了 Agent 最多尝试修正几次。设得太少复杂页面修不完设得太多token 消耗和时间成本都上去了。我一般设 5 次超过 5 次还有大差异的就标记为“需要人工介入”不再自动处理。实际跑下来80% 的页面在 3 次迭代内能达到通过标准。还有一个隐藏参数是每次迭代的修正幅度。如果 Agent 每次只改一个属性迭代次数会很多如果一次改太多可能引入新的差异。我的策略是第一次迭代允许大幅调整比如重写整个区域的布局代码后续迭代只做微调每次只改一个属性。这样既能快速收敛又能避免震荡。注意迭代过程中要保留每次的代码快照和差异报告方便回溯。有时候 Agent 改了两轮之后差异反而变大了这时候需要回退到上一轮的结果。没有快照的话就只能从头再来。4. 常见问题与排查技巧实录4.1 生成代码“看起来对但跑不起来”的几种典型情况这个问题我遇到太多次了。差异报告显示差异率很低但代码一跑就报错。排查下来原因基本集中在几个地方。组件引用路径错误。模板映射表里配置的组件路径和实际项目结构不一致。比如映射表里写的是/components/Button但项目里实际是/components/base/Button。这种错误在生成阶段不会暴露只有渲染的时候才会报模块找不到。解决办法是在生成代码之后加一步静态检查用 TypeScript 的类型检查或者简单的 import 解析来验证路径有效性。样式作用域冲突。生成的代码用了全局样式类名和项目里已有的样式冲突了。比如生成代码里写了一个.container类但项目全局样式里也有.container且定义了不同的宽度。这种问题在隔离环境里渲染时看不出来一集成到项目里就出问题。我的做法是给生成代码的类名加统一前缀比如gen-降低冲突概率。响应式断点缺失。设计稿通常只给一个或两个断点的设计但实际项目需要适配更多断点。生成的代码如果只写了固定宽度在小屏幕上就会溢出。这个问题在差异比对时也发现不了因为比对用的视口宽度和设计稿一致。解决办法是在渲染验证阶段增加多个视口宽度的截图比对至少覆盖移动端、平板、桌面三个尺寸。交互状态未处理。设计稿里的按钮通常只展示默认态但代码里需要处理 hover、active、disabled 等状态。生成的代码如果只实现了默认态功能上是不完整的。这个问题需要在前端验收阶段人工检查或者在生成规则里强制要求所有交互组件必须包含状态处理。问题类型表现排查方法预防措施组件路径错误渲染时报模块找不到检查 import 路径生成后加静态检查样式冲突集成后样式错乱对比隔离环境和集成环境类名加统一前缀断点缺失小屏幕溢出多视口截图比对生成时注入响应式规则状态未处理交互无反馈人工检查交互组件生成规则强制状态覆盖4.2 Agent 陷入“改一个坏一个”的循环怎么破这是闭环系统最让人头疼的问题。Agent 发现标题字体不对改了字体权重结果行高变了导致下方内容偏移又产生新的差异。然后它去修行高行高改完间距又不对了。来回折腾好几轮差异率不降反升。我分析下来根本原因是Agent 缺乏对样式属性之间关联性的理解。字体权重和行高是有关联的间距和容器高度是有关联的单独改一个属性很容易破坏另一个。解决思路有两个方向。一个方向是给 Agent 提供属性关联规则。在生成约束里明确告诉它修改字体相关属性时必须同时检查行高和字间距修改容器内边距时必须同时检查子元素的尺寸约束。这些规则可以写在系统提示里也可以做成一个规则引擎在 Agent 执行修正前做一次校验。另一个方向是限制单次修正的范围。不要让 Agent 自由地改任何属性而是给它一个“修正窗口”每次只允许修改一个区域内的属性且修改后必须重新渲染验证。如果差异率没有改善就回退这次修改换一个策略。这个方式收敛慢一些但稳定性好很多。我实际用的是两个方向结合规则引擎做前置校验修正窗口做后置验证。跑下来震荡的情况减少了大概七成。剩下的三成主要是设计稿本身存在歧义比如某个间距在设计稿里是 23.5px但代码里只能取整这种差异是不可避免的需要人工决策。4.3 设计稿频繁变更时的增量处理策略实际项目里设计稿不是一成不变的今天改个间距明天换个图标后天加个页面。如果每次变更都全量重新生成成本太高而且会覆盖掉人工对生成代码的微调。我的策略是基于节点 ID 的增量更新。每次拉取设计数据时和上一次的快照做对比找出新增、修改、删除的节点。只对这些节点重新生成代码其他部分保持不变。节点 ID 是 Figma 分配的只要设计师不是删了重画ID 就不会变。增量更新的难点在于依赖关系的处理。如果一个容器的布局属性变了它所有子节点的位置都可能受影响需要重新生成。所以增量分析不能只看节点自身还要看它的父级和兄弟节点。我的做法是如果一个节点被修改把它和它的所有后代节点都标记为“需要重新生成”如果它的父级布局属性变了把它父级下的所有子节点都标记为“需要重新生成”。人工微调的保护也很重要。生成代码之后我会在代码里插入特殊的注释标记比如/* generated */和/* manual */。增量更新时只替换generated标记之间的内容manual标记的内容原样保留。这样设计师改设计稿和工程师改代码可以并行不会互相覆盖。实操心得增量更新一定要有回滚机制。有时候设计稿的变更会导致生成代码大面积报错这时候需要快速回退到上一个可用版本。我的做法是每次生成前把当前代码目录打包备份出问题了直接解压覆盖。备份文件保留最近 10 个版本再老的自动清理。5. 这套闭环方案的实际影响范围5.1 对前端工程师日常工作的改变最直接的变化是重复性劳动大幅减少。以前一个中等复杂度的页面从设计稿到可交互的代码大概需要 2 到 3 天。现在用闭环方案生成加修正大概 2 到 3 小时剩下的时间主要花在业务逻辑对接和边界情况处理上。这个效率提升不是线性的页面越复杂、组件复用率越高提升越明显。但工作内容也变了。以前前端工程师的核心竞争力是“还原度”谁能把设计稿还原得一模一样谁就厉害。现在还原度这件事被 Agent 接管了人的价值转移到定义规则和验收结果上。你需要理解设计系统的运作方式知道哪些属性可以自动映射、哪些需要人工干预还要能判断生成结果的质量。这其实对工程师的设计素养提出了更高要求。另一个变化是协作节奏。以前设计和前端是串行的设计定稿前端开发前端开发完了设计验收。现在可以并行设计在 Figma 里改Agent 实时生成代码前端工程师同步看到变更。设计验收和代码验收可以合并成一个环节因为两边看的是同一个东西。这个节奏变化对团队的工具链和沟通方式都有影响需要一段时间适应。5.2 对设计师工作方式的倒逼设计师这边的影响可能更大。以前设计师画图的时候不需要考虑代码实现想怎么画就怎么画。现在如果设计稿要进入闭环流程就必须遵守一些约束用自动布局、用组件实例、用设计令牌、命名规范。这些约束在短期内会增加设计师的工作量但长期来看是好事因为它让设计稿从“一张图”变成了“一份可执行的规格说明”。我观察到的一个有趣现象是当设计师知道自己的设计稿会被 Agent 直接转成代码时他们会更自觉地使用设计系统的组件而不是随手画一个看起来差不多的东西。因为随手画的组件在代码生成时会走模型方案结果不稳定而用系统组件走模板方案结果可控。这种“用脚投票”的机制反过来推动了设计系统的覆盖率提升。还有一个变化是设计评审的重点转移。以前评审主要看视觉效果和交互流程现在还要看“这个设计能不能被自动生成”。比如设计师用了一个很复杂的层叠效果视觉上很好看但代码生成时很难用标准 CSS 实现Agent 可能会生成一堆绝对定位的代码后期没法维护。这种设计在评审阶段就会被质疑设计师需要提前考虑实现成本。5.3 对团队工具链和流程的冲击闭环方案落地不是装一个工具那么简单它牵扯到整个工具链的调整。版本管理需要重新设计。设计稿的版本和代码的版本怎么对应设计稿改了但代码还没生成这时候代码仓库里是什么状态我的做法是给每次生成打一个 tagtag 里包含设计稿的版本号和生成时间。代码仓库里维护一个design-version.json文件记录当前代码对应的设计稿版本。这样出问题的时候可以快速定位是哪个版本的设计稿导致的。CI/CD 流程需要增加设计验证环节。传统的 CI 只跑单元测试和构建现在还要加一步拉取最新设计稿生成代码渲染比对差异率超标就阻断合并。这个环节会增加 CI 的时间但能防止设计稿和代码脱节。我一般把这个环节放在 nightly build 里不阻塞日常开发但每天会出一份差异报告。权限管理也需要调整。以前设计稿的编辑权限和代码的提交权限是分开的现在闭环系统需要同时访问两边。我的做法是给闭环系统一个独立的服务账号设计侧只读代码侧只写生成目录其他目录没有权限。这样即使系统出问题也不会影响人工维护的代码。影响维度传统模式闭环模式需要调整的地方版本管理设计稿和代码独立版本版本需要对应增加版本映射文件CI/CD只跑代码测试增加设计验证调整流水线配置权限设计和代码权限分离系统需要跨端访问增加服务账号评审看视觉效果兼顾可实现性更新评审清单6. 我踩过的坑和最后分享的几个技巧6.1 不要试图一步到位从单页面试点开始我一开始就想做一个全自动的闭环系统结果折腾了两周发现根本跑不通。问题出在设计稿的多样性上。不同设计师有不同的画图习惯有的用自动布局有的用绝对定位有的组件命名规范有的随手写。一个通用的闭环系统要处理所有这些情况复杂度是指数级上升的。后来我换了个思路先选一个设计规范执行得最好的页面做试点。这个页面的设计师愿意配合调整命名和布局方式前端也愿意花时间维护组件映射表。试点跑通之后再逐步扩展到其他页面。每扩展一个页面就补充一批映射规则和过滤规则。这个过程很慢但每一步都是稳的。我的建议是第一个月只做 3 到 5 个页面把闭环的每个环节都跑顺把规则库建起来。不要急着推广推广之前先确保规则库能覆盖 80% 的常见场景。剩下的 20% 长尾场景人工处理就好不要为了自动化而自动化。6.2 差异报告要给人看不能只给机器看我早期的差异报告就是一堆数字和坐标Agent 能看懂但人看不懂。结果出了问题的时候工程师不知道从哪里下手排查。后来我把报告改成了“人机双读”的格式每个差异区域配一张裁剪后的对比图左边设计稿右边渲染结果中间是差异高亮。下面用自然语言描述差异内容和建议修正方向。这个改动看起来只是展示层的优化但实际影响很大。工程师排查问题的速度提升了至少一倍而且非技术角色比如产品经理也能看懂报告参与讨论。有时候产品经理会指出“这个差异不是 bug是设计稿本身有问题”这种反馈在纯数字报告里是看不到的。6.3 保留人工干预的入口不要追求全自动全自动闭环听起来很美好但实际运行中总有一些情况是 Agent 处理不了的。比如设计稿里有一个复杂的插画Agent 生成的代码可能是一个占位图需要人工替换成实际的图片资源。又比如某个交互效果需要 JavaScript 逻辑Agent 只能生成静态样式需要人工补充事件处理。我的做法是在生成代码里预留“人工干预标记”。Agent 遇到不确定的情况时不强行生成而是插入一个带注释的占位符比如/* todo: 需要人工处理 - 复杂插画替换 */。工程师看到这个标记就知道这里需要手动处理。同时差异报告里也会把这些标记列出来作为“待人工处理项”单独展示。这个策略的核心思想是Agent 做它擅长的部分人做人擅长的部分两者通过明确的接口协作。追求 100% 自动化往往会导致系统过于复杂维护成本超过收益。80% 自动化加 20% 人工干预可能是更务实的平衡点。最后分享一个提高生成质量的小技巧在代码生成之前先让模型对设计稿做一次“意图描述”。比如让它用自然语言描述“这个页面是一个电商详情页顶部有导航栏中间是商品图和价格信息底部是加入购物车按钮”。这个描述不直接用于生成代码但可以作为生成时的上下文帮助模型理解每个区域的功能定位。实测下来加了这一步之后生成的代码在语义结构上更合理后续人工调整的工作量也少了一些。
阅读完成 · 觉得有帮助？
