Claude 4.8 vs 4.7：同样的 prompt，差距藏在自我修正里

文章作者、来源：AI运维实验室

5 月 28 日，Anthropic 发了 Opus 4.8。

我没立刻写发布快讯。AI 运维实验室不写模型快讯——满屏的"benchmark 涨了几个点""新模型有多强"，运维看不出能拿来干嘛。

但我做了件事：把同一个真实运维 skill 的 review 任务，分别喂给 4.7 和 4.8，跑同源对比。

跑完之后我决定切。不是因为 benchmark，是因为 4.7 给我返了一条反向的 grep 脚本。如果当时我没仔细看就贴上去用，会把好的图片路径全部判定成错。

下面是完整对照过程。

实验设计

一句话总结：不跑 benchmark，跑真活儿。同一个 prompt、同一份输入，唯一变量是 model ID。

被 review 的 skill 是我自己写的 wiki-publish——把 Markdown 转 Confluence wiki markup 上传的标准流程，265 行，两年沉淀，有 7 个 Step 和一堆踩坑记录。

实验拓扑：

3 份输入 SKILL.md (265 行) + 6 条铁律 + 文档规范   │   ▼ payload.json (24 KB)   │   ├──→ aws bedrock invoke  --model-id  us.anthropic.claude-opus-4-7   │       │   │       ▼   │    opus-4-7.md  (4360 tokens / 57 秒)   │   └──→ aws bedrock invoke  --model-id  us.anthropic.claude-opus-4-8           │           ▼        opus-4-8.md  (5911 tokens / 98 秒)

调用命令很朴素，AWS Bedrock 已经把两个模型都上线了：

# 4.7 aws bedrock-runtime invoke-model \   --model-id us.anthropic.claude-opus-4-7 \   --region us-east-1 \   --body fileb://payload.json \   --cli-binary-format raw-in-base64-out \   raw-4-7.json # 4.8 (同一份 payload.json,只换 model-id) aws bedrock-runtime invoke-model \   --model-id us.anthropic.claude-opus-4-8 \   ...

prompt 让两个模型按我自己定的「Skill 设计 6 条铁律」逐条 review，要求每条结论必须有行号或文本片段作为依据，没把握的写"不确定"。

也就是说，我没问"你觉得这个 skill 好不好"——这种问法两个模型都会给你 5 颗星。我问的是"按这 6 条规则给我打分，给依据"。

5 维度同源对比

跑完之后，我按预设的 5 个维度做了对照：

光看表格，4.8 的好处不算夸张。慢、贵、多说几句"不确定"——这些字面上看起来都是保守，不是聪明。

差距藏在具体内容里。我挑三个最具说服力的差异展开。

先承认这个测试不严谨的地方

把差异展开之前先把丑话说在前面。这个实验作为论文是不合格的：

• N = 1，每个模型只跑了一次，没做重复采样。单次结果有可能是抽样波动，不是稳定差异
• 没控制 temperature，用了 Bedrock 默认值，两个模型的随机性强度可能不完全一致
• 评分维度是事后归纳的，看完两份输出才定的 5 个维度，存在 confirmation bias——我可能下意识挑了 4.8 表现更好的维度
• "4.7 反向 grep" 是单点观察，单次跑出一个错误推理不等于 4.7 系统性差，要重复多次都出现才能下结论

那为什么还写出来？因为我的目的不是证明 4.8 全面强于 4.7，是给你一个自己跑这个对比的方法论。同源对比比 benchmark 更接近真实运维场景，但你看到的趋势是否在你的 skill 上复现，得自己跑一遍。

差异 1：4.7 给了一条反向的 grep（重点）

这段是整次实验最让我后背一凉的地方，所以单独展开。

我让两个模型都核查："![](xxx.png) 不带 images/ 前缀"这个踩坑 SKILL.md 覆盖到没有。

这是个真实的坑——我自己写过一条 memory 记录：「Wiki 图片引用用纯文件名，md 里 ![](xxx.png) 不带 images/ 前缀，否则 confluence-upload.py 拼路径错找不到图」。

也就是说，规则是：**md 里只写文件名，不带 images/**。

4.7 的回答

4.7 给了一段输出，包含一条它生成的校验命令：

# 4.7 给的"硬校验" grep -E '!\[.*\]\(images/' "$MD" && echo "图片路径错误" && exit 1

这条命令的意思是：只要 md 里出现 ![](images/xxx.png) 就报错。

看起来很合理对吧？很像一条防御性脚本。

但它是反的。

4.8 的回答

4.8 给的输出，关键段落是这样：

Step 3 写图片保存到 ~/kiro-doc/images/YYYY-MM-DD-描述.png,wiki 中用 !图片名.png! 引用(不带 images/ 路径,只用文件名)。 Step 7 写"脚本从 ~/kiro-doc/images/ 搜索 wiki 中引用的图片"。 也就是说约定是: .md 里写 ,转换后 wiki 里只剩 !xxx.png!(文件名),上传脚本去 images/ 目录找。 但 SKILL.md 没有显式说明 md2wiki.py 是否会自动剥掉 images/ 前缀。 我标"不确定"是因为缺 md2wiki.py 源码证据,不知道脚本对 images/ 前缀 的处理逻辑。

4.8 的回答是：md 里要带 images/，转换器剥前缀。然后老老实实标注"不确定，缺脚本源码证据"。

谁对？

光看输出我也判断不了，所以我直接 cat 出 md2wiki.py 跑了一次实测：

$ echo '' | python3 ~/bin/md2wiki.py /dev/stdin /dev/stdout !images/foo.png! $ echo '' | python3 ~/bin/md2wiki.py /dev/stdin /dev/stdout !foo.png!

实测结论：md2wiki.py 不剥前缀，原样保留。也就是说 md 里就该写纯文件名 ![](foo.png)，写带 images/ 的 md 上传后会找不到附件。

那么两个模型谁对？

• 4.7 给的 grep 方向是对的（"带 images/ = 错"）
• 4.8 推断的"转换器剥前缀"是错的——脚本不剥

但这恰好是这个实验最值得记的反转：最终答案对错，不能掩盖推理过程对错。

4.7 没有读 Step 7，它就单凭 Step 3 推出了一条 grep，这次碰巧对。下次只要 SKILL.md 的某一段微调（比如 Step 7 加一句"脚本支持 images/ 前缀"），4.7 还是会给同一条 grep——因为它没看那段。它不知道自己为什么对。

4.8 答案错了，但它在输出末尾老实写：

我标"不确定"是因为缺 md2wiki.py 源码证据, 不知道脚本对 images/ 前缀的处理逻辑。

它知道自己缺什么。这给了我一个明确的核实入口——去 cat md2wiki.py。我跑了一次 echo 管道就拿到了答案。

如果当时是 4.7 那种"看起来很有把握"的语气，我大概率不会去翻脚本。

这件事为什么值得单独写

运维 AI 给的命令"看起来合理"和"真的对"之间的距离，就是它有没有交叉读多段上下文。

4.7 给的输出读起来非常专业，有理有据，给出 grep 的笔法甚至比 4.8 还干净利落。如果这次不是我做对照实验、把每条建议都跟 4.8 摆在一起看，我就直接用了。

对一个运维来说，AI 说"我不确定"比说错答案值钱得多。前者触发我去验证（这次就是"去 cat md2wiki.py"），后者让我直接把反向脚本贴进生产 skill。

4.7 的回答里没有"不确定"三个字。它的 grep 像是从权威的喉咙里说出来的。 4.8 答案错了，但留了一个核实入口。

这是这次实验最值钱的一个观察：模型的"自知"比"答对"值钱。

差异 2：4.8 会撤回自己

差异 1 讲的是"4.8 知道自己不知道"。差异 2 是更难的一步——4.8 会推翻自己已经下过的判断。

4.8 在审 SKILL.md 标题格式时，先在表格里写下了"疑似冲突"，然后接着写：

冲突: 标题格式分隔符 — 疑似不一致,不确定   CLAUDE.md 第八条: 2026 MM.DD 业务/系统 主题   SKILL.md Step 6 示例: 2026 05.07 Lambda ... 两者一致(年 空格 月.日 空格)。无冲突。 先前我以为有冲突,核对后撤回。

注意结构：先抛"疑似冲突"的判断 → 自己核对 → 推翻。整个推翻过程显式留在输出里。

为什么这件事难？因为 LLM 的生成是顺序的——一旦写下"疑似冲突"，最省力的下一步就是顺着论证它真的冲突。要在写下后中途调头说"算了不冲突"，模型必须真的回头校验，而不是顺着自己的话说。

4.7 整篇 review 里，"撤回"这种动作出现了 0 次。 不是 4.7 永远不说"不确定"——它也会说，比如它给一条 awk 校验命令时主动声明"字段位置不确定，需先跑一次 file 确认"。但这是前瞻性的不确定：写命令前预留一个验证步骤。 4.7 不做的是回头校验：写完一个判断之后，再回去核对、推翻。

这两种动作在工程上都重要，但运维场景下后者更稀缺——因为前瞻性不确定可以靠提示词逼出来，回头校验不行，模型自己不做就是不做。

这是 AI 内化了我 CLAUDE.md 第一·五条「双向假设验证」——给结论前先问两遍："如果为真，证据是什么；如果为假，反证据是什么"。我自己写下这条规则的时候没指望模型真做到。4.8 做到了。

我在第 17 篇里说过：区别不在工具，在你给它的画像。那篇讲的是我用 user/feedback/project 这套 memory 给 AI 喂画像，让它对我有效。这一篇是反过来——画像还是同一份，连 prompt 也一样，只换了一个模型 ID，4.8 自己开始做出"撤回"和"声明缺证据"这些动作。

也就是说，画像是基础设施，但模型本身的"自知能力"决定了画像能跑多远。我喂给 4.7 的画像和喂给 4.8 的是同一份，但 4.8 把它用得更深。

差异 3：4.8 把孤立 incident 串成因果

最后一个差异，4.8 在我的 incident 库里跨条目联立了一次。

它在审 Step 7 上传流程时，写了这么一条新规则：

上传返回 400/401 时禁止连续重试。 (Confluence 认证连续失败会锁号,见 CLAUDE.md 第十条)。 先看错误体定位(多半是 {code:lang} 校验失败 → 回 .md 改后重转), 确认修复再重发。

这条规则的来源是两个原本孤立的踩坑：

• {code:json} 块内含非法字符 → API 返回 400
• Confluence 认证连续失败 → 账号被锁

4.7 把这两条当独立条目处理。4.8 把因果串了起来：400 触发重试，重试触发认证连续失败，认证失败触发锁号——所以"上传 400 禁止盲目重试"是一条新合成的规则。

这是一线干活的人脑子里的隐式因果链。新模型开始能自己拼了。

拉回自己：我现在切了吗

我没有全切。我按场景路由。

ANTHROPIC_DEFAULT_OPUS_MODEL   │   ├──→ 日常问答 / 写小段代码   │      │   │      ▼   │    claude-opus-4-7   (快,够用)   │   ├──→ review skill / 改配置 / 写运维脚本   │      │   │      ▼   │    claude-opus-4-8   (慢一点,但少脑补)   │   └──→ 长链 agent 任务          │          ▼        看任务复杂度    (步数多时 4.8 的慢会被放大)

成本账：

不是非黑即白全切，是按"AI 一脑补就出事"的场景路由。这次实验里 4.8 表现出"撤回""不确定""缺证据"这些动作，正好就是我让它写 skill 和改配置时最想要它具备的。

三个带走的东西

1. 升级模型别看 benchmark，让它 review 一个真 skill

benchmark 测的是平均能力。运维场景测的是边界——多段联立、跨 incident 串因果、敢不敢说不确定。同源对比一次比看十张 benchmark 截图都准。

2. 看 AI 输出有没有"撤回""不确定""缺证据"这些词

有这些词的输出 = 证据原则强 = 你可以放心用。 没有这些词、回答永远斩钉截铁的输出 = 单边决策 = 你必须逐句核对。 4.7 给我那条反向 grep 的时候，没说"不确定"。这是最大的警告信号。

3. 拿一个真的会被你用的 skill 去测，不要拿"测试用的 prompt"

我这次喂给两个模型的，是我自己每天用的 wiki-publish skill——里面有真实的踩坑、真实的 Step 联动、真实的边界。如果我喂的是一个为测试而写的简化 prompt，4.7 大概率不会暴露"只读单段就下结论"这个问题，因为简化 prompt 没多段可读。

模型的边界只在真实复杂度下才暴露。这就是为什么 benchmark 看不出来。