本文深入探讨了Skill在大模型开发中的重要性强调Skill不仅是业务说明书的堆砌更需要通过系统评测来验证其在真实场景中的稳定性和可靠性。文章详细阐述了评测Skill的三个关键标准输出评测、触发评测和回归评测并建议评测集应包含真实失败案例、业务契约和触发边界以形成可维护的Skill评测体系。最终评测帮助将业务经验转化为可回归、可比较、可维护的工程能力使Skill真正成为大模型可靠的业务能力包。很多人第一次写 Skill会把它当成一份“更懂业务的说明书”把流程、术语、注意事项写进SKILL.md再补几个references/文件似乎 Agent 就能稳定变强。但开源资料看下来一个很扎实的结论是没有评测的 Skill本质上只是 Markdown 和期待。 它可能偶尔有效也可能在关键场景里把业务规则误用、漏用甚至在不该触发的时候强行介入。真正的问题不是“这个 Skill 写得够不够详细”而是它能否在真实业务场景里稳定降低错误率它是否真的比不用 Skill 更好它修改以后旧能力有没有退化这些问题都不能靠感觉回答只能靠评测回答。我更愿意把 Skill 理解成一种“被压缩过的业务经验”。它把专家过去的判断、路径、禁忌和工具使用方式压缩成 Agent 可以按需调用的能力。但经验被压缩以后也会有损耗哪些信息被省略了哪些规则写得太硬哪些场景被误触发哪些判断被模型过度泛化这些都需要评测来发现。Skill 不是文档而是可复用的业务能力Anthropic 的skill-creator把 Skill 建设定义成一个循环先写 Skill再设计真实 test prompts分别跑with_skill和without_skill看输出和 benchmark再继续迭代。这个流程背后的判断很清楚Skill 不是写完就成立而是要证明它让 Agent 变得更可靠。这和我们过去写文档的习惯不同。文档的目标是让人读懂Skill 的目标是让 Agent 在任务中正确行动。它要能触发、能读取合适的上下文、能调用脚本、能遵守边界、能产出稳定结果。所以Skill 更像一个“可复用的业务能力包”而不是一份静态说明。SKILL.md只是入口references/是知识层scripts/是可执行层assets/是模板层。真正决定它有没有价值的是这些东西在任务现场能不能组合成正确行为。这就是为什么 Skill 需要评测。没有评测我们只能说“我觉得它有帮助”。有了评测我们才能说“在这些真实 case 上它比不用 Skill 少犯了哪些错”。这也是 Skill 和普通提示词的分界。提示词更多是一次性引导Skill 则会长期被复用。一旦它长期存在就会遇到版本漂移、业务变化、模型变化、团队成员误用等问题。评测不是为了追求形式完整而是为了让这个长期存在的能力有一个可回归的锚点。评测首先要回答它真的比不用 Skill 好吗AWS 的sample-agent-skill-eval很工程化。它不是只看 Skill 内容是否完整而是把 Skill 放进 eval同一个任务分别跑有 Skill 和无 Skill 的版本再比较断言通过率、触发准确率和执行成本。它甚至把这个过程设计成可以进入 CI/CD。这点非常关键。因为大模型本来就会完成很多任务如果一个任务不用 Skill 也能做对那 Skill 的贡献其实很有限。只有通过with_skill / without_skill对照才能看出 Skill 到底带来了什么。比如一个安全审计 Skill如果裸 Agent 已经能发现大部分问题那 Skill 的价值可能在于覆盖更细的风险编号、减少漏报、统一输出等级而不是“会不会审计”。再比如一个业务筛选 Skill裸 Agent 可能能写出一段看似合理的分析但 Skill 应该让它找到真实代码入口、区分状态边界、避免把筛选问题误判成 query rewrite。所以评测的第一层标准不是“输出好不好看”而是“有没有相对提升”。如果 Skill 不能在真实 case 上稳定超过 baseline它就还不是工程资产只是一个更长的提示词。这里还有一个容易忽略的点baseline 不一定永远是“没有 Skill”。当你已经有了一个旧版 Skillbaseline 就应该是旧版 Skill。评测要回答的问题也随之变化不是“有没有用”而是“新版是否真的更好”。这能防止一种常见误区为了修复一个失败案例给 Skill 增加很多强规则结果目标案例过了其他场景却被带偏。评测标准不是打分表而是业务契约复杂业务 Skill 最容易犯的错是用通用标准评测。比如“回答是否清晰”“是否包含步骤”“是否有总结”。这些标准当然有用但它们只能测表达测不出业务正确性。AWS Well-Architected Skill 的 eval 更值得借鉴。它不只写expected_output还拆出assertions、process_assertions、knowledge_assertions。也就是说它同时检查结果、过程和知识依据有没有覆盖完整问题集有没有引用具体最佳实践 ID有没有给出风险矩阵和优先级。业务 Skill 也应该这样。评测标准至少要分成四类。第一是触发标准什么问题应该触发 Skill什么问题不应该触发。DFINITY 的icskills把output_evals和trigger_evals分开就是因为 Skill 不是越积极越好。一个筛选链路 Skill如果在“帮我重写搜索词”这类普通问题上乱触发就会污染判断。第二是过程标准Agent 有没有走正确路径。它是否读了正确 reference是否定位到真实入口是否运行了必要检查是否跳过了关键验证OpenAI 关于 Agent Skill eval 的文章也强调 trace 和 artifacts因为最终答案看起来对不代表过程可靠。第三是结果标准输出是否符合业务事实。有没有说清楚状态流转有没有给出可验证步骤有没有命中专家答案第四是边界标准它不能做什么。复杂业务里边界往往比答案更重要。不能把 Native 状态当成 JS 状态不能把请求参数和 UI 派生状态混在一起不能在缺少关键日志时直接下结论。这些标准不是为了让评测显得专业而是把业务契约显式化。Skill 要评测的正是这些契约有没有被 Agent 遵守。如果评测标准只有“输出包含某些关键词”复杂业务 Skill 很容易过关。它可以提到入口、状态、缓存、协议却没有真正把它们串成正确链路。所以标准要尽量贴近业务动作是否定位了入口文件是否说明了调用顺序是否区分了数据来源是否给出了验证命令是否指出哪些结论需要更多证据。这些标准越像专家评审时真正会看的东西评测越有价值。复杂业务 Skill 的 Case 应该像事故现场很多评测集失败是因为它们只有 prompt没有现场。对简单任务来说一句话也许够但对复杂业务 Skill 来说一个 case 应该更像“可回放的事故现场”。FluxCD 的agent-skills提供了很好的例子。它的 GitOps 仓库审计评测不是只问“帮我分析这个 GitOps 仓库”而是让 Agent 分析tests/gitops-repo-audit/...里的真实目录结构再检查它是否识别出 monorepo、多集群、FluxInstance、HelmRelease、依赖链和风险项。这说明复杂业务 Skill 的评测集不应该是凭空编的题库而应该从真实场景中长出来历史 bug、人工返工、线上问题、代码 review、排障 transcript、业务 invariant、灰度规则和禁忌操作。一个最小可用的业务 case 可以保持很简单evals/ cases/ state-leakage-filter-case/ prompt.md # 用户真实问题 inputs/ # 日志、代码片段、接口返回、截图说明 expected.md # 专家期望答案 case.json # 来源、断言、评分说明这里最重要的分界是prompt.md和inputs/给 Agent 看expected.md和断言不给 Agent 看。否则评测就变成开卷考试测不出 Skill 是否真的理解业务。我更建议在case.json里保留source字段比如historical_failure、real_task、business_invariant。开源项目里不一定都有这个字段但业务团队需要它。因为过一段时间以后大家会忘记这个 case 为什么存在而评测集一旦失去来源就会慢慢变成没人敢删、也没人理解的样例堆。一个好的 case 还应该说明“它在防什么错误”。例如它不是泛泛地测试“能不能分析筛选链路”而是在防止 Agent 把状态泄漏问题误判为 query rewrite不是测试“能不能写发布流程”而是在防止 Agent 跳过草稿反查不是测试“能不能审代码”而是在防止它只看局部文件、不看真实调用链。case 的名字、来源和断言都应该围绕这个错误展开。这样做有一个好处评测集会天然变成业务知识库。每个 case 都是一段历史经验的压缩版本。新同事可以通过 case 理解业务风险Agent 可以通过 Skill 避免旧错误维护者可以通过评测结果知道哪些经验还有效。评测组织方式输出、触发、回归三条线一个 Skill 的评测不需要一开始做得很复杂但最好从第一天就分清三条线。第一条是输出评测。它回答“用了 Skill 以后结果是否更对”。基础字段可以很简单prompt、inputs、expected、assertions。断言不必一开始自动化先让人能判断就行。第二条是触发评测。它回答“什么时候该用这个 Skill”。AWS 和 DFINITY 都把 trigger eval 单独放出来一般就是正负样本should_trigger和should_not_trigger。这类评测非常适合防止 Skill 过度触发。第三条是回归评测。它回答“这次修改有没有破坏旧能力”。每次修 Skill都应该 rerun 目标失败 case再跑几个相邻 case 和 negative case。如果只跑当前失败很容易过拟合如果全量评测太贵就先跑小范围邻近集。这三条线组合起来才是一个可维护的 Skill 评测体系输出评测有没有解决问题 触发评测有没有在正确时机介入 回归评测有没有破坏旧能力第一版不要追求平台化。我会从 12 到 20 个 case 开始40% 来自真实任务30% 来自历史失败20% 来自业务契约10% 来自触发边界。等 case 多了、人工判断变累了再逐步加脚本 grader、LLM rubric 和 benchmark 面板。这个比例不是固定公式而是一种提醒不要一开始就让模型合成 100 个看似丰富的 prompt。合成 case 可以用但应该排在真实 case 后面。真实失败负责提供方向业务契约负责补边界合成变体只负责扩展表达方式。否则评测集会很快变成“模型喜欢回答的题”而不是“业务真的会出错的题”。评测组织也要克制。早期不要急着设计复杂平台先把 case 目录、专家答案和断言维护好。只有当人工判分开始变成负担时再把稳定断言抽成脚本只有当语义判断反复出现时再写 rubric只有当版本迭代频繁时再做 benchmark 面板。让 Skill 迭代变成工程实验Skill 评测最终解决的不是“怎么打分”而是“怎么迭代”。没有评测时修改 Skill 是凭感觉的加一句规则、补一段说明、塞一个 reference看起来更完整但没人知道它是否真的修好了失败是否引入了新误触发是否让 Agent 多走了没必要的路径。有评测以后每一次修改都可以变成一个小实验失败 case - 聚类成 failure mode - 判断问题在描述、知识、脚本还是 case 本身 - 做最小 Skill / reference patch - rerun 目标 case 邻近 case negative case - 只有通过率提升且无回归才合入Hamel 的 eval 观点也强调从 error analysis 出发先看真实错误再归类失败模式再写评测。这个方向非常适合业务 Skill。因为业务 Skill 的目标不是让 Agent “知道更多”而是让它在复杂现场里少走错路。这也是我认为复杂业务 Skill 必须评测的根本原因。复杂业务里最贵的不是模型不会而是它“看起来会”。它会给出流畅解释会引用一些文件会提出一个似乎合理的方案但关键边界错了最终让人返工。复杂业务 Skill 的评测其实是在训练团队识别“看起来会”的风险。一个回答有术语不代表它懂链路一个回答有代码路径不代表它找到了入口一个回答有修复建议不代表它考虑了副作用。评测标准越清楚团队越能把这些隐蔽错误提前暴露出来。评测集就是把这些错路提前固定下来。它让团队知道这个 Skill 过去在哪里错过现在是否还会错这个 Skill 新增的规则是不是只修了一个例子却破坏了其他例子这个 Skill 是否真的把业务经验转化成了稳定能力。所以Skill 的终点不是SKILL.md而是SKILL.md evals/。前者承载经验后者验证经验。前者告诉 Agent 怎么做后者告诉团队它做得是否可靠。没有 SkillAgent 只能临场发挥。有 Skill 但没有评测团队只是把经验写进了文档。有 Skill 也有评测经验才开始变成可回归、可比较、可维护的工程能力。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取