#能力#
很多人现在已经能用 Claude Code 做出东西了。
一个小网页。
一个本地工具。
一个项目原型。
一个自动整理文件的脚本。
一个能跑起来的功能页面。
但真正麻烦的地方，往往出现在做完之后。
AI 说“完成了”，真的完成了吗？
页面能打开，就代表没有问题吗？
按钮能点，就代表流程顺吗？
代码能跑一次，就代表以后不会坏吗？
很多时候，AI 做东西很快。
可它也很容易漏掉细节。
比如：
删除按钮没确认；
刷新后数据丢了；
手机号输入没校验；
空文件上传会报错；
某个文件路径写死了；
账号、密钥、测试数据被放进代码里；
页面看着能用，手机上一打开全乱了。
所以现在真正值得关注的，不只是“AI 会不会做”。
更重要的是：
AI 做完以后，有没有另一组 AI 专门帮你挑错。
Claude Code 最近开放的 /ultrareview，就是这个方向。
这个功能可以理解成：
让一队云端 AI 审查员，帮你在合并或交付前找 bug。
一、/ultrareview到底是什么？
Claude Code 官方文档里写得很明确：
/ultrareview 是一个研究预览功能，从 Claude Code v2.1.86 及以上版本开始可用。它会在 Claude Code 的云端基础设施里运行深度代码审查。当你执行 /ultrareview 时，Claude Code 会在远程沙箱里启动一队审查智能体，检查你当前分支或拉取请求里的问题。
这里有几个词要翻译一下。
研究预览，意思是功能已经开放试用，但价格、可用性、细节后面还可能调整。
远程沙箱，可以理解成一个云端隔离环境。它不会在你本地电脑里跑一堆审查任务，而是把代码状态送到云端环境里检查。
一队审查智能体，就是多个 AI 审查员并行看你的改动，而不是一个模型扫一遍就结束。
官方说，相比本地 /review，/ultrareview 有三个特点：
第一，信号更高。每个发现的问题都会经过独立复现和验证，所以更关注真实 bug，而不是风格建议。
第二，覆盖更广。很多审查智能体会并行探索改动，容易发现单次审查漏掉的问题。
第三，不占本地资源。审查跑在远程沙箱里，你的终端还能继续干别的事。
这就很关键。
普通的“帮我看一下代码”，更多像请一个人快速扫一眼。
/ultrareview 更像请了一组挑错员：
有人看逻辑。
有人看边界。
有人看安全。
有人看回归。
有人看改动和旧代码有没有冲突。
而且它还会尝试验证问题，减少“看起来像问题，其实不是问题”的噪音。
二、为什么这个功能很值得关注？
因为它戳中了 AI 做项目时最真实的痛点：
做出来很快，验收很难。
以前我们总说：
让 AI 帮我做个网页。
让 AI 帮我修个 bug。
让 AI 帮我生成项目。
让 AI 帮我写个小工具。
现在问题变了。
做出来以后，谁来验收？
很多人自己不会代码。
也不懂安全。
也不知道边界情况怎么测。
AI 说完成了，你只能打开页面点两下。
能点，就觉得差不多了。
但一个小工具真正容易出问题的地方，往往不是首页能不能显示。
而是：
输入为空怎么办？
重复提交怎么办？
网络失败怎么办？
刷新后数据还在不在？
文件名带中文会不会报错？
金额带小数会不会算错？
路径换一台电脑还能不能用？
有没有把调用钥匙写进页面？
/ultrareview 的价值，就在于它把“AI 做完以后再找一队 AI 挑错”这件事，变成了一个命令。
三、怎么用？
先确认版本。
claude --versioncode>官方文档说，/ultrareview 需要 Claude Code v2.1.86 或更高版本。
然后进入一个 Git 项目。
Git 项目可以简单理解成有版本记录的项目文件夹。
在 Claude Code 里运行：
/ultrareview如果不带参数，它会审查你当前分支和默认分支之间的差异，包括未提交和已暂存的改动。Claude Code 会把仓库状态打包上传到远程沙箱里审查。
如果你要审查 GitHub 上的某个拉取请求，可以写：
/ultrareview 1234这里的 1234 换成你的拉取请求编号。
拉取请求可以理解成把一批改动准备合并进主项目之前的申请。
官方文档说，在拉取请求模式下，远程沙箱会直接从 GitHub 克隆对应请求，而不是打包你本地的工作目录；这个模式要求项目里有 github.com 远程地址。
启动前，Claude Code 会显示确认信息。
它会告诉你：
这次审查范围；
文件和行数；
剩余免费次数；
预估费用。
你确认后，审查会在后台继续跑，你还可以继续使用当前会话。官方也明确说，这个命令只有你手动调用 /ultrareview 时才会运行，Claude 不会自己偷偷启动。
四、它和普通/review有什么区别？
Claude Code 里本来就有 /review。
那为什么还要 /ultrareview？
官方文档给了一个清晰对比：
/review 在本地会话里跑，通常几秒到几分钟，适合你边做边快速看反馈。
/ultrareview 在云端远程沙箱里跑，使用多智能体并行审查和独立验证，通常 5 到 10 分钟，适合重要改动合并前做更深一轮检查。
大白话讲：
/review 像随手检查。
/ultrareview 像交付前体检。
什么时候用 /review？
刚改完一个页面。
想快速看有没有明显问题。
还在反复调整阶段。
不想花太多时间和成本。
什么时候用 /ultrareview？
要合并重要改动。
涉及登录、支付、数据迁移、权限、文件操作。
改动比较大。
自己不放心。
想让一组 AI 深挖一遍。
官方周报里也建议，在合并关键改动前，比如认证和数据迁移这类任务，可以运行 /ultrareview。
五、费用和账号要提前讲清楚
这点必须提醒。
/ultrareview 不是所有 Claude Code 使用方式都能用。
官方文档明确写到，它需要 Claude.ai 账号认证，因为它运行在 Claude Code 的网页基础设施上。如果你只用 API Key 登录，需要先运行 /login，用 Claude.ai 账号认证。它在使用 Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry 时不可用；启用了零数据保留的组织也不能用。
这对刚看过第三方模型教程的人尤其重要。
如果你现在是 Claude Code 加 DeepSeek、Kimi、GLM、MiniMax 这类第三方模型，/ultrareview 这条官方云审查路线不一定能直接用。
因为它依赖 Claude Code 的网页基础设施和 Claude.ai 账号。
还有费用问题。
官方文档写到，/ultrareview 是高级功能，会按额外用量计费。Pro 和 Max 用户有 3 次免费试用，但这 3 次是一次性额度，不会刷新，并且截至 2026 年 5 月 5 日；免费次数用完后，审查通常根据改动大小花费 5 到 20 美元。Team 和 Enterprise 没有免费次数，直接按额外用量计费。
所以这篇不能写成“所有人无脑冲”。
更合适的建议是：
先用 /review 做日常快速检查。
真正重要的改动，再考虑 /ultrareview。
运行前看清范围、剩余次数和预估费用。
第一次别拿特别大的项目试。
六、第一次适合拿什么项目试？
别上来就审一个几万行大项目。
第一次建议拿一个小而完整的项目。
比如：
本地待办清单网页；
家庭账单整理工具；
图片素材分类页面；
简单客户跟进表；
文章发布前检查工具；
一个带登录或文件上传的小项目。
最适合的测试方式是：
先让 Claude Code 做一个小工具。
请做一个本地待办清单网页。要求：1. 只用一个 index.html 文件2. 可以新增任务3. 可以勾选完成4. 可以删除任务5. 刷新后任务还在6. 不要使用后端和数据库做完以后，你可以先让它本地快速检查：
/review如果这个项目已经进入 Git 管理，再运行：
/ultrareview这样你能对比两种体验：
本地快速检查会指出什么；
云端多智能体审查又会补出什么。
如果 /ultrareview 能发现刷新保存、输入为空、边界条件、数据覆盖之类的问题，你就能很直观地感受到它的价值。
七、结果出来后怎么看？
官方文档说，审查一般需要 5 到 10 分钟。它会在后台运行，你可以继续使用会话、开始别的命令，甚至关闭终端。你可以用 /tasks 查看正在运行和已完成的审查，也可以打开详情或停止正在进行的审查。审查完成后，经过验证的问题会作为通知回到你的会话里。每个问题会包含文件位置和解释，方便你继续让 Claude 修复。
这里建议读者看三件事。
第一，看严重程度。
影响数据、权限、支付、删除文件的，优先处理。
只是命名、风格、排版的小建议，可以后处理。
第二，看能不能复现。
/ultrareview 的重点就是会验证问题。
但你自己仍然要让 Claude 解释：
请解释这个问题为什么会发生。给我一个最小复现步骤。先不要改文件。第三，看修复是否过度。
AI 找到问题后，另一个 AI 修复问题，也可能改得太多。
所以修复前建议说：
请只修复这个问题。不要顺手重构。不要改动无关文件。修复前先告诉我计划。这个习惯很重要。
深度审查发现问题，只是第一步。
修复时控制范围，同样关键。
八、如果没有 Claude.ai 账号，Hermes 和 OpenClaw 能不能做类似效果？
这个点很值得讨论。
官方 /ultrareview 的云端多智能体审查，短期内很难在 Hermes 或 OpenClaw 里完整复刻。
因为它依赖几个东西：
云端沙箱；
多个审查智能体并行；
独立复现和验证；
和 Claude Code 网页基础设施打通；
成本、任务、结果回传系统。
这些不是写一个提示词就能完全得到。
但思路可以借鉴。
可以把它拆成一个更轻量的 Skill，也就是技能包：
让 Agent 在交付前按多个审查角色检查一次。
OpenClaw 官方文档里说，它使用兼容 AgentSkills 的技能文件夹来教智能体使用工具；每个技能是一个目录，里面包含 SKILL.md 和说明。
Hermes 官方文档也说，技能包是按需加载的知识文档，放在 ~/.hermes/skills/，用来教 Hermes 处理特定任务。
所以，Hermes 和 OpenClaw 虽然没有官方 /ultrareview，但可以做一个“交付前挑错”技能包。
它达不到 Claude Code 云端多智能体的强度。
可对于小网页、小工具、资料整理器、自动化脚本来说，已经很有价值。
九、可以怎么做一个“交付前挑错 Skill”？
思路很简单。
让 Skill 固定做 5 类检查：
- 功能检查：能不能完成核心任务；
- 边界检查：空输入、重复输入、异常文件、刷新、断网；
- 安全检查：有没有密钥、账号、隐私信息暴露；
- 体验检查：按钮、提示、手机端、错误信息；
- 维护检查：有没有无关改动、硬编码路径、过度复杂。
Hermes 可以建一个技能包目录：
mkdir -p ~/.hermes/skills/preflight-review然后创建：
~/.hermes/skills/preflight-review/SKILL.md内容可以这样写：
---name: preflight-reviewdescription: 在项目交付前，从功能、边界、安全、体验、维护五个角度检查问题。适合网页、小工具、脚本、资料整理器交付前验收。version: 1.0.0# 交付前挑错你是交付前审查员。你的任务不是夸项目完成得不错，而是尽量找出可能翻车的地方。## 审查范围请从 5 个角度检查：1. 功能：核心功能是否真的可用2. 边界：空输入、重复输入、异常文件、刷新、断网会怎样3. 安全：是否泄露账号、密钥、路径、隐私数据4. 体验：提示是否清楚，手机端是否能用，错误信息是否友好5. 维护：是否有硬编码、无关改动、过度复杂逻辑## 输出格式### 最高风险列出最值得先修的 3 个问题。### 可复现步骤每个问题尽量给出怎么复现。### 修复建议只给小范围修复建议，不要建议大重构。### 验收清单列出修完后需要检查的项目。## 规则- 先检查，不要直接改文件- 不确定时说不确定- 不要为了显得专业而编问题- 优先找真实会影响使用的问题然后检查 Hermes 是否识别：
hermes skills list使用时可以说：
请使用 preflight-review 技能包，检查这个待办清单网页。先不要改文件，只给我风险、复现步骤和验收清单。OpenClaw 的 Skill 也是一个目录加 SKILL.md。官方文档说，OpenClaw 使用兼容 AgentSkills 的技能文件夹，SKILL.md 里有元数据和说明，用来教智能体完成特定任务。
所以 OpenClaw 也可以做类似技能包。
思路同样是：
创建一个 preflight-review 技能。
写清楚五类检查。
要求先给计划，不要直接改文件。
要求输出复现步骤和验收清单。
每次交付前调用一次。
这在 OpenClaw 里尤其有意义。
因为 OpenClaw 这类本地智能体通常权限更强，能访问文件、终端、浏览器，甚至一些本地服务。
权限越强，越需要交付前检查。
十一、Skill 版和官方/ultrareview的差距
这里要讲清楚，不能夸过头。
Skill 版“交付前挑错”有用，但它不是官方 /ultrareview 的平替。
差距主要有三点。
第一，官方 /ultrareview 是多智能体并行审查。
Skill 版通常还是当前 Agent 按流程检查。
第二，官方 /ultrareview 会在远程沙箱里复现和验证问题。
Skill 版更多依赖本地 Agent 能不能运行测试和读懂项目。
第三，官方 /ultrareview 会把结果回传到 Claude Code 会话里。
Skill 版需要你自己把检查结果整理成修复任务。
但 Skill 版也有优点。
成本更低。
工具更通用。
可以放进 Hermes、OpenClaw 等工作流。
可以按自己的场景改，比如专门检查文章、表格、网页、小工具、资料包。
所以我的建议是：
官方 /ultrareview 适合重要代码改动。
Skill 版“交付前挑错”适合日常小任务验收。
一个重，一个轻。
十二、这件事真正提醒了什么？
过去我们讲 AI 工具，重点常常放在“它能做什么”。
能写代码。
能做网页。
能整理资料。
能生成图片。
能接模型。
能装技能包。
现在开始进入下一个阶段：
AI 做完之后，谁来检查？
这是一个很现实的问题。
因为 AI 的执行力越来越强。
执行力越强，错误的影响也越大。
以前 AI 写错一句话，你删掉就行。
现在 AI 改错一个文件，可能项目跑不起来。
AI 写错一个路径，可能数据丢失。
AI 漏掉一个权限判断，可能带来安全风险。
AI 把调用钥匙写进前端代码，可能直接泄露。
所以，未来好用的 Agent 工作流，应该有两步：
第一步，让 AI 做事。
第二步，让另一套机制挑错。
这个挑错机制，可以是 Claude Code 官方的 /ultrareview。
也可以是 Hermes 或 OpenClaw 里的交付前审查 Skill。
还可以是你自己固定的一套验收清单。
关键是：别让“完成了”三个字成为终点。
十三、给一个最小可用验收模板
如果你暂时不用 /ultrareview，也不想马上写 Skill，可以先复制这段给任何 Agent：
请对当前项目做交付前检查。先不要修改文件。请从 5 个角度检查：1. 功能：核心功能是否真的可用2. 边界：空输入、重复输入、异常情况会怎样3. 安全：有没有密钥、账号、隐私、路径泄露4. 体验：错误提示、手机端、按钮反馈是否清楚5. 维护：有没有无关改动、硬编码、过度复杂逻辑输出格式：- 最高风险 3 个- 每个风险的复现步骤- 建议的小范围修复方案- 修复后的验收清单不要夸项目。不要写空泛建议。优先找真实会影响使用的问题。这就是一个轻量版 /ultrareview 思路。
不如官方云端多智能体强，但比“帮我检查一下”好很多。
最后说一句
Claude Code 的 /ultrareview 值得关注，不只是因为它多了一个命令。
它代表了 Agent 工作流的一个新方向：
AI 不光要会做，还要会被审查。
做得快，是第一层能力。
查得出问题，是第二层能力。
能把问题修小、修准、不乱改，是第三层能力。
以后我们用 AI 做项目，可能都会养成一个习惯：
先让 AI 做。
再让 AI 挑错。
最后让 AI 按清单修。
Claude Code 已经把这件事做成了官方云端功能。
Hermes、OpenClaw 这类工具，也可以用 Skill 的方式先做轻量版。
如果你已经能让 AI 做出小工具，下一步就别只问“它做完了吗”。
多问一句：
有没有另一双 AI 眼睛，帮我认真挑过错？
热门跟贴