# Anthropic 参考对 Investibook Daily Regression 的意义

**Date:** 2026-04-21
**Status:** Reference note

---

## Summary

这份文档用于说明：

- Anthropic `skill-creator` 文档里 “Running and evaluating test cases” 这部分，为什么对 Investibook 当前的 regression / evaluation 重设计有参考价值
- 这种参考价值具体落在哪些设计点上
- 哪些内容应该吸收为 daily regression 的方法论
- 哪些内容不能直接照搬到 Investibook 的 scheduled daily path

结论先行：

- **参考价值很高**
- 但这种价值主要体现在 **benchmark / evaluation 方法论**
- 而不是它原始的 **forward-testing 运行形态**

换句话说：

> Anthropic 提供的是“如何把评测做成闭环”的思路，而不是 Investibook daily regression 的现成执行蓝图。

---

## 背景

Anthropic 这部分文档原始语境是：

- 用测试用例评估 skill 的表现
- 通过 forward-testing 和人工 review 发现问题
- 再迭代 skill 内容

它更偏向：

- skill hardening
- benchmark with review
- iterative improvement

而 Investibook 当前要解决的问题是：

- 建立 case-based 的长期回归系统
- 每天稳定地跑固定 suite
- 做 baseline diff
- 发现 regressions
- 控制 token / runtime / follow-up 成本

因此，两者的目标部分重叠，但并不完全相同。

---

## 为什么它仍然值得参考

尽管原始目标不同，这份 Anthropic 文档对 Investibook 仍然有很强参考意义，原因在于它回答了几个更底层的问题：

### 1. 什么样的输入才算正式 test case

Anthropic 的 test case 不是一段随意 prompt，而是一组结构化评测输入：

- 固定任务
- 固定期望
- 固定 assertions
- 固定 metadata

这和 Investibook 当前从 “workspace replay” 升级到 “case/suite/baseline/regression” 的方向完全一致。

### 2. 什么样的评测结果才可复用

Anthropic 不只看单次 output，还会保留：

- benchmark 结果
- timing
- grading
- review 产物

这说明一个成熟评测系统里，真正重要的不是“跑了一次”，而是“留下了可比较、可追溯、可复查的 artifacts”。

这正好对应 Investibook 需要建设的：

- `eval_run`
- `eval_case_run`
- `eval_judgment`
- `eval_regression`
- token / timing / cost 指标

### 3. 成功标准必须显式化

Anthropic 的核心启发之一是：

- 不要只凭感觉判断“好像变好了”
- 要把成功条件写成 assertions / benchmark criteria

Investibook 当前的设计里，这对应：

- `rubric`
- `negative_assertions`
- deterministic-first judgment

这不是可有可无的增强项，而是 daily regression 能否稳定成立的基础。

### 4. 自动评测和人工 review 需要分层

Anthropic 不是让所有东西都自动判掉，也不是让所有东西都靠人看，而是形成：

- 自动 benchmark
- review viewer
- 人工补判和反馈

这与 Investibook 的 three-layer judge 很契合：

- execution checks
- deterministic rubric
- semantic judge
- 人工 review 兜底

### 5. 评测应该形成闭环，而不是一次性报告

Anthropic 的方法论不是“跑完结束”，而是：

- 发现问题
- review
- 再测
- 更新 baseline / benchmark 理解

这与 Investibook 主设计中强调的：

- rerun
- review
- promote baseline
- regression 运营闭环

高度一致。

---

## Anthropic 可迁移的核心方法论

下面这些点，适合直接吸收到 Investibook 的 evaluation 体系里。

### 1. 固定 case 集，而不是 ad hoc 会话

Anthropic 的做法本质上强调：

- 评测必须建立在一组可重复运行的 test cases 上

对 Investibook 来说，这强化了下面的判断：

- daily regression 不应建立在“最近又出现了哪些 workspace”之上
- 而应建立在固定的 case corpus / suite 之上

这支持：

- `core-daily`
- `daily-lite`
- `weekly-extended`

这样的 suite 设计。

### 2. baseline / candidate 必须可比较

Anthropic 很强调 baseline 与 candidate 的可比性。

虽然它的原始实现更接近同轮并排跑，但更重要的不是“必须双跑”，而是这个原则：

- 同一批 case
- 同一套 assertions
- 同一类输出 contract
- 尽量同一条件

对 Investibook 来说，这意味着：

- baseline diff 必须建立在稳定 case + 稳定 judge + 稳定 artifact contract 上
- baseline 与 candidate 至少要共享 `case version`、`judge version`、`follow-up policy` 等关键条件

### 3. success contract 必须显式

Anthropic 的 test case 不是模糊描述，而是：

- expected behavior
- assertions
- metadata

这对 Investibook 的直接启发是：

- `expected.md` 只能做人类可读说明，不足以支撑正式 regression
- 正式 regression 的执行真值必须下沉到 `case.yaml`
- `rubric` 与 `negative_assertions` 应成为正式 contract

### 4. 评测不只是 correctness，也要记录运行特征

Anthropic 会关心 benchmark 结果之外的运行信息。

对 Investibook，这意味着 daily regression 不应只关心：

- pass / fail

还应记录：

- duration
- token usage
- semantic judge count
- cache hit rate
- follow-up rounds

因为一个 case “还过得去”，并不代表它没有在：

- 变慢
- 变贵
- 变脆弱

### 5. 评测结果必须可 review

Anthropic 的方法论不是把 benchmark 结果藏在脚本输出里，而是明确提供 review surface。

这支持 Investibook 当前对子页面的规划：

- `/admin/evaluation-runs`
- `/admin/evaluation-runs/[runId]`
- `/admin/evaluation-cases/[caseId]`
- `/admin/evaluation-regressions`

即使 v1 不做很重的 human-review workflow，也应保证：

- fail case 可被复核
- baseline diff 可被阅读
- 失败原因可被定位

### 6. 评测应当驱动下一步动作

Anthropic 方法论的关键不在“做出分数”，而在“分数之后怎么办”。

对 Investibook 来说，这对应：

- rerun failed cases
- review disputed cases
- 修 prompt / skill / tool adapter
- promote baseline

如果 daily regression 不能驱动这些动作，它就只是一个 dashboard，不是质量保障系统。

---

## 不能直接照搬的部分

Anthropic 的参考价值很高，但有几类内容不适合直接搬到 Investibook 的 daily scheduled path。

### 1. 不能把 forward-testing 当成 daily 默认模式

Anthropic 的原始语境是：

- skill 改完后，用 forward-testing 去 stress test

这适合：

- 快速打磨 skill
- 探索失败模式
- 对新版本做 richer comparison

但不适合 Investibook daily regression 的默认形态，因为 daily regression 需要：

- 稳定
- 低抖动
- 可控预算
- 易解释

forward-testing 默认会引入：

- 更多环境波动
- 更多交互差异
- 更多运行成本

### 2. 不能把 live task / exploratory loop 作为正式输入

Anthropic 允许从真实任务出发做评测。

Investibook 的 daily regression 不应这么做。原因是：

- live task 会变化
- 外部数据会漂移
- 最近 incident 分布不稳定
- user phrasing 不稳定

这会污染 baseline 信号。

因此 daily regression 仍应坚持：

- frozen input
- fixed suite
- stable replay artifacts

### 3. 不能把 paired rerun 当成 nightly 默认行为

Anthropic 的思路里，baseline 与 candidate 可以在同一轮并排比较。

对 Investibook 而言，这种做法适合：

- manual rerun
- pre-promote validation
- 大改动后的专项比较

但不适合 daily 默认流程，因为：

- 成本翻倍
- execution noise 增大
- 调度和持久化复杂度上升

daily 更合理的做法是：

- 当前 run 与 persisted baseline 做结构化 diff

而不是每天双跑 baseline 和 candidate。

### 4. 不能把多轮 follow-up 作为 daily 主流程

Anthropic 和当前 `replayer` 都比较重视 interactive follow-up。

这对手工验证很有价值，但 daily regression 的目标不是“在线把 agent 调对”，而是“监控是否退化”。

因此：

- follow-up 在 daily 中应当是例外，而不是默认
- 多轮 follow-up 更应属于 manual rerun lane

### 5. 不能让 transcript-level quality analytics 混入 regression substrate

当前仓库里已有一套 `/api/admin/evaluations*`：

- correction_count
- tool_calls
- mtta
- conversation transcript 级别 LLM summary

这类能力适合做：

- workspace quality analytics
- retrospective analysis

但不适合承载正式 daily case regression。

Anthropic 的参考会加强 benchmark thinking，而不是支持继续把 transcript quality 打分扩展成 regression 引擎。

---

## 更合理的吸收方式：拆成两条 lane

Anthropic 的参考最适合被吸收到一个“双 lane”模型中。

### Lane A: Scheduled Daily Regression

目标：

- 稳定
- 可比较
- 低抖动
- 预算受控

建议特征：

- fixed suite
- frozen artifacts
- deterministic-first
- semantic judge on demand
- persisted baseline diff
- CronJob + runner

这条 lane 的重点是：

- 检测 regression
- 输出结构化 verdict
- 记录成本与运行特征

### Lane B: Manual Rerun / Review / Pre-Promote Validation

目标：

- 深挖 fail case
- richer comparison
- human review
- validate big changes

建议吸收的 Anthropic 特征：

- paired candidate-vs-baseline rerun
- richer output review
- human notes / feedback
- exploratory follow-up
- benchmark surface for deeper inspection

这条 lane 的重点是：

- 解释为什么回归
- 判断是不是 false positive
- 决定是否 promote baseline

---

## Anthropic 到 Investibook 的具体映射

| Anthropic 概念 | Investibook 对应物 | 适合进入 daily v1 吗 |
|------|------|----------------|
| test case | `case.yaml` + `expected.md` | 是 |
| expected output / assertions | `ground_truth` + `rubric` + `negative_assertions` | 是 |
| eval metadata | `eval_run` / `eval_case_run` / `eval_judgment` / `eval_regression` | 是 |
| timing / benchmark | token、duration、judge metadata、run summary | 是 |
| benchmark viewer | admin run / case / regression 页面 | 是 |
| analyst review | failure taxonomy + manual review page | 部分是 |
| paired baseline vs candidate runs | manual rerun / pre-promote validation | 否，非 daily 默认 |
| interactive follow-up loop | `manual-debug` 或人工 rerun lane | 否，非 daily 默认 |
| feedback file / iterative edits | intervention / review artifacts | 否，偏 manual |
| forward-testing loop | change validation workflow | 否，非 daily 默认 |

---

## 对当前设计最有价值的启发

如果只保留最有价值的部分，我认为 Anthropic 参考对当前 daily regression 最重要的意义有 5 条：

### 1. 强化 `case.yaml` 的必要性

当前 `tools/replayer/cases.yaml` 仍然偏薄，只够做 replay 入口，不够做正式 evaluation case spec。

Anthropic 的 test case 结构说明：

- 正式 daily regression 必须有 richer case spec

### 2. 强化 `rubric + negative_assertions` 作为主 contract

Anthropic 把 assertions 视为 benchmark 核心。

这支持 Investibook 把：

- deterministic rubric
- negative assertions

放到主 gate，而不是继续以 transcript-level 语义评价为主。

### 3. 强化 run metadata 与 benchmark surfaces 的必要性

Anthropic 的评测不是黑盒。

这支持 Investibook 从一开始就认真设计：

- run summary
- case history
- regression page
- timing / token / cost metrics

### 4. 强化 manual review lane 的正当性

Anthropic 的方法论说明：

- benchmark 并不排斥人工 review
- 相反，人工 review 是复杂边界 case 的必要补充

这帮助 Investibook 避免两个极端：

- 全靠 deterministic rules
- 全靠 semantic / 人工全文阅读

### 5. 强化“评测闭环”而非“评分页面”的产品思维

Anthropic 的 benchmark 最终服务的是改进动作。

这与 Investibook 要做的：

- rerun
- review
- baseline promote
- regression 运营

高度一致。

---

## 最终判断

可以把 Anthropic 文档对 Investibook 的参考意义概括成三句话：

1. 它对 **daily regression 的 benchmark 思维** 很有帮助。
2. 它对 **manual rerun / review lane 的交互形态** 更有直接帮助。
3. 它不适合作为 **scheduled daily runner 的直接实现模板**。

因此，更准确的吸收方式应该是：

- **daily path 学它的 benchmark 方法论**
- **manual lane 学它的 paired review / richer review 机制**
- **不要把其 forward-testing 运行方式直接复制进 nightly regression**

---

## 建议纳入 v1 的点

- `case.yaml` 作为正式 case spec
- `rubric` / `negative_assertions` 作为 success contract
- `eval_run` / `eval_case_run` / `eval_judgment` / `eval_regression` 作为正式结果对象
- 记录 timing / token / cost / judge metadata
- 提供 run list / run detail / case history / regressions 页
- 对 fail/regression case 预留 manual review 入口

---

## 建议放到 manual lane 的点

- paired baseline-vs-candidate rerun
- 多轮 interactive follow-up
- 更重的人类 review 流程
- richer feedback capture
- issue triage / fix-plan authoring
- 变更前的 exploratory forward-testing

---

## 补充说明

下面两组问答，用来补充解释前文里最容易被误解的两个点。

### Q1. 为什么说有些 Anthropic 做法不能直接参考到 daily scheduled path

这里的“不能参考”更准确地说，是：

- **不能直接把其运行形态照搬到 Investibook 的 daily regression 主流程**

而不是说 Anthropic 文档整体没有参考价值。

原因主要有 5 类：

#### 1. 目标不同

Anthropic 原始语境更偏：

- skill hardening
- forward-testing
- 探索失败模式
- 为迭代提供 richer comparison

而 Investibook 的 daily regression 主目标是：

- 稳定
- 可比较
- 低抖动
- 预算可控
- 易解释

因此，适合“探索”的机制，不一定适合“稳定监控”的主路径。

#### 2. 输入稳定性要求不同

Anthropic 可以从 live task / exploratory loop 出发做评测。

但对 Investibook 的 daily regression 来说，如果正式输入来自：

- 实时任务
- 最近 incident
- 不稳定用户 phrasing
- 持续变化的外部数据

那么 baseline 信号会被污染，导致：

- 看到的 diff 不是系统退化
- 而只是输入条件变化

所以 daily path 必须坚持：

- frozen input
- fixed suite
- stable replay artifacts

#### 3. 成本与噪声约束不同

Anthropic 那种 paired baseline-vs-candidate rerun，在 change validation 或人工 review 时很有价值。

但如果把它作为 daily / nightly 默认行为，会带来：

- 成本接近翻倍
- execution noise 增大
- 调度复杂度上升
- 持久化和比较逻辑变重

因此 daily 更适合：

- 当前 run 与 persisted baseline 做结构化 diff

而不是每次都双跑 baseline 和 candidate。

#### 4. daily 的目标不是在线把 agent 调对

Anthropic 和当前 `replayer` 都重视 multi-turn follow-up，这对手工验证和深挖问题很好。

但 daily regression 的主目标不是：

- “现场补救，让 agent 最终做对”

而是：

- “监控系统是否相对 baseline 发生退化”

所以：

- follow-up 在 daily 中应当是例外
- 多轮 follow-up 更适合放到 manual rerun / review lane

#### 5. transcript analytics 不是正式 regression substrate

像下面这类 transcript-level 指标：

- correction_count
- tool_calls
- MTTA
- transcript summary

更适合：

- workspace quality analytics
- retrospective analysis

它们可以帮助理解行为，但不适合直接充当正式 daily case regression 的主判据。

daily regression 仍然应建立在：

- case
- rubric
- assertions
- structured judgments
- baseline diff

这样的 benchmark substrate 上。

### Q2. 具体可以参考 Anthropic 的哪些 benchmark 方法论

最值得借的不是 forward-testing 的运行形态，而是“什么才算一个成熟 benchmark 系统”的方法论。

#### 1. test case 必须是结构化对象，而不是一段 prompt

一个正式 benchmark case 不应只是：

- “拿一段 prompt 跑一下”

而应该包含：

- 固定任务
- 固定期望
- 固定 assertions
- 固定 metadata

映射到 Investibook，就意味着 daily regression 的最小单位应当是：

- 带版本的 `case.yaml`
- 配套的人类可读说明
- 冻结的输入与 artifact

而不是 ad hoc replay。

#### 2. success contract 必须显式化

Anthropic 的核心启发之一是：

- 不要靠“看起来差不多”来判定 benchmark 是否通过

而要把成功标准写成：

- expected behavior
- assertions
- metadata

对应到 Investibook，应落实为：

- `ground_truth`
- `rubric`
- `negative_assertions`

其中：

- `expected.md` 更适合做人类说明
- `case.yaml` 才应承载正式 machine-checkable contract

#### 3. baseline / candidate 的“可比性”比“双跑形态”更重要

Anthropic 很强调 baseline 与 candidate 的可比较性。

这里真正值得借的是原则，而不是“每天双跑”这种形态。

也就是说，只有在下面这些条件一致时，diff 才有意义：

- 同一个 `case version`
- 同一个 `judge version`
- 同一类 artifact contract
- 同一类 follow-up policy
- 尽量一致的执行条件

这是一种 benchmark 设计原则，而不是某种固定 runner 实现。

#### 4. benchmark 结果必须沉淀为可追溯 artifact

成熟评测系统里，重要的不是“某次跑过了”，而是“这次运行留下了可比较、可追溯、可复查的结果对象”。

对 Investibook，这支持从一开始就建设：

- `eval_run`
- `eval_case_run`
- `eval_judgment`
- `eval_regression`

以及与之配套的：

- run summary
- case history
- regression surfaces

#### 5. benchmark 不只看 correctness，也要看运行特征

Anthropic 会把 benchmark 结果之外的运行信息一起纳入评测视野。

这对 Investibook 的启发是：

- daily regression 不应只记录 pass / fail

还应记录：

- duration
- token usage
- semantic judge count
- cache hit rate
- follow-up rounds

因为一个 case 即使“还能过”，也可能已经在：

- 变慢
- 变贵
- 变脆弱

#### 6. judge 要分层，而不是依赖单一判法

Anthropic 体现出来的成熟做法不是“全自动”或“全人工”，而是多层评测机制协同。

这与 Investibook 当前更适合的 judge 分层一致：

- execution checks
- deterministic rubric
- semantic judge
- human review 兜底

其中关键原则是：

- 能 deterministic 判的，优先 deterministic
- deterministic 不足时，再进入 semantic judge
- semantic 仍有争议时，再进入人工 review

#### 7. benchmark 需要 review surface，而不是只停留在脚本输出

Anthropic 的方法论强调 benchmark 结果必须可 review。

这支持 Investibook 提供：

- run list
- run detail
- case history
- regression page

让系统可以回答：

- 哪些 case 回归了
- 回归出现在哪一层 judge
- 当前输出与 baseline 差在哪里
- 这个失败是否可能是 false positive

#### 8. benchmark 最终要驱动闭环动作

Anthropic 的 benchmark 思路最终服务于改进动作，而不是只产出一个分数页面。

对 Investibook，这意味着 daily regression 运行后，应该自然衔接到：

- rerun failed cases
- review disputed cases
- 修 prompt / skill / tool adapter
- promote baseline

如果做不到这一点，系统更像 dashboard，而不是质量保障系统。

这一节的核心总结可以压缩成一条链路：

- 固定 case
- 显式 contract
- 分层 judgment
- 结构化 artifacts
- 与 persisted baseline 比较
- 提供 review surface
- 驱动 rerun / review / promote

这才是 Anthropic 参考里最值得 Investibook 吸收的 benchmark 方法论。

---

## References

- <https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md#running-and-evaluating-test-cases>
- `docs/plans/2026-04-20-evaluation-system/main-design.zh.md`
- `docs/plans/2026-04-20-evaluation-system/case-authoring.zh.md`
- `docs/plans/2026-04-20-evaluation-system/case-judging.zh.md`
- `docs/plans/2026-04-20-evaluation-system/daily-run-cost.zh.md`
- `docs/plans/2026-04-20-evaluation-system/technical-ops.zh.md`
- `tools/replayer/SKILL.md`
- `tools/replayer/cases.yaml`
- `backend/investibook/core/evaluation.py`
- `backend/investibook/api/admin.py`