三个月前，我们介绍了 Tarot Pixel—— 一个不替 Agent 写代码，而是让 Coding Agent 自己看懂设计稿的系统。三个月后，一份混乱的设计稿让我们看到了更深层的问题，也催生了一种新的工程范式。这篇文章讲两件事：当上下文工程深入到”治理脏数据”，以及当上下文做到位了之后，为什么还需要循环工程（Loop Engineering）。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
回顾与起点
《AI Native 的视觉稿还原》一文中讨论了 AI 视觉还原的核心问题：设计稿信息到底应该以什么形式进入 Coding Agent 的工作流。我们提出了 “不建管道，建图书馆”的思路 —— 不替 Agent 生成代码，而是把设计稿整理成干净、分层、持续在线的视觉上下文，让 Coding Agent 按需查阅、自主实现。
这个方向是对的。但当我们带着这套系统走进更多真实业务场景时，两个更深层的挑战浮出了水面：
第一，设计稿的”原始质量”远比我们想象的复杂。当设计师的创作习惯、多人协作的历史痕迹、以及设计工具本身的特性叠加在一起时，”干净的视觉上下文”不是导出就能得到的，需要更深层的工程治理。
第二，即使上下文做到了极致，模型的输出依然有不稳定的时候。一次性生成不等于一次性做对。真正的质量收敛，需要一种新的工程范式。
第一章：一份设计稿引发的反思
1.1 当 Agent 碰到”混乱”
一般的视觉稿还原质量已经不错。但直到我们碰到一份真实业务的设计稿时，问题被彻底暴露了。
具体表现：
- 无论怎么调整提示词，Agent 都做不对关键区域 —— 比如出现元素缺失、位置偏移
- 会把不可见的图层还原出来 —— 设计稿中被隐藏的历史版本、被蒙版遮挡的底层元素，出现在了页面上
-
耗时异常漫长—— 看上去应该 10 分钟能完成的模块，跑了 30 多分钟还没结束
耗时异常漫长 —— 看上去应该 10 分钟能完成的模块，跑了 30 多分钟还没结束
最初我们以为是提示词的问题，反复调整 Skill 文档中的措辞和约束。但几乎没有改善。直到我们深入分析设计稿本身的结构，才发现问题的根源不在提示词，不在模型能力，而在上下文被「脏数据」填满了。
1.2 设计稿的五个结构性问题
打开这份设计稿的图层面板，我们看到了一个触目惊心的结构：
问题一：层次嵌套过深
一个”价格”文字，被 8 层无意义的空分组层层包裹。每多一层嵌套，Agent 通过 API 遍历到它就多一次调用、多一段上下文占用、多一层需要理解的结构关系。这些空分组本身不承载任何视觉信息，却大幅增加了 Agent 的搜索成本。
问题二：Flex 布局不一致
设计工具中的 Auto Layout（对应 CSS 的 Flex）经常出现这种情况：容器声明了 Flex 布局，但子节点的实际尺寸和位置与 Flex 语义不一致。Agent 在获取这些信息后，会忠实地按 Flex 方式实现 —— 但最终渲染出来的效果和设计稿大相径庭。
问题三：大量隐藏图层
上面「组2486」内的内容会被「组2490」覆盖。
上面「组2486」内的内容会被「组2490」覆盖。
设计过程中的历史版本、备份副本、被隐藏的替代方案 —— 这些在视觉上完全不可见的图层，在结构化数据中却是真实存在的。过去我们有基础的降噪（最多处理 5 层深度），但这份设计稿的隐藏图层远超预期，穿透了原有的防线。
问题四：图层规范度问题
图层”价格字体”的宽度为 156px，但实际文字”券后¥1699″只需要约 100px。多出来的空间意味着什么？文字是靠右展示还是靠左展示？当文字内容长度变化时，对齐方式会怎样？结构上的尺寸信息和视觉上的语义表达出现了不一致，模型很容易在这里做出错误判断。
问题五：属性冗余
父节点有白色背景，子节点也有一模一样的白色背景。如果父节点的尺寸完全包含子节点，那子节点的背景就是冗余的。更进一步，如果子节点本身没有其他视觉效果（没有边框、没有阴影、没有圆角），那这个子节点本身就可以被消除 —— 把它的子节点提升一层，结构更扁平、上下文更干净。
1.3 为什么设计稿结构如此重要
起初，我们把 Tarot Pixel 比作”视觉稿的图书馆”。Agent 查阅设计稿信息的过程，本质上是在一棵树上做检索 —— 每一次 API 调用获取一个节点的信息，然后决定是继续深入还是转向兄弟节点。
这棵树的深度和复杂度直接决定了检索效率：树越深，API 调用越多、上下文占用越大；节点越冗余，Agent 需要过滤的噪音越多；结构越混乱，Agent 推断语义的难度越大。
换个角度想：如果你和一个人沟通，他唠唠叨叨讲了一堆，但重点信息非常少，你们的沟通效率就会非常低。当脑子被塞满大量无用信息时，消化和判断就变得极其困难。
这就是我们面对的问题：不是 Agent 不够聪明，而是图书馆管理得不够好。
第二章：上下文工程 —— 降噪
我们之前认为，上下文工程的讨论主要集中在”信息如何分层暴露给 Agent”。三个月的实践让我们看到，上下文工程还有更深的一层：在信息到达 Agent 之前，源头数据本身就需要被深度治理。
2.1 一个月，50+ 次提交
在集中攻坚上下文工程的一个月里，Tarot Pixel 仓库新增了超过 50 次提交。其中绝大多数不是在增加新功能，而是在做一件听上去不那么性感但极其重要的事：降噪。
翻看这段时间的 git 日志，你会看到大量这样的提交信息：
refactor: 裁剪无可视样式的节点，包括图片fill
refactor: 彻底重写导出逻辑，删除不必要的所有属性，彻底简化节点模型
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 拿到的数据从”杂草丛生的森林”变成了”修剪整齐的树”。检索效率、上下文质量、还原准确度，都因此得到了实质性提升。
值得一提的是，降噪过程中我们也曾考虑更进一步 —— 比如在工程层为 Agent 预计算布局上下文（”这里应该用 Flex，gap 12px，方向 column”）。但测试表明，模型在布局推断上已经完全够用了，预计算反而是多余的。这给了我们一个重要启示：工程应该去补足 AI 的短板，而非侵入 AI 已经胜任的领域。 这条原则贯穿了后续所有的决策。
第三章：上下文做到位了，然后呢？
3.1 注意力涣散
经过降噪工程，上下文质量有了质的飞跃。但一个新的问题出现了：Agent 在处理复杂设计稿时，输出质量依然不够稳定。
同样的 Skill 文档、同样的 API，跑两次可能得到不同质量的结果。某些时候 Agent 忽略了显而易见的间距差异；某些时候它把背景色搞错了，但修正提示给过去之后又能立刻改对。
核心原因是什么？不是上下文不干净，而是上下文太大了。
核心原因是什么？不是上下文不干净，而是上下文太大了。
一个复杂的视觉稿可能包含数十个模块、数百个节点。即使每个节点已经被精心清洗过，总信息量依然庞大。模型的上下文窗口能容纳这些信息，但”能装下”和”能充分利用”是两回事。当窗口中同时存在大量视觉细节时，某些细节就是会被”看到但没被注意到”。
而当用户指出”这里不对”的时候，Agent 几乎总能很快修正。这说明模型不是不会做，而是注意力在第一次执行时没有聚焦到那个细节。降噪解决了信息的”纯度”，但没有完全解决信息的”体量”。
3.2 从指令到目标
面对注意力涣散的问题，我们尝试了三种方式：
方式一：写更好的提示词。 在 Skill 文档里加入更精确的布局原则、更严格的切图指南、更多的约束条件。这些相当于在 Agent 执行之前就把规则说清楚。确实有效，但效果有天花板 —— 提示词是”预设指令”，在 Agent 开始执行之前就已固定，它覆盖不了执行过程中所有可能遇到的情况。
方式二：完成后人工反馈。 Agent 做完了，人看一眼，指出”这里不对”，Agent 改。但我们的目标是减少人工干预次数 —— 真正要追求的不是”人能纠正”，而是”系统能自动纠正”。
方式三：给 Agent 一个持续的目标信号。 不告诉它怎么做，而是在它每次做完后，自动告诉它”你做的和目标差多远”，让它自己找到正确的修正路径。
这三种方式的差异，恰好可以用大模型训练中的概念来理解。方式一和二本质上都是 SFT（监督微调）—— 人预先告诉模型应该怎么做，或者事后告诉它做错了。而方式三对应的是 RL（强化学习）—— 设定目标，给出反馈信号，让模型自己学会怎么做得更好。
SFT 的核心问题是：指令在执行前就固化了，它依赖”人预见到所有可能的情况”。RL 的核心优势是：反馈发生在执行之后，而且是持续的，每一轮都根据实际结果给出新的方向。
我们需要的，正是方式三。
3.3 Loop Engineering
2026 年上半年，这种思路在 AI 工程领域有了一个明确的名字：Loop Engineering（循环工程）。
Andrej Karpathy 在 3 月做了一个标志性的实验（来源[1]）：630 行代码，让 AI Agent 对他手工调优了二十年的模型做自动优化。两天、700 次实验、20 个改进点 —— 其中一个是注意力机制中缺失的标量乘数，人类工程师二十年没发现。核心洞察不是”AI 更聪明了”，而是：人类在第 12 个实验后就疲劳了，循环不会。
一个循环的基本结构：执行 → 验证 → 反馈 → 修正 → 再执行。 它和单次提示的本质区别在于：反馈不是发生在执行前（提示词），而是发生在执行后（验证结果）。目标不是一次做对，而是逐步收敛。
Google 的 Addy Osmani 在他的 Agentic 自主性层级模型[2]中，将这种模式归入 Level 3 —— 目标驱动的自主性：Agent 为了达成目标采取一切必要手段，直到满足某个停止条件。他特别强调了一个前提：停止条件必须是可通过自动化测量的。 不要给 Agent “让页面更好看”这样模糊的目标，而要给可量化的标准。
他还提出了 Agent 每次运行前应有的”契约”：目标、范围、停止条件、证据、升级机制、预算。这六个要素，后来几乎成为了我们 Skill 文档的骨架 —— 目标是视觉一致，停止条件是 diff 收敛或 20 轮上限，证据是 diff 图和渲染树数据，升级机制是未收敛时交由人工。
第四章：把循环工程写进 Skill
4.1 “做 → 看 → 改” 闭环
理解了循环工程的思想之后，问题变成了：如何在视觉还原场景中落地？
理解了循环工程的思想之后，问题变成了：如何在视觉还原场景中落地？
我们在 Skill 中内置了一个”做 → 看 → 改”的收敛闭环：
做：Coding Agent 基于上下文工程提供的视觉信息，完成首次代码实现。
做：Coding Agent 基于上下文工程提供的视觉信息，完成首次代码实现。
看：调用 pixel-feedback 工具 —— 获取视觉稿截图（”标准答案”）、通过 Playwright 截取 Agent 实现的页面（”答卷”）、像素级对比生成 diff 图（”哪里答错了”）。
改：Agent 读取 diff 图和 diff 百分比，定位差异区域，通过双边取证（API 获取设计数据 + Playwright 获取实现数据）找到具体偏差项，定向修复。然后回到”看”。
这个循环直到所有可见差异都被解决，或达到 20 轮上限。
关键不在于”多跑几次”，而在于每一轮 Agent 都获得了明确的目标信号 —— diff 图和 diff 百分比告诉它”你离目标还差什么”。
4.2 验证器：精准的目标信号
Claude Code 团队在 2026 年 7 月发布了一篇关于”投入度（Effort）”的技术解读[3]，指出投入度控制的不只是模型”思考多久”，而是它总共愿意做多少工作。这个洞察对循环工程有关键意义：如果目标信号不够精准，投入度再高也是白费。
设想一下：如果只告诉 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 团队在他们的循环入门指南[4]中将循环分为回合式、目标式、定时和主动式四类。我们在 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
上面提到的视觉稿，在经过降噪之后，从节点数看，从 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 自主性层级分析[5]中有一句精准的收束：“验证，永远是最终的瓶颈。” 当 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平台。原文链接：https://mp.weixin.qq.com/s/cEqRXbamIofa0W93sMVtYg