1. 从零吃透提示词工程为什么它值得你花时间大语言模型这两年的热度不用我多说但真正把模型用出生产力的人和只是把它当聊天玩具的人差距往往不在模型本身而在提示词工程Prompt Engineering这门手艺上。我接触过不少团队模型选的是同一个API 参数也差不多可有人能稳定产出结构化的分析报告有人却只能得到一堆正确的废话。问题出在哪出在提示词的设计思路上。这篇笔记是我自己从零系统学习提示词工程时整理下来的包含核心概念、实操方法、踩过的坑以及和 RAG、思维链这些技术怎么配合使用。适合刚入门想系统梳理的开发者也适合已经在用大模型但效果不稳定、想找找问题根源的从业者。不管你是做应用开发、数据分析还是内容生产只要你在和模型打交道这套东西都能直接用上。先说清楚一个前提提示词工程不是玄学也不是会说话就行。它本质上是一种对模型行为的精确控制技术。模型是一个概率系统你给的每一个词、每一个标点、每一处结构都会影响它下一步生成的概率分布。理解这一点后面所有的技巧才有落脚点。我见过太多人把提示词写成一段模糊的需求描述然后抱怨模型不听话。其实模型没有不听话它只是按你给的信息做了最合理的猜测。提示词工程要做的就是把这个猜测空间压缩到你想要的范围内。2. 提示词工程的核心设计思路拆解2.1 模型到底是怎么理解你的提示词的要写好提示词先得知道模型内部发生了什么。大语言模型本质是一个自回归的下一词预测器它把你的提示词当作上下文然后一个 token 一个 token 地往外吐。这里有个关键概念叫prompt token也就是你的提示词被分词后占用的 token 数量。这个数字直接决定了三件事成本、速度、以及模型能记住多少信息。为什么这个重要因为模型的上下文窗口是有限的。你塞进去的提示词越长留给模型生成和推理的空间就越少。我实测过一个案例同样的任务提示词从 200 token 精简到 80 token输出质量反而更高。原因很简单冗余信息会稀释关键指令的权重。模型对提示词的理解不是像人那样逐句分析语义而是通过注意力机制计算每个 token 和其他 token 的关联强度。所以位置很关键——放在提示词开头和结尾的指令通常比夹在中间的更容易被模型重视。这也是为什么很多高效提示词会把核心要求放在最前面把格式约束放在最后面。2.2 结构化提示词为什么比自然语言描述更有效很多人写提示词就像在跟朋友发微信想到哪写到哪。这种写法对简单任务还行一旦任务复杂模型就开始自由发挥。结构化提示词的核心思路是把指令拆成模型容易解析的模块。我常用的结构是这样的角色设定告诉模型它是谁比如你是一名资深数据分析师任务描述明确要做什么越具体越好输入数据需要处理的内容用分隔符隔开输出要求格式、长度、语气、必须包含什么、必须避免什么示例给一两个输入输出样例让模型照着模仿为什么这个结构有效因为它把模糊的自然语言需求转化成了模型训练时见过的大量结构化文本模式。模型在预训练阶段见过无数类似的格式所以对这种结构的响应更稳定。提示角色设定不是随便写的。你是一个助手这种等于没写。角色越具体模型激活的相关知识越精准。比如你是一名有十年经验的儿科医生比你是一名医生效果好得多。2.3 思维链让模型想清楚再回答思维链Chain of ThoughtCoT是我认为提示词工程里性价比最高的技巧之一。原理很简单让模型在给出最终答案之前先把推理过程写出来。为什么这招管用因为大语言模型是逐 token 生成的它没有独立的思考阶段。如果直接让它输出答案它相当于在一步之内完成所有推理容易出错。而让它先写推理步骤相当于把复杂问题拆成了多个简单的下一词预测任务每一步的准确率都更高累积起来最终答案的准确率就上去了。具体怎么用最简单的做法是在提示词里加一句让我们一步一步思考或者给一个带推理过程的示例。对于数学题、逻辑推理、多条件判断这类任务效果提升非常明显。但思维链也有代价输出变长了token 消耗增加速度变慢。所以不是所有任务都值得用。简单的分类、抽取、改写任务直接给指令就行加思维链反而浪费。2.4 提示词工程和 RAG 的关系到底是什么热搜里RAG出现的频率很高很多人搞不清楚提示词工程和 RAG 是什么关系。我用一句话说清楚RAG 负责给模型提供它不知道的知识提示词工程负责让模型正确使用这些知识。RAG 的全称是检索增强生成核心流程是用户提问 → 从知识库检索相关内容 → 把检索结果和问题一起塞进提示词 → 模型基于这些内容生成回答。你看最后一步还是提示词工程。检索回来的内容怎么组织、怎么标注来源、怎么告诉模型只根据这些内容回答全是提示词设计的活。我见过不少 RAG 项目效果差排查下来不是检索的问题而是提示词没写好。比如检索回来五段内容提示词里只是简单拼接模型根本分不清哪段是问题、哪段是参考资料结果就开始胡编。正确的做法是用明确的分隔符和标签把各部分区分开并且明确指令如果参考资料中没有相关信息直接回答不知道。2.5 知识库的三种形态RAG知识库、KG知识库和结构知识库热词里提到了kg知识库、rag知识库和结构知识库区分以及应用场景这块确实容易混淆我按自己的理解梳理一下。RAG 知识库本质是一个向量数据库把文档切片、向量化之后存起来检索时按语义相似度找最相关的片段。它的优势是灵活什么文本都能塞不需要预先定义结构。缺点是检索精度依赖切片策略和向量模型质量而且它只能找到相似的内容做不了多跳推理。KG 知识库知识图谱是把信息组织成实体和关系的形式比如张三—就职于—某公司。它的优势是能做精确的关系查询和多跳推理适合需要严谨逻辑的场景。缺点是构建成本高需要预先定义本体结构而且对非结构化文本的覆盖能力弱。结构知识库通常指关系型数据库或表格类数据信息以行列形式存储适合精确查询和统计。实际应用中这三者经常组合使用。比如一个企业问答系统用 RAG 处理文档类问题用 KG 处理人员关系、产品依赖这类结构化查询用结构知识库处理数据统计。提示词工程在这里的作用是让模型知道当前问题该走哪条路以及怎么把不同来源的信息融合成一个连贯的回答。至于rag知识库能存储图片嘛这个问题答案是能但方式不同。纯文本 RAG 存不了图片但多模态 RAG 可以把图片通过视觉编码器转成向量和文本向量存在同一个空间里检索时就能跨模态匹配。不过这块工程复杂度高我建议先把文本 RAG 做扎实再考虑。3. 核心细节解析与实操要点3.1 提示词的 token 控制省钱又提速的关键prompt token这个话题值得单独拎出来讲因为它直接关系到你的钱包和用户体验。我做过一个统计同一个任务不同人写的提示词 token 数能差三到五倍而效果可能差不多甚至更差。控制 token 的核心原则是每一个词都要有存在的理由。具体怎么做第一删掉所有客套话和冗余修饰。请你帮我仔细认真地分析一下下面这段文字不如分析以下文本。模型不需要你客气它需要的是明确指令。第二用分隔符代替长描述。与其写下面我将给你一段文本这段文本的开始是三个井号结束也是三个井号不如直接用###把文本包起来然后在指令里说处理 ### 之间的内容。第三示例要精简。给示例是为了让模型理解模式不是为了展示你的数据有多丰富。一个典型示例就够了除非任务边界特别模糊需要多个示例来界定。第四善用系统提示词和用户提示词的分工。系统提示词放固定不变的指令和角色设定用户提示词放每次变化的具体任务。这样系统提示词可以被缓存重复调用时不计费或计费更低。我实测过一个客服问答场景优化前每次请求平均 800 token优化后降到 350 token响应速度提升约 40%成本直接砍半而回答质量没有下降。3.2 提示词被拦截怎么办invalid prompt 的排查思路热搜里有个词是invalid prompt: your prompt was flagged as potentially violating our usage p还有prompt闪退这俩其实是同一类问题你的提示词触发了平台的安全审核。遇到这种情况先别急着骂平台。绝大多数时候问题出在提示词里包含了容易被误判的内容。常见的触发点包括涉及暴力、歧视、隐私信息的词汇即使你的本意是让模型分析这些内容也可能被拦截。排查思路是这样的先做二分法定位。把提示词从中间切开分别测试看是哪一半触发的。找到触发段落后逐句测试定位到具体句子。对触发句子做改写用更中性的表述替代。比如要分析一段包含敏感词的用户评论不要直接把评论原文放进提示词而是先做脱敏处理或者用占位符替代敏感词。如果确实需要处理敏感内容考虑在本地部署模型自己控制审核策略。注意不同平台的审核策略差异很大。同一个提示词在这个平台能过换个平台可能就被拦。做产品的话一定要在目标平台上做充分测试别等上线了才发现问题。prompt闪退通常是另一个原因提示词太长超出了上下文窗口或者包含了特殊字符导致解析失败。检查一下 token 数以及有没有未转义的引号、反斜杠之类的字符。3.3 提示词优化器prompt optimizer怎么用才不翻车prompt optimizer使用教程这类内容网上很多我说说自己的实际体验。提示词优化器本质是让模型帮你改提示词它有一定价值但别指望它一键解决所有问题。它的适用场景是你已经有一个能用的提示词但效果不够稳定想让模型帮你找找可以改进的地方。用法通常是把你的提示词和任务描述一起给模型让它输出优化后的版本。但它有个明显的局限优化器不知道你的真实评估标准。它只能根据语言模式判断什么样的提示词看起来更专业而不是什么样的提示词在你的任务上效果更好。所以优化器的输出只能作为参考最终还是要靠你自己的测试集来验证。我的做法是用优化器生成三到五个候选版本然后拿自己的测试用例跑一遍选效果最好的那个再手动微调。这样既利用了模型的语言能力又保证了结果符合实际需求。3.4 视觉大语言模型的提示词有什么不同视觉大语言模型的提示词设计和纯文本模型有本质区别。纯文本模型只需要处理语言信息而视觉模型要同时处理图像和文本提示词需要明确告诉模型看哪里和看什么。关键差异有几点第一空间指代要明确。说图中的物体不如说图片左上角的物体因为模型对空间关系的理解不如人类直观。第二任务要拆细。让视觉模型描述这张图往往得到泛泛而谈的结果不如拆成图中有几个人他们在做什么背景是什么环境这样具体的问题。第三善用对比。如果要模型判断两张图的差异明确告诉它对比图A和图B列出三处不同比让它自由发挥更可靠。第四注意分辨率限制。很多视觉模型对输入图像有分辨率要求太小的图看不清细节太大的图会被压缩导致信息丢失。上传前最好按模型要求预处理一下。4. 实操过程与核心环节实现4.1 搭建一个可复用的提示词模板库单次写提示词效率太低真正提升生产力的是建立自己的模板库。我的做法是按任务类型分类每类维护几个经过验证的模板。模板的结构我固定成这几块[角色] 你是... [任务] 请完成... [输入] ### {content} ### [约束] - 必须... - 禁止... - 格式要求... [示例] 输入... 输出...为什么用这个顺序角色放最前面是因为它影响模型激活的知识领域越早设定越好。任务紧随其后让模型知道要干什么。输入数据用分隔符包起来避免和指令混淆。约束放后面是因为它是对输出的限制模型在生成时会更关注靠近生成位置的信息。示例放最后作为模式参考。我维护了大概二十个模板覆盖文本分类、信息抽取、内容改写、数据分析、代码生成、多轮对话这几大类。每次遇到新任务先看能不能套现有模板不能的话再新建新建之后如果效果好就沉淀进库里。4.2 用思维链解决多条件判断问题举个我实际做过的例子判断一条用户反馈属于哪个优先级。规则是这样的涉及资金安全的最高优先级涉及功能不可用的次高涉及体验问题的中等纯建议的最低。直接让模型判断准确率大概七成。加上思维链之后提升到九成以上。提示词是这样的你是一名客服质检专家。请根据以下规则判断用户反馈的优先级。 规则 1. 涉及资金安全 → P0 2. 功能完全不可用 → P1 3. 功能可用但体验差 → P2 4. 纯建议或咨询 → P3 请按以下步骤思考 第一步这条反馈的核心诉求是什么 第二步它命中了哪条规则 第三步确认优先级。 反馈内容### {feedback} ### 请输出 - 核心诉求 - 命中规则 - 最终优先级关键点在于我不仅让它一步步想还把每一步要输出什么明确规定了。这样模型的推理过程是可检查的出错时我能定位到是哪一步判断错了方便针对性优化。4.3 搭建一个最小可用的 RAG 问答流程rag实战和rag教程是热词我分享一个最小可用的实现思路不涉及具体代码讲清楚每个环节在干什么。第一步文档准备。把你的知识文档切成小块每块 300 到 500 字比较合适。切太短信息不完整切太长检索精度下降。切的时候尽量按语义边界切比如按段落或小节别硬按字数切。第二步向量化。用嵌入模型把每个文本块转成向量存进向量数据库。嵌入模型的选择很关键中文场景建议用针对中文优化的模型通用模型在中文上的语义区分度可能不够。第三步检索。用户提问时把问题也转成向量在数据库里找最相似的几个文本块。通常取 top 3 到 top 5太少可能漏掉关键信息太多会引入噪声。第四步组装提示词。把检索到的文本块和用户问题拼成一个提示词明确告诉模型只根据以下资料回答资料中没有的说不知道。第五步生成回答。模型基于提示词生成最终答案。这个流程里提示词工程的作用在第四步和第五步。我见过很多 RAG 项目检索明明找对了内容但模型还是答错就是因为提示词没把只根据资料回答这个约束说清楚模型就开始用自己的知识胡编。4.4 在 Mac 上搭建本地 RAG 知识库的实操要点怎么在mac上搭建rag知识库这个需求很实际我说说关键点。Mac 上搭建本地 RAG核心是选对工具链。向量数据库方面轻量级场景可以用基于文件的方案不需要额外起服务适合个人使用。文档解析方面PDF 用专门的解析库Markdown 和纯文本直接读就行。嵌入模型方面Mac 的芯片对本地推理支持不错可以跑一些中小规模的嵌入模型速度可以接受。流程上我建议先用小规模数据跑通全流程比如先拿十篇文档测试确认检索和生成都正常再逐步扩大数据量。很多人一上来就导入几千篇文档结果检索效果差排查起来非常痛苦。提示本地部署大语言模型做 RAG 时模型的上下文窗口是硬约束。检索回来的内容加上提示词模板不能超过窗口限制。如果超了要么减少检索数量要么换更大窗口的模型。5. 常见问题与排查技巧实录5.1 模型不按格式输出怎么办这是最高频的问题。你要求输出 JSON它给你输出一段带解释的文字。排查思路首先检查你的格式要求是否足够明确。说输出 JSON不够要说输出一个 JSON 对象包含 name、age、city 三个字段不要输出任何其他内容。其次用示例锁定格式。给一个完整的输入输出示例模型模仿示例的能力很强。再次如果还是不行用预填充技巧。在提示词末尾直接写上输出的开头比如{模型会顺着这个开头继续生成格式就跑偏不了。最后如果格式要求极其严格考虑用结构化输出功能很多平台都支持强制 JSON 模式从解码层面保证格式正确。5.2 模型回答太笼统、没有干货这个问题通常不是模型能力不够而是提示词没有给出足够的约束。模型默认会输出安全的、放之四海而皆准的内容因为这样最不容易出错。解决办法是增加具体性约束。比如要求给出三个具体例子每个例子包含时间、地点、人物要求引用输入文本中的原话作为依据要求如果信息不足明确指出缺少什么信息而不是泛泛而谈要求避免使用可能也许一般来说这类模糊词汇我实测下来加上这些约束后回答的具体程度提升非常明显。5.3 多轮对话中模型忘记了前面的设定多轮对话里模型只能看到当前上下文窗口内的内容。如果对话轮次多了早期的设定会被挤出窗口模型就失忆了。解决办法有几个一是把关键设定放在系统提示词里系统提示词通常不会被挤出二是定期在用户消息里重申关键约束三是做对话摘要把早期对话压缩成一段摘要放在上下文里。我一般用组合方案系统提示词放角色和核心规则每五轮左右在用户消息里重申一次关键约束超过二十轮的对话做一次摘要压缩。5.4 常见问题速查表问题现象可能原因排查方向提示词被拦截包含敏感词或敏感内容二分法定位触发段落改写表述输出格式错误格式约束不明确增加示例使用预填充启用结构化输出回答笼统缺少具体性约束增加例子要求、引用要求、禁止模糊词多轮对话失忆上下文窗口溢出系统提示词固化设定定期重申做摘要RAG 答非所问提示词未约束只用资料明确指令只根据资料回答资料没有就说不知道响应慢、成本高prompt token 过多精简提示词分离系统与用户提示词利用缓存视觉任务效果差空间指代不明确明确位置描述拆细任务预处理图像分辨率5.5 几个我踩过的坑第一个坑过度依赖示例。早期我总觉得示例越多越好一个任务给五六个示例。后来发现示例太多反而会让模型过度拟合示例的表面模式遇到稍微不同的输入就懵了。现在我的原则是简单任务零示例中等任务一两个示例复杂边界模糊的任务最多三个。第二个坑忽视温度参数。提示词写得再好如果温度设得太高输出还是会飘。做需要稳定输出的任务时温度调到 0 到 0.3 之间。做创意类任务时再调高。第三个坑不做 A/B 测试。凭感觉改提示词改完觉得好像好一点但没有数据支撑。后来我养成了习惯任何提示词改动都拿固定的测试集跑一遍用数据说话。测试集不用大二十条覆盖典型场景的用例就够。第四个坑把提示词写死。业务在变提示词也得跟着变。我现在把提示词里的可变部分抽成变量比如角色、约束、示例都做成可配置的改的时候不用动主体结构。6. 提示词工程的进阶方向6.1 从单次提示到提示词流水线单个提示词能解决的问题有限。复杂任务需要拆成多个步骤每个步骤一个提示词前一步的输出作为后一步的输入形成流水线。比如做一份行业分析报告可以拆成信息抽取 → 信息归类 → 趋势分析 → 报告撰写。每一步用专门的提示词每一步的输出都经过校验再进入下一步。这样做的好处是每步可控出错时容易定位而且每步可以用不同的模型简单步骤用便宜的小模型复杂步骤用强模型成本更优。6.2 提示词与知识库的深度结合前面讲了 RAG 的基本流程进阶玩法是在提示词里做更精细的知识调度。比如根据问题类型决定检索哪个知识库、检索多少条、怎么组织检索结果。我做过一个场景同时有产品文档库、历史工单库、FAQ 库三个知识源。提示词里先让模型判断问题类型然后根据类型决定检索策略。产品功能问题查文档库故障排查查工单库常见问题查 FAQ 库。这样比一股脑全查一遍再让模型筛选精度和效率都高得多。6.3 提示词的版本管理与评估把提示词当代码管理这是团队协作的必备实践。每个提示词有版本号有变更记录有对应的测试结果。上线新版本前必须跑回归测试确保没有引入退化。评估指标方面我通常看这几个准确率输出是否符合预期、稳定性同样输入多次调用结果是否一致、token 效率达到同等效果消耗的 token 数、延迟响应时间。这四个指标综合看才能判断一个提示词是不是真的比旧版好。这套东西刚开始做会觉得麻烦但一旦跑起来提示词的迭代速度和质量都会有质的提升。我自己的模板库经过半年多的迭代现在覆盖了日常八成以上的任务新任务基本都能找到可复用的基础模板改改就能用。最后分享一个我自己的习惯每次遇到效果特别好的提示词或者踩了一个印象深刻的坑我都会随手记下来标注清楚场景、提示词内容、效果和原因分析。这些笔记积累下来就是最贴合自己业务需求的提示词工程经验库比任何通用教程都管用。