AI review 到底靠不靠谱？
- 内容介绍
- 文章标签
- 相关推荐
在开始回答这个问题前，我们先来做一个实验。
以 GPT-5.4 Xhigh 为例，你只需要打开任意一个你当前的项目，开启计划模式，输入任意需求，等待他生成方案后实施方案，然后进入 AI review 审查阶段，此时新开一个会话，输入下面的提示词
我实施了以下计划：
```
XXX（这里放他生成的实施方案）
```
请你审查更改diff检查是否全部功能已实现，如果存在遗漏请帮我修复，如果全部已实现，请告知
第一次这么问，AI 大概率能找出一批遗漏并修复。
接下来继续新开一个会话，再把一样的提示词再喂进去，它又能继续找到新的遗漏并继续修。再开一次，还能继续找。这个过程只要你愿意将可以无限循环。
当然，上述情况不止是 GPT-5.4 Xhigh 会出现这样的问题，你换任意 AI 模型都会得到大差不差的结论。
OK，看到这里你现在脑子里念头更符合下面哪个结论？：
- AI 真强，可以永远不会疲倦的 review
- AI 不可靠，它根本什么都做不好
而我认为：
AI review 的确能发现问题，但它没有能力证明“问题已经被找完了”。
这不是某个模型、某个产品或者某个框架独有的毛病，而是当前大模型的底层缺陷。
一、从底层原理看：它为什么会这样
1. 大模型就是一个概率生成器
今天的大模型，其本质上是 “根据上下文预测下一个最可能 token” 。无论外面包了多少 agent、workflow、skills、MCP，底层核心仍然是这个机制。
这意味着它更擅长：
-
生成一个“看起来合理”的回答
-
延续一个“局部一致”的分析链条
-
根据提示词提供高概率的补充项
换句话说，让 AI 生成一个像样的答案，通常比证明这个答案已经完整，要容易得多。这也是为什么 AI 在开头实验下偏向于“补一个可能遗漏的点”，却不会说“已经没有任何遗漏了”。
2. “是否全部实现”本身就是一个高歧义问题
很多人可能没意识到其实“是否全部实现”实际上本身就是一个高度压缩语境，而且极度含糊。
“全部实现”到底指什么？是主流程能跑通就算实现？还是边界条件、错误处理、权限校验、性能退化都算？是只看当前改动涉及的文件？还是要追溯所有可能受影响的调用链？是功能存在即可？还是必须满足你脑中那个没写出来的验收标准？
实际上大部分人也说不明白，实际上连实施方案其实都是 AI 自己生成的。
如果验收标准没有被明确列出来，那么 AI review 实际上只能对“一个模糊目标”做猜测。而面对模糊目标，模型会优先给出“像审查结果”的东西，或者不断补充新的合理怀疑点
3. 训练偏置的影响
现在的大模型通常在训练时就决定了要“尽量对用户有帮助”。
当你说“请审查一下是否全部实现，如果有遗漏请帮我修复”时，这类指令天然会把模型推向一种倾向：
-
找出问题，显得自己有价值
-
给出补充项，显得自己在推进任务
-
避免过早说“没有问题了”，因为这在很多场景里反而更像失职
于是它往往更愿意报出“可能存在的遗漏”
二、当前 AI review 的核心局限
传统软件工程里，要证明“已经没有遗漏”，本来就非常难。很多时候人也不敢打包票，只能通过严格的验收标准、测试、回归检查、代码阅读和线上反馈去逼近。而 AI review 在缺乏完整规格说明的情况下，大模型只会把眼前这一段说圆。但项目不是一段回答，项目是一个由需求、接口、状态、边界、依赖和历史包袱拼起来的整体系统。你修复一个局部缺口，很可能引入另一个局部缺口。AI 能看到这一次改动中的一部分影响，却不一定能稳定地追踪所有连锁反应。
0基础的小白在长期维护一个项目后往往会出现的经典场景：
-
本轮修复 A 问题
-
下轮 review 才发现 A 的修复又暴露了 B
-
再下轮又发现 B 的修复影响了 C
这不一定是模型“笨”，而是因为项目本来就是一个耦合系统。
很多真正致命的问题，不是代码语法层面的，也不是“少写一个 if”这种显性漏洞，而是隐性需求没有被说出来。而且更加危险的不是 AI 明显乱说，而是它给了小白一种很像一切都完成的感觉：
-
已经审查了
-
已经修复了
-
已经再次审查了
看起来每一轮都有进展，但如果使用者缺乏基本代码理解能力，很容易把这种“持续产出”误判成“持续完成”，实际上，两者不是一回事。这也是我反感各类公众号胡吹海吹 AI 现在能力多强的原因。
三、为什么复杂工作流、MCP、 skills 和 agent 编排，不能让零基础的小白直接完成项目
现在我经常能看到这种说法：
只要把提示词写复杂一点，把 skills 配好，把 MCP 接上，把 agent 框架编排起来，哪怕看不懂代码的人，也可以把项目做出来。
这类说法的问题，不是它一点对的地方都没有，而是它把“工具能力扩展”误说成了“工程能力替代”。
不会代码的人，当然可能借助 AI 做出一个能跑的 demo，一个局部可用的脚本，一个短期凑合可用的小闭环，一个看上去功能齐全的原型。
不知道各位的公司有没有大力推广 all in AI，反正我周围的人周围的公司全都在鼓励非技术岗位使用 AI ，然后就会有很多非技术岗位的人拿着做出来的 demo 给老板狠狠的反馈，然后就没有然后了，如果老板觉得不错那么长期维护这下非技术岗位的人做出来的 demo 的人百分之九十九不会是他们自己，而是丢给开发，这是为什么？大家心里心知肚明。确实 AI 很有用，但是从 demo 到项目，中间隔着很多东西，真正的项目不是“代码出现了”，“页面出现了” 就算完成，而是“有人能持续判断这套东西能不能被信任地运行和演进”。
回到我个人理解，什么是工作流、MCP、 skills 和 agent 编排？
-
skills ：是把常见套路、检查清单、经验模板提前写好，帮助模型少走一些弯路。
-
MCP ：是给模型接上更多眼睛和手，让它能读更多文件、查更多接口、调用更多外部工具。
-
agent ：是把任务拆分、串联、并行、重试，让工作流看起来更像一个自动化系统。
这些东西当然有价值，但它们本质上做的是：
-
让模型看得更多
-
让模型做得更快
-
让流程组织得更像“工程”
但是它们并没有下面这些真正关键的能力：
-
什么需求是核心，什么需求是噪音
-
哪个实现是表面修复，哪个实现会引入长期债务
-
哪个边界条件必须覆盖，哪个可以延后
-
哪个问题是 bug，哪个只是风格争议
-
什么叫“达到可交付标准”
工具链可以扩展操作半径，但不能替代判断责任。项目真正困难的部分，从来不是“把 demo 生成出来”
很多小白会误以为，项目开发的难点主要是“我不会写代码”。而实际上真正难的是：
-
你能不能把需求说清楚
-
你能不能识别需求之间互相冲突的地方
-
你能不能知道一个改动会影响哪些旧逻辑
-
你能不能定义验收标准
-
你能不能分辨“暂时能跑”和“长期可维护”
-
你能不能在多个看似合理的方案之间做取舍
这些能力不是多接几个工具就会凭空长出来的。
把各种 skills、工作流、MCP 接口、长提示词堆起来，本质上仍然是在给一个概率生成系统提供更多脚手架，而不是让它变成真正理解业务、理解架构、理解代价的负责人。
很多神话叙事都把项目理解成一次性文本生成任务，好像只要 prompt 足够长，流程足够复杂，任务就能被自动做完。
但工程实际上更接近一连串连续决策：
-
先定义问题
-
再缩小问题
-
再选择方案
-
再约束实现
-
再验证结果
-
再处理回归
-
再为后续演进留余地
这整个链条里，真正稀缺的不是“写代码的能力”，而是“判断哪些生成结果值得信任”的能力。没有这层能力，工具越多，很多时候只是把错误自动化得更快。
四、AI 不是万能的
看到这里估计应该有人又想说，既然 AI review 有局限，是不是就不该用了？我的回答是：不是。我并不认为 AI review 没价值。恰恰相反，它在很多时候非常有价值：
-
它能快速补常见遗漏
-
它能提供额外视角
-
它能帮你整理检查清单
-
它能在你思路卡住时给出新的怀疑方向
但它的价值越大，我们越需要准确理解它的边界。我说那么多不是为了鼓励大家抛弃它，而是把它放回一个正确的位置，去魅，而不是认为 AI 无所不能。AI 在这些位置上会很好用，但前提是你知道它在替你做哪一部分工作，以及哪一部分不能交出去。
真正需要被反驳的，不是“AI 很有用”这件事，而是：
看不懂代码的人，只要把各种 skills、agent、工作流、编排框架、提示词和 MCP 堆起来，就可以完成项目。
更接近当前实际情况的说法应该是：
不会代码的人，确实可以借助 AI 做出一些东西；但这和能够稳定、持续、负责任地完成工程项目，不是一回事。
前者叫借力，后者叫负责。
而工程，最终是要有人负责的。
网友解答：--【壹】--：
能跑就行
--【贰】--：
测试人员的含金量还在上升
--【叁】--：
话说回来，人的工作模式不也是这么回事吗，看到你，脑子中会推测是下一个字是妈还是好。
区别只不过人脑的逻辑处理能力远大于现有的任何ai系统。
--【肆】--：
很赞同,ai review能节省很多精力,但是只能作为辅助工具使用
--【伍】--：
codex里面从计划到生成到每一次修改均让他调用gpt-5.4 xhigh子代理进行review，然后昨天把got接入claude code，顺手就让gpt5.4 review了下，结果找出七八个严重问题
--【陆】--：
非常赞同佬的观点。我也有个想法，这就是说AI不是大家所说的平权，其实他反倒是拉大了使用AI的专业人员和不使用AI的普通人之间的差距。
--【柒】--： xk128:
型、某个产品或者某个框架独有的毛病，而是当前大模型的底层缺陷。
是的就是一个可以正常走路的弗兰肯斯坦
慢慢走还好
你让他猪突猛进容易解体
目前的情况是大家都在狂奔
等出了问题再说
就看什么时候铁人叛乱了
--【捌】--：
我个人的想法是平均水平总是升高的，但是用和不用之间的两端差距也会越来越大
--【玖】--：
深有体会, 之前在试用 OMO 的时候, 就发现一直在 review, 修改, review, 修改, 干了一个小时都没收敛
--【拾】--：
何意味？
--【拾壹】--：
那我不用 ai review 了
在开始回答这个问题前，我们先来做一个实验。
以 GPT-5.4 Xhigh 为例，你只需要打开任意一个你当前的项目，开启计划模式，输入任意需求，等待他生成方案后实施方案，然后进入 AI review 审查阶段，此时新开一个会话，输入下面的提示词
我实施了以下计划：
```
XXX（这里放他生成的实施方案）
```
请你审查更改diff检查是否全部功能已实现，如果存在遗漏请帮我修复，如果全部已实现，请告知
第一次这么问，AI 大概率能找出一批遗漏并修复。
接下来继续新开一个会话，再把一样的提示词再喂进去，它又能继续找到新的遗漏并继续修。再开一次，还能继续找。这个过程只要你愿意将可以无限循环。
当然，上述情况不止是 GPT-5.4 Xhigh 会出现这样的问题，你换任意 AI 模型都会得到大差不差的结论。
OK，看到这里你现在脑子里念头更符合下面哪个结论？：
- AI 真强，可以永远不会疲倦的 review
- AI 不可靠，它根本什么都做不好
而我认为：
AI review 的确能发现问题，但它没有能力证明“问题已经被找完了”。
这不是某个模型、某个产品或者某个框架独有的毛病，而是当前大模型的底层缺陷。
一、从底层原理看：它为什么会这样
1. 大模型就是一个概率生成器
今天的大模型，其本质上是 “根据上下文预测下一个最可能 token” 。无论外面包了多少 agent、workflow、skills、MCP，底层核心仍然是这个机制。
这意味着它更擅长：
-
生成一个“看起来合理”的回答
-
延续一个“局部一致”的分析链条
-
根据提示词提供高概率的补充项
换句话说，让 AI 生成一个像样的答案，通常比证明这个答案已经完整，要容易得多。这也是为什么 AI 在开头实验下偏向于“补一个可能遗漏的点”，却不会说“已经没有任何遗漏了”。
2. “是否全部实现”本身就是一个高歧义问题
很多人可能没意识到其实“是否全部实现”实际上本身就是一个高度压缩语境，而且极度含糊。
“全部实现”到底指什么？是主流程能跑通就算实现？还是边界条件、错误处理、权限校验、性能退化都算？是只看当前改动涉及的文件？还是要追溯所有可能受影响的调用链？是功能存在即可？还是必须满足你脑中那个没写出来的验收标准？
实际上大部分人也说不明白，实际上连实施方案其实都是 AI 自己生成的。
如果验收标准没有被明确列出来，那么 AI review 实际上只能对“一个模糊目标”做猜测。而面对模糊目标，模型会优先给出“像审查结果”的东西，或者不断补充新的合理怀疑点
3. 训练偏置的影响
现在的大模型通常在训练时就决定了要“尽量对用户有帮助”。
当你说“请审查一下是否全部实现，如果有遗漏请帮我修复”时，这类指令天然会把模型推向一种倾向：
-
找出问题，显得自己有价值
-
给出补充项，显得自己在推进任务
-
避免过早说“没有问题了”，因为这在很多场景里反而更像失职
于是它往往更愿意报出“可能存在的遗漏”
二、当前 AI review 的核心局限
传统软件工程里，要证明“已经没有遗漏”，本来就非常难。很多时候人也不敢打包票，只能通过严格的验收标准、测试、回归检查、代码阅读和线上反馈去逼近。而 AI review 在缺乏完整规格说明的情况下，大模型只会把眼前这一段说圆。但项目不是一段回答，项目是一个由需求、接口、状态、边界、依赖和历史包袱拼起来的整体系统。你修复一个局部缺口，很可能引入另一个局部缺口。AI 能看到这一次改动中的一部分影响，却不一定能稳定地追踪所有连锁反应。
0基础的小白在长期维护一个项目后往往会出现的经典场景：
-
本轮修复 A 问题
-
下轮 review 才发现 A 的修复又暴露了 B
-
再下轮又发现 B 的修复影响了 C
这不一定是模型“笨”，而是因为项目本来就是一个耦合系统。
很多真正致命的问题，不是代码语法层面的，也不是“少写一个 if”这种显性漏洞，而是隐性需求没有被说出来。而且更加危险的不是 AI 明显乱说，而是它给了小白一种很像一切都完成的感觉：
-
已经审查了
-
已经修复了
-
已经再次审查了
看起来每一轮都有进展，但如果使用者缺乏基本代码理解能力，很容易把这种“持续产出”误判成“持续完成”，实际上，两者不是一回事。这也是我反感各类公众号胡吹海吹 AI 现在能力多强的原因。
三、为什么复杂工作流、MCP、 skills 和 agent 编排，不能让零基础的小白直接完成项目
现在我经常能看到这种说法：
只要把提示词写复杂一点，把 skills 配好，把 MCP 接上，把 agent 框架编排起来，哪怕看不懂代码的人，也可以把项目做出来。
这类说法的问题，不是它一点对的地方都没有，而是它把“工具能力扩展”误说成了“工程能力替代”。
不会代码的人，当然可能借助 AI 做出一个能跑的 demo，一个局部可用的脚本，一个短期凑合可用的小闭环，一个看上去功能齐全的原型。
不知道各位的公司有没有大力推广 all in AI，反正我周围的人周围的公司全都在鼓励非技术岗位使用 AI ，然后就会有很多非技术岗位的人拿着做出来的 demo 给老板狠狠的反馈，然后就没有然后了，如果老板觉得不错那么长期维护这下非技术岗位的人做出来的 demo 的人百分之九十九不会是他们自己，而是丢给开发，这是为什么？大家心里心知肚明。确实 AI 很有用，但是从 demo 到项目，中间隔着很多东西，真正的项目不是“代码出现了”，“页面出现了” 就算完成，而是“有人能持续判断这套东西能不能被信任地运行和演进”。
回到我个人理解，什么是工作流、MCP、 skills 和 agent 编排？
-
skills ：是把常见套路、检查清单、经验模板提前写好，帮助模型少走一些弯路。
-
MCP ：是给模型接上更多眼睛和手，让它能读更多文件、查更多接口、调用更多外部工具。
-
agent ：是把任务拆分、串联、并行、重试，让工作流看起来更像一个自动化系统。
这些东西当然有价值，但它们本质上做的是：
-
让模型看得更多
-
让模型做得更快
-
让流程组织得更像“工程”
但是它们并没有下面这些真正关键的能力：
-
什么需求是核心，什么需求是噪音
-
哪个实现是表面修复，哪个实现会引入长期债务
-
哪个边界条件必须覆盖，哪个可以延后
-
哪个问题是 bug，哪个只是风格争议
-
什么叫“达到可交付标准”
工具链可以扩展操作半径，但不能替代判断责任。项目真正困难的部分，从来不是“把 demo 生成出来”
很多小白会误以为，项目开发的难点主要是“我不会写代码”。而实际上真正难的是：
-
你能不能把需求说清楚
-
你能不能识别需求之间互相冲突的地方
-
你能不能知道一个改动会影响哪些旧逻辑
-
你能不能定义验收标准
-
你能不能分辨“暂时能跑”和“长期可维护”
-
你能不能在多个看似合理的方案之间做取舍
这些能力不是多接几个工具就会凭空长出来的。
把各种 skills、工作流、MCP 接口、长提示词堆起来，本质上仍然是在给一个概率生成系统提供更多脚手架，而不是让它变成真正理解业务、理解架构、理解代价的负责人。
很多神话叙事都把项目理解成一次性文本生成任务，好像只要 prompt 足够长，流程足够复杂，任务就能被自动做完。
但工程实际上更接近一连串连续决策：
-
先定义问题
-
再缩小问题
-
再选择方案
-
再约束实现
-
再验证结果
-
再处理回归
-
再为后续演进留余地
这整个链条里，真正稀缺的不是“写代码的能力”，而是“判断哪些生成结果值得信任”的能力。没有这层能力，工具越多，很多时候只是把错误自动化得更快。
四、AI 不是万能的
看到这里估计应该有人又想说，既然 AI review 有局限，是不是就不该用了？我的回答是：不是。我并不认为 AI review 没价值。恰恰相反，它在很多时候非常有价值：
-
它能快速补常见遗漏
-
它能提供额外视角
-
它能帮你整理检查清单
-
它能在你思路卡住时给出新的怀疑方向
但它的价值越大，我们越需要准确理解它的边界。我说那么多不是为了鼓励大家抛弃它，而是把它放回一个正确的位置，去魅，而不是认为 AI 无所不能。AI 在这些位置上会很好用，但前提是你知道它在替你做哪一部分工作，以及哪一部分不能交出去。
真正需要被反驳的，不是“AI 很有用”这件事，而是：
看不懂代码的人，只要把各种 skills、agent、工作流、编排框架、提示词和 MCP 堆起来，就可以完成项目。
更接近当前实际情况的说法应该是：
不会代码的人，确实可以借助 AI 做出一些东西；但这和能够稳定、持续、负责任地完成工程项目，不是一回事。
前者叫借力，后者叫负责。
而工程，最终是要有人负责的。
网友解答：--【壹】--：
能跑就行
--【贰】--：
测试人员的含金量还在上升
--【叁】--：
话说回来，人的工作模式不也是这么回事吗，看到你，脑子中会推测是下一个字是妈还是好。
区别只不过人脑的逻辑处理能力远大于现有的任何ai系统。
--【肆】--：
很赞同,ai review能节省很多精力,但是只能作为辅助工具使用
--【伍】--：
codex里面从计划到生成到每一次修改均让他调用gpt-5.4 xhigh子代理进行review，然后昨天把got接入claude code，顺手就让gpt5.4 review了下，结果找出七八个严重问题
--【陆】--：
非常赞同佬的观点。我也有个想法，这就是说AI不是大家所说的平权，其实他反倒是拉大了使用AI的专业人员和不使用AI的普通人之间的差距。
--【柒】--： xk128:
型、某个产品或者某个框架独有的毛病，而是当前大模型的底层缺陷。
是的就是一个可以正常走路的弗兰肯斯坦
慢慢走还好
你让他猪突猛进容易解体
目前的情况是大家都在狂奔
等出了问题再说
就看什么时候铁人叛乱了
--【捌】--：
我个人的想法是平均水平总是升高的，但是用和不用之间的两端差距也会越来越大
--【玖】--：
深有体会, 之前在试用 OMO 的时候, 就发现一直在 review, 修改, review, 修改, 干了一个小时都没收敛
--【拾】--：
何意味？
--【拾壹】--：
那我不用 ai review 了