完整题目
在大模型应用中，如何系统地设计和构建有效的prompt？请说明构建原则、常用技巧（如少样本学习、思维链等）及实际应用场景。
本文目录
一、核心设计原则
1. 清晰性（Clarity）
- 任务边界明确：告诉模型"做什么"和"不做什么"
- 输出格式约束：用JSON/XML模板、Markdown表格等结构化输出
2. 具体性（Specificity）
- 避免模糊指令，如"写得好一点" → 改为"用学术风格，包含3个论点，每个论点配1个数据支撑"
3. 上下文完整性
- 提供必要的背景知识、角色设定、用户画像
二、关键技巧与场景
| 技巧 | 核心做法 | 典型场景 |
|---|---|---|
| Few-shot | 2-5个输入-输出示例 | 格式固定任务（抽取、分类、SQL生成） |
| CoT（思维链） | "Let's think step by step" 或显式拆解步骤 | 数学推理、复杂决策、多步分析 |
| Self-consistency | 多次采样取多数投票 | 高确定性要求的推理任务 |
| ReAct | Thought → Action → Observation 循环 | Agent工具调用场景 |
三、RAG与Agent中的差异化设计
RAG场景
【系统指令】你是领域专家，严格基于提供的参考资料回答。
【参考资料】{retrieved_docs}
【约束】若资料不足，明确告知"根据现有信息无法确定"，禁止编造。Agent场景
- 工具描述：用Function Schema精确定义参数和返回值
- 状态管理：在Prompt中维护任务进度、历史Action、错误回溯
四、工程实践要点
- 版本管理：用Git管理Prompt模板，记录变更与效果
- 动态组装：按场景拼接System/User/Context模块，避免硬编码
- 评测闭环：建立Prompt-level的单元测试（输入变体→输出断言）
学习建议
掌握Prompt基本结构，结合实例练习少样本学习与思维链技巧，理解其在RAG和Agent中的应用逻辑。
换一种问法，检查是否真正理解
场景切入
假设你在做电商客服，用户问‘这款手机续航怎么样？’只回一句不够，你打算怎么设计prompt让模型既能给出参数，又能对比竞品，最后还推荐配件？
层层追问
你平时写prompt一般注意什么？……如果模型输出总是不符合格式，你会怎么调整？……那再进阶一点，比如让它做多步推理，你会用什么技巧来保证准确性？
直球架构
请系统地讲一下构建有效prompt的原则、常用技巧比如few-shot和思维链，以及在RAG或Agent场景下有什么特别的考虑？
练习口述回答 · 约4分钟
- 一句话定位：prompt设计本质是跟模型对齐意图
- 核心原则：清晰性、具体性、上下文完整性
- 关键技巧：few-shot和chain-of-thought的适用边界
- 业务落地：客服退款场景中的prompt设计
- 风险与取舍：动态组装与评测闭环
这道题其实问的是，你怎么让大模型听懂人话并且干好活，本质是意图对齐。我理解prompt设计不是写作文，而是做接口，得把任务边界、输出格式、上下文约束都交代清楚。
先说核心原则。我总结三个：清晰性、具体性、上下文完整性。清晰性就是告诉模型做什么和不做什么，比如输出格式用JSON模板框死，避免模型自由发挥。具体性就是别写“写得好一点”，要改成“用学术风格，包含三个论点，每个配一个数据支撑”。上下文完整性是说提供必要的背景，比如角色设定、用户画像。这三个原则其实对应的是模型最怕的三种情况：歧义、模糊、信息缺失。
再说技巧。最常用的两个是[[Few-shot]]和[[Chain-of-Thought]]。Few-shot适合格式固定的任务，比如抽取、分类、SQL生成，给两到五个输入输出示例，模型基本就能照做。Chain-of-Thought适合数学推理、复杂决策，加一句“Let's think step by step”或者显式拆解步骤。但落地时很少只用一种，比如做客服退款意图识别，我会先给几个例子做few-shot，再让模型按“用户诉求-订单状态-退款原因”的链条推理，这样准确率更高。
举个例子，客服退款场景。用户说“我买了件衣服，大小不合适，想退”，如果只给few-shot，模型可能直接输出“退货申请”，但忽略了订单是否已发货、是否在退款期内。所以我会在prompt里加CoT，让模型先判断订单状态，再检查退款政策，最后输出结果。同时输出格式用JSON，包含“action”和“reason”字段，这样下游系统可以直接解析。
这里有个坑：前提是模型能力要够。如果模型本身逻辑弱，CoT反而会放大错误。还有，few-shot的示例要覆盖边界情况，比如退款被拒的例子，否则模型会偏向常见情况。我上线前会特别关注这些。
另外，在[[RAG]]场景下，prompt设计要区分系统指令和用户指令。系统指令强调“基于参考资料回答”，用户指令才是具体问题。如果资料不足，要明确说“根据现有信息无法确定”，禁止编造。这个其实涉及到[[Faithfulness]]评估，怎么判断模型有没有忠实于资料，是一个值得深挖的点。
最后，工程上我会用动态组装，把系统指令、上下文、示例拆成模块，按场景拼接，避免硬编码在代码里。版本管理用Git，每次改动记录效果。同时建立prompt级的单元测试，输入变体看输出是否符合断言。
所以，我更倾向把prompt设计看成持续的调试过程，不是一锤子买卖。核心是理解模型能力和任务特点，动态调整。