🧱 结构化 Prompt 设计原则
从散文到模板：Role/Context/Task/Constraints/Examples 骨架 + 迭代优化闭环。
Prompt 怎么构建：分层叠加 v0→v4
🧱 靠谱 prompt 是叠出来的
不是一次写成，而是分层叠加。从最小可用版开始，一层层加，每一层解决上一层暴露的问题。
🎯 v0 核心三要素
• 任务：要模型做什么（总结/改写/写代码/推理）
• 输入：给什么材料
• 输出：要什么格式
例：「把下面这段会议记录总结成 3 条待办。」
结构化骨架（记住这个模板）
🧱 结构化 = 固定区块的模板
把 prompt 从一段散文改成有固定区块的模板。
好处：可维护、可复用、对不同模型鲁棒性更好。
「区块之间职责分离」是关键。
📦 六大区块
>Role（角色）
Context（背景）
Task（任务）
Constraints（约束）
Examples（示例）
Input（输入）
XML 标签或 Markdown 标题 # 都行，思路一样。
设计原则
角色放最前
设定基调，影响后面所有生成。
任务用动词+宾语
直接「总结/对比/提取」，别写「我希望你能…」这种模糊句式。
约束用清单体
模型比读段落更容易遵守清单。
输入输出隔离
用 包住用户可变部分，其余是模板常量。
格式声明放约束末尾
且用「正向描述 + 示例」双保险（输出 JSON 如下：{…}）。
关键指令首尾重复
模型有近因偏差，结尾的话权重更高——易翻车的指令（务必输出 JSON 不含 markdown）首尾各说一次。
| 模型 | 偏好 |
|---|---|
| Claude | 吃 XML 标签很顺，官方推荐分块 |
| GPT 系列 | Markdown + 编号清单 OK，few-shot 友好 |
| 国产（DeepSeek/通义/混元） | 结构化 + few-shot 有效，但超长 prompt 边际收益下降快，控制长度 |
怎么优化：迭代方法论
常见调优杠杆（按性价比排序）：
① 加/换 few-shot 示例（收益最大）
② 否定约束改正向指令（不要啰嗦 → 输出≤100字）
③ 加角色 + 受众
④ 拆分复杂任务（一个 prompt 别想干三件事）
⑤ 末尾重复关键指令（近因偏差）
💡 经验法则：80% 的场景 few-shot + 清晰约束就够，不需要上 CoT 或复杂框架。
项目实战：智能问数 Agent 的 Text2SQL
🏢 场景
企业微信里的查数据 Agent：业务人员用自然语言查数据库（岗位/面经信息），Agent 自动生成 SQL 返回结果。
从 v0 到 v4 分层构建，准确率一路从 <30% 提到 85%+。
🗄️ 核心：嵌入 Schema
提效最明显的一步是让 Agent 知道数据库长什么样——Prompt 里嵌入完整数据库 Schema（表名/字段名/类型/注释/样例值）。
模型不再凭空捏造字段名。
| 版本 | 核心改进 | 准确率 |
|---|---|---|
| v0 | 最小可用（任务+输入+输出） | < 30% |
| v1 | 嵌入 Schema + 角色 | ~ 50% |
| v2 | SQL 生成约束（必须 WHERE/地点过滤/LIMIT） | ~ 60% |
| v3 | Few-shot + 分 Agent | ~ 75% |
| v4 | 错误恢复 + 空结果处理 | 85%+ |
最大坑：语法对但语义错
90% 的查询错误不是 LLM 不行，是 Prompt 没写清字段归属，或上下文压缩压掉了关键约束。
嵌 Schema + 样例值收益最大
让模型看过数据库长什么样，比任何约束都有效。
分 Agent + 定制 Few-shot 第二大
岗位查询和面经查询各维护专属示例，Prompt 更精简聚焦。
正面约束 > 负面约束
「必须包含 ×」比「不要遗漏 ×」有效 3 倍以上。
空结果恢复链被低估
空结果自动放宽条件重查，让空结果率从 15%+ 降到 7.5%。
结构化 Prompt 是把散文改成固定区块模板（Role/Context/Task/Constraints/Examples/Input），职责分离、可维护可复用。构建靠分层叠加 v0→v4，优化靠「固定测试集 + 单变量改动 + 调优杠杆 + bad case」闭环。80% 场景 few-shot + 清晰约束就够。Text2SQL 实战：嵌入 Schema 收益最大，分 Agent + 定制 Few-shot 次之，正面约束 > 负面约束。
核心是把 prompt 从一段散文改成有固定区块的模板，关键是区块之间职责分离。骨架一般是 Role、Context、Task、Constraints、Examples、Input 六大块。设计上几个要点：角色放最前设定基调、任务用动词加宾语别写模糊句式、约束用清单体模型更容易遵守、输入输出隔离用 input 块包住用户可变部分、格式声明放约束末尾而且是正向描述加示例双保险、关键指令开头结尾各说一次因为模型有近因偏差。
我的方法论是把它当可控实验而不是玄学。首先固定一个测试集，挑 10 到 20 个真实 case 做回归，不然改完 A 好了 B 坏了你发现不了；然后单变量改动，一次只改一处，换角色、加约束、改 few-shot 分开做，否则不知道哪条生效；接着用几个高性价比杠杆，按收益排是加 few-shot 最大、把否定约束改成正向指令、加角色和受众、拆分复杂任务、末尾重复关键指令；最后做 bad case 分析，看模型错在哪类输入上，补那种示例比泛泛改写有效。
我在智能问数 Agent 上做过，就是把自然语言转 SQL 查企业微信数据库的场景。最大的坑是语法正确但语义错误，90% 的查询错误不是 LLM 能力不行，是 Prompt 没写清楚字段归属。我的调优杠杆按实际收益排：嵌入数据库 Schema 加样例值收益最大，让模型看过数据库长什么样比任何约束都有效；分 Agent 加定制 Few-shot 第二，每个 Agent 的 Prompt 更精简聚焦；正面约束替代负面约束，「必须包含×」比「不要遗漏×」有效 3 倍以上；还有空结果恢复链，自动放宽条件重查，让空结果率从 15% 多降到 7.5%。