# AI Workflow 评测与优化 Playbook

> 公开版 v0.1 · 2026-07  
> 用途：把一次 AI Workflow 优化变成可比较、可归因、可复现的产品实验。

## 先记住三个原则

1. 优化顺序固定为 **Contract → Workflow → Prompt**。
2. 确定性问题交给程序和结构，语义判断才交给模型。
3. Judge 提供信号，产品 Owner 对 trade-off 和发布结论负责。

---

## 一次完整 Campaign

### Step 0｜定义问题

- 目标用户和任务是什么？
- 哪个结果需要改善？
- 什么不能因此退化？
- 本轮唯一主要假设是什么？

### Step 1｜冻结 Contract 和 Baseline

记录：

- 输入变量、类型、必填状态；
- 输出 Schema、空结果语义与错误结构；
- 主模型 / fallback 的一致性；
- 路由、聚合和 End 节点；
- 模型、参数、插件版本与 baseline checksum。

完成后才能回答：“candidate 到底改变了什么？”

### Step 2｜冻结两层评测集

#### Tier-1 · Core Regression

- 规模小、变化慢、严格冻结；
- 覆盖主要场景与高风险边界；
- 不在这组数据上调 Prompt；
- 发布前用它判断是否引入新的 P0。

#### Tier-2 · Campaign Set

- 围绕本轮薄弱点建立；
- 允许针对性诊断和迭代；
- 验收后归档，不跨 Campaign 当作通用结论。

每条样本至少记录：

```yaml
sample_id: ""
selection_reason: ""
scenario: ""
must_include: []
must_not_include: []
evidence_refs: []
severity_if_failed: P0 | P1 | P2
```

### Step 3｜做最小 Candidate

先把失败按层分类：

- Contract：解析、Schema、ID、错误语义、主备不一致；
- Workflow：路由、变量传递、重试、fallback、聚合；
- Prompt：遗漏、误报、粒度、重点、语言。

每轮只改一个主要变量。修改前写：

```markdown
## Hypothesis
如果我们改变 ______，
那么 ______ 场景的 ______ 指标会改善，
同时 ______ 底线不会退化。

## Change boundary
- 会改：
- 不会改：
- 已知风险：
```

### Step 4｜用三层证据评测

#### Layer 1 · Contract / Hard Gate

由程序 Pass / Fail：

- 可解析；
- Schema 正确；
- ID / Evidence 存在且匹配；
- 语言、空结果和错误返回稳定；
- 主备与路由一致。

P0 不得被平均分抵消。

#### Layer 2 · Semantic Quality

建议从以下维度建立 1–5 分 Rubric：

- 忠实与证据；
- 关键信息覆盖；
- 结构与粒度；
- 重点与具体性；
- 可读性与语言。

没有唯一参考文本时，优先评约束与证据，不追求逐字匹配。

#### Layer 3 · Runtime / Trace

单独记录：

- 技术成功率与 fallback 率；
- P50 / P95 延迟；
- Token 与成本；
- 重复运行一致性；
- 失败节点和原因。

不要把运行指标与语义分简单相加。

### Step 5｜盲评和 Verdict

匿名 A/B 至少做到：

- 不显示版本、模型和优化说明；
- A/B 顺序随机；
- 全部评分落盘后再揭盲；
- 记录 A 胜 / B 胜 / 平局、维度分与理由；
- 主动寻找 baseline 更好的样本。

最终 Verdict：

```yaml
status: ship | iterate | reject
candidate: ""
dataset_versions: []
release_gates:
  contract_p0: pass | fail
  semantic_review: pass | fail
  runtime_regression: pass | fail
known_limits: []
deployment_status: not_deployed | deployed
approved_by: ""
approved_at: ""
```

---

## 6 份 SOP 索引

1. Contract 审计与 baseline 冻结
2. 两层评测集冻结
3. 单变量假设与 Candidate 迭代
4. 批跑、三层评测与回归
5. 可读报告与证据链
6. 匿名 A/B 与盲评揭盲

## 不可声称清单

每次报告都应写清楚：

- 哪些路径没有测试；
- 哪些样本量不足以支持切片结论；
- 哪些改善只在本 Campaign 成立；
- 候选是测试通过、内部清关，还是已经生产部署；
- 哪些 trade-off 被接受，哪些进入下一轮。

## 复用前必须替换

这份公开版只提供结构。使用前请重新定义：

- 你的业务 Contract；
- 你的 P0 / P1 / P2 边界；
- 你的真实样本与数据使用权限；
- 你的语义 Rubric；
- 你的延迟、成本和发布门槛；
- 你的人工 Owner 与签字流程。

---

这套方法的目的不是让评测显得复杂，而是让团队能够回答一个简单问题：

**我们为什么相信这次真的变好了？**