技术方案评估 Prompt：让 AI 像架构师一样评估方案
把候选方案与约束贴进去，AI 按成本、复杂度、可维护性、扩展性与团队熟悉度多维打分，输出对比表与风险清单，并给出在什么条件下该选哪个方案。适合选型评审前先自己过一遍。
发布 2026-06-21更新 2026-10-14用法
把两个或多个备选方案的技术背景粘进来，配合下面的 prompt。
什么时候用 / 别用
| 场景 | 用不用 | 原因 |
|---|---|---|
| 两三个方案并列选型、需要开会拍板 | 用 | 评分表正好提供评审会的共同标尺 |
| 想给已定方案找反面意见 | 用 | 风险矩阵这一节专治「全员一致同意」 |
| 写 ADR（架构决策记录）前的素材准备 | 用 | 输出结构几乎可直接搬进 ADR 模板 |
| 需要精确的性能 / 成本数字做决策 | 别用 | AI 给的是量级判断，不能替代压测与账单测算 |
| 强依赖公司内部现状（既有系统、人员、排期） | 慎用 | 必须把约束写进「方案背景」，否则输出的是通用教科书答案 |
最常被误用的一点：把这条 prompt 当成「让 AI 替我做决定」。它的正确用法是「让 AI 把分歧点摆到桌面上」——决策权始终在你，因为只有你知道团队下个季度的排期和谁会离职。
Prompt
我正在评估以下技术方案，请像资深架构师一样帮我分析。不要给泛泛的建议，按以下结构输出：
## 方案概要
（每个方案 1 句话总结核心思路）
## 五维评分（1-5 分）
| 维度 | 方案 A | 方案 B | 说明 |
|---|---|---|---|
| 开发效率 | ? | ? | 搭起来快不快 |
| 可维护性 | ? | ? | 半年后好不好改 |
| 性能 | ? | ? | 预期吞吐量级 |
| 生态成熟度 | ? | ? | 社区/文档/工具链 |
| 团队匹配度 | ? | ? | 现有团队技能栈是否匹配 |
## 风险矩阵
列出每个方案的 Top 3 风险，按「概率 × 影响」排序：
- 风险描述
- 概率（高/中/低）
- 影响（高/中/低）
- 缓解措施
## 迁移成本
如果现在从方案 A 切到方案 B，需要改什么？列出具体的改动点和工作量估算。
## 你的推荐
基于以上分析，你推荐哪个方案？给出理由（不超过 3 条）。
## 你不确定的地方
列出你在评估中信息不足、需要我补充确认的点。不要猜。
---
方案背景：
（粘贴你的方案详情）
效果
不加 prompt 时 AI 通常说「两个都很好，看你的需求」——正确但没用。
加了这条 prompt 后 AI 被迫给出具体评分、风险和推荐，而且最后的「不确定的地方」经常能帮你发现自己遗漏的考量点。
一个对照例子
问"我们后端该用 REST 还是 GraphQL"：
不用这条 prompt：
"REST 简单成熟，GraphQL 灵活但复杂，看你的团队和需求来选。"
——说了等于没说，每个字都对，但帮不了决策。
用这条 prompt（五维评分 + 风险矩阵），AI 会被逼着量化：
维度 REST GraphQL 说明 开发效率 4 3 GraphQL 要搭 schema/resolver，前期慢 团队匹配度 5 2 团队没人用过 GraphQL 风险矩阵：GraphQL 的 N+1 查询（概率高×影响中）、前端过度查询打垮 DB（概率中×影响高）。 推荐：REST。理由：团队零 GraphQL 经验，且当前接口数 < 20，GraphQL 的灵活性收益不抵学习成本。
后者直接能拿去开评审会——它把"看需求"翻译成了可争论的具体维度。
为什么有效
- 五维评分把「感觉」变成可比较的量：架构争论最难的是没有共同标尺，评分表至少让分歧点显性化。
- 强制列「你不确定的地方」：这一条是防幻觉的闸门，AI 不熟悉的领域会被显式标出而不是编造。
- 要求给迁移成本：不考虑迁移成本的架构建议等于空谈，这一步决定了方案是「下个季度」还是「下个财年」。
验收判据：拿到结果先过这四条
- 「你不确定的地方」不能是空的 —— 这一节为空 = AI 在编。信息不足却给了满篇结论，是最危险的失效模式，必须回头补约束重问。
- 每一格评分都要有「说明」 —— 只有数字没有理由的评分表毫无价值，评分的可争辩性全在那句说明上。
- 风险矩阵要能落到具体动作 —— 「缓解措施」写「加强监控」= 没写。合格的缓解措施应当是可排期的任务（加限流、加超时、先做 POC）。
- 推荐理由不超过 3 条且可证伪 —— 「更现代」「更符合趋势」这类不可证伪的表述应当剔除，换成「团队零经验」「接口数 < 20」这种可核查的事实。
第 1 条是这套 prompt 的命门。 我们见过太多「AI 给的评估看起来很专业，结果每个数字都是它自己编的」——强制暴露不确定性，是唯一能低成本发现这件事的机制。
进阶（自动化）
把评分表固化成 ADR（架构决策记录），让半年后的自己知道当时为什么这么选：
mkdir -p docs/adr
ai-eval --options "REST,GraphQL" --out docs/adr/0007-api-style.md
# 评审通过后再合并，避免 AI 结论直接进主干
三个变体：按你的决策阶段选一个
| 变体 | 追加指令 | 适用 |
|---|---|---|
| A 快速筛选 | 「只做五维评分与一句话推荐，不展开风险矩阵」 | 方案多达 4 个以上，先收敛到 2 个 |
| B 反面审查 | 「假定我已选定方案 A，请只攻击它：列出会让它失败的三个场景与触发条件」 | 决策前找反证，专治团队一边倒 |
| C 迁移视角 | 「把迁移成本作为第一优先级重排结论，并给出可分阶段落地的最小切换路径」 | 存量系统改造，关注可落地性而非最优解 |
接进管道（headless）
# 把方案描述喂进去，直接产出可贴进 ADR 的 Markdown
cat options.md | claude -p "按 /prompts/tech-architecture-eval 的模板评估，
采用变体 C（迁移视角），约束：团队 5 人、无 Go 经验、下季度排期已满"
约束必须写进命令里。不写团队规模与技能栈，AI 会默认按「能力无限的团队」评估——而「团队匹配度」这一维恰恰是最能左右结论的一格。
延伸阅读
- API 设计 Prompt — 选定方案后落地 API
- Context Engineering — 给足约束 AI 才不说废话