vibe‑coding 九阳神功之验：多模型交叉验证，专治 AI 幻觉

vibe‑coding 九阳神功之验：多模型交叉验证，专治 AI 幻觉

系列顺序：夯（Git） → 抄 → 学 → 喂 → 规 → 验 → 测 → 扩 → 收 一句话：AI 说的都对？你信它你就输了。用 Claude 验 GPT，用 GPT 验 Claude，让它们互相打脸。

AI 编程现在最大的坑不是”不会写”，而是：

• 写得太快
• 改得太多
• 炸了没后路
• 炸完你甚至不知道它到底改了哪些文件

所以我准备写一套 vibe‑coding 九阳神功：核心不是提示词，而是把 AI 变成”可控交付的队友”。

这套”九阳神功”我先定了九个字诀：

• 夯：Git 生存技能（刹车 / 保险 / 录像）
• 抄：拆解 yfge/orion、ai-shifu/ai-shifu 的优秀骨架，搭底盘
• 学：学习行业黑话，会组合技术栈、不懂原理也能不翻车
• 喂：把 API 文档 / 资料结构化成可执行知识
• 规：让 AI 出计划 + tasks.md，按清单推进
• 验：多模型交叉验证，专治幻觉
• 测：自动测试，交付有证据
• 扩：扩展认知边界，但必须可验证
• 收：上线交付、监控回滚、复盘闭环

这篇咱们讲第六式 验：用多个模型交叉验证，别让一个 AI 的幻觉变成你的 bug。

---

AI 幻觉有多坑？

先说几个我真实踩过的坑：

案例 1：不存在的 API

在做 ai-shifu 集成飞书登录时，GPT-4 告诉我飞书有个 /open-apis/auth/v3/user_access_token 接口。我照着写完了，一跑——404。查了官方文档，v3 根本不存在，实际是 v1。AI 编了一个看起来很合理的 URL。

案例 2：错误的配置参数

让 Claude 帮我写 Nginx 配置，它给了一个 proxy_buffer_size 128m 的建议。看起来很专业对吧？实际上这个值大得离谱，生产环境会直接吃光内存。AI 不是故意坑你，它只是在”合理推测”。

案例 3：过时的写法

让 GPT 写 React 代码，它给了 componentWillMount——这玩意在 React 16.3 就废弃了，React 18 直接删了。

共性：AI 的回答看起来都”头头是道”，你不验证就直接用，等上线了才发现是坑。

---

交叉验证：让 AI 互相 review

核心思路很简单：一个 AI 写，另一个 AI 审。

就像代码 review 不能自己 review 自己，AI 的产出也不能只靠它自己验证。

基本套路

Claude 写方案 → GPT review → 有分歧的点人工裁决
GPT 写代码 → Claude 审代码 → 合并最优方案

实操步骤

第 1 步：让 AI-A 写方案

（在 Claude 里）
请帮我设计 Orion 的消息重试机制：
- 消息发送失败后自动重试
- 支持指数退避
- 最多重试 3 次
- 记录每次重试的日志

请给出：技术方案 + 关键代码 + 配置项

第 2 步：把方案丢给 AI-B review

（在 GPT 里）
以下是一个消息重试机制的技术方案，请帮我 review：

[粘贴 Claude 的方案]

请检查：
1) 有没有遗漏的边界情况？
2) 指数退避的实现是否正确？
3) 有没有更好的做法？
4) 有没有明显的 bug 或过时的写法？

第 3 步：合并意见

通常两个 AI 的意见会有 80% 一致 + 20% 分歧。分歧的部分才是你需要关注的——那往往就是潜在的坑。

---

哪些场景必须交叉验证？

不是所有代码都需要交叉验证。我的经验法则：

必须验（高风险）

场景	原因	怎么验
API 对接	AI 最爱编 API 签名和参数	用另一个 AI 对照官方文档
安全相关	认证、加密、权限 AI 经常瞎编	必须交叉验证 + 人工审
数据库 schema	字段类型、索引、约束容易出错	让另一个 AI review DDL
部署配置	Nginx/Docker/K8s 配置错一个字就炸	必须交叉验证

可以不验（低风险）

场景	原因
简单 CRUD	模式固定，不太会错
UI 布局	跑起来就能看到对不对
工具脚本	跑一次就知道行不行

---

实战模板：4 种交叉验证姿势

姿势 1：方案对比

同一个需求，分别问两个 AI，对比方案差异：

（分别问 Claude 和 GPT）
我要在 fh_java 项目中实现分布式锁，用于防止定时任务重复执行。
请给出技术方案（Redis/ZooKeeper/数据库锁），推荐哪种，为什么。

对比要点：

• 推荐的方案一致吗？
• 不一致的理由各是什么？
• 谁的理由更有说服力？

姿势 2：代码审查

一个写，一个审：

（在 AI-B 里）
请 review 以下代码，重点检查：
1) 有没有安全漏洞（SQL注入/XSS/CSRF）
2) 有没有性能问题（N+1查询/内存泄漏）
3) 有没有使用过时的 API
4) 错误处理是否完善

[粘贴代码]

姿势 3：事实核查

当 AI 告诉你一个”事实”时（比如某个 API 的参数格式），用另一个 AI 核实：

（在 AI-B 里）
请验证以下说法是否正确：
"飞书开放平台的 user_access_token 接口是 POST /open-apis/auth/v3/user_access_token"

请查阅飞书官方文档，给出正确的接口路径和参数格式。

姿势 4：方案压力测试

让一个 AI 专门找另一个 AI 方案的毛病：

（在 AI-B 里）
以下是一个技术方案。请扮演"资深架构师"角色，专门挑毛病：
- 高并发下会不会有问题？
- 数据一致性有保障吗？
- 出了故障怎么恢复？
- 有没有更简单的替代方案？

[粘贴方案]

---

进阶：自动化交叉验证

如果你经常需要交叉验证，可以把流程半自动化。

用脚本批量验证 API 信息

#!/bin/bash
# verify-api.sh：把 AI 声称的 API endpoint 实际调一下

ENDPOINTS=(
  "GET https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal"
  "POST https://open.feishu.cn/open-apis/im/v1/messages"
)

for ep in "${ENDPOINTS[@]}"; do
  METHOD=$(echo $ep | cut -d' ' -f1)
  URL=$(echo $ep | cut -d' ' -f2)
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" -X $METHOD "$URL")
  echo "$STATUS $METHOD $URL"
done

跑一下就知道 AI 说的 API 路径到底存不存在。

用 diff 对比两个 AI 的输出

# 把 Claude 的方案存到 plan-claude.md，GPT 的存到 plan-gpt.md
diff --color plan-claude.md plan-gpt.md

差异部分就是你要重点审的地方。

---

我的验证 checklist

每次 AI 给我关键代码或方案，我会过一遍这个清单：

## 验证 Checklist

### 事实类
- [ ] API 路径是否正确？（对照官方文档）
- [ ] 参数格式是否正确？（字段名、类型、必填/选填）
- [ ] 版本号是否最新？（框架版本、API版本）
- [ ] 依赖包是否存在？（npm/pip/maven 搜一下）

### 逻辑类
- [ ] 边界情况是否处理？（空值、超时、重复、并发）
- [ ] 错误处理是否完善？（不只是 try-catch，要有具体处理）
- [ ] 资源是否正确释放？（数据库连接、文件句柄、锁）

### 安全类
- [ ] 有没有 SQL 注入风险？
- [ ] 有没有硬编码的密钥？
- [ ] 权限检查是否到位？

### 性能类
- [ ] 有没有 N+1 查询？
- [ ] 有没有不必要的全表扫描？
- [ ] 缓存策略是否合理？

---

验的心法：不信任，但利用

“验”不是说 AI 不行，恰恰相反——AI 非常能干，但它有一个致命弱点：它不知道自己不知道什么。

人类犯错会犹豫、会说”我不确定”，AI 犯错时依然信心满满、头头是道。所以你必须建立一套验证机制：

1. 关键决策必须双模型 —— 一个写一个审
2. API/配置必须实测 —— 不要只看 AI 的说辞，跑一下
3. 安全相关必须人工审 —— AI 不是安全专家，你也不一定是，但至少要有意识
4. 记录验证结果 —— 在 tasks.md 里标注”已验证”和”验证方式”

---

总结

“验”的核心就一句话：用 Claude 验 GPT 的结论，用 GPT 验 Claude 的方案，让它们互相打脸，你来裁决。

• AI 的幻觉不可避免，但可以被发现
• 交叉验证是最低成本的质量保障
• 不是所有代码都要验，高风险场景必须验
• 养成习惯：关键产出，多问一个 AI

下一式我们讲 测：验证了方案没问题，还得用测试证明代码真的能跑。