Add Milky notes: 20 file(s)

InBox/milky_BV1HWd6BsEmG.md

@@ -0,0 +1,321 @@
+---
+title: "[Milky] 为您整理《OpenAI：Skill的自动评分器怎么搭》笔记 | BV1HWd6BsEmG"
+source: "milky@4ueo.com"
+date: 2026-06-09 10:48
+tags: [milky, bilibili, notes]
+email_id: 1995
+---
+
+Milky 为您整理了《OpenAI：Skill的自动评分器怎么搭》| BV1HWd6BsEmG 笔记。
+
+OpenAI Skill 自动评分器构建指南
+
+一、为什么需要评分器
+
+当更新一个 Skill 并执行完成后，表面结果正常不代表真的变好了。核心问题是：
+
+Skill 是否真的完成了预期任务？
+修改是否引入了新的问题（回归）？
+如何在不同版本之间进行性能比较？
+
+评分器的职责就是回答这些问题，让 Skill 的质量变化可衡量、可追踪。
+
+
+二、运行轨迹记录
+
+2.1 什么是运行轨迹
+
+评分的前提是有东西可以打分。OpenAI 的做法是使用 CodeExec JSON 记录 Skill 的完整执行过程。
+
+2.2 配置方式
+
+`json
+{
+  "code_exec": true  // 启用后输出结构化执行记录
+}
+`
+
+2.3 记录内容
+
+启用后，Skill 每执行一步都会输出结构化记录，包括：
+
+跑了什么命令
+创建了什么文件
+执行顺序
+时间戳
+
+2.4 关键特性
+
+| 特性 | 说明 |
+|------|------|
+| 完整性 | 记录完整执行流程，而非日志摘要 |
+| 可解析性 | 结构化数据，可被程序直接读取 |
+| 可调试性 | 失败时可精确定位到具体哪一步出错 |
+
+没有运行轨迹，评分器只能看最终产物，无法分析执行过程。
+
+
+三、评分器类型
+
+3.1 确定性检查（Deterministic Checks）
+
+3.1.1 原理
+
+纯代码规则驱动的检查，不用大模型，写死判断逻辑，程序直接对着运行轨迹核对。
+
+3.1.2 典型检查项
+
+`
+有没有执行 npm install
+有没有创建 package.json
+命令执行顺序是否符合预期
+是否在指定目录执行操作
+`
+
+3.1.3 核心特性
+
+| 特性 | 说明 |
+|------|------|
+| 确定性 | 同样行为每次判断结果一致，没有模糊地带 |
+| 可调试 | 一旦失败，打开记录文件即可看到从哪一步开始偏离 |
+
+3.1.4 局限性
+
+确定性检查能回答"基础动作做了没有"，但无法回答"做出来的东西是不是你想要的样子"。
+
+
+3.2 评分细则检查（Rubric-based Checks）
+
+3.2.1 原理
+
+使用 LLM 作为裁判，读取仓库内容，按预定义的评分细则输出结构化打分结果。
+
+3.2.2 适用场景
+
+很多 Skill 的验收标准本来就是软性规则，例如：
+
+代码结构是否干净
+组件组织是否符合团队约定
+样式配置是否按既定风格落地
+命名规范是否遵循
+
+3.2.3 评分细则的拆解方法
+
+把模糊的质量标准拆成若干个可独立判断的维度：
+
+| 模糊标准 | 拆解后的维度 |
+|----------|--------------|
+| 代码质量好 | 组件是否按功能分目录 |
+| | 是否有未使用的引用 |
+| | 样式类名是否遵循命名约定 |
+| | 配置项是否集中管理 |
+
+3.2.4 关键要求：锁定输出格式
+
+必须提前定义输出模板，规定模型必须输出哪些字段：
+
+`json
+{
+  "passed": true/false,
+  "total_score": 85,
+  "dimensions": [
+    {
+      "name": "component_organization",
+      "score": 90,
+      "reason": "组件按功能正确分目录"
+    },
+    {
+      "name": "unused_imports",
+      "score": 70,
+      "reason": "发现3处未使用的import"
+    }
+  ]
+}
+`
+
+3.2.5 为什么必须锁死格式
+
+| 自由输出 | 锁死格式 |
+|----------|----------|
+| 每次措辞不同 | 格式统一 |
+| 无法跨版本比较 | 结果可量化 |
+| 无法进自动化流程 | 可直接集成 CI/CD |
+| 输出是"审稿意见" | 输出是"评估数据" |
+
+
+四、评分器组合策略
+
+4.1 分工明确
+
+`
+确定性检查 ──→ 抓底线（基础动作有没有发生）
+评分细则检查 ──→ 抓质量（做出来的东西像不像你要的）
+输出格式锁定 ──→ 防飘移（每次评分结果一致）
+`
+
+4.2 集成到流水线
+
+这套组合设计之初就面向 持续集成（CI）：
+
+不再依赖工程师手动触发测试
+成为持续运行的回归守门员
+Skill 每次更新都会自动验证
+
+
+五、6 类扩展检查
+
+在基础评分器之上，可按需叠加以下检查：
+
+5.1 命令数与循环检测
+
+`
+检查运行记录里执行了多少条命令
+`
+
+目的：检测行为退化
+
+案例：如果一个 Skill 以前 6 步能完成，现在要 18 步，表面上任务还是完成了，但系统正在变差。
+
+5.2 消耗量追踪
+
+`
+记录每次运行消耗的 token 数量
+`
+
+目的：防止 Skill 越来越臃肿
+
+每次执行越来越贵
+每次执行越来越慢
+
+5.3 构建检查
+
+`bash
+skill 完成后直接执行构建命令
+npm run build
+`
+
+目的：端到端验证
+
+很多项目表面完成，构建就露馅
+成本低，应该默认开启
+
+5.4 运行时冒烟检查
+
+`bash
+启动开发服务器
+npm run dev
+发送测试请求
+curl http://localhost:3000/api/health
+`
+
+目的：验证服务是否真正可用
+
+注意：这类检查更慢，按风险等级决定是否每次都执行。
+
+5.5 仓库清洁度检查
+
+`
+检查任务完成后是否出现不该有的文件
+`
+
+目的：确保系统没有被"弄脏"
+
+5.6 权限回归检查
+
+`
+验证 skill 是否还能在最小权限下正常工作
+`
+
+目的：防止权限漂移
+
+某次改动后悄悄开始依赖更高权限
+权限漂移在自动化后会变成结构性风险
+
+5.7 扩展策略
+
+`
+原文建议：先加快速检查，再按风险叠加慢检查
+         不是一次全上，是按需扩展
+`
+
+| 检查类型 | 速度 | 建议频率 |
+|----------|------|----------|
+| 命令数检测 | 快 | 每次 |
+| 消耗量追踪 | 快 | 每次 |
+| 仓库清洁度 | 快 | 每次 |
+| 构建检查 | 中 | 每次 |
+| 运行时冒烟 | 慢 | 按风险 |
+| 权限回归 | 慢 | 定期 |
+
+
+六、5 条核心原则
+
+原则一：量真正重要的东西
+
+Don't measure for the sake of measuring. First, think about what you'd actually care about if it got worse.
+
+不要为了有指标而有指标，先想清楚什么变差了，你会真的在意。
+
+原则二：先写清晰可检查的定义
+
+If the success criteria are fuzzy, the evaluation will be too.
+
+验收标准模糊，评估就没有意义。先把"什么叫做对"写成可执行的判断。
+
+原则三：把评估扎在真实行为上
+
+Record the full execution trace and write deterministic checks around the actual actions taken.
+
+记录 Skill 的完整运行轨迹，围绕实际执行的动作写确定性检查。
+
+原则四：规则不够时，再让模型补上
+
+Use rubric-based evals to handle quality judgments that rules can't cover, not as a replacement.
+
+用评分细则处理规则覆盖不了的质量判断，顺序不能反。确定性检查在前，LLM 评分在后。
+
+原则五：让真实失败去驱动样本增长
+
+Every time you manually fix something, turn it into a test case.
+
+每次手动修复都是一个信号，把它变成测试用例，让 Skill 持续把这件事做对。
+
+
+七、整体流程图
+
+`
+┌─────────────────────────────────────────────────────────┐
+│                    Skill 执行                            │
+└─────────────────┬───────────────────────────────────────┘
+                  ▼
+┌─────────────────────────────────────────────────────────┐
+│            CodeExec JSON 记录运行轨迹                     │
+└─────────────────┬───────────────────────────────────────┘
+                  ▼
+         ┌───────┴───────┐
+         ▼               ▼
+┌───────────────┐ ┌─────────────────┐
+│ 确定性检查     │ │ 评分细则检查     │
+│ (规则驱动)     │ │ (LLM 裁判)       │
+└───────┬───────┘ └────────┬────────┘
+        ▼                  ▼
+        └────────┬─────────┘
+                 ▼
+┌─────────────────────────────────────────────────────────┐
+│              结构化评估结果（跨版本可比较）                │
+└─────────────────┬───────────────────────────────────────┘
+                  ▼
+┌─────────────────────────────────────────────────────────┐
+│                   进入 CI/CD 流水线                       │
+└─────────────────────────────────────────────────────────┘
+`
+
+
+八、参考资料
+
+原文标题：Testing Agent Skills Systematically with Evals
+原文链接：https://developers.openai.com/blog/eval-skills
+视频来源：慢学AI（BV1HWd6BsEmG）
+
+──────────────────────────────
+— Milky 视频总结助手