dhinakaran 说得直接：Skills 可能是去年 AI 领域最重要的发明，而 Skills 的评价和持续改进是 2026 年最关键的问题。

他们在工程团队中跑了整整一年的 Skills 迭代：自动化调试、数据分析、系统监控、代码审查、团队绩效分析。Skills 悄悄变成了团队运作的支柱。一个结论是：让一个 Skill 工作起来容易，让它真正工作好——那才是真正的工程发生的地方。

Skills 到底是什么

Skills 是一种奇怪的、强大的代码和文本混合体。不只是 prompt，不只是代码，而是 CLI 命令、bash 管道、结构化 prompt、预加载参考数据、自动化逻辑的混合——全部连接在一起完成一个特定任务。

它们看起来差异巨大：调试 Skill 主要是 CLI 调用和数据解析命令——从云基础设施拉日志、过滤事件、关联时间线。分析 Skill 在 LLM 处理之前就把数据通过多个转换管道处理。代码审查 Skill 读文件、检查模式、应用判断。Analytics Skill 拉数据、分析模式。

Skill 的形态决定了它的评价和改进方式——分析调试 Skill 和代码审查 Skill 的评价方法根本不是一回事。

评价三个维度

看一条执行轨迹，判断三个东西：

第一，它得到正确答案了吗？第二，需要多少次人工干预？第三，它跑得有多快、用了多少 API/Tool 调用？

让 Skill 变好的四种方式

实际优化一个调试云基础设施日志的 Skill 的过程——原始版本准确率大概 60%，但慢、有错误假设、CLI 调用经常用错 flag。最终每个改进都落在这四类里：

信息类改进：告诉 Skill LLM 一直搞错的事。比如"事件被批处理在 payload 数组内部，不在顶层"——一行话，一整类错误消失了。

修复失败调用：Skill 需要猜项目 ID 和 bucket 是什么，猜错、失败、再试。加一个路由表查找信息，4-5 次探索调用变成 1 次查找。

命令格式化：早期版本 AI 每次都从零写解析管道。迭代构建了一个经过实战测试的查询模板库，多次运行后精炼到输出恰好是工程师需要的样子。

架构信息：很多失败来自于对系统的误解——Skill 没有的系统架构信息。解决方案是让优化 Skill 把系统细节加回原始 Skill。

自进化循环

真正的循环是这样的：Skill 执行，评估轨迹，把学到的东西喂回去。诊断阈值、因果链、调查 playbook——全都来自 AI 观察自己犯错、和真实结果对比、自我改进。

Skill 变聪明不是因为有人坐下来写了手册。是因为每次执行都是一个训练信号，反馈循环把它捕捉到了。

未来的样子

现在的 Skills 是静态的，只有你推动它才会变。这是限制，不是特性。

对 Skill 评价的未来愿景：对标 AI 整体评价的愿景——评价是自动化的脚手架，不是终产品，是让你能自动化其他一切的基础设施。

未来图景：Skills 应该自动进化。评价检测到 Skill 性能下降（CLI 变了、数据格式变了、任务本身进化了），并建议修复——不只是标记回归，而是提出修复方案。定期优化运行，用最近的轨迹重新检查 Skill、收紧 prompt、更新模板、刷新预加载参考数据。当现有 Skills 在某个任务上彻底失败？系统建议写一个新的 Skill——不是几周后人发现缺口，而是评价脚手架自己识别出"这类任务一直在失败、现有 Skills 都不覆盖，这里有个新 Skill 草稿"。

"Skills 给 Agent 能力让它擅长某个工作。评价决定它能不能保持擅长——并变得更好。最先搞懂 Skill 评价的团队会是第一批实现改进循环自动化的。"