Skills 全生命周期管理体系（SLM）项目进展说明

一、我们要解决什么问题

我们的笔记产品允许用户（或内部团队）编写 Skills。一个 Skill 就是一份指令文档（SKILL.md），告诉 AI 如何在特定场景下帮助用户处理笔记。目前我们已经有 28 个 Skill，但存在几个突出问题：

• 大部分 Skill 没有测试用例：21 个 Skill 缺少系统化的自动化测试，无法量化判断它们是否能正确完成宣称的任务。
• 没有笔记质量评估：一个 Skill 能跑通不代表它生成的笔记对用户有价值。结构是否清晰、信息是否冗余、有没有建立笔记间链接，这些都没有评估标准。
• 版本升级没有对比依据：改了新版 Skill 之后，无法客观判断是比旧版进步了还是退步了，只能靠主观感受。
• 没有发布门禁：哪些 Skill 可以上线、哪些有安全隐患、哪些还需要修复，缺乏统一、自动化的判定流程。
• 时间紧：4.22 必须交付可上线的管理系统。

二、我们在搭建什么

为了解决上述问题，我们正在搭建一套完整的 Skills 全生命周期管理体系（Skill Lifecycle Management，简称 SLM）。这套系统分为五个模块，覆盖从测试用例生成、执行对比、效果评估、到发布门禁的完整闭环。

---

模块 1：Eval Suite Factory（测例工厂）

功能：自动为每个 Skill 生成分级测试用例。

每个 Skill 都需要有一份自己的 "eval suite"（评测套件）。我们参考了 xsct.ai 的方法论，将测试用例分为三个难度等级：

• easy：标准输入、单一意图、1-2 步可完成，用来验证 Skill 的基础可用性。
• medium：组合意图、边界条件、需要多步推理，用来测试 Skill 的能力边界。
• hard：针对四种已知 AI 失效模式（长链推理衰减、自我修正失败、复杂约束处理、一致性崩溃），用来暴露 Skill 在压力下的天花板。

每个测试用例包含六个固定字段：

1. system_prompt：给评测系统的角色设定
2. prompt：模拟用户向 AI 发出的真实请求
3. requirements：3-6 条可观察的评分检查点
4. criteria：四个等级（excellent/good/fair/poor）的评分细则
5. reference_answer：参考答案，供 AI 评委对比
6. assertions：机器可检查的关键词断言

当前进度：

• 已编写 eval_generator.md 和 eval_reviewer.md 两个 Agent Prompt
• generate_suite.py 可以为一个 Skill 自动生成 9 条测试用例
• batch_generate.py 正在后台批量为剩余 27 个 Skill 补全测试用例
• skill-creator 的 eval suite 已经生成并可查看

---

模块 2：Execution Engine（执行引擎）

功能：运行测试并做三方对比（Triangulation）。

传统的 Skill 测试只做 "有 Skill 和没有 Skill" 的对比。我们的执行引擎支持三种配置同时跑同一套测试：

• vanilla：不加载该 Skill，看基础 AI 自己的表现（基线）
• reference：加载已发布的旧版本 Skill（目前如果没有旧版，则 fallback 为当前版）
• candidate：加载工作目录中的最新 Skill（待测版本）

通过这种方式，任何一次 Skill 版本升级都可以拿到三组数据，计算出 "相对基线的提升率"（Normalized Gain），避免凭感觉迭代。

当前进度：

• triangulate.py 已完成，支持并发执行和断言自动检查
• 目前尚未大规模跑测试，等待批量 eval suite 生成完毕后启动

---

模块 3：Note-Effect Evaluation（笔记效果评估）

功能：评估 Skill 输出的笔记在实际业务场景中的质量。

这是通用测试框架没有、但对我们产品至关重要的差异化模块。我们从五个维度打分：

1. Structure（结构）：标题层级、列表、格式是否清晰一致
2. Density（密度）：有没有废话，关键信息是否完整保留
3. Links（链接）：是否主动建立了笔记间的内部链接、标签、引用
4. Actionability（可执行性）：结论、下一步动作是否明确
5. Fidelity（保真度）：是否忠实反映源材料，没有编造内容

评分采用 Agent-as-a-Judge 模式，要求评委必须引用原文作为评分依据，避免幻觉评分。

另外，我们还做了 Claims-Based Coverage Scorer（承诺覆盖率评分）：

• 自动解析 SKILL.md 中写的 "我能做 X"
• 检查这些 X 是否被测试用例或评分维度覆盖到
• 输出 Coverage Score = 已验证的承诺数 / 总承诺数

当前进度：

• note_judge.md Agent Prompt 已完成
• coverage_scorer.py 已完成，可跑通单 Skill 的 claims 提取和覆盖率计算

---

模块 4：Lifecycle Management（生命周期管理）

功能：版本注册、发布门禁、安全扫描、打包控制。

这是 Skill 能否上生产环境的最后一道关卡。每个 Skill 会被判定为三种状态之一：

状态	判定标准
certified	easy 通过率 ≥90%，medium ≥80%，hard ≥60%，coverage ≥70%，note judge ≥6.5，stability ≥0.8，无安全问题
provisional	easy 通过率 ≥70%，medium ≥50%，coverage ≥50%。基本可用，但有小缺陷
blocked	未达到 provisional 标准，或有安全/兼容性等严重问题

包含四个核心脚本：

• skill_registry.py：扫描全部 28 个 Skill，生成 registry.json 注册表
• security_scanner.py：静态扫描脚本中的危险模式（eval()、rm -rf、硬编码密码、未授权网络请求等）
• release_gate.py：根据测试数据和安全扫描结果，输出每个 Skill 的发布状态
• package_gate.py：仅允许 certified 和 provisional 状态的 Skill 进入发布包（.skill 文件）

当前进度：

• 四个脚本均已写完并跑通
• 首次 Registry 和安全扫描已完成：28 个 Skill 全部在册，安全扫描 0 个高危问题
• 由于 21 个 Skill 还没有 eval suite，首次 Release Gate 暂时全部为 blocked，这是预期结果

---

模块 5：Dashboard & CI（仪表盘与持续集成）

功能：让上述流程自动化、可追踪。

• GitHub Actions 工作流（.github/workflows/skill-ci.yml）：
  • PR 阶段：自动跑 quick_validate.py + 仅测试变更的 Skill
  • Release 阶段：全量跑 triangulate、registry、security scan、release gate
• HTML Report：未来会基于 skill-creator 的 generate_review.py 扩展，支持跨版本 benchmark 可视化对比

当前进度：

• CI 脚本已完成
• HTML 报告生成器待 triangulate 数据积累后扩展

三、当前项目基线

指标	数值
总 Skill 数量	28
已有 eval suite	1 个（skill-creator）+ 正在后台批量生成
已修复阻塞项	Python 3.9 兼容性问题已修复
安全扫描高危问题	0 个
Registry	已生成
Release Gate 结果	暂时 28 个 blocked（因缺少测试数据）

四、关键交付物清单

当前已产出的文件：

• skill-lifecycle-management-bundle.zip：SLM 核心代码包（含所有脚本、Agent Prompt、CI 配置、当前报告）
• skill-creator-eval-suite-example.json：自动生成的 eval suite 样例
• Skills_测评与管理体系方案_建议稿.docx：前期方案文档