架构错误的代价是几周重构，不是几天。最便宜的发现方式是在写代码前跟一个聪明人吵一架——但多数团队周二早上找不到那个人。这篇讲怎么用推理级 AI 当一个结构化的 devil’s advocate，每份设计文档抓出 3-5 个真问题。
这篇主要解决什么问题
含糊的”这设计好不好”prompt 拿到的是含糊的”挺好，但有些考虑”。这套流程用强制 steelman → 攻击的序列，产出具体可操作的批评——就像资深同事真有空时给你的那种。产出：一份带缓解措施和已驳回替代方案的、被打磨过的设计文档。
这篇适合谁看
Tech lead、资深工程师、即将开始多周实现的独立开发者。对没资深兜底的独立开发和还没建立设计 review 反射的新晋 tech lead 尤其有用。
什么时候适合用
任何涉及以下情况的功能开工前：新数据模型、新服务、复杂状态管理、分布式协调、支付 / auth 流、回滚痛苦的改动。经验法则：撤销要超过 2 天，就跑 review。
什么时候不建议用
琐碎功能。团队已有成熟做法的常见模式（没必要让 AI 重新考虑你的标准 CRUD 端点）。注定要扔的探索性 spike。
开始前准备
- 一页设计文档。粗糙也行——bullet 就够——但必须包括：目标、约束、提议方案、考虑过的替代。
- 选推理重型模型：Claude Opus / Sonnet 带 extended thinking，或者 GPT-5.5 reasoning 模式。速度优先模型批评肤浅。
- 想清这次设计的”好”长什么样。“p95 延迟 200ms 以下”是好；“可扩展”不是。AI 按你说的标准批评，标准模糊批评就模糊。
具体步骤
- 一页设计文档分这几节：目标（一句）、约束（3-5 条硬限制）、方案（你的提议）、考虑过的替代（你驳回的 2-3 个）。
- 粘到 Claude / ChatGPT（推理模型）。问：“Steelman 这个设计。给出它对的 3 个最强理由。”
- 然后问：“做 devil’s advocate。找 5 个最大弱点，要具体——失败模式叫什么、什么时候触发、触发的代价。”
- 每条弱点问：“不动整体架构的最小缓解措施是什么？“这能把可修的关切和架构级阻塞分开。
- 问：“我应该考虑过哪些替代架构？列 2 个，跟我的方案做显式权衡。“列出你真没想到的，这流程就赚了。
- 高风险设计追加：“走 3 个现实失败场景。什么状态可能不一致？重试逻辑在哪里变脆？”
- 把缓解措施、显式驳回的替代（带原因）、“已考虑的失败”一节更新进文档。这份才是给真人看的。
第一次实操怎么跑
- 挑一份已经上线的设计文档——结果已知。跑一遍 review。
- 对比 AI 预测的弱点和实际生产里出的问题。它抓到真问题了吗，还是只盯理论问题？
- 记下哪种 prompt 措辞产出有用批评、哪种产出含糊批评。下次真设计上用这个校准。
- 不要在”明显没问题”的设计上跑。价值在真的不确定的设计上。
完成后检查
- AI 找的问题是你真没想过的，还是把你文档里已经写过的复述？后者也行，但价值低。
- 弱点能被验证吗？“可能会慢”是感觉；“用户超过 50 条时这设计会发 N+1 查询”是可测的。
- 它提的替代方案有真权衡，还是只给明显更差的让你显得对？严格更差的是噪音。
- 缓解措施真的是最小的，还是 AI 偷偷重设计了？推回创蔓延式的重设计。
怎么复用这套流程
- prompt 序列（steelman → devil’s advocate → 缓解 → 替代 → 失败）存成可复用的 Claude Project / Custom GPT。
- 设计 + 批评对存进一个文档目录。10 次 review 后你会看到 AI 擅长抓什么（竞态、缺失失败模式）和不擅长什么（组织 / 政治约束）。
- 上线 3 个月后把实际结果追加进去重跑。AI 在你领域的”预测 vs 实际”准确度会提升你的信任校准。
建议的操作流程
新的分析管道：1 页设计 → AI steelman（“批处理省 4 倍成本、比流式简单、团队熟悉”） → AI devil’s advocate（4 个真问题：晚到事件、回填、热分区、schema 迁移） → 3 条给最小缓解、1 条做重设计 → 1 个替代重新考虑（流式确实值得看） → 真人 review 接到的是被磨过的提议。
容易踩的坑
- 问 “这设计好不好” 拿到 yes-and-fluff。用 steelman 然后攻击的序列。
- 让 AI 重新设计而不是批评。压住它”只评论、不重写”直到批评全听完。
- 跳过 steelman——拿到一边倒的攻击，错过设计的真实强项。
- 把 AI 批评当权威。它揭示问题，是否重要你来定（你有 AI 没有的上下文）。
- 在你已经写完代码后才跑——沉没成本会让你驳回每条批评。一定要在写之前。
- 给真人看 AI 批评本身。给他们的应该是已经吸收了缓解措施的”被打磨过”的设计——这才是重点。
进阶技巧
- 数据模型设计：“对这个 schema 走 5 个现实查询，哪些要在设计外做 join 或反范式？”
- 分布式系统：“这设计能在哪里部分失败？分区或重启时什么状态可能不一致？”
- API 设计：“给 3 个看起来对的调用，但违反实现假设。”
- 设计 + 批评 + 缓解整套存成 Markdown。一年后回到这个系统，这份是金子。
FAQ
- 用哪个模型？: 推理重型：Claude extended thinking、GPT-5.5 reasoning。速度模型（Haiku、GPT-5.4）批评较弱。
- 取代真人 design review 吗？: 不——做预过滤。资深同事的时间花在已经过 AI 批评的文档上更值。
- AI 批评错了怎么办？: 经常会错；没关系。错的批评也能让你浮现需要文档化的假设。只是别为不存在的问题加缓解。
- 要多久？: 每份设计 20-40 分钟。跟几周重构比，是工具箱里 ROI 最高的。
- 省略 steelman 行吗？: 别。没有它，批评会一边倒，你会过度修正。