skills的创建、迭代、评估

无聊的感言：

也是好久没有认认真真写博客了，最近一直在进行相应的实习（主要是打杂），只能摸鱼时间进行相应的学习。今年感觉很多岗位给了AI岗，也是趁机进一步学习了关于skills的内容，在这里和大家进行相应的分享，这里很感谢B站的UP:

看了她的视频，我才感觉自己在慢慢的接收自学的方式，才会去尝试进行相应博客的耐心阅读

这一篇文章会包含多个部分很多的内容，这些主要是我在学习时和AI进行探讨记录的笔记：

skills创建

一、起源：为什么需要 Agent Skills？

核心矛盾

通用大模型（如 Claude）虽强，一旦落地到具体行业，就会撞上通用能力与领域专业知识之间的鸿沟。模型能写代码，却未必懂得如何填写一份政府 PDF 表单；能分析数据，却未必理解你们团队独特的工作流。

传统方案为何失效

简单 Function Calling：每次都要为单个任务造轮子，碎片化、难复用。
全量系统提示词：把全部专业知识塞入上下文，不仅挤占 Token 预算，还会让关键指令被"淹没"------模型的注意力被稀释，核心任务质量下降。

解决路径

Anthropic 提出的 Agent Skills ，本质是把领域专业知识打包成一个结构化文件夹 ，让智能体按需动态加载。其设计目标简单而有力：可组合、可扩展、可移植。

🧭 停下来想一想： 你手头是否有一个你非常熟悉、但大模型总是做不好的任务？如果让你把这个任务的"know-how"写成一份指南，你会担心指南太长塞不进提示词吗？这就是 Agent Skills 要解决的真实痛点。

为什么"渐进式披露"是基石？

答案藏在人类查阅手册的行为里：先看目录，再跳读相关章节，必要时才翻附录。Agent Skills 把同样的逻辑赋予模型，目的不是无限堆砌知识，而是用极少的初始成本换取随用随取的深度知识，始终守住上下文窗口这个稀缺资源。

💡 引导反思： 这一设计的成立，依赖一个假设------模型能够像人一样正确判断"我该用哪个技能"。如果模型判错了呢？你认为这个"判断"应该交给模型直觉，还是设置更死板的触发规则？

二、核心机制：三层渐进式披露

分层模型

整个技能加载被切分为三个清晰的层级，每一层都有明确的触发时机与上下文代价：

第一层：元数据（名称+描述）

- 加载时机：Agent 启动时，常驻系统提示词。
- 作用：嗅觉标签，让模型知道"我有哪些技能可用，何时该用"。
- 成本：每条仅几十 Token。

第二层：SKILL.md 正文

- 加载时机：模型判断任务相关时，一次性完整读取。
- 作用：可独立完成工作的精简指令集。

第三层：关联资源文件 （如 forms.md, reference.md）

- 加载时机：仅在需要更细分信息时，由模型主动跳转读取。
- 作用：深度参考，不拖累常规任务。

🧭 停下来想一想： "一次性完整读取正文"这个设定，与我们一开始猜测的"正文也渐进读取"不同。这里是不是有点反直觉？为什么不把正文也切碎？试着从"指令完整性"的角度想想：一份残缺的菜谱能指导做菜吗？

关键实现问题

① 元数据会消耗上下文，那岂不是不能无限加载技能？

是的，不能无限加载。 但 50 个技能的元数据总计也就相当于一段中等对话的长度，且换来的是零推理成本的全局感知。真实场景里一个 Agent 通常只需 5-20 个领域技能，"无限"本就不是目标。

💡 如何自己验证？ 你可以设计一个实验：在 Agent 的系统提示中逐步增加技能元数据，观察初始 Token 占用和回答质量的变化。你预测转折点会出现在第几个技能？

② 技能用完后，正文会从上下文中删除吗？

同一个会话里不会主动删除，它变成对话历史的一部分，直到被更靠后的新信息挤出上下文窗口（FIFO）。开启一次新会话，所有技能又回到只有元数据的初始状态------这是一种优雅的"自然遗忘"，兼顾了连续任务的效率和不同任务之间的安全性。

③ 如果技能正文被挤出窗口，模型会怎么办？

模型会表现出"不记得"，并可能再次触发该技能的读取。这正好反映了 Agent 的短时记忆机制。

🧭 反思时刻： 这种"用后即留，挤掉再读"的策略，你认为是优点还是隐患？比如在医疗诊断中，一个关键禁忌症被挤出窗口可能导致危险。这提示我们需要什么补充机制？（提示：可以想想 Critical Instructions 或护栏设计）

三、技能的设计与组织：从抽象到具体

技能目录结构

复制代码

skill-name/
├── SKILL.md          # 必选，入口（含 YAML 元数据 + 正文）
├── reference.md      # 可选，参考文档（第三层）
└── scripts/          # 可选，可执行脚本

SKILL.md 中的 Markdown 链接，正是连接第二层与第三层的"跳转门"。

元数据规范的精髓

元数据采用 YAML 前置块，关键在于描述要包含触发条件，而非泛泛而谈。

复制代码

name: pdf-editor
description: >
  用于编辑和填写PDF文档的技能。当用户需要修改PDF文件、填写PDF表单、
  或对PDF进行注释时使用。

一个糟糕的描述："与 PDF 有关的技能"------太模糊，模型无法判断时机。

💡 反思题： 你现在可以试着为一个你精通的任务写一条 30 字以内的元数据描述。写完后问自己：模型读完后，能准确区分"先别动""现在该用"吗？

设计案：医疗诊断 Agent 的技能包

我们将信息按以下逻辑分层，原则是：放嗅觉线索在第一层，放最小可用流程在第二层，放少见深挖的细节在第三层。

|-----|---------------------------------------|------------|
| 层级 | 医疗诊断示例 | 核心逻辑 |
| 第一层 | 胸痛鉴别诊断：当患者主诉胸痛、胸闷、心悸时使用 | 路由触发 |
| 第二层 | 关键病史采集 → 危险信号筛查 → 鉴别诊断逻辑树 → 输出格式 | 80% 任务一次完成 |
| 第三层 | TIMI-评分表.md、溶栓药物指南.md（仅在心源性确诊后加载） | 5% 深度需求 |

🧭 挑战一下： 如果突然需要增加一个"患者年龄<18岁"的儿科分支，你会放在哪一层？是第二层流程里的一个判断分支，还是第三层的一个新关联文件？思考一下触发频率和流程复杂度的平衡。

四、边界判断：何时"过度工程化"？

过深嵌套的三种伤害

推理成本：模型每多判断一层"是否需要深入"，就多一步推理延迟。
上下文污染：深层文件加载后留在记忆里，可能干扰当前主干任务。
维护噩梦：交叉引用形成循环，指南更新时极易遗漏。

三要素检查表

直接用这三个问题给技能做体检：

深度必要性：引用链超过 3 层了吗？
触发频率：下一层的使用概率是否低于 5%？
自包含能力：只看第二层能否处理 80% 的情况？

💡 实战练习： 回头看你自己的技能构想，里面有没有一个"只有不到 5% 用户会用到、但你却把它写在核心流程里"的知识点？如果有，尝试把它剥离开，放进一个关联文件。

五、生态定位：Skills、MCP、Tool Use 如何共处

能力栈分层

职权利要求

Skills：教你"怎么做" ------ 过程性知识，可组合，可复用。
MCP：提供"连接谁" ------ 标准化接口，像 USB-C。
Tool Use：执行"做一次" ------ 单次原子操作。

协同案例：智能招聘筛选 Agent

Skills：定义"简历筛选流程"（评分标准、分级逻辑、通知策略）。
MCP：连接简历库、日历系统、邮件服务。

🧭 场景推演： 假设公司从 Gmail 切换到 Outlook，同时决定把"文化契合度"的评分改由 AI 面试官完成。请问哪些部分需要改动 Skills？哪些只改 MCP 连接？如果 Skills 里混杂了邮件系统的具体 API 指令，会付出什么代价？

六、终极对比：渐进式披露 vs. RAG

|------|--------------|----------------|
| 维度 | 渐进式披露 | RAG |
| 加载单元 | 完整、自洽的逻辑流程 | 语义相似的知识碎片 |
| 决策权 | 模型基于任务理解主动选择 | 检索系统基于向量距离被动配给 |
| 知识结构 | 树状的目录层次 | 高维向量空间 |
| 最佳场景 | 复杂任务的执行规程 | 海量事实性知识的即时问答 |

💡 关键分歧时刻： 这两种策略看似都在解决"上下文窗口有限"的问题，但本质上 RAG 解决的是"信息在哪里"，而渐进式披露解决的是"能力如何组织"。你认为对于一个 Agent，能否将二者融合？试着构思一个场景：Agent 先用技能加载急救流程，过程中遇到需要最新药物剂量的地方，再调用 RAG 检索最新文献。请画出这个"流程推进+事实注入"的协同逻辑。

一个思想实验的结论

Agent Skills 赋予 Can do what，RAG 提供 Know what。 现代 Agent 架构的成熟形态，大概率是技能主干 + RAG 枝叶的结合。

skills的设计模式

1. 为什么我们必须学习设计模式？

我们从一个真实困境开始：你构建的 Agent 在演示时对答如流，但一进入需要多步骤精确执行的复杂任务，就开始遗漏关键步骤、在某个环节自由发挥、甚至使用了过时的 API 参数。

读到此处，不妨暂停一下：你自己的 Agent 开发经历中，最让你感到"失控"的一次是什么？是它跳过了步骤，还是它"创造"了你不需要的东西？

Google Cloud Tech 提出的 5 种 Agent Skill 设计模式 ，正是为了应对两大核心痛点：指令退化（上下文漂移） 和 Token 爆炸。本质上，它们在解决一个根本问题------如何在不灌爆上下文窗口的前提下，让大模型在正确的时机，严格遵循正确的规范，做正确的事。

2. 核心基石：Skill 不是工具，是"能力包装"

在深入模式之前，我们先校准一个关键定义。

什么是 Skill？

一个 Skill 是一个包含 SKILL.md（YAML 头 + Markdown 正文）的文件夹。它的三层架构是理解一切模式的基础：

L1 元数据层：名字、描述、触发短语。约 100 tokens。
L2 核心指令层：流程、约束、规则。一般不超过 5K tokens。
L3 参考知识层：按需加载的详细文档、代码示例。

Skill ≠ 工具

工具给 LLM 一把锤子（新的执行能力）。
Skill 告诉 LLM 在什么情况下用锤子，怎么握，从哪个角度敲，敲几下之后停下来检查。

这个类比很清晰，但请你此刻思考一个问题：如果 Skill 把"何时使用""如何执行"都规定得那么死，会不会扼杀 LLM 的创造力？边界在哪里？带着这个疑问看下面的模式。

渐进式披露：按需才可见

系统只在开始时注入所有 Skill 的名字和简短描述，只有当大模型判断需要时，才加载该 Skill 的完整指令和参考文档。这使得安装了上百个 Skill 的 Agent 依然保持轻量的上下文。

3. 五大设计模式逐次展开

以下五种模式，你可以将它们视为从"轻量级知识注入"到"重量级流程控制"的渐变谱系。

3.1 Tool Wrapper：最坚实的按需知识注入

核心机制 ：利用框架内置的 load_skill_resource 函数，在需要时把 references/ 里的规范文件注入上下文。

为什么它最"坚实"？ 因为在 adk-python 源码中，资源加载逻辑已被编码为 LoadSkillResourceTool，具备沙箱保护和标准化路径处理。你是站在框架的肩膀上，而不是纯靠提示词祈祷。

类比：全科医生 + 专科参考书书架。需要心脏病知识时抽出《心脏病学手册》，用完放回去，大脑还是同一个大脑。

注意，这里你可能会联想到微服务中的服务发现或插件化架构。但区别在于：Tool Wrapper 注入的是知识（指令、规范），而不是可执行代码。这种只注入知识的方式，安全性更高，但也意味着它不能教你全新的"动作"。你是否同意这个判断？

3.2 Generator：模板驱动的输出一致性

核心机制 ：将"格式规范"与"内容生成"分离。模板存放在 references/ 中，Agent 只需按规则填充内容，从而确保每次生成的文档结构一致。

类比：律师的合同模板。每次只需填入当事人、金额、日期，保障了法律条文的规范性和效率。

3.3 Reviewer：外部检查清单驱动的分级评审

核心机制 ：提供一个结构化的 checklist，强制 Agent 按 Critical / Major / Minor / Info 等级别进行审查，而非笼统的一句"你帮忙看看有什么问题"。

类比：飞机起飞前的检查清单。飞行员不能凭感觉，必须逐项打勾。

现在，你能否尝试把 Generator 和 Reviewer 的关系想得深一层？Generator 保证了"自己做出来的东西格式合规"，Reviewer 还要再查一遍格式吗？如果查，不就是冗余？如果不查，万一 Generator 漏了呢？这个矛盾我们会在后面的深度问题中专门讨论。

3.4 Inversion：先采访，再动手

核心机制：颠覆"用户指令 → Agent 执行"的传统流，强制 Agent 在行动前通过结构化问题澄清需求，确认边界。

类比：不是立刻画图纸的建筑师，而是先问"几口人住？""生活习惯如何？"的先发问者。

读到这，不妨设身处地想一想------如果 Inversion 模式连续问你五个问题，你会不会烦躁？作为设计者，你该如何在"问清楚"和"不惹烦用户"之间划下那条线？我们下面就要面对这个问题。

3.5 Pipeline：带检查点的多阶段流水线

核心机制 ：将大任务拆成顺序阶段，每个阶段有明确的 Activities、Outputs 和 Go/No-Go 决策点。Pipeline 可以嵌套其他模式，例如在开头放 Inversion 澄清需求，在末端放 Reviewer 复核，中间用 Generator 或 Tool Wrapper 生产。

类比：工厂流水线，冲压、焊接、涂装......上一站不合格，绝不流入下一站。

4. 直击实务的四重追问

上一部分我们看到了模式本身，但它们的真正考验在工程落地的细节里。

4.1 Inversion 的边界：提问的艺术与克制

如何在采访的数量与质量间平衡？我们需要从四个维度施加约束。

问题预算：最多 3 个问题，超过则改为输出一次性"需求确认单"。每个问题都必须提供默认选项。
优先级排序：P0 不澄清不安全（必须问），P1 影响效率（可跳过），P2 优化建议（不问）。
增量确认：完成一个阶段，展示成果，再问下一个关键决策。利用参与感降低烦躁。
情绪检测：当用户说"直接做""快点"，跳过所有非 P0 问题，并对 P0 采取最安全的默认值。

现在请你反思：上面的策略成立的前提是什么？前提是"用户知道自己在做什么，只是懒得说"。如果用户本身对需求也是模糊的，这些策略的效力会不会下降？届时你是该坚持采访，还是切换到"探索性原型"模式？

4.2 模式组合的冲突：Reviewer 发现问题后，该回到哪？

Pipeline 中 Generator 和 Reviewer 共存时，"回溯权"的矛盾必须被显式编码。

解决方案 ：在 Pipeline 的 SKILL.md 中建立一张"缺陷严重度 → 回溯阶段"映射表。

需求矛盾 / 方向性错误 → 回溯到 Phase 1 (Inversion)
Critical / Major 缺陷 → 回溯到 Phase 2 (Generator)，并附带精确的修复点
** Minor / Info 问题** → 原地修复，不重启流水线

裁判是谁？ 是规定好输出格式的 SKILL.md 本身。要求 Reviewer 必须输出 action 字段，Generator 必须写明"修复模式"（全量重做还是定点修改）。

注意，这里隐含了一个架构假设：Pipeline 的控制权是"中央计划型"的，而非"去中心协商型"的。如果未来你需要 Generator 和 Reviewer 互相博弈、自主协商修复方案，你还适合用 Pipeline 模式吗？还是应该考虑多 Agent 协作？这个问题将引向我们的下一组难题。

4.3 框架依赖风险：如何不让版本升级毁掉你的 Skill？

Tool Wrapper 的强大依赖框架级保障，反过来也受制于框架变更。唯一的防线是 Skill 级别的契约测试。

不要测试"框架内部怎么实现的"，而测试 "框架应该怎么对待 Skill"。

测试的三个关键契约点：

L1 可解析性：名字和描述在任何版本下都能被正确解析。
资源加载行为 ：用标准路径 references/... 能加载，尝试用 ../../ 逃逸会被沙箱拒绝。
渐进式披露链路：模拟大模型决策"需要某 Skill"后，技能被正确加载。

这一条经验能否平移到其他依赖框架的项目中？假设你正在用一个还在快速迭代的 LangChain 版本，为它写契约测试的核心思路是什么？试着把答案概括为一句话。

4.4 Token 预算的真实影响：60%-80% 的节省何时成真？

节省比例的数学本质是：

复制代码

Token 消耗 = 轮次 × (∑所有Skill的L1描述 + 被触发Skill的L2+L3)

降幅最大 （接近 80%）的场景：拥有大量 Skill（50+）、单次只用其中极少数、对话轮次长。
降幅最小（可忽略）的场景：仅 1-2 个 Skill、每次都用满全部 Skill、对话极短。

skills的评估

第一部分 · 为什么需要 Evals？------失效模式驱动的评估框架

1.1 从"看着不错"到"系统验证"

文章开门见山指出了一个普遍的困境：开发者构建完 Agent Skill，往往手动触发几次，输出"看起来不错"就发布上线。而在传统软件工程中，我们绝不会只凭肉眼判断代码是否正确------单元测试、CI 是标配。

🤔 引导：读到这儿，不妨先停一下。回想你上次部署一个 AI 功能时，你用了多少时间做测试？如果当时有人问你"你怎么知道它明天仍然靠谱"，你的回答会是什么？

这种"凭直觉上线"的方式会带来三类风险：

|---------------|----------------------|
| 风险类型 | 描述 |
| 无法区分改善与回归 | 看似更快，实则悄悄跳过了某个关键步骤 |
| 静默失效 | 没有报错，但结果不对劲 |
| 缺乏可追踪性 | 无法建立行为基线，团队只能凭记忆判断好坏 |

📌 核心论点 ：将软件测试思维引入 Agent Skill 开发，建立一套 系统化、可量化、可重复的 Evals，是保证质量的唯一可靠途径。它不是锦上添花的附加品，而是可执行的规格说明。

1.2 失效地图：Skill 失效的四条静默路径

文章没有直接抛出"测试框架"，而是先诊断"什么会出错"。这种从问题出发的设计思维，本身就值得我们借鉴。

作者把 Skill 的静默失效归纳为四条路径，形成了一张"失效地图"：

根本没触发（No Trigger）------最隐蔽，用户表达了需求但 Agent 没调用对应 Skill。
触发了但任务没完成（Outcome Failure）------该做的事没做完。
结果对了但过程走歪了（Process Failure）------例如先迁移再备份，最终文件都在，但下次迁移失败时就没有可用的备份。
完成了但质量不达标（Style/Efficiency Failure）------风格不符、token 浪费。

🔍 引导：上述四条路径，哪一类在你的项目中最容易发生却最不容易被发现？对于第三类（过程走歪），如果只看最终产物，你能否举出一个真实场景，证明"结果对"仍然意味着风险？

1.3 从失效路径反推成功标准

四条失效路径正好对应了四大评估维度：

|----------------|--------|--------------|
| 维度 | 对应失效 | 核心问题 |
| Outcome | 任务没完成 | 该做的事做了吗？ |
| Process | 执行路径错误 | 用对工具了吗？顺序对吗？ |
| Style | 质量不达标 | 输出符合规范吗？ |
| Efficiency | 资源浪费 | 绕弯路了吗？ |

⚠️ 注意：这里有一个隐藏的前提假设------你能够定义什么是"正确"的过程和风格。如果团队的规范本身是模糊的，那么 Style 评估就会失去锚点。这是不是意味着，想做好 Evals，得先内部对齐规范？不妨想想你的团队现在是否有一份公认的代码风格指南或者流程 SOP。

第二部分 · 评测方法的武器库

2.1 确定性检查：Outcome 的试金石

Outcome 通常有明确的"完成"标志（文件创建、命令执行），因此最适合用确定性检查------断言只能为"真"或"假"。

文章特别强调了小测试集的设计，必须覆盖三类场景：

显式触发：直接指令
隐式触发：日常用语
负样本：不应触发 Skill 的请求

🤔 引导：为什么负样本如此重要？如果只测显式触发，你的测试通过率可能虚高，但真实用户会用各种隐晦的表达，也可能要求完全不相干的功能。请你想像一下，一个"代码格式化" Skill，什么样的用户请求最容易导致"过度触发"？如果出现过度触发，最终损失的是什么？

2.2 基于评分规则的评估：Style 和 Process 的量表

有些质量维度不能简单用"通过/失败"一刀切，于是引入 Rubric（评分规则），设定优秀、良好、需要改进、失败等分级标准。其目标不是追求满分，而是快速定位特定的回归问题。

🔍 引导：这里有一个微妙之处------评分规则是由人编写的，它本身会携带编写者的偏好。如果团队里两位骨干对"良好的命名规范"理解不同，Rubric 会不会成为分歧的放大器？换作你，会用什么流程来让 Rubric 达成共识？

2.3 LLM-as-Judge：让 AI 评判 AI

当标准模糊到难以写规则时，可以引入另一个 LLM 做裁判。这是一种强大的方法，但作者也提醒：LLM-as-Judge 是概率系统，不同模型判断可能不同。

🧠 元思考：如果用一个 LLM 评估另一个 LLM 的输出，你如何确保评估的可靠性？这个问题没有标准答案，但值得记住：LLM-as-Judge 应当被保留给"人类评审"外的补充用例，并且最好和确定性规则搭配使用。

2.4 Trace 级评分：看见过程

Trace 分级提供了对智能体思维过程的逐步骤诊断，是唯一能暴露"结果对但过程错"的手段。我们会在第三部分专门深入。

第三部分 · 设计 Trace 级别评估

3.1 Trace 的本质：Agent 的"黑匣子"

Trace 记录了每一步工具调用、参数、时间戳和推理摘要，类似飞机的黑匣子。它让我们得以从飞行全程的操控动作中发现问题，而非仅仅看是否降落成功。

✈️ 类比：飞机安全降落，但黑匣子显示曾在跑道尽头急刹。Trace 评估就是去做那个读黑匣子的调查员。你的 Agent 曾经"降落"过吗？你是如何确认它没在半空做过危险动作的？

3.2 从"理想黄金路径"出发

设计 Trace 评估的起点，不是列举所有可能的错误，而是先定义一条正确的"理想路径" 。这通常可以直接从 SKILL.md 中的指令描述提炼出来。

例如，从"备份 → 验证备份 → 迁移 → 验证 schema → 写日志"的指令中，提取出期望的工具调用序列。

📝 引导：试着拿出你手头的一个 Skill，读一遍其中的步骤指令。你能从中提取出至少 4 步的理想调用序列吗？如果提取不出来，是不是意味着 Skill 本身的指令就不够明确？

3.3 四类断言

在理想路径的基础上，可以设计四类检查断言：

|-----------|---------------------------|---------------|
| 类型 | 示例 | 暴露的问题 |
| 顺序检查 | 备份 必须在 迁移 之前 | 前置依赖混乱 |
| 存在性检查 | 至少存在一次 verify_schema 调用 | 关键步骤跳过 |
| 缺失检查 | 没有 drop_table 调用 | 危险操作 |
| 参数级检查 | 备份文件名格式符合 backup_*.dump | 参数错误（即使碰巧结果对） |

⚖️ 思考：这四类断言各有各的稳定性代价。参数级检查最精准但也最脆弱------工具改名或参数微调就会误报。你如何决定哪些地方必须用严格的 L3 断言，哪些可以放松到 L1 语义层？优先级会因 Skill 的风险等级（如涉及数据删除 vs. 单纯格式化）而变化吗？

3.4 Outome+Trace 的组合逻辑

Trace 评估和 Outcome 评估不是"二选一"，而是**与门（AND）**关系：

|---------|-------|------------------|
| Outcome | Trace | 综合判断 |
| 通过 | 通过 | ✅ 合格 |
| 通过 | 失败 | ⚠️ 功能可用但过程有隐患 |
| 失败 | 通过 | ❌ 流程对但结果错，可能环境问题 |
| 失败 | 失败 | ❌ 全面失败 |

🧩 引导：这个矩阵让你联想到什么？它其实是我们评估架构的底层模型。如果 CI/CD 流水线只汇报"通过/失败"，就损失了丰富的信号。如何设计报告，让团队能区分"功能可用但有隐患"和"全面失败"？

第四部分 · 集成到 CI/CD：从研究到工程

4.1 将评估变成质量门禁

手工评估最大的问题不是不准，而是不持久 。集成到 CI/CD 的本质就是把 Skill Evals 从"开发者的记忆依赖"转变为系统级的强制检查，就像代码单元测试必须通过才能合入 PR。

💡 引导：如果你曾经忘记过跑测试导致线上事故，那么你一定深有体会。想像一下，当每次 PR 都自动运行评估并直接评论结果时，开发者的心理安全感受会怎样变化？会不会反而让人不敢改 Skill？

4.2 评估分层：测试金字塔的 AI 版

借鉴测试金字塔，我们设计了评估分层：

冒烟评估：3~5 个高价值用例，每次 push 都跑，<2 分钟。
变更触发评估：只跑与变更的 Skill 相关的评估。
全量回归：每日凌晨定时全量跑，生成趋势报告。

🏗️ 引导：这个分层解决了成本和反馈速度的矛盾。但实施的前提是，你需要一种方法根据文件路径自动映射到评估集。你的项目目前能仅凭 git diff 就能判断哪些 Skill 被修改了吗？如果不能，你会怎么建立这种映射？

4.3 门禁策略：柔性阻断

不是所有失败都值得阻断合入。可以定义：

|--------------------|---------------------|
| 维度 | 门禁策略 |
| Outcome 失效 | 阻断 |
| Process 严重违规（缺失备份） | 阻断 |
| Style 轻微偏差 | 警告 |
| Efficiency 轻微退化 | <10% 自动通过，>30% 阻断 |

⚠️ 矛盾点：这里其实隐含了一个权衡------严格的阻断会降低交付速度，但能提升质量。如果在早期迭代中 Skill 变化频繁，过于严格的阻断可能削磨团队的耐心。你相信应当在项目初期就设置硬阻断，还是先以警告模式运行一段时间，再逐步在关键点加码？

4.4 一个 GitHub Actions 的实例骨架

我给出了一个完整的 CI 工作流示例，包括冒烟、变更触发和全量回归三个 Job，以及如何通过 dorny/test-reporter 发布 JUnit XML 报告。

🛠️ 动手信号 ：这个示例你可以直接复制并改造。在动手前，不妨先确认：你的 Skill 仓库是否已经具备一个可命令行运行的评估脚本 run_evals.py？如果没有，那就是第一步。你觉得最难的部分是写这个评估脚本本身，还是设计流水线 YAML？