简介这份PPT聚焦人工智能与大模型应用中的提示语设计方法面向希望提升ChatGPT使用效率的开发者、产品经理、运营人员和自动化脚本爱好者。它从问题解决过程切入讲解提示语背后的结构化思路用输入、目标、步骤、约束与粘合剂五要素把模糊想法转成清晰任务其中输入参照5W1H目标参照SMART原则约束分为上下文环境与精确业务规则。在运维脚本案例中原始需求是如何把日志目录文件独立压缩、按日期重命名、移动到备份目录并向访问日志追加文件总数和总大小爬虫案例要求抓取头条文章主内容、进入二级页面、记录标题并生成独立PDF同时加入异常处理Web应用案例围绕人员信息表实现增加、修改、删除、查询并限定前端框架、数据库类型以及名称长度和性别选项等业务规则。资源包内只有一个pptx演示文稿体积约42KB轻量便于查阅和二次整理。已有82人学习或下载。读者可借此建立可复用的提问框架理解需求拆解、规则表达、步骤衔接与结果验收的写法并把案例模板迁移到脚本生成、数据采集和Web原型搭建中。对经常使用大模型写代码、做数据分析或生成文档的读者它能帮助减少反复试错提升一次生成可用结果的概率也可作为团队分享与课程辅助材料适合系统学习提示语底层逻辑并反复查阅。1. 从「写一句话」到「约束一个条件分布」ChatGPT 提示语的底层逻辑是什么同一段输入同事发过去得到三行正确但没用的废话你发过去拿到一段能直接塞进函数的 JSON差别通常不在谁更会措辞。ChatGPT 这类大模型每吐一个 token都是在给定前文的前提下做一次概率采样提示语能做的唯一一件事就是把这个概率分布往你要的方向压。想通这一点很多被当成玄学的问题就有解了为什么加一句「请认真思考」有时有效有时无效为什么把硬性要求放在开头或结尾比埋在中间更管用为什么同一段提示语换个模型就崩。这套底层逻辑对写业务代码的人同样重要ai 编程提示词、ai agent 的任务规划步骤、多模态大模型的图文混合指令本质上是同一套条件约束在不同载体上的落地。下面按生成机制、结构模板、参数调优、工程化四层往下拆。2. 大模型的生成机制决定了提示语的四个可调维度2.1 自回归解码提示语的每一句都在改下一个 token 的概率大模型不做「先想好整段再落笔」这件事。它把输入切成 token 序列预测下一个 token 的概率分布采样出一个把它接到序列尾部再预测下一个。整个过程是 P(x_t | x_t)也就是在给定全部前文的条件下求第 t 个位置的条件概率。提示语的全部作用就是参与构造这个条件项。理解了这一点下面几个现象就不再奇怪。第一模型不会「记住」你没写进上下文的要求上一轮对话里说过的规则如果被更长的内容挤出了有效注意力范围它就等于不存在。第二模型对局部措辞敏感因为一个词的变化会顺着链式分解影响后面每一步采样。第三输出长度不可控因为解码没有全局规划阶段你只能通过停止条件去截断。温度参数正是在这个环节起作用。它不改模型权重只改采样时分布的陡峭程度温度趋近 0 时等价于每步取概率最高的 token输出稳定但容易呆板温度升高则把低概率 token 的生存空间放大多样性上来的同时跑偏概率也上来。写抽取、分类、格式转换类提示语时我一般把温度压到 0 到 0.3写头脑风暴、文案候选时才放到 0.7 以上。from openai import OpenAI client OpenAI(api_key你的密钥, base_urlhttps://api.openai.com/v1) MODEL gpt-4o-mini # 按你账号下实际可用的模型标识替换 def ask(system: str, user: str, temperature: float 0.2) - str: resp client.chat.completions.create( modelMODEL, messages[ {role: system, content: system}, # 稳定约束区角色、铁律、输出格式 {role: user, content: user}, # 变量区本次任务的真实数据 ], temperaturetemperature, max_tokens800, # 直接封死单次输出的 token 上限防跑飞 ) return resp.choices[0].message.content这段代码的关键不在 SDK 调用本身而在 system 与 user 的分工。system 里放的是跨请求不变的规则user 里放的是每次都会变的数据包括待处理文本、字段清单、本轮特例。这个划分让提示语从一段长字符串变成「模板 变量」后面的版本管理和评测才有落脚点。max_tokens不只是省钱手段它也是硬性的停止条件能挡住模型在格式混乱时的自我延续。2.2 上下文窗口与信息位置关键约束放在哪一段更稳上下文窗口是硬上限超出部分会被截断截断位置通常由接口或网关决定而不是你。更麻烦的是窗口没满也不代表每段文字被同等对待。长上下文里普遍存在「首尾更牢、中间更松」的现象塞在几千字文档正中间的一条格式要求被漏掉的概率明显高于放在开头 system 和结尾 user 里的同一条。常见做法是把提示语按信息权重排布system 头部放角色和铁律user 尾部放「只输出 JSON不要解释」这类执行指令中间夹大段原始材料。遇到必须整篇输入的长文档我会先加一步「摘录与任务相关的原文片段不要改写」再让模型基于摘录作答相当于用一次额外调用把长材料压缩到有效注意力范围内。位置适合放什么漏掉的后果system 开头角色、术语约定、绝对禁止项全局风格漂移system 结尾输出格式总则、字段清单格式不稳定user 开头本轮任务数据、背景材料答非所问user 结尾执行指令、边界条件、示例忘记约束开始自由发挥位置本身不是玄学它对应的是注意力在序列上的分布差异。同一份提示语只把「必须输出 JSON」从中间挪到 user 末尾解析成功率经常就有肉眼可见的变化这种改动成本几乎为零值得先试。2.3 从机制落到四个可调维度角色、上下文、格式、硬约束把上面的机制翻译成可操作的抓手就是四个维度。角色定义收窄词汇分布和语气空间任务上下文提供条件信息决定模型「知道什么」输出格式约束解码结果的形状让下游程序能解析硬约束负责排除不合法输出比如长度上限、禁止编造字段、缺失时填 null。维度作用机制典型写法反例角色收窄用词与专业词汇分布你是一名负责接口联调的测试工程师你是一个很厉害的 AI上下文提供条件信息下面是三段日志接口返回码定义见附录帮我看下这个格式限制输出形状输出 JSON字段固定为 a/b/c给我一个结果硬约束排除非法输出字段缺失填 null不要编造尽量准确一些四个维度里格式和硬约束最容易被忽略也最容易带来工程收益。角色写得再漂亮如果输出是一段散文下游还得再写一层解析代码反过来格式钉死之后提示语的可维护性会立刻上一个台阶因为每次改动都能用同一批用例验证。3. 把提示语写成可复用结构模板、示例与结构化输出3.1 五段式模板角色、任务、上下文、输出格式、硬约束零散地堆要求改一次崩一次写成固定骨架每次只动其中一段问题定位会快很多。我常用的骨架是五段角色、任务、上下文、输出格式、硬约束顺序固定段落之间用空行或小标题隔开便于人读也便于模型切分。# 角色 你是一名电商订单数据核对助手只处理订单字段不做业务建议。 # 任务 从用户给出的订单文本中抽取字段判断是否存在金额不一致。 # 上下文 订单文本由客服系统导出字段可能缺失金额单位为元允许出现全角字符。 # 输出格式 仅输出 JSON字段为 order_id、amount、currency、mismatch、reason。 mismatch 为布尔值reason 不超过 30 个汉字无异常时为空字符串。 # 硬约束 1. 不要输出 JSON 之外的任何字符不要使用代码块包裹。 2. 文本中没有的字段一律填 null禁止推测。 3. 金额出现多个候选值且无法判断时mismatch 置为 truereason 写明「多值冲突」。这个骨架的价值在于可替换性。任务换掉、上下文换掉角色和硬约束往往能整段复用反过来如果线上出现格式解析失败第一件事就是确认输出格式段有没有被动过。写模板时尽量用「必须」「仅」「禁止」这类无歧义动词少用「尽量」「最好不要」因为后者在采样环节几乎不构成约束。3.2 少样本示例与思维链什么时候加、什么时候是负担少样本示例的作用是把「格式要求」变成「格式演示」。模型在解码时会模仿示例的句式与字段顺序示例越贴近真实输入分布模仿效果越好。示例不是越多越好两到五条、覆盖边界情况字段缺失、多值冲突、单位混杂通常就够凑一堆同质示例只会挤占上下文。思维链适合需要多步推理的任务比如从对比文本中判断冲突、按规则做条件累加。它的代价是输出变长、token 成本上升并且在抽取类任务上容易引入原文没有的内容。抽取、分类、格式转换这类任务加一句「先在内部推理但只输出最终 JSON」比让它把推理过程写出来更实用。任务类型需要 few-shot需要思维链说明字段抽取需要2 至 3 条不需要示例直接示范格式文本分类需要边界样本优先不需要示例固定标签口径规则判定与计算视规则复杂度需要分步降低跳步错误文案生成可选不需要示例会限制多样性3.3 结构化输出用 JSON Schema 把字段钉死只要下游是代码而不是人就应该让模型输出可解析结构。部分模型和接口支持通过response_format传入 JSON Schema让服务端在解码阶段做约束如果所用模型或网关不支持就退化成在提示语里逐字段定义再加一层解析兜底。import json schema { type: object, properties: { order_id: {type: [string, null]}, amount: {type: [number, null]}, currency: {type: string, enum: [CNY, USD, UNKNOWN]}, mismatch: {type: boolean}, reason: {type: string, maxLength: 60}, }, required: [order_id, amount, currency, mismatch, reason], additionalProperties: False, } def extract(text: str) - dict: resp client.chat.completions.create( modelMODEL, messages[ {role: system, content: SYSTEM_PROMPT}, # 3.1 中的五段式模板 {role: user, content: text}, ], temperature0, # 结构化抽取不需要随机性 response_format{ type: json_schema, json_schema: {name: order_extract, strict: True, schema: schema}, }, ) raw resp.choices[0].message.content return json.loads(raw) # 网关不支持 schema 时这里要配合清洗逻辑strict打开后字段名和类型基本不会跑偏additionalProperties设为 false 能挡掉模型自行添加的解释字段。链路仍要留兜底json.loads外面套 try失败时把原始输出和输入一起记日志用这批失败样本反过来修提示语。字段的null与空字符串要提前约定否则下游判空逻辑会到处打补丁。4. 提示语参数怎么调温度、长度限制与失效排查4.1 temperature、top_p、max_tokens 的取值区间提示语文本和采样参数要一起调只改一边常常白费力气。同一段提示语在温度 0.2 下格式稳定在温度 1.0 下就可能开始加解释性前后缀这不是提示语写错了而是采样空间被放开了。参数控制什么常用区间什么时候动它temperature分布陡峭程度抽取 0 至 0.3生成 0.7 至 1.0输出不稳定或过于死板top_p累积概率截断0.1 至 1.0一般只调它和温度中的一个max_tokens单次输出上限按任务实测加 20% 余量输出被硬截断时frequency_penalty重复词惩罚0 至 0.5出现机械重复presence_penalty新话题鼓励0 至 0.5内容过于收敛stop停止序列按协议定需要精确切分多段输出实践里最常踩的坑是同时大改温度和 top_p然后无法判断哪个参数起了作用。稳妥做法是一次只动一个固定随机种子模型支持时跑同一批用例对比。max_tokens设得太小会把 JSON 尾部截掉表现成「格式突然变差」实际是长度不够这类误判在排查时很常见。4.2 四类高频失效与对应的排查动作失效现象机制层面的原因排查动作指令漂移长上下文中约束被稀释把硬约束移到 user 末尾缩短无关上下文格式崩溃温度偏高或字段定义有歧义降温、补null约定、加一条负例幻觉字段缺少「不存在则填 null」的明确指令补硬约束并在下游做字段白名单校验输出截断max_tokens偏小或 stop 命中过早打印 finish_reason按实测长度上调多轮后失忆历史被挤出窗口或未被重述每轮重述关键规则或做历史摘要排查顺序建议固定先看 finish_reason 确认是正常结束还是被截断再看原始输出是否含 JSON 之外的字符最后才怀疑模型能力。把这三步做成习惯能省掉大量换模型、改提示语的无效尝试。提示语调试本质上和写代码调 bug 一样先确认现象再定位变量不要一上来就整段重写。4.3 建一批固定用例改动前后跑通过率靠人眼看几次输出判断提示语好坏是最容易反复的环节。准备二十到五十条覆盖边界的固定用例每条标注期望字段每次改动前后跑同一批记录通过率改动才有依据。import json, time def run_suite(cases, prompt_fn, threshold0.95): passed, failures 0, [] for c in cases: try: out prompt_fn(c[input]) # 内部固定 temperature0 data json.loads(out) assert set(c[expect_keys]) set(data) # 字段完整性 assert data[mismatch] c[expect_mismatch] # 业务判定 passed 1 except Exception as e: failures.append((c[id], repr(e)[:120])) time.sleep(0.2) # 避开接口限流 rate passed / len(cases) print(fpass_rate{rate:.2%}) for fid, err in failures[:5]: print(FAIL, fid, err) return rate threshold用例集要包含「字段全缺」「金额多值」「全角字符」「超长文本」这类边界而不是只放标准样本否则通过率永远漂亮但线上照样翻车。threshold作为上线门槛比如 0.95低于就不合并提示语改动。失败样本要连输入一起留档它们是最有价值的回归资产。5. 提示语当代码管版本、分层拼装与面向 Agent 的拆分5.1 一个提示语一个文件一次改动一次提交把提示语散在业务代码字符串里改动不可追溯回滚只能靠记忆。常见做法是建prompts/目录一个任务一个文件文件名带版本号例如order_extract_v3.md模板变量用{{text}}占位。业务代码只负责读取文件、填充变量、调接口提示语本身走代码评审。变量注入前做长度检查超限就先摘要或报错而不是交给接口静默截断。上线时把提示语文件的哈希记进日志出问题能立刻定位线上跑的是哪一版这比在群里问「谁改的提示语」高效得多。5.2 分层拼装稳定层前置变量层后置长提示语可以拆成三段拼装稳定层是角色、术语表、输出格式整段不变示例层是 few-shot改一次影响面大需要跑全量评测变量层是本轮输入。把稳定层放在最前面还有一个附带好处前缀不变的内容更容易被服务端缓存复用调用成本和延迟都会好一些。层级内容改动频率验证要求稳定层角色、术语、格式、硬约束低跑全量用例示例层few-shot 样本中跑全量用例并查边界样本变量层本轮输入与临时特例每次请求长度与编码校验面向 Agent 场景还要再拆一层把「规划步骤」和「单步执行」分成两个提示语。规划提示语只输出步骤列表执行提示语只处理一个步骤并输出结构化结果这样每步的输出都能单独校验失败时也能只重跑那一步而不是整条链路重来。多模态任务同理图像描述与文本决策分开写避免一条提示语里同时承担感知和判断两件事。调试节奏上我一般固定一个原则一轮只改一个变量跑完评测再决定是否合并到主干。本文还有配套的精品资源点击获取