1.1 技术方案评审提示词的定义、目标与适用边界
我理解的“技术方案评审提示词”，就是给大模型或评审助手写的一段结构化指令，让它按照架构师和评审专家的视角，对一份技术方案做系统化检查。它不是简单的“帮我看看这个方案行不行”，而是把评审目标、输入材料、检查维度、输出格式都讲清楚。我见过不少团队直接丢一句“评审一下”，结果模型返回一堆泛泛而谈的话，落地价值很低。提示词的本质是约束评审行为，让机器输出可验证、可追溯的评审意见。
目标这块，我一般会拆成三层。第一层是发现硬伤，比如架构缺失、接口对不上、安全措施没写。第二层是给出修改建议，让方案作者知道往哪改。第三层是形成评审记录，方便会后跟踪。适用边界也要说清楚：提示词适合做初筛和辅助检查，不适合替代人工决策。涉及商业机密、合规红线、团队政治这些内容，模型给不了最终结论。我经常提醒团队，把提示词当成一个不知疲倦的初级评审员，而不是最终拍板的人。
有个朋友问我，能不能用提示词完全自动化评审。我的回答是：可以自动化一部分，但边界要画明白。方案背景模糊、目标冲突、技术选型有争议，这些需要人来判断。提示词能帮你把检查项过一遍，把明显漏掉的内容标出来。它的价值在于减少遗漏、统一评审尺度，而不是替代评审会议。适用边界清晰了，后面设计提示词才不会跑偏。
1.2 评审角色设定与上下文注入：架构师与评审专家视角
角色设定我习惯分两层写。一层是“架构师视角”，关注整体结构、模块边界、技术选型是否合理、演进路径是否清晰。另一层是“评审专家视角”，关注细节证据、风险点、可验证性。我会在提示词里明确写：“你是一位有十年经验的后端架构师，同时具备安全评审和数据评审经验。”这样模型输出的语气和关注点会更贴近实际评审场景。角色越具体，输出越少泛化。
上下文注入是很多人忽略的一步。我只给方案文档不够，还要注入项目阶段、团队规模、历史遗留问题、合规要求。比如“这是二期改造项目，存量系统不能停机”“团队只有三个后端”“必须通过等保三级”。这些上下文会直接影响评审结论。我通常会在提示词里加一段“背景约束”，把非文档信息也写进去。模型看到这些，才会给出有场景感的建议，而不是教科书式回答。
我踩过一个坑：角色写得太宽泛，比如“你是技术专家”，模型就喜欢说“建议加强安全性”这种空话。后来我把角色拆成“架构评审专家+安全评审专家+运维评审专家”，要求每个维度用对应视角发言。上下文注入也要控制篇幅，别把提示词写成项目百科。我的经验是：角色两到三个，上下文三到五条关键约束，足够了。
1.3 输入信息结构化：方案背景、目标、架构、数据、接口、部署与风险
输入信息我习惯拆成七个块：背景、目标、架构、数据、接口、部署、风险。每个块用固定小标题，让模型知道去哪找信息。背景写业务痛点和项目由来，目标写可衡量的预期结果，架构写模块划分和技术栈，数据写存储方案和数据流，接口写内外依赖和协议，部署写环境要求和发布策略，风险写已知坑和应对措施。这种结构化输入能显著提升评审命中率。
我经常看到方案文档写得很长，但关键信息散落在各处。提示词里我会要求作者先按这七个块整理摘要，再附上原文链接。模型处理结构化摘要比处理大段散文更稳定。接口这块特别容易漏，我会单独要求写清楚“调用方、被调用方、协议、鉴权、超时重试”。部署块要写“环境差异、配置管理、回滚方案”。风险块不能只写“风险可控”，要写具体场景和缓解措施。
有个小技巧：输入信息里加一列“待确认项”。作者自己没想清楚的地方，标出来让评审重点看。模型看到待确认项，会优先围绕这些点提问。我试过把待确认项单独放在输入末尾，输出里的“待确认问题”明显更聚焦。输入结构化不是追求格式漂亮，而是让模型少猜、多引用。信息缺失的地方，模型要能指出来，而不是编一个答案。
1.4 评审维度与检查项：完整性、一致性、可扩展性、安全性、性能、可运维性与成本
评审维度我一般列七项：完整性、一致性、可扩展性、安全性、性能、可运维性、成本。每个维度下面挂具体检查项。完整性看背景目标架构数据接口部署风险是否齐全。一致性看架构图和接口定义是否对得上、数据流和部署图是否冲突。可扩展性看模块解耦、容量规划、水平扩展路径。安全性看认证授权、数据加密、审计日志、攻击面。性能看关键链路指标、压测方案、缓存策略。可运维性看监控告警、日志追踪、发布回滚。成本看资源估算、云服务选型、人力投入。
检查项不能太抽象。我会把“安全性”拆成“接口鉴权方式是否明确”“敏感数据是否脱敏”“是否有越权访问防护”。“性能”拆成“核心接口P99目标是否给出”“是否有压测计划”“数据库索引和慢查询预案”。每个检查项要求模型给出“通过/不通过/信息不足”三态结论。三态比打分更实用，因为很多方案确实信息不足，硬打分反而误导。
维度之间会有重叠，我会在提示词里说明优先级。新建系统侧重完整性和可扩展性，改造升级侧重一致性和可运维性，涉及用户数据的方案安全性权重调高。成本维度容易被忽略，我通常要求单独写一段“成本估算依据”。评审不是找茬，是帮作者把没想到的维度补上。检查项清单我建议控制在二十到三十条，太多模型会漏，太少覆盖不全。
1.5 输出格式设计：问题分级、证据引用、修改建议、结论与待确认项
输出格式我设计成五块：问题分级、证据引用、修改建议、结论、待确认项。问题分级用“阻断/严重/一般/建议”四档。阻断指不修改不能上线，严重指高风险，一般指改进项，建议指优化点。证据引用要求模型指出方案原文的章节或段落，不能凭空说“文档没写”。修改建议要具体到“补一张时序图”“在接口定义里增加幂等字段”。结论用“通过/有条件通过/不通过”。待确认项列出需要作者补充的信息。
我特别看重证据引用。没有证据的评审意见很难服众。提示词里我会写：“每条问题必须引用输入材料中的原文位置，找不到原文的标为‘信息不足’。”这样模型不容易编造。修改建议也要分优先级，阻断项必须给具体改法，建议项可以给方向。结论不能模棱两可，要有明确判断。待确认项单独列出来，方便会后跟踪。
输出格式稳定了，评审结果才能横向对比。我见过有的提示词让模型自由发挥，结果每次输出结构都不一样，人工复核很痛苦。固定格式不是限制模型，是降低阅读成本。我还会要求输出用表格汇总问题，表格后面再展开说明。表格列包括：问题编号、级别、维度、原文位置、问题描述、修改建议。这样会后分配任务很方便。
1.6 提示词设计原则：明确性、可验证性、少歧义、可复用与可迭代
明确性我放在第一位。提示词里少用“尽量”“适当”“合理”这种词。改成“必须列出至少三个风险点”“接口定义必须包含鉴权方式”“性能目标必须给出数值”。明确性还体现在任务边界上：评审什么、不评审什么、输出多少字、用什么格式。我写提示词时会通读一遍，把模糊形容词圈出来替换掉。模型不怕要求严，怕要求虚。
可验证性是指每条评审意见都能被人工复核。证据引用、检查项三态结论、修改建议的具体程度，都是可验证性的体现。少歧义要求同一段提示词不同人读出来理解一致。我会让团队成员交叉读提示词，看有没有歧义。可复用是指模板能套用到不同项目，变量部分抽出来配置。可迭代是指评审结果能反哺提示词，比如某类问题经常漏报，就在检查项里加一条。
这五个原则有冲突的时候，我会优先保明确性和可验证性。可复用和可迭代可以慢慢打磨。我自己的习惯是每季度回顾一次提示词版本，看哪些检查项命中率低、哪些输出格式没人用。提示词不是写一次就完事，它跟代码一样需要维护。把评审记录和人工复核结果存下来，下一版提示词就有依据。设计原则说到底就一句话：让模型输出人敢用、能用、好用的评审意见。
2.1 通用技术方案评审提示词模板结构：角色、任务、输入、约束与输出
我手上有一套用了快两年的通用模板，结构就五块：角色、任务、输入、约束、输出。看起来简单，但这五块每块都要写实。角色部分我不写“你是技术专家”这种虚话，直接写“你是负责过千万级日活系统的后端架构师，有安全评审和数据库评审经验”。任务部分拆成三条：找出阻断性问题、给出可落地的修改建议、输出结构化评审报告。输入部分要求按背景、目标、架构、数据、接口、部署、风险七块整理摘要。约束部分写死“每条问题必须引用原文位置”“找不到原文标为信息不足”。输出部分固定五段式，问题分级用阻断、严重、一般、建议四档。
这套模板我分享给过好几个团队，反馈最多的问题是“约束写太多模型会不会不听话”。我的经验正好相反，约束越具体，输出越稳。比如“修改建议要具体到补哪张图、加哪个字段”比“给出合理建议”好用得多。我还会在约束里加一条“禁止编造方案中不存在的内容”，这条对减少幻觉很管用。
模板不是越全越好。我见过有人写了三页提示词，模型反而抓不住重点。我的做法是把模板控制在八百字以内，角色两到三行，任务三到四条，约束五到六条。剩下的靠变量注入和场景化扩展。
2.2 AI技术方案评审提示词：大模型评审的上下文组织与推理引导
大模型做评审，上下文组织比提示词措辞更重要。我试过同一个提示词，输入材料从散乱段落换成结构化摘要，评审命中率差了一倍多。我的做法是要求方案作者先填一个固定模板，把七块信息浓缩到一页纸，再附原文链接。模型拿到这页纸，推理路径会清晰很多。上下文里我还会塞三到五条项目约束，比如“存量系统不能停机”“团队只有三个后端”“必须过等保三级”。这些信息不写进去，模型给的建议就是教科书式的。
推理引导这块，我常用一个技巧叫“分步评审指令”。第一步让模型检查信息完整性，列出缺失项。第二步按维度逐项评审，每个维度输出通过、不通过或信息不足。第三步汇总问题并分级。第四步给出修改建议。这种分步指令比“一次性评审所有维度”的输出质量高不少。模型在每一步的注意力更集中，漏项明显减少。
有个坑我踩过：上下文太长，模型会丢掉前面的指令。我的解决办法是把关键指令放在输入材料后面重复一遍。比如输入末尾写“请按上述五段式输出，每条问题必须引用原文位置”。重复一遍之后，输出格式的稳定性提升很明显。上下文组织不是堆信息，是帮模型建立评审的思考路径。
2.3 场景化模板扩展：新建系统、改造升级、云原生与微服务、数据与AI方案
通用模板能覆盖七成场景，剩下三成要靠场景化扩展。新建系统我加两条约束：可扩展性权重调高、要求给出容量规划路径。改造升级我加“存量兼容性检查项”和“回滚方案完整性检查”。云原生和微服务方案我加“服务边界划分是否合理”“服务治理策略是否明确”“配置中心与注册中心选型依据”。数据与AI方案我加“数据质量评估”“模型上线后的监控与回退机制”“训练数据合规性”。
场景化扩展不是另起一套模板，是在通用模板上挂检查项。我的做法是维护一个检查项库，按场景打标签。新建系统标签下挂十二条检查项，改造升级挂十五条，云原生挂十八条，数据AI挂二十条。评审时根据项目类型自动带入对应标签的检查项。这样模板复用率高了，维护成本也降下来了。
我见过有团队给每个场景写一套完整提示词，结果维护了七八套，改一处要同步改七八个地方。后来他们改成“通用骨架加场景插件”的模式，维护量少了一大半。场景化扩展的关键是插件化，不是复制粘贴。检查项库要定期更新，新踩的坑变成新检查项，过时的检查项降权或删除。
2.4 模板变量与可配置项：项目类型、评审阶段、关注优先级与合规要求
模板变量我抽了四类：项目类型、评审阶段、关注优先级、合规要求。项目类型决定带入哪些检查项。评审阶段分需求评审、架构评审、详细设计评审、上线前评审，每个阶段关注点不同。需求评审侧重目标清晰度和边界定义，架构评审侧重模块划分和技术选型，详细设计评审侧重接口和数据结构，上线前评审侧重部署方案和回滚预案。关注优先级用高、中、低三档，高优先级维度的检查项要求模型必须给出明确结论，不能只写信息不足。合规要求单独作为变量注入，比如等保级别、数据出境要求、行业监管条款。
变量设计有一个原则：变量值要能被程序解析。我不用“比较高”“适当关注”这种模糊值，全部用枚举值。项目类型枚举：新建、改造、云原生、数据AI。评审阶段枚举：需求、架构、详设、上线前。关注优先级枚举：高、中、低。合规要求用标签列表，比如“等保三级”“GDPR”“金融监管”。枚举值的好处是模板可以自动化组装，不需要人工每次调。
可配置项还包括输出语言、输出长度、是否启用严格模式。严格模式下模型对信息不足的检查项必须标红提示，宽松模式下可以给推测性建议。我一般默认严格模式，上线前评审才开宽松模式。变量和可配置项让一套模板适配多种场景，这是提示词工程化的基础。
2.5 评审结果质量评估与提示词迭代：命中率、误报漏报、人工复核与版本管理
评审结果质量我用三个指标衡量：命中率、误报率、漏报率。命中率是模型提出的问题里人工复核确认为真的比例。误报率是模型提出的问题里人工判断为不成立的比例。漏报率是人工评审发现的问题里模型没提出来的比例。我每个月抽二十份评审报告做人工复核，统计这三个指标。命中率低于六成就要调提示词，漏报率高于三成就要加检查项。
人工复核我设计了一个简单表格：问题编号、模型结论、人工复核结论、偏差原因。偏差原因分四类：模型误判、信息缺失、检查项遗漏、原文表述歧义。统计偏差原因分布，就知道该往哪个方向迭代。信息缺失多就加强输入结构化要求，检查项遗漏多就补检查项库，模型误判多就收紧约束条件。
版本管理我借鉴了代码管理的思路。每个提示词版本记录变更内容、变更原因、生效日期、关联的评审报告批次。回滚机制也要有，新版本上线后先跑十份历史方案对比效果，效果不达预期就回滚。提示词迭代不是拍脑袋改，是按数据改。我见过有的团队频繁改提示词，改完不记录，出了问题找不到原因。版本管理这件事，开始做比做得多精细更重要。
2.6 常见风险与避坑：信息缺失、模型幻觉、过度泛化、安全合规与数据脱敏
信息缺失是最常见的风险。方案文档写得含糊，模型要么标信息不足，要么自己脑补。我的应对办法是在提示词里写死一条规则：“背景、目标、架构、数据、接口、部署、风险七块中任何一块缺失超过两项关键信息，直接输出‘输入信息不足，建议补充后再评审’。”这条规则拦住了大量无效评审。
模型幻觉在技术评审里挺隐蔽。模型会编造“方案中未提及的接口定义”或者“假设存在某个中间件”。我的做法是要求每条问题必须附带原文引用，引用格式是“章节号加原文摘录”。找不到原文引用的意见自动降级为待确认项。这个约束不能百分百消除幻觉，但能把幻觉的杀伤力控制住。
过度泛化是另一个坑。模型喜欢说“建议加强安全性”“建议完善监控”，这种话没有落地价值。我在约束里加了“修改建议必须包含具体动作和预期产出”，比如“在接口定义文档中增加鉴权方式字段，预期产出是接口鉴权矩阵表”。安全合规和脱敏这块，提示词里要明确禁止模型输出敏感数据原文，涉及用户数据的评审要求先脱敏再输入。我一般建议团队在输入材料阶段就做脱敏处理，不要指望模型帮你脱敏。
2.7 落地流程与协作机制：会前自检、会中辅助、会后跟踪与知识沉淀
落地流程我拆成会前、会中、会后三段。会前自检是方案作者先用提示词跑一遍评审，把阻断级和严重级问题改掉再上会。这一步能过滤掉六成以上的低级问题，评审会时间缩短一半。会中辅助是评审主持人用提示词实时检查参会人提出的问题有没有覆盖关键维度，防止漏评。会后跟踪是把评审报告里的待确认项和修改建议录入任务系统，指定负责人和截止时间。
协作机制里最重要的是角色分工。方案作者负责会前自检和修改，评审主持人负责会中引导和结论汇总，记录员负责把模型输出和人工意见合并成最终评审记录。我见过有的团队让一个人干所有事，结果模型输出没人复核，评审记录没人跟踪，流程跑两周就停了。分工明确才能持续跑下去。
知识沉淀这块我特别看重。每次评审结束后，把新发现的问题类型补充到检查项库，把误报案例记录到偏差原因库，把优质修改建议整理成案例集。这些沉淀物是下一版提示词的输入。我自己的习惯是每月做一次复盘，看这个月新增了哪些检查项、哪些检查项被标记为低效。评审流程跑顺了，提示词会越用越准，团队对AI评审的信任度也会慢慢建立起来。
