多模型角色评审法
解决什么问题
不懂代码的人很难独立判断 AI 写的代码到底有没有 bug、逻辑对不对。单靠一个模型自审有局限（它可能对自己的盲点视而不见）。这是作者摸索出来的应对方式：把不同模型当"有不同性格的同事"来用，让它们互相审查、互相打架，弥补自己看不懂代码的短板。
核心内容
核心心智模型：把每个 AI 模型想象成一个有鲜明性格的真人同事，据此分配任务和判断该信谁：
- Claude —— "最理想的 CTO"：沟通能力强、有主见但很协作，不会一味顺着你说，会挑战你的想法。这也是作者最喜欢用 Claude 做探索/规划/长期协作的原因。
- Codex（GPT 系） —— "戴着帽衫趿着拖鞋、坐在暗房里的公司最强程序员"：不爱沟通，你只有遇到最难的 bug 才会去麻烦他，他会关起门来解决问题，"两小时后出来说：搞定了"，但过程完全不透明。
- Gemini（尤其在 Antigravity 里） —— "才华横溢但吓人的疯狂科学家"：设计审美极强，但你如果盯着它的思考过程看,会看到诸如"先删掉整个 dashboard→啊不对，改主意了，加回来→我能不能顺便改一下数据库？"这种反复横跳的操作,"你会想当场把这个人开除",但最后做出来的设计效果非常好。
由此派生的两条实践：
- 按性格分任务：需要快速、审美好的前端/UI 任务交给 Gemini；复杂棘手的 bug 交给 Codex 单独攻关；日常协作、探索、规划这种需要"对话"的环节留给 Claude。
- 交叉评审当"多方开会打架"：让写代码的模型自己
/review，再让另外 1-2 个独立的模型/工具（如 Codex、另一个 Cursor 会话）各自单独评审同一份代码，然后把这些"意见"喂回给最初写代码的模型，要求它逐条反驳或修复，而不是照单全收——"就像公司里其他团队负责人看了你的代码提出意见，你得自己判断这些意见站不站得住脚"。作者观察到，Claude 有时会因为同一个问题被反复提出而变得"有点不耐烦"，直接回复"这是设计如此,不是 bug"。
适用边界
- 这些"性格画像"是作者基于自己使用习惯的主观印象（"这可能只是我的个人经验"），不是严谨的模型能力评测,模型迭代后可能变化很快。
- 交叉评审的价值取决于"至少有一个人能判断谁说得对"——如果用户完全不懂技术、无法判断哪个模型的意见更靠谱，这套机制的边际收益会打折扣。
关键引述 · 原话
"Let's say Claude, she would be the perfect CTO... but then there's also Codex... it's like really not communicative, but it solves all the worst problems... let's say Gemini is like a crazy scientist." — Zevi Arnovitz
"I'll do peer review a bunch of times and I'll have other models review other models code and kind of have them fight it out basically." — Zevi Arnovitz
关联卡片
- 与 `non-technical-pm-ai-build-pipeline--zevi-arnovitz.md` 的第 5 步（review + peer review）是同一实践的心智模型基础 - 与 `escape-hatch-design-principle--guillermo-rauch.md`（跨模型会诊）、`4x4-debugging--lazar-jovanovic.md`（第 3 招外部顾问）同属"卡住/存疑时找另一个模型验证"的家族思路
被这些卡引用
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2