悟空技巧十：评估与度量，用数据驱动 AI 协作持续进化

你让悟空生成了一份技术方案，通读一遍觉得「逻辑清晰、结构完整」，直接交给了研发团队。一周后，架构师反馈：方案里 30% 的接口定义缺少边界条件说明，两个核心组件的选型缺乏压测数据支撑，根本无法进入开发排期。

你让 AI 写了一段数据清洗脚本，本地跑通了样例数据，直接部署到生产环境。三天后，监控报警：遇到脏数据时脚本静默失败，导致下游报表连续两天数据断层。

AI 的输出「看起来很好」，不等于「工程上可用」。

在前面的九篇文章中，我们构建了从 需求澄清、交付物定义、示例对齐、分步执行、迭代优化、上下文管理、工具协同、工程化封装 到 多 Agent 协同 的完整工作流。

但所有这些技巧，都依赖一个隐含假设：人类能准确判断 AI 的输出质量。

现实是：人类审查会疲劳、会受认知偏差影响、无法覆盖边界条件，且根本无法规模化。当 AI 协作从「个人玩具」走向「团队基础设施」时，靠「感觉不错」来验收，就是埋下生产事故的种子。

今天，我们探讨技巧十：如何通过「评估与度量」，建立自动化质量门禁和数据飞轮，让 AI 协作从「主观验收」走向「可观测、可度量、可演进」的工程闭环。

🎯 核心问题：为什么「肉眼验收」靠不住？

大语言模型（LLM）的本质是概率生成系统。它的输出具有三个工程特性：

1. 非确定性（Non-Determinism）：相同 Prompt 多次运行，结果可能不同。Temperature 越高，波动越大。
2. 隐蔽性缺陷（Silent Failures）：AI 擅长生成「看起来专业」的文本。逻辑漏洞、数据幻觉、边界遗漏往往隐藏在流畅的行文中，肉眼极难察觉。
3. 审查疲劳（Review Fatigue）：人类对前 3 次输出能认真 Review，到第 10 次就会下意识放行。质量防线随使用频次指数级衰减。

解决思路：不要依赖人类直觉，要用确定性度量约束概率性输出。

就像软件工程从「手动测试」进化到「CI/CD 自动化门禁」，AI 协作必须建立可量化的评估体系、自动化评审机制和持续改进飞轮。

📊 核心理念：评估与度量（Evaluation & Measurement）

将主观的「感觉不错」转化为客观的「指标达标」。通过结构化评分卡、自动化评审（LLM-as-a-Judge）、质量门禁和坏案例库，构建可观测、可回归、可演进的 AI 质量体系。

🛠️ 四大实战技巧

技巧一：结构化评分卡（Structured Scorecard）

不要问「这方案好不好」，要问「这方案在哪些维度得了几分」。

为高频场景定义多维评分 Rubric，明确权重与及格线。

示例：技术方案评审评分卡

效果：验收从「模糊定性」变为「精确定量」。低于及格线直接打回，避免人情放行或疲劳妥协。

技巧二：LLM-as-a-Judge（自动化评审）

人类审查无法规模化，但 AI 可以。用一个独立模型（或独立 Agent 角色）作为「评审员」，基于评分卡自动打分并输出修改建议。

Judge Prompt 模板：

# generated by hugo AI
你是资深技术评审专家。请基于以下评分卡，对候选方案进行独立评审。

## 评分卡
[粘贴上述结构化评分卡]

## 评审规则
1. 逐项打分，必须给出具体扣分原因和原文引用
2. 禁止泛泛而谈（如"整体不错但需优化"），必须定位到具体段落/字段
3. 若某维度低于及格线，输出明确的修复建议
4. 最终输出 JSON 格式：{"scores": {...}, "total": X, "passed": true/false, "feedback": [...]}

## 候选方案
{{candidate_output}}

请开始评审。

关键避坑指南：

• 独立性：Judge 模型应与生成模型不同（或至少隔离上下文），避免自证偏差。
• 强约束：必须绑定结构化 Rubric，否则 Judge 会退化为「和事佬」（倾向给高分）。
• 防偏好：LLM Judge 天然偏好长文本和礼貌语气。需在 Prompt 中明确声明「长度和语气不计入评分，仅评估事实与逻辑」。

技巧三：质量门禁（Quality Gates）

评分不是目的，拦截不合格输出才是。将评估嵌入工作流，建立自动化门禁。

┌─────────────────────────────────────────────────────────┐
│                  AI 协作质量门禁流水线                   │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  [生成 Agent] ──▶ 输出候选方案                           │
│     ↓                                                   │
│  [Judge Agent] ──▶ 自动打分 + 生成反馈                   │
│     ↓                                                   │
│  [Gatekeeper] ──▶ 判断 total >= 阈值 ?                   │
│     ├─ Yes ──▶ 放行 → 交付 / 发布                       │
│     └─ No  ──▶ 拦截 → 自动重试(≤2次) / 转人工 Review     │
│                                                         │
└─────────────────────────────────────────────────────────┘

实战配置示例：

• 博客生成 Skill：格式分 <4 或包含禁用词 → 自动拦截并触发重写。
• 代码生成 Skill：单元测试覆盖率 <80% 或静态扫描报错 → 阻断合并，返回修复建议。
• PRD 生成 Skill：需求可测试性 <3 → 暂停流程，要求产品经理补充验收条件。

效果：质量防线前置。不合格输出根本不会流到下游，大幅降低返工成本和生产风险。

技巧四：数据飞轮与坏案例库（Bad Case Library & Data Flywheel）

评估的终极目的不是拦截，而是进化。建立坏案例库，驱动 Prompt 和 Skill 持续迭代。

飞轮机制：

拦截坏案例 → 归类根因（幻觉/格式/逻辑/缺数据）
   ↓
更新 Skill 约束 / 补充 Few-shot 反例 / 调整 Judge 权重
   ↓
回归测试（用历史坏案例验证修复效果）
   ↓
质量基线提升 → 拦截率下降 → 飞轮加速

坏案例库结构示例：

bad_cases/
├── hallucination/
│   ├── case_001_api_version_wrong.md
│   └── case_002_benchmark_fabricated.md
├── format_violation/
│   └── case_003_missing_frontmatter.md
└── logic_gap/
    └── case_004_edge_case_unhandled.md

每次 Skill 升级，用坏案例库跑一次回归测试。确保「修好一个 Bug，不引入三个新 Bug」。

⚙️ 为什么评估与度量有效？

1. 确定性约束概率性：用固定 Rubric 和阈值锁定质量下限，对抗 LLM 的随机波动。
2. 审查规模化：LLM Judge 可 7×24 小时无疲劳评审，覆盖 100% 输出，人类只需处理拦截的边界案例。
3. 闭环进化：坏案例库将「一次性失败」转化为「永久性免疫」。Prompt 和 Skill 随使用频次指数级优化。
4. 工程可观测：从「黑盒生成」变为「白盒度量」。团队可追踪质量趋势、定位瓶颈、量化 AI 协作 ROI。

🚀 进阶技巧

技巧一：Prompt A/B 测试

不要凭感觉调 Prompt。对关键 Skill 维护 v1/v2 版本，用相同测试集跑分，数据说话。

“用 50 个历史需求分别跑 Prompt-A 和 Prompt-B，对比平均分、及格率、Token 消耗和延迟。选择综合 ROI 更高的版本上线。”

技巧二：AI 回归测试套件（Regression Suite）

为核心 Skill 建立自动化测试集。每次修改 Prompt 或升级模型版本，自动跑分并生成 Diff 报告。

# 伪代码示例
python eval_runner.py \
  --skill architecture-design \
  --test-suite tests/arch_cases.yaml \
  --judge-model claude-sonnet-4 \
  --output report_20260518.json

技巧三：成本-质量权衡（Cost-Quality Tradeoff）

高质量往往意味着高 Token 消耗和长延迟。建立 SLO 意识，按场景分级：

不要对所有任务一视同仁。工程化的本质是在约束条件下做最优分配。

🔄 在系列中的定位

前九篇解决了「怎么生成、怎么编排、怎么规模化」，技巧十补齐了「怎么度量、怎么拦截、怎么进化」。至此，AI 协作工程化闭环正式完成。

┌──────────────────────────────────────────────────────────────┐
│                   悟空技巧演进全景                            │
├──────────────────────────────────────────────────────────────┤
│  阶段一：单次任务质量（Quality per Task）                      │
│    ① Input → ④ Process → ② Output → ③ Style → ⑤ Iteration  │
│                                                              │
│  阶段二：长周期稳定性（Stability across Sessions）             │
│    ⑥ Context Management / GC / Checkpoint                   │
│                                                              │
│  阶段三：端到端行动力（Action & Execution）                    │
│    ⑦ Tool-Augmented / API Routing / Grounding               │
│                                                              │
│  阶段四：团队规模化（Scale & Systematization）                 │
│    ⑧ Prompt as Code / Templates / Skill Packaging           │
│                                                              │
│  阶段五：多智能体架构（Multi-Agent Architecture）              │
│    ⑨ Orchestration / Role Separation / Cross-Validation     │
│                                                              │
│  阶段六：可观测与持续进化（Observability & Evolution）          │
│    ⑩ Evaluation / Quality Gates / Data Flywheel / SLOs      │
└──────────────────────────────────────────────────────────────┘

十种技巧的全景映射

🧠 本质思考：AI 协作是 SRE 能力的延伸

很多人以为 AI 工程的终点是「让模型输出更好」。但工程现实是：概率系统永远会有缺陷，真正的护城河是「多快能发现缺陷、多准能拦截缺陷、多稳能修复缺陷」。

评估与度量，就是把 SRE（站点可靠性工程）的理念引入 AI 协作：

• 评分卡 = SLO / SLI 定义
• LLM Judge = 自动化监控与告警
• 质量门禁 = 发布阻断与熔断机制
• 坏案例库 = 事故复盘与免疫补丁
• 回归测试 = 变更验证与防退化

当你用 SRE 的思维去治理 AI 输出时，你会发现：AI 不再是一个不可控的黑盒，而是一个可度量、可拦截、可回归、可演进的可靠系统。

AI 一直都很聪明，只是你需要学会如何为它建立一套可观测的治理体系。

系列结语： 从技巧一到技巧十，我们走完了从「单次对话优化」到「企业级 AI 工程体系」的完整路径。这不仅是 Prompt 技巧的集合，更是一套将 AI 从「聊天玩具」改造为「生产基础设施」的方法论。

希望这套体系能帮你和团队，真正把 AI 变成像 Git、Docker、CI/CD、Prometheus 一样可靠、可度量、可演进的工程基座。

你在实际落地 AI 协作时，是如何评估输出质量的？有没有建立自动化门禁或坏案例库？遇到过哪些度量上的挑战？欢迎留言讨论。

See also

• 悟空技巧十四：AI Agent 生产环境调试与可观测性，当 AI 开始「胡说八道」时如何快速定位根因
• 悟空技巧七：工具协同，让 AI 从「聊天」走向「行动」
• 悟空技巧三：示例驱动，用 Few-shot 对齐 AI 输出标准
• 悟空技巧九：多 Agent 协同，从单兵作战到虚拟团队
• 悟空技巧二：交付物先行，先定义格式再生成内容