1. 先找准问题提示词工程到底在解决什么1.1 大模型不是搜索引擎而是“按指令推理的执行者”很多人第一次接触大模型时会把它当成一个更聪明的搜索引擎来用输入一个关键词期待它直接返回标准答案。但实际用下来就会发现同一个模型有人能让它写出可交付的周报、能跑的代码、结构清晰的调研报告有人得到的却是正确的废话。差别不在模型本身而在你给它的指令。我更喜欢把大模型理解成一个“阅读理解能力极强、但极其依赖指令质量的临时工”。它读得懂你的话但它不知道你心里想要什么、不知道你的验收标准是什么、更不会主动追问。你说“帮我写个方案”它只能猜一个最通用的方案写法给你你说“帮我写一份面向管理层的一页纸落地规划包含时间节点、负责人建议、风险点”它交付的东西就完全不一样。提示词工程本质上就是把“你脑子里完整的验收标准”翻译成模型“能严格照做的指令”。这也解释了为什么同一个模型在不同人手里效果天差地别。模型的能力边界只是其中一半另一半取决于你如何挖掘。提示词工程就是干这个的在不动模型参数、不写代码的前提下把模型的潜力尽量压榨出来。1.2 提示词工程能解决的四大类问题根据我这一年多来的实际使用经验提示词工程解决的问题基本可以归为四类。第一类是输出质量不稳定。同一个问题换个问法答案水准就忽高忽低。这类问题大多出在指令太笼统模型只能靠概率去猜“最可能的答案”而不是“最正确的答案”。第二类是输出格式不符合预期。你要的是表格它给你一段话你要JSON它给你带说明文字的伪JSON你要分点它给你写成一坨。这类问题在工程场景下尤其致命因为下游程序没法解析它的输出。第三类是复杂任务做不好。当任务需要多步推理、需要组合多个信息源、需要严格遵循某些约束时模型往往会“跳步”或者“想当然”。典型表现是让它做一个包含清洗、分析、结论三段的数据处理它直接跳到结论过程逻辑全部缺失。第四类是幻觉和事实错误。模型会把编造的内容说得有理有据尤其在你不给它参考资料的情况下。提示词工程没法根治幻觉但可以通过强制引用、分步验证、限定回答范围等方式把幻觉的影响降到最低。把这四类问题记在脑子里后面所有方法都是围绕着它们来设计的。你会发现好的提示词从来不是“文采好”而是“约束到位”。2. 一套能覆盖80%场景的提示词框架2.1 信息分五层角色、任务、背景、要求、样例我见过很多提示词模板有的催你写“请你扮演一位资深XX专家”有的让你堆一堆形容词。但实际效果最好的是结构化的“信息分层”。我把手头能稳定复用的提示词统一整理成五个层次角色层、任务层、背景层、要求层、样例层。角色层解决“模型以什么视角和立场来回答”。它不只是加一句“你是专家”这么简单而是要明确视角、语气、知识范围。比如“你是一名有十年经验的数据库运维工程师擅长MySQL性能优化回答时请使用业内通用的术语不要堆砌概念”就比“你是MySQL专家”精准得多。任务层是整段提示词的核心必须用一两句话把任务说清楚。关键是要写“做什么做到什么程度”而不是只写“关于什么”。比如“分析这份销售数据找出华东区连续三个月下滑的产品线并给出三类可能原因”就是一个明确的任务描述它限定了分析对象、分析范围、输出数量。背景层给模型提供上下文告诉它“当前处于什么情境”。背景信息越具体模型的回答越贴合实际。比如同样让模型写一封客户沟通邮件你告诉它“客户是合作三年的老客户最近因为物流延迟投诉过两次”和什么都不告诉它写出来的邮件完全不是一个水准。要求层是很多人最容易忽略的。你需要明确告诉模型输出的格式、长度、风格、禁忌。比如“用表格输出”“每条不超过50字”“不要使用专业术语面向普通用户解释”“不要出现猜测性内容”等等。模型非常遵守“明确的约束”但完全读不懂“你心里默认的约束”。样例层是效果提升最大的一层。给模型示范一个“理想输出长什么样”它模仿起来会极其精准。哪怕只给一个简短的示例输出质量的稳定性都会明显上升。我甚至见过只靠样例、不给任何描述性要求的提示词效果反而更好——样例是比抽象描述更高效的沟通方式。2.2 把一个模糊需求翻译成可执行的指令很多人写提示词的问题不是“不会写”而是“太笼统”。原因是脑子里觉得“这需求谁听了都懂”但模型不是人它不会结合你的实际情况去补全信息。我们来做一个对比看同一个需求从“模糊”到“清晰”的演变过程。第一版提示词大概是这样的“帮我写一个关于公司团建活动的方案。”模型会输出一份非常通用的团建方案包含目的、时间地点、活动流程、预算看上去结构完整但你拿给领导看大概率会被打回来——因为里面没有结合你们公司的实际情况。第二版提示词开始有信息了“我们公司有80人预算3万计划在6月中旬团建想办一场户外拓展和水上活动结合的活动请帮我写一个方案。”这个版本比第一版好很多但模型还是会在很多细节上“自由发挥”——活动具体时间怎么安排、安全怎么保障、餐饮怎么订、雨天备选方案是什么它都会默认按最常规的来。第三版提示词也就是我推荐的版本会把所有关键细节都显式写出来并且规定输出结构。我给你们看一个实际可用的结构你是一名有5年经验的团建活动策划师。我们的团队有80人年龄集中在25到35岁6月中旬计划在杭州周边举办一天团建预算3万元含交通、餐饮、活动费用。请输出一份活动执行方案必须包含上午的活动项目户外拓展类、下午的活动项目水上项目、各环节时间节点、人员分组方案、餐饮安排、雨天备选方案、费用预算明细表、需要提前准备的物料清单。预算明细表按项目分列总金额不得超过3万。这套提示词里的关键信息全部是明确的人数、预算、时间、地点、活动类型、输出结构。模型拿到这样的指令几乎没有“自由发挥”的空间每项内容都会基于给定的条件去推理。这就是提示词工程和“随便问问”的核心区别——你在用信息密度压缩模型的猜测空间。我在这里给你们一个自查清单写完提示词之后对着检查模型中是否知道任务对象是谁是否知道任务的边界和限制是否知道输出的结构和格式是否有足够的背景信息支撑它做出决策如果四项目标有不确定的说明提示词还得补信息。2.3 三个高频技巧的原理与使用边界网上流传的提示词技巧五花八门但剥掉包装之后真正普适、稳定生效的核心技巧就是三个few-shot少样本示例、CoT思维链、角色扮演。这三个技巧不是互相替代的关系而是可以组合的。few-shot 的原理最好理解给模型看几个输入输出的示例让它通过模仿格式和风格来完成任务。它的优势在于对格式类任务的约束力极强。比如让模型把一段话拆成“问题、分析、结论”三段你在提示词里给一个拆好的示例它输出的结构就会严格对齐。使用边界也很明显示例太少了模型抓不到规律示例太多了会占用上下文空间一般2到4个高质量示例就够了。思维链 CoT 是目前提升复杂推理能力最有效的手段。它的原理是让模型在输出最终答案之前把推理过程显式写出来。为什么有效因为大模型在“一步得出答案”时本质上是在做概率预测很容易选中“听起来像回事但逻辑不严谨”的答案。但如果你引导它分步推理模型就可以在第一步的结论基础上继续推演相当于把一个大问题拆成几个小问题逐个解决。最经典的用法就是在提示词里加一句“请一步一步思考先列出已知条件再逐步推导”。角色扮演这个技巧很多人理解得太浅。它不仅仅是“让模型装成一个专家”而是通过角色设定改变模型的默认输出偏好。比如让模型“以小学老师的口吻向三年级学生解释光合作用”和你直接问“什么是光合作用”输出内容的词汇选择、句子长度、类比方式会完全不同。使用角色扮演的核心诀窍是角色的属性要具体不能只给身份还要给风格、受众、约束。这三个技巧熟悉之后再看任何提示词案例你都能拆解出它用了哪个技巧、为什么要这么用。不会再看什么都觉得玄。3. 按任务类型拆解不同场景的指令设计实战3.1 内容生成类从“写得更好”到“写给谁看、怎么落地”内容生成是大多数人使用大模型最高频的场景包括写文案、写邮件、写周报、写策划、写文章。在这个场景里最容易犯的错误是提示词里只写“帮我写一篇关于XXX的文章”然后抱怨模型写得太水。问题不在模型而在于你完全没定义“好”的标准。一篇内容要想写得好至少需要定义四件事目标读者是谁、核心信息是什么、希望读者看完后做什么、语气风格是什么。我们看一个实战例子。假设你要让大模型帮你写一篇公众号推文推广你公司新上线的数据分析工具。第一版提示词“帮我写一篇关于我们数据产品的公众号推文。”模型大概率会给你一篇放之四海而皆准的介绍文全是产品功能罗列。第二版提示词按内容生成四要素来设计你是一名企业服务领域的科技媒体编辑。请为我们的数据分析产品写一篇公众号推文目标读者是中小型企业的运营负责人他们对数据工具不熟悉但每天被Excel报表折磨。核心信息是“我们的工具可以自动生成可视化报表不需要会写代码和SQL”。希望读者看完后预约产品演示。文章风格要求偏口语化、用场景故事引入不要一上来就列产品功能讲清楚“它帮用户解决了什么麻烦”。篇幅1200字左右结尾附上预约引导。看到没有第二版和第一版的差别核心就在四个定义目标读者是“被Excel折磨的运营负责人”核心信息是“不需要编码能力”行动目标是“预约演示”风格是“口语化场景故事引入”。这四项信息限定了模型输出的每一个决策用什么样的案例开场、强调什么卖点、用什么语气、导向什么行动。好的内容生成提示词本质上就是在替模型做“选题决策”。内容生成还有一个进阶技巧用“反向约束”提升内容品质。比如明确告诉模型“不要使用以下表达方式”“不要出现以下词语”“不要用夸张形容词”。结合我自己的实测这类反向约束比正向描述“请写得真实一点”要有效得多。模型对“不做什么”的响应往往比对“做什么”更精确。3.2 信息抽取与结构化输出用格式约束让模型“吐出”可用的数据信息抽取是大模型在工程场景里最有价值的应用之一。以前做信息提取靠正则表达式和人工现在只要给模型一篇文章它就能帮你抽出实体、关系、关键字段而且能应对非标准化的文本。但这个场景对输出格式的要求极其严格——格式稍微不合法下游解析程序就崩了。我最常用的方式是双层约束第一层在提示词里明确指定输出格式第二层给一个格式示例。比如我需要从一批IT售后工单文本里提取故障类型、影响范围和处理建议你是一名IT运维支持工程师。下面是客户提交的售后工单内容请从中提取结构化信息并以JSON格式输出。JSON字段要求如下fault_type故障类型从“网络故障”“硬件故障”“软件故障”“账号权限问题”四类中选择、affected_scope影响范围用一句话概括、suggestion处理建议不超过50字、priority优先级取值为高/中/低根据影响范围推断。只输出JSON对象不要输出任何解释性文字。示例格式{fault_type:网络故障,affected_scope:会议室所有终端无法上网,suggestion:检查核心交换机对应端口状态,priority:高}注意我在提示词里做的几个关键动作定义字段名、定义候选值范围、约束长度、明确“只输出JSON”、给出了示例。这套组合下来模型输出的内容几乎不需要二次清洗就能直接喂给程序解析。如果不用这套约束模型的输出会是什么样它可能会在JSON外面包一个代码块、可能会给JSON加一段前言、甚至可能用中文双引号导致解析失败。抽取类任务还有一个容易踩的坑字段候选值描述不精确。比如“故障类型”这个字段如果我不指定候选集模型会按自己的理解分类抽出来的结果五花八门。一旦你把候选值限定为“网络故障/硬件故障/软件故障/账号权限问题”模型的分类行为就和你的业务口径对齐了。这就是我在前面反复说的信息密度越低模型自由发挥的空间就越大。抽取类任务的本质就是通过约束把“自由发挥空间”压到零。另外对于更复杂的抽取任务建议把抽取拆成多个步骤来执行。比如先从一篇长文档里抽关键词再基于关键词生成摘要最后把摘要翻译成多种语言分步输出。一次提问做完所有事效果通常不如分步骤做。原因很简单每一步的输出都是下一步的输入分步执行等于每步都给了模型一次“重新组织信息”的机会。3.3 代码生成与调试把需求说清楚代码才靠得住用大模型写代码并不是新鲜事但很多人抱怨“生成的代码根本跑不通”或者“逻辑不完全符合需求”。我排查过不少类似的情况大部分问题都出在同一处需求描述缺少“边界条件”。模型不是人你如果只说“写一个函数把两个列表合并”它默认用最简单的拼接不会自动去处理重复项、排序问题或者性能要求。写代码提示词的通用结构我认为可以分为四块函数功能、输入输出参数、边界约束、示例调用。看一个具体案例。比如我需要一个“提取URL中所有参数并转为字典”的函数。第一版提示词可能是“用Python写一个解析URL参数的函数。”模型的输出大概率是能用的但它可能不会处理URL编码、不会处理参数重复的情况或者没有返回空字典的兜底逻辑。第二版提示词我会写成这样用Python写一个函数parse_url_params功能是从URL字符串中提取查询参数并转为字典。要求输入参数url为字符串返回值为dictkey为参数名value为参数值参数值需要做URL解码同一参数出现多次时value用list存储没有参数时返回空字典容错处理URL不合法或缺少?的情况。函数写完后再补两个调用示例一个普通场景一个参数重复场景。不要输出其他说明文字。这版提示词里我给模型的每一项要求都在压缩它的“默认行为”空间。模型写代码最常见的失败模式就是“能编过但没考虑边界”而这些边界条件恰恰是提示词里要显式写出来的。实测下来加上边界描述之后模型生成的代码一次通过率会高很多。代码调试场景也很有技巧。当你把一段报错代码扔给模型不建议直接说“帮我看看这段代码有什么问题”更有效的做法是第一说明代码的目标功能第二贴出报错信息第三告诉模型你尝试过的排查方向。比如这段代码的目标是从一个CSV文件里读取数据过滤掉金额小于100的行然后按日期分组求和。运行时出现KeyError: amount。我已经确认CSV表头里确实有amount列。请分析可能的原因并给出修复后的完整代码。注意“我已经确认表头里有这一列”这个信息它直接帮模型排除了一个最明显的排查方向让模型不会在无关方向上浪费算力。给模型的上下文里每多一条“我确认过XX没问题”模型的分析效率就高一分。很多人调试代码时习惯只贴报错不贴自己试过什么模型就不得不自己从头猜结果往往是“正确的废话”——列出十几个可能原因但没有一个深入检查。3.4 复杂推理任务用思维链引导模型一步步想明白数学题、逻辑分析、多条件决策这些都属于复杂推理任务。在这类任务上大模型的表现最不稳定因为你直接问一个难度稍高的数学题它可能给出一个“看起来很有条理但结论错误”的回答。思维链是解决这类问题最有效的手段。基本原则是让模型先把推理步骤写出来再给结论。我们来看一个对比。直接问“一家商店打8折出售商品折后再减免20元顾客实际支付156元原价是多少”这个题本身不难但如果你让模型直接算它有可能在中间步骤出错。改进后的提示词是请按以下步骤解决这个数学问题第一步列出题目中的已知条件第二步设未知数建立等量关系第三步逐步求解第四步把结果代回原题验算。题目一家商店打8折出售商品折后再减免20元顾客实际支付156元原价是多少这个提示词加了两个关键约束一是“按步骤”二是“把结果代回验算”。尤其是验算这一步它能显著降低最终答案的错误率。我在实测中发现很多大模型在做完推理后如果引导它验算一遍它能发现自己前面的计算错误并主动修正。如果不加这一步它很少会自己检查。对于更复杂的逻辑推理类任务更推荐用“分阶段提示词”而不是一口气问完。比如做数据分析报告你可以拆成三个阶段第一阶段让它清洗和归纳数据输出图表的指标第二阶段基于数据做分析给出结论第三阶段把这些结论组织成一份报告。每个阶段的输出作为下一阶段的输入这样既保证了推理质量也让每一环都可检查、可修正。4. 效果评估、迭代调试与常见问题实录4.1 效果评估不是拍脑袋建立自己的分级检查表提示词写完之后怎么判断好不好我见过太多人靠“感觉”——感觉这次输出比上次好一点、感觉这个版本好像更专业。但“感觉”这个东西不稳定同一个提示词今天用和明天用、换一个模型用结论可能就不一样。我推荐大家建立一个分级检查表每次迭代提示词后用同一批测试输入跑一遍逐项打分。我的检查表分为四个维度准确性、格式合规、信息完整度、约束遵循度。准确性指的是回答内容本身正确与否不涉及表述风格格式合规是判断输出是否严格符合你定义的格式比如JSON能不能直接解析信息完整度是看你要求涵盖的内容点是否全部覆盖有没有遗漏约束遵循度是检查模型有没有违返你制定的禁忌比如说了不要用术语结果用了术语或者说了不要超过50字结果写了一大段。每个维度按0到5分打分跑完记录分数每次改动提示词后对比分数变化。这个流程看着笨但长期用下来非常有用。因为提示词迭代最怕的是“为了改而改”你改了一个地方感觉顺眼了但可能在另外一个维度上变差了。打分表能逼你用数据说话而不是凭感觉。我自己实际测试提示词的时候通常准备三到五条不同的测试输入。原因是单条输入验证不了稳定性。如果你的提示词在五条不同输入上都能拿4分以上那才算一个合格的提示词。4.2 我踩过的几个典型“坑”问题、原因、解法这一年多来我自己踩过不少坑也帮别人排查过很多问题挑几个高频的、典型的分享给你们。第一个坑在提示词里用了否定句式但模型总是“反着做”。最典型的例子是“不要提到XXX”结果模型通篇都在围绕XXX展开。原因在于模型对“不要做”的对象反而建立了更高的关注度。我后来的处理方式是把“不要做”改成“请聚焦于YYY”用正面指令替代负面禁令。比如“不要提价格”改成“请重点介绍产品功能和使用场景”效果会好很多。如果确实需要禁止某个内容建议放在提示词最后并使用“如果涉及XXX请跳过不写”这类弱化表达。第二个坑提示词里同时塞了太多要求模型只能“挑重点”执行。上下文容量越大模型就越倾向于选择性地执行其中一部分指令。尤其当要求之间存在隐性冲突时模型会自动排序你认为最重要的那个要求可能恰恰被它忽略了。解决办法是给要求排优先级。我通常的做法是在提示词末尾加一句“以上要求中输出格式为最高优先级其次为不超字数其余要求尽量满足”。这个方法非常管用能让模型在“没法同时满足”时优先保障你最在意的点。第三个坑把提示词写成了“对话记录”长度越来越长但效果反而变差。很多人迭代提示词时习惯在原版上不断追加补充说明结果提示词膨胀到几百个字中间还有一堆前后矛盾的地方。我现在的做法是每次迭代都重写一版干净的提示词而不是在原版上打补丁。把角色、任务、背景、要求、样例分开排版删掉一切“装饰性”的描述比如“请务必认真”“一定要仔细”这类的词它们不会让输出变好只会占用上下文空间。第四个坑以为同一套提示词可以通吃所有模型。不同模型的指令遵循能力差异非常明显同一个提示词在GPT系列、Claude、国产开源模型上表现各不相同。最典型的例子是有的模型对格式约束响应很好有的模型却总在JSON外包一层代码块。我的经验是在正式使用某个模型的提示词之前先拿两三个典型用例跑一遍观察它的“性格”然后针对性地调整提示词。比如对格式遵循弱的模型提示词里就要更多依赖样例而不是描述性规则。4.3 轻量级调试流程建议从60分到90分的迭代路径很多新手拿到提示词写完第一版就急着用效果不好就觉得是模型不行。但根据我的经验提示词的打磨其实是一条很清晰的迭代路径大概三轮左右能把效果从“勉强能用”提到“稳定可靠”。第一轮目标是“跑通”。只验证核心功能是否实现有没有明显的错误。比如你让模型抽取JSON字段这一轮只需要确认“它能输出合法的JSON”。在这个阶段不要纠结细节质量。第二轮目标是“对齐约束”。把你在提示词里设的每一条要求逐一对照输出检查。要求写了的字段有没有都出现候选值是不是严格在限定范围内格式是不是完全合规这一轮做的事情就是找“模型没有遵守的要求”。第三轮目标是“质量优化”。在这个阶段你的提示词逻辑已经没问题了但输出内容可能还不够有深度、不够贴切。这个阶段的优化方向不再是加要求而是加背景信息和高品质的样例。背景信息帮助模型更好地理解语境样例帮助模型对齐你心中的“好”是什么样。这三轮跑完之后如果还有问题大概率就不是提示词的问题了而是要往思路层面调整这个任务是不是设计得太复杂要不要拆分成两步这个信息源是不是就不适合用这个模型来处理记住一个原则提示词调试的目标不是“让模型变聪明”而是“让你要的结果更容易被模型猜中”。每一次迭代都是在降低模型的理解难度。这套方法下来大部分任务的输出效果都会有明显提升。我自己现在写任何提示词前三轮迭代已经是肌肉记忆了。真正的高手不是第一次就写出完美提示词的人而是知道怎么通过系统化调试逼近最优解的人。