阿里妹导读
三个月前，我们介绍了 Tarot Pixel——一个不替 Agent 写代码，而是让 Coding Agent 自主理解设计稿的系统。三个月后，一份混乱的设计稿暴露了更深层的问题，催生了新的工程范式。本文将探讨两个核心议题：当上下文工程深入至“脏数据治理”层面，以及在上下文优化到位后，为何仍需引入循环工程（Loop Engineering）。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
回顾与起点
《AI Native 的视觉稿还原》一文探讨了 AI 视觉还原的核心问题：设计稿信息应以何种形式进入 Coding Agent 工作流。我们提出“不建管道，建图书馆”的思路——不替 Agent 生成代码，而是将设计稿整理为干净、分层、持续在线的视觉上下文，供 Agent 按需查阅、自主实现。
这一方向正确，但在深入真实业务场景时，两个深层挑战浮出水面：
第一，设计稿的“原始质量”远超预期。设计师习惯、协作历史痕迹及工具特性叠加，使得“干净的视觉上下文”无法直接导出，需进行深层工程治理。
第二，即使上下文极致优化，模型输出仍存在不稳定性。一次性生成不等于一次做对，真正的质量收敛需要新的工程范式。
第一章：一份设计稿引发的反思
1.1 当 Agent 碰到“混乱”
常规视觉稿还原质量尚可，但面对真实业务设计稿时，问题彻底暴露：
关键区域还原错误：无论怎么调整提示词，Agent 仍出现元素缺失、位置偏移；
还原不可见图层：设计稿中被隐藏的历史版本、被蒙版遮挡的底层元素出现在页面上；
耗时异常：本应 10 分钟完成的模块，运行 30 多分钟仍未结束。
起初以为是提示词问题，反复调整 Skill 文档无果。深入分析后发现，根源在于上下文被“脏数据”填满，而非模型能力不足。
1.2 设计稿的五个结构性问题
打开该设计稿图层面板，结构触目惊心：
问题一：层次嵌套过深
一个“价格”文字被 8 层无意义空分组包裹。每多一层嵌套，Agent API 调用次数、上下文占用及结构理解成本均大幅增加，而这些空分组不承载任何视觉信息。
问题二：Flex 布局不一致
设计工具中的 Auto Layout（对应 CSS Flex）常出现容器声明 Flex 但子节点尺寸位置与语义不一致的情况。Agent 忠实按 Flex 实现，导致渲染效果与设计稿大相径庭。
问题三：大量隐藏图层
「组 2486」内容会被「组 2490」覆盖。设计过程中的历史版本、备份副本等视觉上不可见的图层，在结构化数据中真实存在。原有基础降噪最多处理 5 层深度，此设计稿远超预期，穿透了原有防线。
问题四：图层规范度问题
图层“价格字体”宽度为 156px，实际文字仅需约 100px。多余空间导致对齐方式不明，结构尺寸信息与视觉语义不一致，模型易做出错误判断。
问题五：属性冗余
父子节点背景色重复，若父节点完全包含子节点且子节点无其他视觉效果，则该子节点可消除，将其子节点提升一层，使结构更扁平、上下文更干净。
1.3 为什么设计稿结构如此重要
树的深度和复杂度直接决定检索效率：树越深，API 调用越多、上下文占用越大；节点越冗余，噪音过滤成本越高；结构越混乱，语义推断难度越大。
沟通同理：若对方唠叨一堆却重点稀少，沟通效率极低。大脑被无用信息塞满，消化判断便极其困难。
问题核心并非 Agent 不够聪明，而是图书馆管理不善。
第二章：上下文工程 —— 降噪
此前认为上下文工程聚焦于“信息如何分层暴露给 Agent"。三个月实践表明，更深一层在于：信息到达 Agent 之前，源头数据本身需深度治理。
2.1 一个月，50+ 次提交
集中攻坚上下文工程的一个月内，Tarot Pixel 仓库新增超 50 次提交。绝大多数并非增加新功能，而是在做一件至关重要之事：降噪。
Git 日志显示大量此类提交信息：
refactor: 裁剪无可视样式的节点，包括图片 fillrefactor: 彻底重写导出逻辑，删除不必要的所有属性，彻底简化节点模型feat: 增加对非自身树的背景裁剪以及增加对无视觉的节点的裁剪refactor: 优化降噪，背景色跨节点清除 + 去除完全无视觉节点feat: 支持 flex 单 child 裁剪 + 支持背景冗余去除 + 支持无用 radius 去除feat: 支持多文本的容器尺寸超过所有文本时，将这个容器干掉feat: 增加伪 flex 布局（flex 内部元素超出 flex-item 很多）的去 flex 布局能力refactor: 大幅提升降噪效率 + 修复透明 png 图被误当成不透明而过度裁剪问题
每一行看似小修小补，共同构成了一套完整的设计稿降噪流水线。
2.2 降噪流水线
降噪非简单“删除无用节点”。每个图层都可能承载视觉意义，误删会导致还原空洞。这是精度要求极高的工程问题。
插件侧建立五阶段降噪流水线：
阶段一：结构解析。将设计工具原始节点树转换为结构化数据，处理蒙版、矢量形状识别、坐标系统归一化。
阶段二：降噪。最复杂环节——深度裁剪（去空分组）、不可见图层清除（被遮挡、零尺寸、全透明）、伪 Flex 布局矫正、联集类型特殊处理。
阶段三：合并缩减。将视觉上属同一装饰单元的多个图层合并标记，减少节点数量。
阶段四：冗余清洗。清除属性层面冗余：跨节点重复背景色、被 overflow 裁剪的圆角、无效描边和阴影。
2.3 降噪的效果
以引发问题的设计稿为例：
指标 |
降噪前 |
降噪后 |
平均节点深度 |
8-12 层 |
3-5 层 |
不可见节点占比 |
~35% |
0% |
冗余属性 |
大量重复背景色、无效圆角 |
清除 |
Agent 单模块 API 调用次数 |
15-25 次 |
5-10 次 |
单模块平均耗时 |
30+ 分钟（qoder 极致） |
10-15 分钟（qoder 极致） |
降噪不改变视觉表达，渲染效果一致。但 Agent 获取的数据从“杂草丛生的森林”变为“修剪整齐的树”，检索效率、上下文质量、还原准确度实质性提升。
曾考虑在工程层预计算布局上下文（如“此处应用 Flex，gap 12px，方向 column"），但测试表明模型布局推断已足够，预计算反而多余。启示：工程应补足 AI 短板，而非侵入 AI 已胜任领域。此原则贯穿后续决策。
第三章：上下文做到位了，然后呢？
3.1 注意力涣散
降噪后上下文质量飞跃，但新问题出现：Agent 处理复杂设计稿时，输出质量依然不稳定。
同样 Skill 文档、同样 API，两次运行结果质量可能不同。有时忽略间距差异，有时背景色错误，但修正提示后能立即改对。
核心原因：非上下文不干净，而是上下文太大。
复杂视觉稿含数十模块、数百节点。即使精心清洗，总信息量依然庞大。模型上下文窗口能容纳，但“能装下”与“能充分利用”是两回事。大量视觉细节并存时，某些细节会被“看到但没被注意到”。
用户指出错误时，Agent 几乎总能快速修正。说明模型非不会做，而是首次执行时注意力未聚焦细节。降噪解决了信息“纯度”，未完全解决“体量”。
3.2 从指令到目标
面对注意力涣散，尝试三种方式：
方式一：写更好的提示词。在 Skill 文档加入更精确布局原则、切图指南、约束条件。相当于执行前预设规则。有效但有天花板——提示词是“预设指令”，执行前已固定，覆盖不了所有情况。
方式二：完成后人工反馈。Agent 做完，人指出错误，Agent 修改。但目标是减少人工干预，追求“系统自动纠正”而非“人能纠正”。
方式三：给 Agent 持续的目标信号。不告知做法，而在每次做完后，自动告知“你做的和目标差多远”，让其自行找到修正路径。
三种方式差异可用大模型训练概念理解。方式一和二本质是 SFT（监督微调）——人预先告知或事后纠错。方式三对应 RL（强化学习）——设定目标，给出反馈信号，让模型自学优化。
SFT 核心问题：指令执行前固化，依赖“人预见所有情况”。RL 核心优势：反馈发生在执行后且持续，每轮根据实际结果给出新方向。
我们需要的是方式三。
3.3 Loop Engineering
2026 年上半年，此思路在 AI 工程领域有了明确名称：Loop Engineering（循环工程）。
Andrej Karpathy 在 3 月做了标志性实验：630 行代码让 AI Agent 自动优化其手工调优二十年的模型。两天、700 次实验、20 个改进点——其中一个是注意力机制中缺失的标量乘数，人类工程师二十年未发现。核心洞察非"AI 更聪明”，而是：人类在第 12 个实验后疲劳，循环不会。
循环基本结构：执行 → 验证 → 反馈 → 修正 → 再执行。与单次提示本质区别：反馈发生在执行后（验证结果）而非执行前（提示词）。目标非一次做对，而是逐步收敛。
Google 的 Addy Osmani 在 Agentic 自主性层级模型中，将此模式归入 Level 3——目标驱动的自主性：Agent 为达成目标采取一切必要手段，直至满足停止条件。他强调前提：停止条件必须可通过自动化测量。勿给“让页面更好看”等模糊目标，而要给量化标准。
他还提出 Agent 每次运行前应有的“契约”：目标、范围、停止条件、证据、升级机制、预算。这六要素成为我们 Skill 文档骨架——目标是视觉一致，停止条件是 diff 收敛或 20 轮上限，证据是 diff 图和渲染树数据，升级机制是未收敛时交人工。
第四章：把循环工程写进 Skill
4.1 "做 → 看 → 改”闭环
理解循环工程思想后，问题变为：如何在视觉还原场景落地？
Skill 中内置“做 → 看 → 改”收敛闭环：
做：Coding Agent 基于上下文工程提供的视觉信息，完成首次代码实现。
看：调用 pixel-feedback 工具——获取视觉稿截图（“标准答案”）、通过 Playwright 截取 Agent 实现页面（“答卷”）、像素级对比生成 diff 图（“哪里答错了”）。
改：Agent 读取 diff 图和 diff 百分比，定位差异区域，通过双边取证（API 获取设计数据 + Playwright 获取实现数据）找到具体偏差项，定向修复。然后回到“看”。
循环直至所有可见差异解决，或达到 20 轮上限。
关键不在“多跑几次”，而在于每一轮 Agent 都获得明确目标信号——diff 图和 diff 百分比告知“离目标还差什么”。
4.2 验证器：精准的目标信号
Claude Code 团队 2026 年 7 月发布关于“投入度（Effort）”的技术解读，指出投入度控制的不只是模型“思考多久”，而是总共愿意做多少工作。此洞察对循环工程有关键意义：若目标信号不够精准，投入度再高也是白费。
若只告诉 Agent“继续优化，让页面更像设计稿”而不给具体 diff 数据，Agent 会花大量 token 自我验证——反复截图、调整——但因“差不多了”标准模糊，很可能在几个区域间来回反复，直至投入度耗尽。花了很多 token，无实质性收敛。
正如 Loop Engineering 文章所言：
验证器是循环的心脏。没有一个真正的输出门控，你得到的不是循环，而是让 Agent 永远在给自己的作业打分。
视觉还原场景中，验证器以 diff 百分比为核心指标，轮廓图为辅助。diff 百分比提供客观、可量化的收敛度——非模型判断“差不多像了”，而是确定性算法逐像素比对。
开发了 element-diff 模块，能在像素对比之上进一步识别元素级差异（如“第 3 号差异是文字「立即下单」，水平先上偏移了 4px"）。但实践中发现，是否需要它取决于模型能力——Opus 常忽略 diff 图细节，element-diff 有用；Kimi K3 直接读 diff 图就能精准理解每一处差异。且 element-diff 无法识别背景差异，在列表类重复内容中还会产生干扰信息。因此作为储备能力，基础验证器不够用时再引入——若 AI 已能理解 diff 图，不必过度工程。
4.3 模型性格与循环策略
运行循环过程中，发现被严重低估的因素：不同模型有截然不同“性格”，直接影响循环收敛方式。
Opus 思考能力极强，但有“主见”。常忽略 diff 图上某些差异，自判“这里不改更合理”，甚至主动纠正设计稿中不合理间距和字号。有时是优势，有时是干扰。
Fable 提升的是 effort——更好的完成度，且是“合理的”完成度。它在遵循设计稿和保持代码质量间找平衡，并不 1:1 复刻每个像素，更符合人类预期。
Kimi K3 同样完成度高，但风格截然不同——严格遵守视觉稿，1:1 复刻，自己的想法很少。
需说明：完全遵守和不完全遵守视觉稿，都不一定是好事。视觉稿是人设计的，本身不完美。完全复刻有时会出现“过拟合”——把设计师的 1px 偏差、不完全统一的间距也忠实还原，反而导致效果不如设计意图。
理解模型性格，有助于选择合适循环策略。对 Opus，需更严格验证抑制“自由发挥”；对 Kimi K3，需在 Skill 中加入更多关于“设计意图”而非“像素精度”的引导。
4.4 两条链路，四种循环
不同技术栈验证方式不同，但方法论一致。支持两条链路：浏览器链路（Web/PC，Playwright/CDP 截图，HMR 秒级刷新）和真机链路（DX/Muise/Weex，3eye 真机截图，需重新构建推送）。循环逻辑完全一样：改代码 → 截图 → diff → 修复 → 再截图 → 直到收敛。
每个技术栈模块都内置视觉还原和反馈链路两个职能——非两个独立功能，而是同一个循环的两个阶段。
Claude Code 团队在循环入门指南中将循环分为回合式、目标式、定时和主动式四类。Skill 中实现的 pixel-feedback 闭环是目标式循环——明确了成功标准（diff 收敛），Agent 就不需自己判断什么叫“足够好”。Claude 团队总结精辟：“检查越量化，Agent 就越容易自我验证。”
4.5 收敛与止损
设计合理的循环需明确终止条件：
收敛出口：diff 图中所有可见红/绿差异都能被解释（已修复 or 确认为不可修复的渲染差异），Task 清单全部关闭。
止损出口：迭代次数达到 20 轮上限，输出当前 diff 和未关闭 Task 清单，交给人工。
若连续两轮 diff 百分比无明显下降，说明当前方案可能有结构性偏差——此时 Agent 应重新审视整体思路，而非继续微调。循环不是蛮力，需在每一轮做出方向判断。
关键规则：diff 图只是定位问题指引，修改必须以 API 精确数值为准；只改被定位到的节点，禁止整体重写；相同偏差连续未收敛则停止并请示人工。
第五章：端到端融合与 AI Native 反思
5.1 架构全景
三个月迭代表明，上下文工程和循环工程非两个独立方向，而是视觉还原从“能做”到“做好”的两个必要支点。
上下文工程解决"Agent 能看到什么”——通过降噪和渐进式 API，确保信息干净、精确、按需分层。循环工程解决"Agent 能做到多好”——通过反馈闭环和像素级验证器，让输出持续向目标收敛。
两者相互依赖：上下文越干净，首次实现越好，循环修正差异越少，收敛越快。没有上下文工程，循环会在噪声中打转；没有循环工程，上下文再干净也无法保证一次做对。
5.2 效果
上述视觉稿，经降噪后，节点数从 245 降低到了 113
Agent 还原效果如下（使用 Qoder + Kimi K3 经过反馈循环）：此外注意第二张商卡上券后价格，视觉稿有瑕疵，但模型很好地将其理解为要靠右（因为第一个商卡靠右，且其他都是靠右），它不会因为看到有差异而去修改。
下面是另一个案例演示了上下文工程带来的实际视觉还原效果：在未经过循环工程的情况下一次还原完毕（模型采用 Qoder 极致）。
下面是加入反馈循环链路之后，评测案例端到端效果
以上 3 个案例基于 cantus 跑出效果，大部分案例均可达到很高视觉分和非常高代码质量，肉眼看已无限接近交付态。
差异集中在商品图片区域（真实商品图与设计稿占位图不同，预期内差异）和少量文字亚像素渲染差异。布局、间距、颜色、字号等核心维度上，已达到很高视觉一致性。这是上下文工程保证首次实现质量、循环工程收敛剩余差异的共同结果。
5.3 AI Native 思维
做 Tarot Pixel 过程中，最深体会非某个技术方案，而是一种思维方式转变。
谦虚：当 Agent 输出不对时，第一反应应是“我给的信息是否充分？是否有矛盾？”，而非“模型不行”。若 Agent 在“猜”，不是告诉它“不要猜”，而是找到为什么它会猜。
耐心：看 Agent 执行每一步时，关注 thinking 过程是否合理。思路对但结果有偏差，问题在执行；思路就是错的，要审视上下文是否引导它走偏了。就像教小孩做题——不是帮他做对这道题，而是找到他薄弱的知识点。
目标驱动：给 AI 目标，而非指导 AI 做事。上下文工程是“给它做题所需的参考资料”，循环工程是“告诉它离正确答案还有多远”。怎么做——让它自己决定。
边界感：贯穿全文的一条线。降噪是必要的，因为脏数据不是模型能自行解决的。布局推断是不必要的，模型自己够用。element-diff 是有条件的，取决于模型的视觉理解能力。这条边界不是固定的——它随着模型能力的进化而移动。AI 能做好的事就让 AI 做，做不好的才用工程去帮助。这也意味着，今天的工程方案，可能在明天因为模型进步而变得多余。好的 AI Native 系统，应该拥抱这种变化而非抵触它。
第六章：Loop Engineering 的更多可能
6.1 用循环来写循环
循环工程不仅用在 Skill/Agent 设计中，也用在了系统本身的开发中。
@ali/tarot-pixel-match图像对比算法就是一个例子。这是我们团队并不擅长的图像处理领域，传统做法是请算法专家。我们换了个方式：准备一批覆盖各种场景的测试用例，让 AI Agent 持续探索和优化算法。
关键在给模型布置任务时的提示词设计。不是简单说“把 diff 降下来”，而是给出差异化的优化目标：
通过持续改进算法，在测试集中 A、B、C 等用例的 diff 百分比保持稳定的前提下，对 D、E、F 等用例进行大幅降低，对 G、H、I 等用例进行一定程度的降低。另有一份你不可见的测试集会验证你的泛化能力。在优化过程中，将每一轮的优化思路、效果变化记录到 steps.md 中持续跟踪。
这段提示词有几个关键点：“保持稳定”防止顾此失彼，差异化的目标让模型有清晰的优先级；不可见测试集迫使模型追求泛化而非过拟合特定用例；steps.md 过程记录让每一轮迭代的思路和数据可追溯，相当于模型自己的实验日志。
这本质上就是一个循环：脑暴 → 实现 → 验证 → 分析失败 → 改进 → 再验证。而且有一个有趣的特性：甚至不需要定义一个精确的最终目标，只要测试用例集足够大、场景覆盖足够广，模型就可以持续迭代优化下去。用例集就是它的“训练数据”，覆盖面越广，优化就越有效。最终在不可见测试集上的表现达到了预期效果——人类在第 12 个实验后就疲劳了，循环不会。
6.2 用定时循环持续提升业务指标
循环还可以延伸到更长周期的业务优化。一个正在探索的方向：用定时循环持续优化业务效果——设定可量化的基线指标，让 Agent 周期性地分析表现、定位瓶颈、生成优化方案、实施修改，每次循环后对比基线记录效果。
这是 Claude Code 团队定义的“定时循环”在业务中的应用——任务本身不变，但输入在变化。与视觉还原的目标式循环不同，业务优化循环没有明确的终态，而是一个持续逼近的方向。基线指标就像 diff 百分比——提供“变好还是变差”的客观信号，Agent 的工作是持续让数字朝正确方向移动。
第七章：未来计划
真机验证环境：与交易团队共建的真机链路基础能力已经跑通——iOS 链路已实现自动化的“做 → 看 → 改”闭环，Android 链路将继续建设。
验证器打磨：持续优化验证器的能力——更精准的 diff 算法、更稳定的截图基线、更智能的差异归类，使循环的每一轮反馈都更准确，效果更稳定，收敛更快。
大规模评测：当前的降噪和循环策略主要在有限的业务场景中验证。下一步将建设大规模评测体系——覆盖更多行业、更多设计风格、更多技术栈的测试用例集，系统性地度量和提升泛化能力。用例覆盖面越广，系统的鲁棒性就越强——这本身也是一个循环。
未来目标：一次接近完成，少量的自修复，逼近 0 次的人工干预。
总结
三个月前，提出“不替 Agent 写代码，只给 Agent 提供干净的视觉上下文”。三个月后，这个思路被分解为两个工程方向：
上下文工程，解决源头数据的质量问题——50+ 次提交的降噪流水线，把设计师的原始图层树转换为 Agent 可高效消费的结构化信息。
循环工程，解决输出质量的收敛问题——Skill 内置的“做 → 看 → 改”闭环，让 Agent 的输出在持续的目标反馈中逐步收敛到视觉一致。
上下文工程提高起点，循环工程保证终点。两者缺一不可。
Addy Osmani 在他的 Agentic 自主性层级分析中有一句精准的收束：“验证，永远是最终的瓶颈。”当 Agent 越来越自主时，限制系统上限的不是生成能力，而是我们验证其输出的能力。你能验证到什么精度，系统就能收敛到什么精度。
说到底，上下文工程和循环工程遵循的是同一个朴素的原则：给 Agent 足够干净的信息，给它明确的目标，给它可量化的验证，然后让它自己去做。
参考链接：
[1]https://x.com/hanakoxbt
[2]https://x.com/addyosmani/status/2072885435312042327
[3]https://x.com/ClaudeDevs/status/2074900291062034618
[4]https://x.com/ClaudeDevs/status/2074208949205881033
[5]https://x.com/addyosmani/status/2072885435312042327
千问 AI 平台 - 为 Agent 而生，驱动 AI 生产力