【AI Engineering · Harness 系列】06 独立 Evaluator——为什么让模型自评 = 养蛊

前五篇讲了 Harness 的主体——护栏、心跳、上下文。

这一篇讲 Harness 的"第五支柱"：独立评审机制。

核心观点不复杂但极易被忽视——让生成内容的模型自己评估生成质量，等于让考生自己批卷。

我会用 OpenClaw 的classroom-article-writer-v2Skill 为例，讲透"独立 Evaluator"的完整实现。

一、开篇钩子：AI 的自我表扬泡泡

2026 年 3 月我写课堂型文章时，遇到一个诡异现象。

我让 CodeBuddy 写完文章后自己打分。每次它都给自己85-92 分，评语类似：

“本文结构清晰，逻辑严密，数据详实，具有高度可读性和传播价值。”

我当时有点得意——原来 AI 写东西这么稳，自评 90 分基本等于发布了。

直到有一次我把同一篇文章扔给另一个 Claude 账号评估，它给了62 分，评语是：

“开篇钩子弱，数据点缺乏独立来源，中段逻辑跳跃，结尾草草。”

差 30 分。这不是小差距，这是"发得出去"和"发出去丢人"的差距。

问题出在哪？让生成者评审生成物，本质是"自己骗自己"——模型在生成时已经形成了"这样写没问题"的内在判断，让它回头审自己，它会自动合理化。

这就是"养蛊"——你以为你养了两个 Agent，其实它们串通好一起糊弄你。

真正有效的评审必须是独立的。独立到什么程度？这一篇讲透。

二、调研追溯：三种评审模式

2.1 Self-Evaluation（自评）

做法：同一个模型实例，先生成再评估。

致命缺陷：

• 生成过程产生的"理由"留在上下文里，评估时会被这些理由说服
• 没有真正的"独立视角"
• 倾向于为生成物辩护

Anthropic 官方文档原话：“Single-model self-evaluation should never be used for high-stakes content.”

2.2 Different-Instance Evaluation（跨实例评审）

做法：两个不同会话的同模型，第一个生成，第二个评估（不共享上下文）。

优点：

• 评估者没有生成过程的"合理化偏见"
• 仅凭最终输出判断

局限：

• 两个实例是同模型，对同类错误有共同盲点
• 评估标准受训练数据影响，可能都倾向"看起来专业"

2.3 Cross-Model Evaluation（跨模型评审）

做法：Claude 写，GPT-4 评；或 Sonnet 写，Haiku 评。

优点：

• 不同模型的盲点不重叠
• 评估标准显著不同，能互相挑刺

代价：成本翻倍 + 工程复杂度上升。

2.4 我的做法：分级评审

不是所有内容都需要跨模型评审——成本不值得。我的分级策略：

三、概念精析：独立 Evaluator 的三个要件

3.1 独立的三个层次

"独立"不是一刀切，有层次：

Level 1：上下文独立
评审者看不到生成过程——只看最终输出。

Level 2：实例独立
评审者在不同的模型会话里，没有任何共享状态。

Level 3：模型独立
评审者用不同的模型（Claude vs GPT-4 vs Gemini），训练数据和偏好不同。

三个层次层层递进，成本也递进：

• L1：几乎零成本
• L2：成本 ×2
• L3：成本 ×2 + 工程复杂度 ×3

3.2 评审 Prompt 的设计要点

好的评审 Prompt 有三个特征：

要点 1：评审标准必须显式
不能说"评估这篇文章好不好"，要说"按以下 5 个维度打分，每维 20 分"。

要点 2：必须要求具体证据
“62 分"不够，要"62 分，扣分项：①开篇第三段无数据支撑（-8）②中段…”

要点 3：必须允许拒绝
评审 Prompt 必须留一个"建议重做"的出口。如果每次都给 60-90 分，就是假评审。

3.3 一个反直觉的发现

评审 Prompt 越具体，评审质量越高；反之则倒退为夸夸群。

这是因为模型在模糊指令下会默认"友好模式"——人类训练偏好决定了它倾向赞美。必须用具体标准逼它进入"审判模式"。

四、实例拆解：classroom-article-writer-v2 的自检报告机制

这是我用了 3 个月打磨的 Skill。从 v1 的"自评 90 分基本发"进化到 v2 的"自检报告 + 独立评审"。

4.1 v1 的失败：自评泡泡

v1 里我给 SKILL.md 加了一段：

## Step 5：自评打分 写完文章后，请按以下维度自评： - 开头吸引度（0-20） - 逻辑清晰度（0-20） - 数据充实度（0-20） - 可读性（0-20） - 原创性（0-20） 给出总分和改进建议。

结果：连续 15 篇自评全在 85-92 分。完全没用。

4.2 v2 的改造：结构化自检 + 独立评审

v2 把流程拆成两步：

Step A：结构化自检报告（不打分，只"列清单"）

## Step A：自检报告（不打分） 生成文章后，必须产出以下清单： ### A1. AI Slop 反清单 check - [ ] 未使用"综上所述"、"总而言之"等填料 - [ ] 未使用"本文将"、"让我们"等 AI 典型开场 - [ ] 未出现渐变背景堆砌 - [ ] 未使用左侧彩条容器 - [ ] 未在正文出现 emoji 填空 - [ ] 未用"数据显示"不附来源 ### A2. 设计基线 - 封面参考样式：[具体引用哪篇] - 正文结构：[线性/分章/问答] - 代码示例：[是/否，几个] - 字数：[实际字数] ### A3. 待用户决策项 （列 2-3 个必须用户拍板的点） ### A4. Tweaks 状态 - 调参面板：[已装/未装] - 隐藏开关：[已加/未加]

关键变化：不让模型给自己打分，只让它对照清单勾选。

打分是主观，勾选是客观。客观的东西可以被第三方复核，主观的东西只能被自己合理化。

Step B：独立评审（新会话）

## Step B：独立评审（在新会话执行） 把 Step A 的输出文件 + 文章原文发到新 Claude 会话，使用如下 Prompt： --- 你是资深内容编辑。以下是一篇待发布文章 + 作者的自检报告。 请独立评估： 1. 自检报告的 AI Slop 清单每项 check 是否成立（对照原文） 2. 文章实际质量（5 维度打分，需具体证据） 3. 给出"建议发布 / 建议修改 / 建议重写"的决定 注意： - 不要客气，不要假设作者的善意 - 每个扣分必须指出具体段落 - 如果你是我的老板，你会让这篇发出去吗？ ---

4.3 真实数据：v1 vs v2 的评审差异

同一篇文章（迁移系列 S3 第 6 篇）：

v1 自评结果：

总分: 88/100 - 开头吸引度: 18 - 逻辑清晰度: 17 - 数据充实度: 17 - 可读性: 18 - 原创性: 18 评语: 文章结构完整，逻辑清晰，具有一定深度。建议发布。

v2 独立评审结果：

总分: 64/100 - 开头吸引度: 10（-10: 首段没有具体案例，泛泛而谈） - 逻辑清晰度: 14（-6: 第三节到第四节跳跃） - 数据充实度: 10（-10: 3处"据统计"未标来源） - 可读性: 15（-5: 中段连续 4 个无序列表导致节奏单调） - 原创性: 15（-5: 核心观点在 Anthropic 2024 已讨论，未体现增量） 决定: 建议修改 具体建议: 1. 首段加入 1 个具体踩坑故事 2. 补充 3 处数据来源 3. 第三节末尾加过渡段 4. 原创观点明确标注与 Anthropic 的差异

差 24 分，且每个扣分都有具体段落指引。我按这份报告改了 40 分钟，成品质量显著提升。

4.4 独立 Evaluator 的工程实现

OpenClaw 里的IndependentEvaluator：

# openclaw/evaluators/independent.pyfromdataclassesimportdataclassfromtypingimportLiteralfromopenclaw.core.llm_clientimportcall_llm@dataclassclassEvaluationResult:total_score:int# 0-100dimension_scores:dict# {"开头": 10, "逻辑": 14, ...}specific_issues:list[str]# 具体扣分段落decision:Literal["publish","revise","rewrite"]raw_response:strclassIndependentEvaluator:"""独立评审器——强制用新 session"""EVAL_PROMPT=""" 你是资深内容编辑，以严苛著称。以下是一篇待发布文章。 文章原文： --- {article} --- 作者的自检报告： --- {self_check} --- 请按以下要求独立评估： 1. **验证自检报告**：逐项对照原文，check 哪些成立、哪些不成立。 2. **5 维度打分**： - 开头吸引度 (0-20) - 逻辑清晰度 (0-20) - 数据充实度 (0-20) - 可读性 (0-20) - 原创性 (0-20) 每维度扣分必须指出具体段落。 3. **最终决定**：publish / revise / rewrite 三选一 4. **立场**：假设你是作者的老板，直接决定发不发。不要客气。 输出 JSON 格式： {{ "total_score": 64, "dimension_scores": {{"开头": 10, "逻辑": 14, ...}}, "specific_issues": ["首段无具体案例（扣8分）", ...], "decision": "revise", "reasoning": "..." }} """defevaluate(self,article:str,self_check:str)->EvaluationResult:# 强制用新 session，不继承任何历史上下文response=call_llm(system="",# 无系统提示，彻底独立user=self.EVAL_PROMPT.format(article=article,self_check=self_check),model="claude-sonnet-4-5",# 同模型跨实例评审session_id=None,# 强制新 sessiontemperature=0.3,# 低温度保证评审稳定性)importjson data=json.loads(response)returnEvaluationResult(total_score=data['total_score'],dimension_scores=data['dimension_scores'],specific_issues=data['specific_issues'],decision=data['decision'],raw_response=response)# 跨模型版本classCrossModelEvaluator(IndependentEvaluator):defevaluate(self,article:str,self_check:str)->EvaluationResult:# 用 GPT-4 评审 Claude 写的response=call_llm(system="",user=self.EVAL_PROMPT.format(article=article,self_check=self_check),model="gpt-4-turbo",# 换模型session_id=None,temperature=0.3,)# ... 同上

4.5 成本与收益

实测 3 个月数据：

每篇成本多 $0.25，返工率从 41% 降到 9%——这是明确的正收益。

五、启发与方法论：三条可迁移原则

原则 1：生成和评审必须物理分离

不能是"同一个模型的两段 prompt"——那是左右互搏，看起来像两个人实际是一个人。必须是不同 session / 不同模型。

原则 2：评审标准必须具体到可被反驳

“这篇文章质量高” 不是评审，是感叹。
“开头吸引度 10/20 分，因为首段没有具体案例” 才是评审。

如果评审不能被反驳（你可以说"我觉得案例其实在第二段"），那就不是评审。

原则 3：评审者必须被授权说"不"

如果评审者永远只能在 70-95 分之间打分，那是个摆设。

必须有一个明确的"建议重写"选项。没有拒绝权的评审，都是假评审。

六、反驳性思考

反驳一：成本翻倍值得吗？

看场景。对内草稿不值得，对外发布绝对值得。返工一次的时间成本 >> 多花 $0.25 的评审成本。

反驳二：评审者也会出错怎么办？

会。但"两个独立模型都错"的概率远低于"一个模型自评错"的概率。

这是统计学——独立错误相乘，相关错误相加。

反驳三：这不就是 LLM-as-judge 吗？

对，但很多人用错了。LLM-as-judge 的正确用法是独立 session + 具体标准 + 允许拒绝，错误用法是同 session 自评 + 模糊指令 + 永远打 80+ 分。

这一篇讲的就是正确用法的工程化。

七、收官与预告

下一篇（07）是第三篇硬货：

《五大反模式：我在 OpenClaw 踩过的坑 + 完整事故复盘》

我会把过去 6 个月最严重的 5 次事故完整复盘——含原始日志、修复 PR、根因分析。这篇比 03/04 更"血淋淋"，也更有参考价值。

全系列地图

路易乔布斯
2026 年 5 月 · 深圳
养虾系列 S4 · Harness Engineering 深度拆解 06/08