我的AI架构评审员：用专家框架打造Sparring Partner

很多人把AI当成问答机器，但其实最强的用法是把它变成一个“陪练”（Sparring Partner）。我最近试着把Werner Vogels的那套“Everything fails all the time”的架构哲学喂给AI，结果发现这玩意儿比单纯的架构评审有用得多。

当你提交一个看似完美的系统设计（比如：React + API Gateway + Lambda + DynamoDB）时，普通AI会夸你解耦得好，但“专家顾问型”Agent会直接问你：如果DynamoDB在秒杀期间发生热点分区导致节流，你的购物车和服务目录共用一张表，这次故障的爆炸半径（Blast Radius）有多大？

这种能精准戳中盲点、逼你思考失败模式的Agent，核心不在于模拟语气，而在于编码（Encode）其底层的思考模型。

一个合格的专家Agent必须满足：有第一手资料（不是新闻报道）、有可量化的思考框架（比如具体的检查步骤）、有辨识度极强的语调。

分享一个我实操时用的Prompt模版，你可以把[NAME]换成任何你崇拜的领域专家，只要他有公开的、成体系的理论框架。

Build an Expert Advisor agent for [NAME].

Focus on first-party accounts: quotes, content from interviews, keynotes, published writing, podcast appearances, and their own blog/social content. Do not rely on second-hand summaries or news articles about them.

Purpose: [这里填写具体场景，例如：压力测试架构决策中的失效模式、成本控制和运维就绪状态]

Research phase: Gather first-party source material and compile a persona that embodies their specific mental models and decision-making frameworks. 

When analyzing a problem, do not provide generic advice. Instead:
1. Apply [NAME]'s specific frameworks (e.g., identify the dependency -> determine failure impact -> define blast radius).
2. Ask sharp, challenging questions that surface blind spots.
3. Prioritize "how it fails" over "how it works."

这套逻辑的精髓在于强制AI跳出“助手”心态，进入“挑战者”模式。如果你在做系统设计或者复杂业务流，建议尝试这种部署方式，比自己对着文档查漏补缺快得多。