夜雨聆风
装完Superpowers，跑了一遍代码审查，出来十几条建议，每条都写得头头是道，什么「这里可以优化性能」「那个函数应该重构」「建议增加错误处理」。
看着都挺有道理，我一咬牙，全改了。
改完跑测试，炸了。三个功能挂了两个，还有一个跑是能跑，但结果不对。回滚回去一看，AI建议「优化」的那段代码，本来就没问题，改完反而引入了新bug。
（那一刻我盯着屏幕，想把这插件卸了）
但冷静下来想，这不是AI的问题，是我没有判断标准。AI给建议是它的职责，判断该不该采纳是我的职责，我把「建议」当成了「指令」，这才是翻车的根源。
01 AI给建议≠建议都对
Superpowers是Claude Code的技能框架插件，170K+ stars，8阶段工作流，从脑暴到代码审查一条龙。装完之后它会干一件事，给你的代码提建议。
很多建议。一堆建议。
交流群里有人装完后说，「是挺不错的，提出了不少建议，但是这些建议不知道是采还是不采纳」。
这不是Superpowers的问题，是所有AI审查工具的通病，它只管提，不管你能不能判断。就像PM只管提需求，不管开发能不能做，等等，我好像就是那个PM。
问题不是AI给的建议不好，是你没有「验收标准」。
AI不会拦你，它只会一脸正经地帮你把错误的想法执行到底。
你让它改，它就改，改完对不对它不负责，负责的是你。
02 PM怎么审需求，就怎么审AI的建议
PM做需求评审，不会业务方说「要做」就做，得交叉验证，看数据，看用户反馈，再评估技术可行性。
AI建议也一样。一个AI说「这里要改」，你信不信？
不信？那就再问一个。
但交叉验证不是「问更多人」，是「用不同视角看同一个问题」。
有人分享了个做法：tmux开两个窗格，左边Claude，右边GPT，同一个问题丢给两个模型，看它们意见一不一致。一致 → 大概率靠谱，可以采纳；不一致 → 要小心，得自己判断。
（这不就是PM的「多利益方评审」吗？只是把业务方换成了AI）
但这里有个坑。交叉验证不是万能的，两个AI可能犯同样的错，尤其是训练数据重叠的部分。所以真正的判断力还是在你自己，AI只是帮你缩小判断范围，不是替你判断。
需求评审也不是投票制，不是3个人说要做就做。关键是「为什么」，不是「多少人」。
道理都懂，具体怎么干？
03 三种交叉验证方式，踩了两个坑
手动复制粘贴，最笨但最稳。把Superpowers的建议复制到ChatGPT网页版，问它怎么看。零配置，打开浏览器就能干。缺点是累，上下文容易丢，复制过去的时候可能漏了关键信息，AI给的判断就偏了。
我就这么干过，复制了五条建议过去（累），ChatGPT说其中两条没必要改，一条改了会引入问题。我回去一看，确实。
tmux多窗口，一个终端跑Claude Code加Superpowers，另一个跑另一个模型。上下文完整，不用复制来复制去，但屏幕小的时候看着头疼，两个窗口来回切。
踩了个坑：两个模型的上下文窗口不一样，Claude能记住的ChatGPT可能忘了，得手动同步关键信息。我有一次忘了同步，结果两个AI基于不同的上下文给建议，对不上。
还有人提到Hermes Kanban模式，把审查任务拆成多个子任务并行跑。自动化，不用手动切窗口，但配置门槛高，得先装Hermes。
也踩了个坑：并行审查的时候，两个模型可能基于不同版本的代码给建议，合并的时候冲突。解决方法：先commit，再让所有模型基于同一个commit审查。
我自己的经验：小项目手动党，因为懒。大项目？我还没做过大的，等我做了再写。
04 判断一条建议该不该采纳，我自己的习惯
先看它改的是功能逻辑还是代码风格。 功能逻辑要慎重，代码风格随意。AI特别爱建议「优化」已经够用的代码，这种建议我一般不改。能跑就行，别动。
再看两个模型对这条建议的意见一不一致。一致的话采纳概率高，不一致就标记出来自己看。
还要看采纳后出了问题好不好回滚。好回滚就大胆试，不好回滚就多想一步。有些改动牵一发动全身，改完回不去，这种要特别小心。
还有一种建议是「看起来对但改了会炸」的那种。 是的，遇到过。AI建议重构一个函数，说这样更清晰。改完发现这个函数被十几个地方调用，调用方式全得改，工作量翻了三倍。（所以现在AI建议重构，我第一反应是「不动行不行」）
说到底，PM的核心能力就是判断什么值得做，现在这个能力用在了判断AI的建议上，也算是一种复用吧。
结尾
多模型交叉验证这件事，说白了就是把「一个人说了算」变成「多人评审」。
PM对这个逻辑应该不陌生，你每天都在干这事。
下次AI给你一堆建议的时候，别急着采纳，也别全否定。找一个你觉得最可疑的，丢给另一个AI看看，至少比你自己盯着代码纠结强。