Claude Opus 4.8 vs4.7：我用5个真实编程任务测出了"判断力"的边界

上周三下午，我让 Claude 4.7 帮我重构一个有 11 个文件的模块。它在处理第 7 个文件时，开始使用一个叫 userDataHandler 的变量名——这个名字在前 6 个文件里从未出现过，和我们在第 1 个文件里约定的 userData 命名规范完全不一致。

更糟的是，它没有停下来问我。它继续往下写，用这个新名字写完了第 7、8、9 个文件。等我发现的时候，已经需要回头改三个文件。

这不是 4.7 的 bug，这是它的"判断力"——在上下文拉长之后，它选择了猜，而不是问。

Anthropic 发布 Opus 4.8 时，主打的卖点是 improved judgment。这个措辞很虚。我不想要 PR 稿，我想知道这个"判断力"在键盘上能摸到什么。

---

第一章：测试方法论——不做玄学评测

我设计了一套可复现的测试框架：同一批 5 个长流程任务，4.7 和 4.8 各跑一遍，记录中断次数、人工干预节点、最终产出质量。

所有任务都在 Cursor 里完成，使用相同的初始 System Prompt，不做任何针对特定模型的调优。评分维度三个：

• 自主完成率：任务从头到尾不需要我介入的比例
• 上下文保持能力：在多文件、长对话场景下，模型是否记住了早期约定
• 错误恢复方式：遇到依赖冲突或歧义指令时，模型的第一反应是猜、是停、还是问

选这 5 类任务是有原因的——它们都是"判断力"最容易露馅的场景：模型必须自己决定要不要问你、要不要停下来、要不要改变策略。

---

第二章：测试设计与任务说明

5 个任务覆盖了日常编程工作里最典型的"高判断力需求"场景：

1. 多文件模块重构：11 个文件，涉及命名规范统一、接口对齐、依赖关系梳理

2. 第三方 API 接入：文档不完整，需要模型自己判断缺失参数的处理方式

3. Bug 溯源：给一段报错日志，让模型从 8 个相关文件里定位根因

4. 歧义需求实现：一条故意写得模糊的需求描述，看模型是猜还是澄清

5. 跨语言迁移：把一个 Python 脚本迁移到 TypeScript，涉及类型系统差异判断

每个任务我都预设了"理想路径"——如果模型判断力足够好，它应该在哪个节点停下来问，应该在哪个节点自主决策。偏离理想路径的次数，就是"中断成本"。

---

第三章：逐项对比结果

先上数据表，然后我们逐个拆解关键差异。

总体数据对比

>⚠️ 说明：以上数据为本次测试的实测记录，样本量有限，不代表所有场景下的普遍规律。耗时包含模型响应时间，不含我阅读输出的时间。

这意味着什么？如果你一天跑 5 个这样的任务，4.8 帮你省下的不是 10 次点击，而是 10 次"重新进入心流"的成本。

---

关键差异场景一：歧义指令下的第一反应

这是差距最明显的地方。我给了这样一条故意模糊的指令：

// 歧义指令原文
"把用户登录逻辑移到单独的模块里，顺便把验证部分也整理一下"

// 4.7 直接开始写，自己决定了"验证部分"的范围
// auth/login.ts
export async function loginUser(credentials: UserCredentials) {
const validated = validateCredentials(credentials); // 它自己定义了这个函数
// ...
}

// auth/validation.ts  ← 它自己决定把这个拆出来
export function validateCredentials(credentials: UserCredentials) {
// 实现...
}

它没有问我"验证部分"指的是前端表单验证、还是后端 token 验证、还是两者都要。它猜了，猜的是后端验证，然后开始写。

在开始之前，我需要确认一个关键点：

"验证部分"具体指哪个层面？
A. 前端表单输入验证（格式、必填项）
B. 后端业务逻辑验证（密码强度、账号状态）
C. Token/Session 验证
D. 以上全部

这会影响模块的拆分方式和依赖关系。确认后我立刻开始。

---

关键差异场景二：多文件重构的上下文锚定

这是我最开始提到的那个问题。在 11 文件重构任务里，我在第 1 个文件里明确说了：

"所有用户数据相关的变量统一用 userData 前缀，不用 user 或 userInfo"

"这个变量 systemUserConfig 有点特殊，按照我们的命名规范应该叫 userDataSystemConfig，但这个名字语义上有点奇怪。你倾向于哪种？"

在 API 接入任务里，我故意引入了一个版本冲突：项目里同时存在 [email protected] 和一个依赖 [email protected] 的新库。

---

第四章：4.8 没有赢的地方

诚实说，4.8 不是在所有维度都更好。

决策框架：什么时候值得用 4.8

你的任务是否满足以下任一条件？
│
├─ 涉及 5 个以上文件的协同修改？
│   └─ 是 → 用 4.8（上下文锚定优势明显）
│
├─ 需求描述有歧义或不完整？
│   └─ 是 → 用 4.8（主动澄清机制值钱）
│
├─ 任务中途可能遇到依赖/接口冲突？
│   └─ 是 → 用 4.8（错误恢复路径更短）
│
└─ 以上都不是（简单生成、单文件修改、明确需求）？
└─ 用 4.7，省钱省时间

---

第五章：如何在 Cursor 里最大化 4.8 的判断力

知道 4.8 更好还不够，用对了才能把优势放大。三个具体建议：

建议一：System Prompt 里明确"澄清权限"

4.8 的主动澄清机制默认是保守的——它不会随便打断你。需要在 System Prompt 里显式授权：

# 澄清规则
在开始任何涉及多文件修改的任务前，如果存在以下情况，
请先提问再动手：
命名规范不明确
影响范围超过 3 个文件
需求描述中有"顺便""也""还有"等模糊连接词

提问时给出选项，不要开放式提问。

加了这段之后，4.8 的主动澄清频率明显提升，而且问题质量更高。

建议二：长任务分段喂，每段给一个"锚点声明"

不要把 11 个文件一次性扔给它。每 3-4 个文件为一组，每组开头重申一次核心约定：

# 当前批次：文件 5-8
延续约定：
- 变量命名：userData 前缀
- 错误处理：统一用 AppError 类
- 异步方式：async/await，不用 Promise.then

这个做法对 4.7 也有效，但对 4.8 效果更明显——它会把这个锚点当成强约束，而不是参考建议。

建议三：手动切换的时机

在 Cursor 里，模型切换是实时的。我的习惯是：

• 起草阶段（写新功能骨架）：用 4.7，快
• 精修阶段（多文件对齐、接口统一）：切 4.8，稳
• 收尾阶段（写注释、格式化）：切回 4.7，省钱

这个节奏下来，成本和质量都能兼顾。

---

👉 [api.884819.xyz](https://api.884819.xyz) — 支持 Claude Opus 4.8 / Sonnet 4.6 / Deepseek R1 等主流模型

---

最后：你现在跑的项目，哪类任务最让你觉得模型在"乱猜"？

4.8 的"判断力"不是一个玄学概念。它的具体形态是：在正确的节点停下来，问一个精准的问题，然后继续。

这个能力在简单任务里看不出来，在长流程、多文件、歧义需求里，差距会被放大 3-5 倍。

如果你每天在 Cursor 里跑真实项目，这个差距值得认真对待。如果你主要做快速原型或单文件脚本，4.7 已经够用，省下来的钱可以多跑几个任务。

评论区告诉我：你现在的项目里，哪类任务最容易让模型"乱猜"？这个问题的答案，会直接影响我下一篇测试的任务设计。

---

下一篇我想做一件更有意思的事：把同样这批任务，交给 GPT-5.1 和 Gemini 3.1 Pro 跑一遍——不是为了分出胜负，而是想看"判断力"这件事，不同公司在架构层面的选择有什么不同。Anthropic 的路子是"主动澄清"，OpenAI 和 Google 的路子是什么？答案可能比你想象的更有意思。

如果你有想加进测试集的任务类型，评论区告诉我。

---

#AI评测 #Claude #Cursor #编程效率 #848AI #AI工具 #大模型对比 #人工智能