技术方案评审是软件研发流程中质量保障的关键一环，但现实中经常遇到这样的困境：评审会议时间紧张，与会者来不及细读文档；评审意见偏重细节，缺乏系统性；跨团队专家资源稀缺，方案里埋的架构隐患没人发现。把大模型引入评审环节，可以让它扮演一个不知疲倦、覆盖面广的初审专家，在人工评审之前先过一遍筛子。不过要让模型输出真正有价值的评审意见，关键不在模型本身，而在你写给它的那份提示词。
为什么随手一句提示词得不到好的评审结果
很多人第一次尝试用大模型评审方案时，会直接把方案贴进去，加上一句“帮我评审一下这个技术方案，给出意见”。这种做法得到的结果通常是三类：一类是纯夸奖，说方案结构清晰、考虑周全；一类是泛泛而谈，建议“注意性能问题”“加强异常处理”；还有一类是复述方案内容，缺乏独立判断。
出现这些问题的根本原因是提示词缺少约束。大模型在没有明确指令的情况下，会倾向于生成“安全”且“通用”的回复，因为它无法判断你期望的评审深度、关注维度和严格程度。评审本质上是一项专业判断活动，一个优秀的人类评审专家脑子里有一套隐含的检查清单：需求是否闭环、架构是否有单点、技术选型是否有踩坑前科、失败场景是否被考虑。这套检查清单必须通过提示词显式地传递给模型，否则它只能靠训练数据里的通用经验来拼凑答案。
另一个常见误区是提示词里没有要求模型先理解再评价。人类专家评审时会先通读方案建立整体认知，再逐项深挖。如果提示词直接要求“列出十条问题”，模型会为了凑数硬找问题，导致意见质量参差不齐。好的评审提示词应该分阶段引导模型：先总结方案核心内容，再分维度评估，最后汇总输出。
一份高质量评审提示词的四个核心要素
第一是角色设定。角色不是装饰，它会显著影响模型的回答风格和专业深度。设定角色时要具体，比如“你是一名有十五年分布式系统架构经验的技术专家，擅长高并发、高可用系统设计，评审风格严格且注重细节”，比单纯的“你是技术专家”效果好得多。角色越具体，模型调用的知识域越聚焦。
第二是评审维度划分。把一次评审拆解成若干独立维度，每个维度单独评估，是保证意见覆盖面的关键。常见的维度包括：需求理解与完整性、架构设计与合理性、技术选型依据、性能与容量评估、安全与权限设计、异常与降级方案、可扩展性与可维护性、实施计划与风险。在提示词中明确列出这些维度，并给每个维度附上一两句判断标准，模型就能有章可循。
第三是输出格式约束。没有格式约束的评审意见往往难以落地使用。建议要求模型按照固定结构输出：每个维度给出评分或等级、具体问题描述、问题在方案中的位置引用、修改建议以及优先级。格式化输出还有一个好处，就是便于后续把评审结果录入到流程系统里做跟踪管理。
第四是严格程度与评分标准。同样是评审， tolerate 度不同结果差异很大。提示词中应明确告诉模型：问题必须基于方案原文，不允许臆测；如果方案中某信息缺失，要指出“信息缺失”而不是假设其存在；意见按阻塞、建议、提示三级分类。这些约束能有效抑制模型的幻觉倾向。
可直接复用的完整提示词模板
下面这份模板把上述四个要素整合在一起，经过实际使用验证，可以直接复制到任何大模型对话界面使用，只需把占位符替换为你的方案内容即可。
你是一名资深技术架构师，拥有15年分布式系统设计经验，
擅长高并发、高可用、数据一致性领域，评审风格严格、
注重细节，只基于方案原文给出意见，不做臆测。
请评审以下技术方案，按两个阶段完成：
【第一阶段：方案理解】
用不超过200字总结该方案的目标、核心设计和关键约束，
如果我总结的内容与方案原文有偏差，说明方案表述存在问题。
【第二阶段：分维度评审】
对以下每个维度逐一评估，输出格式为：
维度名称 | 等级(通过/建议修改/阻塞) | 问题描述(引用原文位置) | 修改建议
1. 需求完整性：目标是否明确，边界是否清晰，是否有遗漏场景
2. 架构合理性：是否存在单点故障，模块职责是否清晰，依赖是否合理
3. 技术选型：选型是否有依据，是否有更稳妥的替代方案
4. 性能与容量：是否给出容量估算，瓶颈点是否被识别
5. 安全设计：权限、数据、接口安全是否被考虑
6. 异常与降级：失败场景是否有预案，是否有回滚方案
7. 可维护性：复杂度是否可控，是否有过度设计
8. 实施风险：计划是否可行，是否有隐性依赖
【最终输出】
汇总所有阻塞级问题，给出整体结论：通过 / 修改后通过 / 不通过。
以下是待评审的技术方案：
{在此粘贴方案全文}
使用这份模板时有几个实用技巧。首先，如果方案很长，建议分两次提交：先让模型基于全文完成第一阶段的理解总结，确认理解无误后再触发第二阶段的维度评审，这样能减少长上下文带来的注意力稀释。其次，对于特定领域的方案，可以在维度列表里追加定制项，比如涉及资金的项目增加“对账与幂等设计”，涉及第三方的增加“外部依赖容错”。最后，评审完成后可以追加一句“请针对所有阻塞级问题，各给出一个具体的修改示例”，让模型从指出问题升级到协助解决问题。
还有一点值得强调，模型评审不能完全替代人工评审。大模型擅长的是覆盖面检查和常识性风险识别，而对于业务上下文、团队历史包袱、组织协作等隐性因素，它缺乏判断依据。比较务实的做法是把模型评审定位为初审环节：先用提示词模板跑一遍，把机器能发现的问题清掉，再组织人工评审聚焦在架构争议点和业务决策上，这样人工评审的效率和深度都会明显提升。
持续优化你的评审提示词
提示词不是写完就一劳永逸的，它需要随着使用反馈迭代。建议建立一个简单的反馈机制：每次人工评审结束后，对照模型之前给出的意见，把人工发现但模型遗漏的问题类型记录下来，然后回到提示词里检查是哪个维度的判断标准写得不够明确，针对性地补充描述。经过几轮迭代，提示词会越来越贴合你的团队和业务特点。
另一个优化方向是引入评分基线。在提示词中给出历史方案的评分参考，例如“通常合理的方案在性能维度至少包含容量估算和压测计划两项”，能让模型的判断标准更加稳定，减少不同次评审之间的波动。如果你的团队方案模板是固定的，还可以把模板本身的结构说明写进提示词，让模型知道每个章节预期包含什么内容，缺失时直接指出，这比通用的评审提示效果好得多。