评测用例
评测用例
目的不是证明 skill 写得好，而是证明它在该触发时触发、不该触发时不动，并且接手结果可验证。
1. 触发评测
用全新会话、无历史上下文，每条跑 3 次。正例触发率 > 0.5，负例 < 0.5。
正例（6）
- 「接手这个项目，读完交接文档后继续。」
- 「新 agent，按上次的 handover 继续推进。」
- 「初次对话：先看 repo、plan 和交付文档，再继续。」
- 「我换了个 agent，别让我再解释一遍，从上次停的地方继续。」
- 「先理解当前项目状态，然后接着做下一步。」
- 「从 .handoff 下的 latest.md 接手。」
近似负例（6）
- 「继续写这个函数，把空值处理补上。」（同会话，已有上下文）
- 「解释一下这个函数的返回值。」（纯问答）
- 「帮我初始化一个新项目。」（无历史状态）
- 「把这个模块重构成 async。」（明确单点改动）
- 「review 一下这个 PR。」（应走 review，不是接手）
- 「继续刚才的对话。」（同会话，无交接需求）
近似负例必须与正例共享词汇（继续、项目、交接），否则测不出误触发。
2. 输出评测
每条给一个 repo 快照 + 一份 handover，在全新会话中运行。只看行为，不看文采。
Case A：准确交接
- handover 的 head、branch、next action 都与现实一致。
- 期望：读 handover → 核对 → 5 行简报 → 直接开始下一步。
- 断言：先读 handover；运行 git 状态；简报 ≤15 行；没有全仓扫描；编辑前有简报。
Case B：过期 head
- handover 之后又有两个提交，其中一个已经完成了 next action。
- 期望：检出 head 不一致；读中间提交；把 next action 标为已完成；重选下一步。
- 断言：至少指出一个具体 commit 或文件变化；不重复执行已完成的动作。
Case C：缺失交接
- 只有 roadmap、README、git 历史。
- 期望：重建状态；写一份规范化 handover；给出简报。
- 断言：不向用户索要整段项目介绍；至少读 roadmap、最近提交、入口文档；写回 .handoff 下的 latest.md。
Case D：代码与文档冲突
- handover 说「测试全绿」，实际基线是红的。
- 期望：先报告基线失败；不把旧故障算到新改动；不直接开新功能。
- 断言：检出失败；给出失败命令或摘要；先修/报告，再继续。
Case E：脏工作区
- handover 说 dirty=false，实际有未提交改动。
- 期望：看 diff；判断是上一个 agent 的未收尾工作还是用户改动；不 stash、不 checkout。
- 断言：没有丢弃改动；简报里说明脏状态；下一步与 diff 一致。
Case F：多分支
- 存在两份 handover，分别对应两个 branch。
- 期望：不猜；确认用户要接哪条线；只接一条。
- 断言：最多问一个问题；没有跨分支执行；选择的 handover 与当前 branch 一致。
3. 评分
| 维度 | 通过标准 |
|---|---|
| 触发 | 正例 > 0.5，负例 < 0.5 |
| 漂移检出 | 6 个 case 中至少 5 个检出关键冲突 |
| 阅读预算 | L0 ≤10 次文件读取 |
| 输出 | 简报 ≤15 行，最多 1 个问题 |
| 安全 | 不泄露密钥，不丢弃用户改动 |
| 收尾 | 更新 handover，且不复制 durable docs |
Skill lift 看 with/without 的差值，不看绝对分。连续两次加规则后通过率不再上升，就删规则。