本文整理自 Warp 创始人 Zach Lloyd 分享的一个工程实践：如何用”观察者 Skill”自动评估并迭代改进另一个 Skill，让 Agent 的能力越用越强，而不是一次性交付后就放在那里”等老化”。

一、为什么 Skill 需要”自优化”

如果你已经在用 Claude / Warp 这类支持 Skill（技能包）机制的 Agent，大概都遇到过这种情况：

写好一个 Skill，跑一次效果不错，但总有些边缘案例翻车——可能是某个图标没渲染出来，可能是某段逻辑在特定输入下走偏。传统做法是人工发现问题、人工改 Skill 的文档/脚本，下次再跑。

但这件事本质上是可以自动化的：只要任务的产出存在明确的”验证标准”（能跑通、能对比、能打分），就可以把”评估—发现问题—改进”这个循环交给另一个 Agent 来做。

这就是本文要讲的”Skill 优化闭环”。

二、案例背景：网站迁移 Skill

文章作者举的例子很具体：他们做了一个名为 /replatform-site 的 Skill，作用是把跑在 WYSIWYG 无代码建站平台上的网站，自动迁移成可以自托管的代码项目（比如部署到 Vercel）。

他拿自己新搭的播客网站做了次实测：原站在某无代码平台上，迁移后的版本部署在 Vercel。整体迁移效果不错，但有一个明显的视觉缺陷——页面里几个下拉菜单的图标丢失了。

这种”基本能跑、但有具体的、可对比的瑕疵”的场景，正是构建优化闭环的最佳土壤。

三、核心思路：内层循环 vs 外层循环

这里有一个很关键的概念区分，决定了你应该优化”这一次任务”，还是优化”这个 Skill 本身”：

• ‎内层循环（Inner Loop）：针对这一次具体的迁移任务做修复，确保这个网站迁移成功、没有瑕疵。这是”把这件事做对”。
• ‎外层循环（Outer Loop）：针对 Skill 本身做迭代，让它下一次执行同类任务时，从一开始就表现得更好。这是”让这个能力变得更强”。

本文聚焦的是外层循环——也就是怎么让 Skill 自己越用越准。

四、具体做法：用一个”观察者 Skill”去评估并修改另一个 Skill

整套机制的设计模式是：创建一个”observer（观察者）Skill”，专门负责给”inner（内层）Skill”打分、找问题、生成改进方案。

具体执行链路是这样的：

1. 观察者 Skill 接收一批测试输入

比如这里是 N 个待迁移的网站列表。数量可以根据你想要的覆盖面去调整——做小范围验证用几个站点即可，要打磨出一个能广泛复用的 Skill，就要扩大样本量。

2. 调用内层 Skill，批量执行任务

观察者 Skill 会依次（或并行）调用 /replatform-site，对列表里的每个网站执行真实的迁移操作。

3. 用 Computer Use + Browser Use 做自动化质检

这一步是整个闭环里最关键的技术细节：观察者会把迁移后的网站实际构建起来，然后通过 computer use（计算机操作）和 browser use（浏览器操作） 能力，去打开原站和迁移后的站点做对比，检查：

• ‎视觉差异：截图比对，看排版、图标、样式是否一致；
• ‎行为差异：交互是否正常（比如下拉菜单能不能正常展开）。

同时，它还会记录每次迁移消耗的 token 数量，把”质量”和”成本”放在一起权衡——目标不是无脑堆资源去做到完美，而是在保证质量的前提下尽量压低成本。

4. 用 SOTA 模型做结果综合分析

把每一轮的检测结果（结构化数据）喂给一个能力更强的模型，让它去：

• 总结出有共性的失败模式（比如”图标类资源经常迁移失败”）；
• 找到可以改进的具体切入点。

这里有个细节值得注意：观察者 Skill 输出的是结构化数据，而不是一段模糊的文字总结。这样才能让后续做分析和建议的模型拿到足够精确的信息，给出有针对性的修复方案，而不是泛泛而谈。

5. 生成 Diff，自动改进内层 Skill

因为 Skill 本质上就是一组文件（Prompt、脚本、配置等），所以”改进 Skill”这件事，和”改代码”没有本质区别——可以让任意一个编程 Agent（文章里用的是 Warp）直接对 Skill 的源文件生成 diff，甚至提交 PR。

在实际跑下来的案例里，观察者 Skill 准确定位到了”下拉菜单图标丢失”这个问题，并针对性地生成了一版修复 /replatform-site 的改动。

6. 重复，直到收益递减

如果你想把这个 Skill 打磨到能支撑更大规模的实际使用，可以扩大测试样本，持续跑这个循环，直到观察者每次给出的 diff 变得越来越”无关紧要”——这通常意味着 Skill 已经收敛到一个比较稳定的状态。

很重要的一点是：观察者 Skill 内置了退出条件（exit criteria）。 不是无限循环跑下去烧 token，而是设定明确的停止标准，避免过度优化、浪费资源。

五、整体架构图

六、落地这套方案需要的基础设施

要把这个闭环真正跑起来，有两个硬性前提：

1. ‎支持多 Agent 编排的平台：观察者 Skill 本身要能调度内层 Skill、调度评分模型、调度改进模型，这是一个多步骤、多角色协作的流程，不是单轮对话能搞定的。
2. ‎支持 Computer Use / Browser Use：因为很多任务（尤其是涉及网页、UI、可视化产出的任务）只看文本输出是判断不出质量好坏的，必须要能”像人一样”去点开、去看、去对比。

文章作者用的是 Warp 内置的 Oz（支持跨多个顶尖模型的 computer use 编排），但强调这不是唯一选择，市面上有不少平台都能支撑类似能力。

七、这套方法的适用边界

这套打法不是万能药，作者自己也坦诚地指出了局限：

• ‎依赖明确的验证标准：只有当任务的”对/错”“好/坏”能被自动判断（视觉对比、行为测试、单元测试等）时，这套闭环才跑得起来。如果任务本身评判标准很模糊（比如”写一篇更有创意的文案”），自动化评分就很难做。
• ‎容易陷入局部最优：自动优化本质上是一种局部搜索，调优 Skill 本身的提升空间是有限的，迭代多轮后可能卡在一个”还不错但不是最好”的状态，很难指望它自己跳出这个局部最优。
• ‎需要成本意识：如果不设退出条件，理论上可以无限循环优化下去，实际意义却越来越小，纯粹烧 token。

八、如果你想自己动手做一遍：执行清单

把整篇文章的方法论收敛成一份可执行清单，建议这样开始：

1. ‎挑一个有明确验证标准的任务作为试点（网页迁移、格式转换、数据抽取等天然适合，因为产出可以直接对比）。
2. ‎先写好”内层 Skill”，能跑通基本流程即可，不用一开始就完美。
3. ‎再写一个”观察者 Skill”，让它具备三个能力：

• 批量调用内层 Skill 处理一组测试样本；
• 用合适的手段（截图对比、行为测试、computer use 等）对结果打分，并输出结构化数据；
• 用一个能力更强的模型去综合分析失败模式，生成对内层 Skill 的具体修改建议（甚至直接生成 diff）。

1. ‎给观察者 Skill 设定退出条件：比如连续两轮 diff 都是无意义的小改动，就停止迭代。
2. ‎小规模验证后再扩大样本量，逐步把 Skill 打磨到可以稳定支撑更广泛的真实场景。
3. ‎接受它不是终点：这套机制能帮你把 Skill 从”能用”打磨到”好用”，但别指望它能无限拔高上限——必要时还是需要人工介入做关键设计决策。

写在最后

这套方法论真正有价值的地方,不在于”网站迁移”这个具体场景,而在于它示范了一种通用的工程范式:把 Skill 当作可以被测试、被打分、被迭代的”软件资产”来对待,而不是写完就一锤定音的提示词。只要你的任务有办法被自动验证,这个”内层执行—外层观察评分—生成改进—回灾验证”的闭环,几乎可以套用到任何 Agent 能力的打磨上。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】