Prompt 工程被验证有效的模式并不多：角色与边界、结构化输出、少示例、思维链、自检回路、上下文分区、失败降级、版本化评测。这 8 个模式覆盖了生产环境 90% 的场景，本文逐一给出模板与反例。
为什么大多数 Prompt 失败？
失败 Prompt 有个共同点：把模型当搜索引擎用——一句话需求丢进去，指望它理解你没有说出口的约束。有效 Prompt 的本质是工程约定：输入是什么、输出长什么样、边界在哪、错了怎么办。下面按模式展开。
模式一：角色与边界（Role + Boundary）
你是一名资深代码评审员。职责：只评审给出代码的正确性与安全问题。
边界：不讨论代码风格，不重写整个文件；发现的问题按 [严重度][位置][原因][建议] 四段输出。
如果代码无法评审（信息不足），直接回复"需要补充上下文"并列出缺失项。要点：边界句和职责句同样重要。没有边界，模型会用"热心"填补空白——重写你的代码、解释基础概念，输出不可控。
模式二：结构化输出（Schema First）
用示例把格式"钉死"，而不是用形容词描述格式：
输出必须严格是 JSON 数组，不要任何额外文字：
[{"issue": "问题描述", "severity": "high|medium|low", "line": 12}]
示例：
[{"issue": "未校验空指针", "severity": "high", "line": 42}]反例："请结构化地输出你的分析结果"——"结构化"是人类的想象，模型需要的是具体 schema。
模式三：少示例（Few-shot）
2–5 个精选示例的效果稳定优于零示例，也优于 20 个冗余示例。选示例的标准：覆盖边界情况，尤其要包含一个"应拒绝/判空"的示例，否则模型对模糊输入会强行编造答案。
模式四：思维链（按任务类型启用）
推理类任务（数学、多条件判断、根因分析）在要求"先列出推理步骤，再给最终答案"后有可测量提升；简单分类与抽取任务不要加，纯属浪费 token 与延迟。经验法则：答案需要组合两个以上事实的任务，才值得思维链。
模式五：自检回路（Self-check）
完成草稿后，先按以下清单自检并修正，再输出最终答案：
1. 输出格式是否符合 schema
2. 每个事实性断言是否有材料支撑
3. 是否存在未处理的空值/异常分支实测能拦截大部分格式错误与编造断言，代价是一轮额外推理。对质量敏感、对延迟不敏感的管线值得开启。
模式六：上下文分区
长上下文 prompt 按固定顺序组织：角色与规则 → 材料（带编号） → 任务指令 → 输出格式。检索增强场景下，把最强证据放在材料的开头与结尾（模型对中间内容注意力弱），这一条在 RAG 系统搭建实践 里有详细展开。
模式七：失败降级
预定义三档输出：正常答案 / "资料未覆盖" / "需要人工"。让模型有台阶下，是压住幻觉最便宜的手段——大量幻觉来自模型不敢说"不知道"。
模式八：版本化与评测
Prompt 进 Git、变更写说明、每次修改跑同一套评测集（哪怕只有 30 条）。没有回归评测的 Prompt 迭代等于裸奔。把这些模式组合进工程管线的方法，可参考逆向分析里的提示词驱动辅助分析思路——方法论是通用的。