Opus 4.8 上手指南：让 AI 真正学会给自己代码挑刺

Opus 4.8 来得挺突然。

更有意思的是，它这次最值得关注的点，不是“又会写代码了”，而是——它更会发现自己写错了什么。

这点对写代码的人太关键了。

以前你让模型自己 review 自己刚写的代码，很多时候像领导开会：说了很多，没啥用。它会给你一堆漂亮话，比如“结构清晰”“逻辑合理”“建议添加注释”。听起来很专业，真跑起来还是报错。

Opus 4.8 的变化在于，它更愿意承认：

这里可能有 bug。
这里边界条件没处理。
这里测试覆盖不到。
这里我刚才的实现其实不稳。

这就让它从“代码生成器”，更像一个能坐你旁边一起排查问题的搭子。

下面咱们不聊虚的，直接讲怎么用。

Opus 4.8 最适合干什么？

如果你平时用 AI 写代码，Opus 4.8 这几个场景很值得试：

• 写完功能后，让它做自查
• 让它找边界条件
• 让它检查异常处理
• 让它补测试用例
• 让它解释为什么这段代码会出错
• 让它在不大改结构的情况下修 bug
• 让它对比两个实现，挑出更安全的方案

尤其是“自我审查”这件事，体验会明显不一样。

以前模型写完代码，你问一句：

检查一下这段代码有没有问题。

它大概率扫一眼就说：

整体看起来没问题，建议增加日志和注释。

这不叫审查，这叫敷衍。

现在你可以把任务拆得更狠一点，让 Opus 4.8 真正进入“找茬模式”。

推荐工作流：别让它边写边自嗨，要分两轮

很多人用 AI 写代码，习惯一句话搞定：

帮我写一个用户登录接口，顺便检查一下有没有 bug。

这类提示词看着省事，实际效果一般。

原因很简单：写代码和审代码是两种状态。

写代码时，模型会倾向于完成任务。
审代码时，模型需要反过来质疑自己的方案。

所以更靠谱的流程是：

1. 让它只负责实现
2. 再让它切换身份审查
3. 根据问题清单修复
4. 再补测试

注意，我这里不是让你多折腾，而是让你少踩坑。

你多花 3 分钟，可能少掉半小时调 bug。

第一步：让 Opus 4.8 先写代码，但别急着夸它

可以这样问：

你是一名资深后端工程师。

请用 Node.js + Express 实现一个登录接口：
- 接收 email 和 password
- 校验参数不能为空
- 从数据库查询用户
- 使用 bcrypt 校验密码
- 登录成功后返回 JWT
- 登录失败返回明确错误信息

要求：
- 代码结构清晰
- 包含必要的异常处理
- 不要省略关键逻辑

它会给你一版实现。

这时候别急着复制进项目。

真正关键的动作在后面。

第二步：让它进入“挑刺模式”

直接用下面这段提示词。

现在请你不要继续优化代码。

请站在代码审查者的角度，严格检查你刚才写的代码。

重点检查：
- 是否有运行时错误
- 是否有安全漏洞
- 是否有边界条件遗漏
- 是否有异步处理问题
- 是否有异常没有捕获
- 是否有变量名、依赖、导入缺失
- 是否有测试难以覆盖的地方

请按下面格式输出：

## 问题清单
- 问题位置：
- 问题原因：
- 可能后果：
- 修复建议：

不要说“整体没问题”。如果你认为没问题，也要说明你检查了哪些点。

这段提示词的重点是两句话：

• “不要继续优化代码”
• “不要说整体没问题”

前一句防止它一边检查一边重写，越改越乱。
后一句防止它偷懒。

你会发现，Opus 4.8 更容易指出自己上一轮的漏洞，比如：

• 忘了导入某个依赖
• JWT secret 没校验
• 用户不存在和密码错误返回信息可能泄露风险
• 没处理数据库查询异常
• bcrypt compare 没有 await
• 请求体为空时会报错

这才是有价值的 review。

第三步：让它只修问题，不要顺手大装修

AI 有个毛病：一修 bug，就想顺便“重构全世界”。

你只是让它补个异常处理，它可能给你换架构、换目录、换命名、换鉴权方案。看着高级，合进去全是冲突。

所以修复时要加限制。

请根据上面的“问题清单”修复代码。

限制条件：
- 尽量保持原有结构不变
- 不要引入新的框架
- 不要改接口入参和返回格式
- 只修复已发现的问题
- 如果必须调整结构，请先说明原因

请输出：
1. 修复后的完整代码
2. 每处修改对应解决的问题

这样它会收敛很多。

你拿到代码后，也更容易做 diff。

第四步：让它补测试，尤其是失败场景

很多人只让 AI 写主流程测试。

比如登录接口，只测“账号密码正确能登录”。

这不够。

真正容易炸的地方，通常都在失败场景里。

继续用这段：

请为修复后的登录接口补充测试用例。

重点覆盖失败场景：
- email 为空
- password 为空
- 请求 body 为空
- 用户不存在
- 密码错误
- 数据库查询异常
- JWT_SECRET 未配置
- bcrypt 校验抛错

要求：
- 使用 Jest
- 每个测试说明验证目标
- 不要只写 happy path
- 如果需要 mock，请给出完整 mock 示例

这里的关键是：别只测 happy path。

真实项目里，用户不会按你的想象输入。线上环境也不会永远配置正确。数据库更不会天天心情好。

一个更狠的提示词：让 Opus 4.8 自己反驳自己

如果你想进一步压榨它的审查能力，可以让它扮演两个角色。

请对你刚才的实现进行双角色审查。

角色 A：原作者
- 解释这段代码为什么这样设计
- 说明你认为它安全、可靠的原因

角色 B：挑剔的代码审查者
- 逐条反驳角色 A
- 找出隐藏风险
- 指出哪些假设不成立
- 给出更稳妥的修复方案

输出时不要写空泛评价，要引用具体代码片段。

这个玩法很适合复杂逻辑。

比如：

• 支付回调
• 权限判断
• 数据同步脚本
• 文件上传
• 定时任务
• 订单状态流转

这些场景一旦出错，不是页面报个红那么简单，可能是真扣钱、错发货、权限泄露。

让它自己反驳自己，能挖出不少隐藏问题。

场景示例：用 Opus 4.8 检查一个文件上传接口

假设你写了一个头像上传接口。

你可以这样让它审：

请审查下面的头像上传接口，重点检查安全问题。

关注点：
- 文件类型校验是否可靠
- 文件大小是否限制
- 文件名是否可能导致路径穿越
- 是否可能上传脚本文件
- 是否会覆盖已有文件
- 错误处理是否会泄露服务器路径
- 是否适合放到生产环境

请输出高风险、中风险、低风险问题，并给出修复代码。

代码如下：
[粘贴代码]

它通常会指出这些点：

• 不能只看文件后缀
• 文件名要重新生成，别相信用户上传的名字
• 需要限制 MIME 类型和文件大小
• 上传目录不能直接暴露执行权限
• 错误信息不要返回本地路径
• 最好做图片内容校验

这类建议很实用。

你照着改，线上事故概率会低很多。

Opus 4.8 自查能力变强后，最值得改的习惯

别再把 AI 当“一次性答案机”。

更好的用法是把它当成一个流程里的多个角色：

• 需求分析员：帮你拆需求
• 工程师：帮你写实现
• Reviewer：帮你找问题
• 测试工程师：帮你补用例
• 运维视角：帮你看配置和异常

同一个模型，不同提示词，表现会差很多。

你只说“帮我看看”，它可能随便看看。
你说“按安全漏洞、边界条件、运行时错误逐条检查”，它才知道该往哪儿用力。

AI 不怕任务难，怕你说得太糊。

避坑清单：别把 Opus 4.8 当神仙

Opus 4.8 的自查确实更强，但别直接闭眼上线。

下面这些坑，还是要躲。

1. 不要只让它检查“有没有问题”

这个问法太宽。

换成：

请检查运行时错误、安全漏洞、边界条件、并发问题、异常处理和测试覆盖缺口。

越具体，结果越有用。

2. 不要让它一边审查一边重写

容易把问题搞混。

审查阶段只输出问题。
修复阶段再改代码。

3. 不要忽略依赖和运行环境

很多 bug 不在代码逻辑里，而在环境里。

比如：

• Node 版本不兼容
• Python 包版本不同
• 环境变量没配置
• 数据库字段名对不上
• 前端接口路径写错

提示词里最好补一句：

如果问题可能来自运行环境、依赖版本或配置，也请指出。

4. 不要让它默认你的业务规则

比如订单能不能取消，优惠券能不能叠加，退款后库存怎么回滚。

这些不是模型能凭空知道的。

你要把规则说清楚。

业务规则：
- 已支付订单 30 分钟内可取消
- 已发货订单不可取消
- 取消后需要回滚库存
- 使用优惠券的订单取消后，优惠券恢复为可用

再让它审查，效果完全不一样。

5. 不要省掉测试

AI 说修好了，不代表真修好了。

让它补测试，再自己跑一遍。

命令行里的绿色通过，比模型的自信靠谱多了。

可以直接收藏的万能审查模板

下面这段适合大部分代码场景。

你现在是一个非常严格的代码审查者。

请审查下面的代码，不要急着重写。

请重点检查：
- 运行时错误
- 逻辑漏洞
- 安全风险
- 边界条件
- 异常处理
- 并发或异步问题
- 性能隐患
- 可测试性问题
- 依赖、导入、配置缺失

输出格式：

## 高风险问题
- 位置：
- 原因：
- 后果：
- 修复建议：

## 中风险问题
- 位置：
- 原因：
- 后果：
- 修复建议：

## 低风险问题
- 位置：
- 原因：
- 后果：
- 修复建议：

## 建议补充的测试用例
- 用例名称：
- 输入：
- 预期结果：

要求：
- 必须引用具体代码位置
- 不要写空泛评价
- 如果没有发现某类问题，请说明检查依据

代码如下：
[粘贴代码]

把它放进你的常用提示词库。

每天写完功能丢进去跑一遍，很多低级 bug 能提前拦住。

适合 Opus 4.8 的高价值任务

如果你想快速感受差异，别拿“写个 Todo List”测。

用下面这些任务更明显：

• 审查登录、注册、找回密码接口
• 检查支付回调幂等性
• 分析订单状态机漏洞
• 检查 SQL 查询是否有注入风险
• 审查文件上传安全
• 给复杂函数补单元测试
• 找 React 组件里的状态同步问题
• 检查异步队列是否会重复消费
• 审查定时任务失败重试逻辑

这些场景里，模型会不会找问题，一眼就能看出来。

我的建议：把 Opus 4.8 放在“提交前 10 分钟”

如果你每天都写代码，可以养成一个简单习惯：

准备提交前，把核心代码丢给 Opus 4.8 审一遍。

别让它泛泛评价。
让它按风险分级。
让它补测试。
让它解释每个问题的后果。

这套流程跑下来，你会少很多尴尬时刻：

• 刚提 PR 就被同事指出空指针
• 测试环境一跑就 500
• 上线后发现环境变量没配
• 用户输入一个空字符串就把接口打崩
• 支付回调重复执行两次，订单状态乱了

AI 最值钱的地方，不是帮你写出第一版代码。

第一版代码谁都能写。

真正省时间的是：它能帮你在提交前，把那些“你以为没问题”的地方揪出来。