提示词Prompt是普通用户和大模型交互时输入的一段自然语言指令。对新手来说最先接触到的提示词往往就是聊天框里那几句话让 AI 写一段朋友圈文案、解释一段报错、整理会议纪要、生成一张海报素材。这些用法看起来简单但一旦开始系统学习你很快就会意识到提示词不只是“会说人话”而是一整套理解模型能力、控制输出质量、沉淀模板、构建稳定应用的方法论。这篇文章面向刚接触大模型、想从零开始理解提示词概念的开发者。先解释提示词底层是什么再讲新手必须掌握的 6 个核心概念然后给出一套可复用的提示词结构模板最后结合常见问题、排查路径和生产落地建议帮助你从“随便聊聊”升级成“稳定产出”。先建立一个共识这里讲的是“解析”不是“背诵模板”。比收藏一百个提示词模板更重要的是理解模板为什么有效、什么时候要改、改坏了怎么排查。1. 提示词是什么先建立一个准确的技术认知1.1 一句话解释和它背后的模型机制通俗地说提示词是交给大模型的“开工单”。你写清楚要做什么、背景是什么、结果长什么样模型按这张“开工单”生成内容。从技术机制看大语言模型LLM本质是一个自回归模型给定一段前文模型根据概率分布预测下一个 token再把新 token 接在末尾继续预测直到生成结束。提示词就是这段前文的起点。模型生成的每个 token 的概率都会受到提示词措辞、顺序和上下文的影响。这就解释了一个新手常问的问题“为什么同一句话换个说法答案就变了”因为模型本来就是在做条件概率预测不同表达会改变条件分布输出自然不同。提示词工程的目标就是通过设计这段“输入条件”让模型的输出尽量贴近你的真实需求。1.2 提示词在实际交互里承担了哪些职责提示词表面上是一段文字实际上至少承担以下几类职责任务定义告诉模型“你现在要做什么”例如翻译、总结、写代码、生成 SQL。背景补充提供领域信息、数据来源、目标读者让模型在正确语境下推理。行为约束规定不能做什么例如“不要编造数据”“不要输出解释”。输出格式指定 JSON、Markdown、表格、列表等结构方便程序解析。示例演示给出 1 到 3 个输入输出对让模型模仿你的期望结果。推理引导要求模型先分析再得出结论减少跳步和臆测。这些职责可以混在同一段提示词里也可以拆到 system 和 user 等不同角色中。新手最容易犯的错误是只写“任务定义”把背景、格式和约束全丢给模型自由发挥。1.3 角色和消息结构提示词不只有一句话在 API 类接口中提示词通常被组织成消息数组常见角色有三种{ model: gpt-4o-mini, messages: [ {role: system, content: 你是一名资深 Java 工程师回答要简洁代码必须有注释。}, {role: user, content: 请解释 Spring 的 Bean 生命周期并给出一个初始化回调示例。}, {role: assistant, content: Spring Bean 生命周期可以简化为实例化、属性填充、初始化、使用、销毁五个阶段。} ], temperature: 0.3 }system设定整体人设、规则和边界相当于“系统配置”。user当前用户真正要问的事情。assistant模型历史回复。多轮对话中把前面的 assistant 回复塞回上下文模型才能保持连贯。不同模型对 system 的敏感度不一样。有的模型严格遵循 system有的模型会优先听 user 里的最新指令。落地时要以模型官方文档为准不能假设所有模型行为一致。2. 新手必须先掌握的 6 个核心概念2.1 Token提示词不是按“字数”计费的Token 是模型处理文本的最小单位。一个中文汉字可能对应 1 到 2 个 token一个英文单词通常拆成 1 到 2 个 token标点、空格也可能占 token。API 费用、上下文窗口上限、响应延迟都以 token 计算。对新手的影响有两点提示词不是越长越好。提示词占用的 token 会挤占输入窗口留给输出的空间变少。长提示词会增加延迟和成本。如果同一个系统提示词每次请求都完整发送费用会线性上涨。常见模型上下文窗口从几千到几十万 token 不等。超过窗口的部分会被截断或报错表现通常是“模型忘记了前面的内容”或直接拒绝请求。排查这类问题时第一步就是检查 token 消耗。2.2 上下文窗口模型能记住的范围是有限的上下文窗口Context Window是模型一次请求能看到的全部文本范围包括 system、历史对话、用户输入和已经生成的输出。上下文窗口不是模型的“长期记忆”而是“工作台”。它决定了单次对话能容纳多少资料。实际项目中常用“外置记忆”弥补窗口限制把大文档切片通过检索把相关片段插入提示词而不是把所有内容都塞进去。这就是 RAG检索增强生成的基本思路。新手可以先不深入 RAG但要建立这个意识提示词不是唯一的信息载体必要时可以让代码替你做信息筛选。2.3 Few-shot 示例比“说要求”更有效的是“给例子”零样本Zero-shot是指只给任务描述不给示例。少样本Few-shot是指在提示词里放几个输入输出示例。对很多任务来说Few-shot 比单纯描述更能稳定输出质量因为示例比抽象规则更容易被模型模仿。示例三要素输入用户给的是什么。输出期望模型生成的是什么。风格语气、长度、结构、是否包含解释。一个典型 Few-shot 示例请根据用户评价生成客服回复要求语气礼貌先致谢再解释最后给出处理方案。 示例 1 用户评价你们发货太慢了等了 5 天才收到。 客服回复非常抱歉给您带来不好的体验。因为大促期间订单量激增物流比平时慢了 1 到 2 天。我们已经联系仓库优先处理您的后续订单预计 2 天内送达。感谢您的耐心等待。 示例 2 用户评价商品质量不错但包装破损了。 客服回复感谢您的反馈。我们已经将包装问题同步给仓储部门后续会加强加固处理。如商品有损坏您可以申请免费换货我们会优先为您处理。 新评价你们客服电话一直打不通账号又登录不了。 客服回复注意示例不能太多。示例太多会占用上下文也可能让模型过度模仿示例细节导致泛化变差。一般 2 到 5 个即可并且示例之间要有区分度。2.4 输出格式控制让模型输出能被程序解析聊天场景里模型输出自然语言就够了。应用场景里输出要传给程序解析就必须约定格式。常见做法是让模型输出 JSON 或 Markdown也可以使用结构化函数调用。请分析下面这段用户反馈并只输出 JSON不要输出其他解释文字。 { sentiment: positive|neutral|negative, category: 物流|质量|客服|退换货|其他, summary: 一句话概述问题 } 用户反馈商品收到时外包装完好但里面的杯子有个小缺口申请换货后客服处理很快。当模型输出“JSON 外边还带解释文字”时常见解法有在提示词里明确“只输出 JSON不要代码块不要解释”把 JSON 结构定义得更完整或者让模型先输出校验文本再解析。生产环境最好再加一层解析容错例如从字符串里提取 JSON 片段而不是假定模型每次都严格守规矩。2.5 采样参数temperature、top_p 这些数字到底管什么提示词管理“说什么”采样参数管理“怎么说”。常用参数如下表。参数作用常见值调大效果调小效果temperature控制随机性0 到 1 之间常用 0.2 到 0.8更发散、更有创意更稳定、更保守top_p核采样概率阈值0.9 或 1.0候选范围更宽候选范围更窄max_tokens输出最大 token 数按任务长度设置允许更长输出输出可能被截断presence_penalty对重复提及话题的惩罚0 到 1鼓励引入新话题容易重复frequency_penalty对高频词出现的惩罚0 到 1降低词频重复词更容易反复出现新手最容易犯的错误是把 temperature 调得很高导致同一个问题每次答案都不同。如果任务是分类、提取、生成 JSON建议 temperature 设 0 到 0.3如果是创意写作、头脑风暴才把 temperature 调高。注意temperature 和 top_p 一般建议只调一个不要同时大幅度调整。2.6 Prompt、Skill、Agent 到底是什么关系关键词里经常出现“Skill”“Agent”“提示词框架”新手容易混。先给一个基础结论提示词Prompt一次请求中的输入文本。提示词工程Prompt Engineering设计、测试、优化提示词的方法论。提示词框架Framework把提示词组织成固定结构的方法例如 CRISPE、BROKE、CO-STAR。Skill技能把提示词、处理流程、脚本、工具封装成可复用的“能力包”。提示词是 Skill 的核心组成部分但 Skill 还能包含前置处理、参数校验、结果后处理。Agent智能体以模型为大脑配合工具调用、任务规划、记忆管理构成的自动化程序。Agent 会动态生成提示词而不是像普通应用那样只使用固定提示词。关系可以概括成一句话提示词是基础单元提示词工程是设计基础单元的方法Skill 是基础单元的封装Agent 则是在运行时动态使用这些单元的自动系统。新手入门时先把提示词写好再逐步理解 Skill 的封装方式最后再拥抱 Agent 的复杂度。反过来学很容易被“自主规划”“工具调用”绕晕。3. 一套适合新手的提示词结构模板3.1 通用六要素结构写提示词不是写作文不需要文采需要结构。推荐新手先按六要素组织角色让模型扮演什么身份。任务要完成的具体动作。背景任务相关的资料、对象、约束。要求可执行的规则。示例期望的输出样例。输出格式最终结果的结构。模板可以写成这种形式【角色】 你是一名具备 X 年经验的 {岗位}擅长 {领域}。 【任务】 请帮我 {具体任务}。 【背景】 对象{目标对象或目标读者} 资料{提供必要信息}没有资料就写明“未提供相关资料时请主动提问” 【要求】 1. {规则一} 2. {规则二} 3. 不要 {禁止行为} 【示例】 输入{示例输入} 输出{示例输出} 【输出格式】 {JSON / Markdown / 表格 / 分点列表}这个模板不是万能公式而是新手的第一根拐杖。熟练之后可以根据任务类型删减要素。比如分类任务可以不要背景创意写作可以不写输出格式。3.2 一个从“模糊”到“清晰”的完整案例先看一个非常典型的模糊提示词帮我写一段产品介绍。问题在哪没有产品信息、没有读者、没有篇幅、没有风格、没有输出结构。模型只能根据常识猜结果自然不可控。优化后的提示词【角色】 你是一名 B 端 SaaS 产品的内容策划。 【任务】 为我们的客服工单系统写一段官网首页产品介绍。 【背景】 产品客服工单系统核心功能是工单流转、SLA 超时提醒、多客服协作。 目标读者中小型企业的客服主管非技术背景。 调性专业、可信、避免夸大。 【要求】 1. 全文 300 字左右。 2. 第一段说明产品解决什么问题。 3. 第二段列出三个核心功能每个功能用一句话解释对客服主管的价值。 4. 结尾给一句行动号召。 5. 不要出现“革命性”“极致”“赋能”等空泛词。 【输出格式】 直接输出三段文字每段前加一个小标题。对比看优化后的提示词把“不可控的猜测”变成“可以验收的输出”。判断提示词好坏的标准不是字数多少而是模型输出是否稳定地符合预期。3.3 按场景分类的提示词模板示例代码生成与解释你是一名 Python 后端开发。请实现以下函数要求 1. 使用类型注解。 2. 处理输入为 None 的情况。 3. 给出一个调用示例。 4. 不输出无关解释。 函数说明给定一个整数列表返回其中所有偶数的平方按原顺序排列。文本总结请总结下面这段会议纪要输出三项 1. 决策形成的一致结论。 2. 待办负责人和截止时间。 3. 风险需要跟进的问题。 如果原文没有对应信息请写“无”不要编造。数学建模或数据分析你是一名数学建模竞赛选手。针对以下问题请先给出假设再列出建模思路最后给出至少两种可选模型及适用条件。输出使用 Markdown 三节 ## 假设 ## 建模思路 ## 模型对比图片或视频生成的风格提示词图片生成类模型的提示词结构和文本模型有所不同一般包含主体、背景、构图、光影、风格、画质几个部分。比如“吉卜力风格”这类效果提示词本质是调用一种被训练数据广泛认可的动画美术风格。这种风格与特定动画工作室的美术特征有关但在模型里已经变成一种可被“风格词”触发的视觉模式。使用时要参考对应模型的官方提示词规范不同模型对风格词的响应差异很大。主体一个背着书包的小学生在雨后的小巷里回头看。 背景老城区、潮湿石板路、远处有暖色路灯。 构图中景人物在画面左侧。 光影雨后的环境反射光柔和。 风格吉卜力风格手绘质感治愈系。 画质高细节4K。视频生成模型也遵循类似结构主体动作、场景切换、镜头运动、时长、风格。具体字段以官方模板为准因为不同产品的关键词体系并不通用。4. 怎么写、怎么验证、怎么迭代提示词的工程化方法4.1 用“输入-过程-输出”三视图设计提示词写提示词之前不要急着打字先用三视图想清楚输入模型能拿到什么信息是用户输入、数据库查询结果还是上一轮的输出是否可能为空过程模型需要做哪些推理是直接回答还是先分析再总结还是调用外部工具输出最终交给谁给用户阅读还是给程序解析失败时如何兜底把这三项写下来再转换成提示词里的六要素思路会清晰很多。很多提示词效果差不是因为“不会写”而是因为根本不知道自己想要什么。4.2 验证提示词好坏的检查清单每次写完提示词不要只看一次输出至少用下表检查一遍检查项通过标准任务明确换一个人来读提示词也知道要模型做什么背景完整模型不需要猜关键信息或已允许主动提问约束可执行“不要编造”“不要输出解释”等可以客观判断输出格式清楚JSON 结构、Markdown 标题层级、字段名都写明示例匹配示例与真实任务同型不含错误示范边界覆盖空输入、超长输入、敏感输入都有处理策略稳定性相同输入连续跑 3 到 5 次输出结构基本一致成本可控提示词 token 数、输出长度在预算内这个清单不只是新手用生产环境改动提示词前也应该过一遍。4.3 迭代提示词一次只改一个变量提示词迭代最常见的错误是“大改”风格改一下、格式改一下、示例换两个一起发出去发现输出变了却不知道是哪个改动起的作用。推荐做法是建立提示词的版本记录。每次只改一个变量然后用同一组测试用例反复验证。测试用例至少包含 3 到 5 条覆盖正常情况、边界情况和错误情况。把每次的输入、输出、耗时、是否符合预期记录下来。版本 v1.2 修改内容temperature 从 0.7 降到 0.2 测试集5 条客户评价包含正面、负面、中性和超长文本 结果JSON 解析成功 5/5之前为 3/5 结论保留本次修改这种“提示词回归测试”的习惯越早建立越好。它可以防止你花半天调出一个“感觉变好”的提示词结果换一批数据就崩。5. 新手最常踩的 6 个坑和排查链路5.1 六个常见坑坑现象为什么错推荐做法1. 提示词过短模型答案泛泛而谈缺少针对性任务和背景缺失模型只能猜至少写清角色、任务、背景、输出格式四项2. 要求笼统输出“看起来对但没法验收”缺少可判断的约束把“写得好一点”改成“不超过 300 字采用总分结构”3. 忽视输出格式JSON 解析失败程序报错模型没被告知格式要求显式声明格式并给出字段说明4. 一次改太多变量不知道哪个改动生效分组实验被破坏一次只改一个参数或一段提示词5. 把模型当确定性程序相同输入输出时好时坏模型本身是概率采样降低 temperature增加示例增加校验层6. 忽视内容安全生成违规内容或敏感内容提示词没有设置边界明确禁止内容增加合规过滤流程5.2 输出不符合预期时的排查顺序当提示词效果不理想按这个顺序排查不要先怀疑模型“笨”输入是否正确。先确认传给模型的最终文本是否经过了程序拼接、转义、截断。经常是开发环境里拼错了变量。提示词结构是否完整。角色、任务、背景、格式、示例是否齐全。参数是否合适。temperature 是否过高max_tokens 是否太小导致截断。上下文是否够用。关键信息是否被挤出上下文窗口或者历史对话污染了本次任务。示例是否带偏。示例里的错误示范会被模型学到。模型和版本差异。不同模型对 system 的重视程度、对格式的敏感度都不同要查官方文档。最后才考虑模型能力边界。确实超出模型能力时换模型或换方案而不是继续堆提示词。5.3 一个常见报错案例JSON 老是被“解释文字”包裹现象模型返回了 JSON但 JSON 前后有多余的说明文字代码解析失败。排查先看真实返回内容确认是模型问题还是提示词问题。然后检查提示词是否写了“只输出 JSON”是否给出了足够明确的字段结构是否在示例中展示过“只有 JSON、没有解释”的样子。解决把“只输出 JSON不要输出任何解释文字”放在提示词最后如果模型仍不听话改用函数调用等结构化能力最后在代码层增加提取和容错逻辑例如用正则抽取第一个{到最后一个}之间的内容再解析。6. 从提示词到生产落地新手进阶路径6.1 提示词在真实项目里是“代码的一部分”聊天框里写提示词可以随意。工程项目里提示词必须版本化、外置化、可观测。推荐把提示词放入单独文件或配置中心而不是硬编码在代码里。这样修改提示词不必重新发布代码也方便回滚。prompts/ system.md customer_analysis/prompt_v1.2.md customer_analysis/examples.json customer_analysis/config.json同时要把提示词版本、模型、参数、输入摘要、输出摘要写入日志。出问题时你才能知道“当时用哪个版本、什么参数、产生了什么结果”。否则提示词一改线上行为变化都无从追踪。6.2 生产环境要额外处理安全和成本安全方面至少要关注三点提示词注入当用户输入会被拼进 system 提示词时用户可能通过“忽略之前的指令”等方式绕过规则。不要把系统提示词直接拼接未过滤的用户输入要对输入做边界隔离和内容审计。内容合规文本生成、图片生成都涉及内容安全模型可能输出违法违规、色情低俗或暴力内容。提示词层要写明限制应用层要有过滤和审核机制。敏感信息不要在生产环境日志里记录完整用户输入和模型原文避免个人隐私和商业秘密泄露。成本方面生产环境应该给输出设置 max_tokens 上限对单次请求做预算控制高频场景优先考虑用更小、更便宜的模型长文本场景用摘要或检索替代“全文灌进提示词”。6.3 下一步把提示词封装成 Skill再走向 Agent当你能在固定任务里稳定写出一套好提示词下一步可以尝试把它封装成 Skill。Skill 通常包含一个描述文件、一段系统提示词、可能还有校验脚本和示例数据。封装之后别人可以直接复用不必理解内部提示词细节。再往后是 Agent。Agent 会把提示词变成运行时动态生成的指令模型根据用户目标选择工具、拆解步骤、观察反馈、修正计划。这时提示词工程质量会直接影响 Agent 的稳定性相当于从“写固定剧本”升级到“设计决策规则”。不建议新手一上来就做 Agent。先把单个提示词的输入输出控制好把回归测试习惯建立起来再进入 Skill 和 Agent整个学习曲线会平滑很多。6.4 给新手的学习路径和练习建议学习资料方面可以按顺序接触模型官方提示词指南、吴恩达的提示词工程课程、社区里的提示词框架总结。不过资料只是参考真正的理解来自对比实验。推荐一个 21 天练习路径第 1 周每天用六要素模板写 3 个提示词覆盖写作、编程、总结三类任务记录每次输出是否符合预期。第 2 周为同一个任务写三个不同版本提示词对比结构差异带来的效果差异练习一次只改一个变量。第 3 周选一个真实任务建立 5 条测试用例做提示词回归测试然后尝试封装成 Skill。练习时不要只关注“这次输出好不好”还要关注“这次输出为什么好”。理解原因才能把经验迁移到新任务。遇到不懂的术语先回到模型机制本身token 怎么处理、上下文窗口怎么限制、采样参数怎么影响输出。把这三个基础点吃透提示词工程的大多数问题都能找到解释。