Prompt 中如何设计角色、任务、约束、输出格式和示例？
这道题考的是 Prompt 工程的核心设计能力。很多人在写 Prompt 时，要么写得很笼统（"帮我写一段文案"），要么堆砌术语（"你是一个专业的营销专家，请运用SWOT分析..."）。这两种都不好。真正好的 Prompt，需要把角色、任务、约束、输出格式、示例这几个要素设计清楚。
核心就一句话：像招聘一个专家一样写 Prompt——先定岗位、再交任务、补充背景、说明交付标准。下面逐一拆解。
一、Prompt 四要素框架：角色、任务、上下文、格式的协同关系
写 Prompt 最常用的框架是 Role-Task-Context-Format（角色-任务-上下文-格式），四者缺一不可。
Role（角色） 决定模型调用哪类知识。你告诉模型"你是一个10年经验的后端架构师"，它就会从架构师视角回答；换成"你是一个刚入职的初级工程师"，回答深度和侧重点完全不同。
Task（任务） 明确要完成的动作。动词开头，说清楚具体做什么——"分析"、"对比"、"总结"、"翻译"，不要用模糊的"处理"或"看看"。
Context（上下文） 提供必要背景。很多人忽略这一点，觉得模型"应该懂"。但模型不懂你公司业务、不懂你当前项目、不懂你之前的对话历史。上下文就是给模型补齐这些信息，让回答更贴合实际需求。
Format（格式） 规定输出样式。你要表格还是段落？要代码块还是 Markdown？要中文还是英文？格式越明确，输出越可控。
这四者的关系是递进的：先告诉模型"是谁"（Role），再告诉它"要做什么"（Task），再补充"在什么情况下做"（Context），最后说明"用什么方式交付"（Format）。
二、角色设定的四个关键维度
角色设定不是简单写"你是专家"，要包含四个维度。
身份明确：你是谁？要具体到职业和经验级别。"资深Java架构师"和"应届生"回答同一个问题，深度和风格完全不同。
专业背景：在哪方面有经验？"10年电商系统架构经验"意味着它懂高并发、分布式、库存一致性这些场景。
目标受众：说给谁听？"给CTO汇报的技术方案"和"给新人培训的入门文档"，语言深度和结构都不一样。
输出风格：正式还是通俗？要专业术语还是通俗解释？"严谨学术风"和"轻松口语风"，读起来完全两个样。
举个例子，同样是解释"什么是微服务"：
- 给技术团队：讲CAP定理、服务治理、分布式事务
- 给管理层：讲业务快速迭代、团队自治、故障隔离
- 给新手：讲"把大商场拆成独立店铺"的比喻
角色决定"谁在回答"，回答的视角和深度完全不同。
三、约束设计与结构化输出的实战技巧
约束设定边界
约束告诉模型"能做什么、不能做什么"。约束不是限制，而是划定安全区。
常见的约束类型：
- 内容边界："不要提及竞品名称"、"不回答政治敏感话题"
- 范围边界："只基于提供的文档回答，不要编造"
- 质量边界："代码必须通过ESLint检测"、"回答不超过200字"
- 免责约束："如果不确定，请明确说明，不要猜测"
约束设计有个原则：约束是边界，不是限制。意思是约束告诉模型"这片区域是安全的"，而不是"这也不能做那也不能做"。太死板的约束会让模型变得畏手畏脚，反而影响输出质量。
结构化输出：用 JSON Schema 定义字段
如果你需要机器可读的输出，直接用 JSON Schema 约束格式：
{
"type": "object",
"properties": {
"title": { "type": "string", "description": "文章标题" },
"summary": { "type": "string", "maxLength": 100 },
"tags": { "type": "array", "items": { "type": "string" } },
"wordCount": { "type": "integer" }
},
"required": ["title", "summary"]
}预填充引导：给模型一个开头
想让模型输出特定格式？给它一个开头。比如要 JSON，就写 {"；要 XML，就写 <output>。模型会自动续写这个格式。
{
"role": "user",
"content": "提取文章关键信息，以JSON格式返回。\n{"
}这样模型会直接在 { 后面继续写，而不是先解释"好的，我来提取..."。
四、示例设计与 Prompt 调优闭环
少样本学习（Few-shot）
想让模型按你的风格输出？给示例比描述规则更有效。
示例设计要覆盖三种场景：
- 正常场景：标准输入、标准输出
- 边缘场景：边界条件、特殊情况
- 异常场景：错误输入、典型错误
比如教模型做代码评审：
输入：一段没有注释的函数
输出：指出缺少文档注释，建议补充
输入：一段3行代码
输出：指出代码太短，建议合并到其他逻辑
输入：一段正常的函数
输出：给出正面评价这样模型学会判断"什么时候批评、什么时候表扬"，而不是机械地给所有代码都挑毛病。
调优闭环：固定变量、单点修改、记录指标
Prompt 调优和代码迭代一样，要科学地改：
- 准备样例：收集一批代表性测试用例
- 固定变量：一次只改一个元素
- 记录指标：准确率、响应时间、一致性
- 单点修改：改了A，看A的效果
- 回归测试：确保改A不会破坏B、C
调优最常见的错误是"一次改太多"。改了角色设定、任务描述、输出格式，然后发现效果好了——但你不知道是哪改对了，也不知道哪个改错了。
面试怎么答
基础版（结构清晰、不漏要点）：
好的 Prompt 设计包含四个核心要素：角色、任务、上下文、格式。角色设定要明确身份、专业背景、目标受众和输出风格，决定模型的回答视角。任务用动词开头，说清楚具体动作。上下文补充必要背景，让回答更贴合实际。格式规定输出样式，要明确具体。
约束用来划定边界，包括内容边界、范围边界、质量边界。结构化输出用 JSON Schema 定义字段格式，可以用预填充引导（给
{"）让模型直接输出目标格式。示例设计用少样本学习，覆盖正常、边缘、异常三种场景。调优时固定变量、单点修改、记录指标、定期回归测试。
加分版（展示深度理解）：
我设计 Prompt 的思路是像招聘专家一样写 JD。角色设定要包含身份、专业背景、受众、风格四个维度，比如"你是一个有10年经验的电商后端架构师，面向技术团队，用严谨专业的语言解释技术方案"。
约束是边界不是限制，划定安全区而不是设置禁区。我会设置免责声明（"不确定时说明"）、知识边界（"只基于提供文档"）、内容边界（"不提及第三方品牌"）。
结构化输出用 JSON Schema 约束字段，加预填充引导
{"让模型直接续写。示例设计覆盖三种场景，调优时每次只改一个变量，记录准确率、响应时间、一致性等指标。
一句话总结
Prompt 设计就是"招聘专家"：先定岗位（角色）、再交任务、补充背景（上下文）、说明交付标准（格式、约束、示例），越具体的 JD 越能找到合适的人。