01 / WHY
为什么评测是产品工作，而不只是工程工作
AI 输出是概率性的，很多任务也没有唯一标准答案。如果“质量”只停留在感觉里，团队就只能靠看几个 Demo、追一个总分，或者在上线后被动接住问题。评测真正困难的部分，是把用户价值、产品边界和风险翻译成可执行的标准——这正是产品判断发生的地方。
先定义行为
什么必须发生、什么绝不能发生、什么只是表达差异。
再设计证据
哪些样本代表真实使用，哪些指标只能做诊断，哪些退化必须阻塞发布。
最后做选择
Judge 可以给信号，但产品 owner 仍需对 trade-off 和发布结论负责。
02 / LOCATE
先分清问题在哪一层
我把优化顺序固定为 Contract → Workflow → Prompt。越靠左越确定，也越不应该交给模型“自己领会”。
Contract
先冻结输入、输出、Schema、错误语义和主备一致性。系统接不住的结果，文案再好也没有意义。
Workflow
把路由、校验、重试、聚合和 fallback 放在可观察的节点里。确定性规则用结构表达。
Prompt
Prompt 只承担语义判断：什么算行动项、什么是重点、哪些不确定性必须保留。
反模式：看到坏结果就加一句 Prompt，最后得到一段没人能归因、也没人敢删的“超级说明书”。
03 / MEASURE
一套评测系统，要同时回答三件事
评测不是一个分数，而是一组互相校验的证据。硬错误不能被平均分掩盖，语义提升也不能以运行不稳定为代价。
Contract 与硬规则
JSON / Schema / Evidence / 空结果 / 路由
程序判断 Pass / Fail语义质量
忠实、覆盖、结构、具体性、可读性
Rubric + LLM Judge + 人工校准运行与 Trace
成功率、fallback、延迟、Token、重复一致性
单独记录，不与语义分相加两层数据，不让“优化”污染“验收”
Tier‑1 · Core regression
少量、慢变、严格冻结。只负责回答：这次改动有没有破坏已经守住的底线？
Tier‑2 · Campaign set
围绕一个薄弱点临时建立。用来形成假设、观察切片，并允许本轮针对性迭代。
把一次优化变成可归因的 Campaign
- 01冻结 Contract 与 baseline
- 02冻结两层评测集
- 03提出一个主要假设
- 04最小化修改 Candidate
- 05重复批跑与三层评测
- 06人工签 Verdict
04 / BUILD
方法背后的实际工作
这套 Playbook 不是先写出来、再找案例填进去的。它从一组真实会议 AI Workflow 的审计、数据整理、候选迭代和盲评中反向沉淀。
份执行 SOP
Contract、数据集、Candidate、评测、报告与盲评
个 LLM 节点
完成 Evidence Guard 与 root status 约束
节点 / 连线
保持原图结构不变，隔离本轮变量
冻结样本 × 重复运行
候选两轮均通过 Contract P0 Gate
05 / DECIDE
一次真实的判断，而不是漂亮的胜率
在 20 条冻结样本的匿名 A/B 中，候选在 19 条非平局样本里赢了 17 条；但更重要的是，盲评同时找出了两条 baseline 更好的长文本案例。
候选 decisive 胜率
17 胜 / 2 负 / 1 平
候选侧 P0
baseline 为 16 / 20
候选忠实与证据
baseline 为 2.60 / 5
06 / TOOL
为什么用 Dify Workflow
这里选择 Dify，不是因为可视化画布天然让结果更好，而是因为节点、路由、变量、fallback 与导出的 DSL 让产品假设有了可审计的载体。哪些由代码保证、哪些由模型判断、信息在哪一步丢失，都可以被讨论。它提供的是一个合适的实验台；评测纪律仍需要另外建立。
07 / REUSE
把方法带走
公开版去掉了内部业务、数据与环境信息，保留一套可以套进其他 AI Workflow 的操作骨架：两层数据集、三层评测、单变量 Campaign、盲评与不可声称清单。
- 5 步主流程与 6 份 SOP 索引
- 评测集与 Campaign 文件结构
- 发布门槛和 Verdict 模板
- 复用前需要替换的业务 Contract 清单