提示词工程这个事儿我断断续续研究了大半年踩了不少坑也攒了不少心得。最近在做项目复盘的时候发现很多新手朋友最大的困惑不是“不会写提示词”而是“不知道怎么写才稳定、可复用”。市面上各种技巧分享零零散散什么角色扮演、思维链、少样本示例单个看都有道理凑在一起反而不知道怎么组合。这篇内容算是我自己的一份学习笔记把提示词工程的技巧和常用框架做了系统梳理希望能给同样在摸索的人一些参考。这篇内容适合谁如果你是刚接触大模型应用开发或者已经在日常工作中依赖AI辅助但经常觉得输出不稳定、质量忽高忽低那这篇大概率对你有帮助。我会把技巧背后的原理讲清楚也会给出可以直接抄作业的框架模板和对比案例让你不只知道“怎么问”更知道“为什么这么问”。1. 先解决一个根本问题提示词工程到底在调什么很多人把提示词工程简单理解为“把需求说清楚”实际远不止如此。我在反复实验后意识到提示词本质上是在做一件事控制模型的条件概率分布。大模型本身就是下一个词的概率预测器你给它什么样的上下文它就在什么样的概率空间里采样。提示词工程调的不是模型参数而是采样空间本身。这个认知非常关键。一旦你想明白了这一点很多之前觉得玄学的问题就有了分析框架。比如说为什么加了“让我们一步步思考”之后推理正确率会提升因为这句话把输出分布往后验推理的方向偏移了模型更倾向于生成链式的中间步骤而不是直接跳到最后结论。为什么角色设定有效因为它改变了模型“以谁的口吻、按什么标准”来组织语言等于给输出分布加了一个强约束条件。再往下拆提示词里的信息其实可以分为几个层级指令层你要模型做什么是翻译、总结、改写、分类还是生成代码。上下文层模型需要知道的背景信息、业务场景、数据材料。格式层输出应该长什么样是JSON、Markdown表格还是纯文本分段。约束层不能做什么比如字数限制、禁止编造、必须引用原文等。示例层给出输入输出的范例让模型“照葫芦画瓢”。我之前犯过的错误就是把这些层全混在一起想到哪写到哪。后来发现每次写提示词之前先在脑子里过一遍这五个层级检查有没有缺项输出质量会有本质性提升。这比背十个“万能模板”都管用。还有一个值得注意的点提示词工程和微调的分工。提示词解决的是“模型已经会了但你没有正确引导它展示出来”的问题微调解决的是“模型根本不会这个任务”的问题。如果你发现怎么调提示词输出都在瞎编大概率不是你写提示词的姿势不对而是任务本身就超出了模型的能力边界。这时候就别在提示词上死磕了换个模型或者考虑微调效率更高。2. 五类高频实用的提示词技巧技巧这个东西单独记是记不住的一定得理解它解决了什么问题才能在实际场景中用得出来。我把自己常用到的技巧归纳成五大类每一类都对应一个具体痛点。2.1 角色设定给模型一个“视角锚点”这是最基础也最容易被低估的技巧。很多人的角色设定写得跟“COSPLAY”一样只写了“你是一个文案专家”然后就没有然后了。但真正有效的角色设定必须包含能力边界、语言风格、专业标准、任务目标四个要素。我之前写一段小红书风格的文案用了两种写法对比。第一种“你是一个小红书博主帮我写一篇保湿面霜的种草笔记。”第二种“你是一位有五年护肤经验的小红书博主擅长用日常化语言分享真实体验文案风格偏口语化多用感叹号和emoji重点是让普通女孩觉得‘这个我买得起且真的有用’避免夸大功效宣传。请用40到60字写一篇保湿面霜的种草笔记。”后者的效果明显好于前者不是玄学而是第二种提示词把采样的约束空间压得更小了模型更容易生成符合预期的文本。实操下来角色设定还有一个隐藏作用降低模型“胡说八道”的概率。当角色被限定为“五年经验的护肤博主”时模型对护肤品成分的描述会变得谨慎因为这个角色预期中带着专业背景胡扯会有“身份冲突”。这个机制对垂直领域内容生成非常管用。2.2 少样本示例用“照葫芦画瓢”约束输出少样本示例是目前我用过的最能保证输出格式稳定的方法没有之一。原理很简单模型在预训练中学过海量文本模式你对齐了几个输入输出对之后它会强行去拟合你给的模式。让我印象最深的一次是我要做客服工单分类。当时试了各种描述性的分类规则准确率一直在70%左右徘徊。后来我改成每个分类配两条示例分类规则 - 物流相关涉及快递配送、发货时效、运输异常 - 产品咨询涉及规格参数、使用方式、功能疑问 - 售后申请涉及退货退款、换货维修、补偿诉求 示例 问我的快递都三天了没有任何物流更新怎么回事 答物流相关 问你们的耳机支持双设备连接吗 答产品咨询 问收到货发现包装破损了能换一台吗 答售后申请加了这几个示例之后分类准确率直接上了90%。原因是示例比规则“更具体”模型从示例中归纳出的边界比从抽象文字中理解的边界更贴近你想要的那个。少样本示例有三个关键细节示例要和真实任务同分布、示例数量不要太多3到5个足够、示例之间的差异性要大。如果示例太相似模型会把它们归成同一个模式泛化能力会变差。我见过有人一口气给了20个示例反而把模型搞糊涂了因为示例之间的噪声干扰了模式提取。2.3 思维链让推理过程显性化思维链是我在数学和逻辑推理场景中使用率最高的技巧。它的核心是让模型把隐式的推理过程变成显式的文字步骤本质上是在“引导模型逐步解码”。我做过一个数据验证任务给出一份销售记录和退货记录判断是否对得上。直接问模型“请核对数据是否有出入”模型经常会直接给个“数据一致”或者“存在差异”的结论但说不清楚差异在哪。加上思维链提示之后请逐步核对以下两组数据 1. 先逐项列出每个订单号的销售金额和退货金额 2. 对比两项数值标记出不一致的订单号 3. 汇总差异总金额并得出结论模型给出的答案质量完全变了不仅能指出哪几个订单有问题还能附带计算过程方便我人工复核。这就是思维链的核心价值——它既提升了答案的准确率也让答案变得可验证。思维链还有一个变体叫“零样本思维链”Zero-shot CoT就是加一句简单的“让我们逐步思考”或“请一步一步推理”。这个方法在很多推理类任务上都有奇效。但注意思维链适用于有明确推理链条的任务千万别用在总结归纳类的任务上否则模型会输出一堆没必要的中间步骤反而显得啰嗦。2.4 格式约束让输出“规规矩矩”做应用开发的朋友一定深有体会模型输出格式乱了后面的代码解析直接爆炸。格式约束是提示词工程里最不能偷懒的一环。我的做法是在提示词里明确指定输出结构同时给出一个模板。比如请从以下会议纪要中提取关键信息严格按下面的JSON结构输出不要输出其他任何内容 { 会议时间: , 参会人员: [], 核心议题: , 决议事项: [], 待办任务: [{负责人: , 截止时间: , 内容: }] }这样写比“用JSON输出”管用得多。因为模型对JSON结构有自己的默认理解你不明确的话它可能输出嵌套层级不同、字段名不一致的JSON这会导致下游解析出错。模板一给字段名和结构都被定死了后续代码解析就稳了。格式约束这里有个容易忽视的点给出的示例模板里不要放实际数据。我之前吃过亏在模板里填了一个示例日期“2024-01-15”结果模型输出时原样照抄了这个日期导致数据污染。模板字段保持空值或者用占位符效果会好很多。2.5 任务分解一次只说一件事这个技巧看似简单实际是很多人忽略的“隐形杀手”。我刚开始用大模型的时候喜欢把多个任务塞进一个提示词里比如“请总结这段文章并提取三个关键词然后翻译成英文最后写一句评价”。结果模型往往哪个任务都做得不够好。原因也不复杂多个任务混在一起会分散采样的概率空间。模型在每个子任务上的专注度被稀释了输出质量自然会下降。我现在养成了一个习惯复杂需求先拆成多个独立的提示词调用或者一个主任务带多个明确编号的子任务。如果因为成本或延迟原因必须在一个提示词里完成多任务那就给每个任务编号并明确每个任务对输入的处理方式请依次完成以下三个任务每一步的输出都用“任务一结果”、“任务二结果”、“任务三结果”开头 任务一提取这段话的中心论点 任务二判断该论点是否包含具体数据支撑 任务三将中心论点改写为一句反问句分步指令和统一格式开头的组合能最大限度减少任务间彼此干扰。实测下来比直接堆需求的效果好很多。3. 常用框架深度拆解与选型建议技巧是零件框架是把零件组装起来的方法。这两年网上流行的提示词框架不少我逐个都试用过选几个真正好用的拆开讲讲。3.1 ICE最基础的四要素框架ICE是我用过的最简洁好上手的框架四个字母对应四个要素IInstruction明确指令告诉模型你要干什么。CContext提供背景信息给模型理解任务的足够上下文。EExample给出输入输出示例约束模型的输出风格和结构。这个框架最大的优势是轻量、无脑、容易记。适合那些需求明确、不需要过多花哨技巧的任务。比如写一封邮件、翻译一段话、整理一份会议摘要ICE框架两三分钟就能组装完。我自己用ICE时的一个心得是把Context写充分远比Instruction写得华丽更重要。很多背景信息你觉得模型“应该知道”但大模型的知识截止时间和你不一样你不给它补充它就真的不知道。尤其是涉及你业务内部的术语、缩写、流程时Context写不写到位效果是两倍差距。用一个我常用的模板示意一下I指令把下面的客服对话记录改写为一封升级投诉邮件语气正式且有理有据。 C背景用户已连续两次反映快递损坏客服均只提供优惠券补偿用户要求全额退款。公司关于此类客诉的升级标准是“货物损毁影响使用且客诉不低于两次”。 E示例 输入用户包装全坏了这谁还敢用 输出尊敬的客服团队我的包裹收到时外包装严重破损内物已经受损影响到正常使用这已是第二次出现类似情况……3.2 CRISPE适合复杂需求的分步骤框架CRISPE框架比我上面讲到的ICE重一些但功能也更全。它有五个步骤CRCapacity Role设定模型的能力和角色。IInsight提供背景信息和深层语境。SStatement陈述具体任务和期望结果。PPersonality定义输出风格或个性。EExperiment要求模型给出多个版本或方案再从中迭代。这个框架适合的典型场景是内容创作、方案策划、市场分析报告这类需要“创意发散”的任务。CRISPE的独特之处在于最后那个“Experiment”它会要求模型给出多个备选方案这在做选题、定策略的时候特别好用。我用CRISPE写过一个产品推广方案的策划实际效果确实比直接“帮我想三个推广方案”好很多。因为在“Insight”环节你把竞品情况、目标用户、预算限制都交代清楚了模型产出的方案明显更贴合实际情况而不是泛泛而谈的空话。3.3 APE框架和思维链的配合APE框架非常轻巧只有三个动作AAction做什么。PPurpose为什么做。EExpectation期待什么结果。别小看这三个词它们的本质是在强制你把“任务目标”和“成功标准”说清楚。我发现在很多真实场景里用户自己并没有想清楚“我让AI干这件事是为了什么”导致输出的东西方向就跑偏了。比如“帮我把这篇技术文章翻译成英文”和“帮我把这篇技术文章翻译成英文目的是让海外技术社区读者能快速理解核心架构设计所以术语要准确但句子不必逐字对应可以适当调整为英文母语者的表达习惯”两者的产出质量天差地别。APE和思维链配合使用的效果也很不错。APE管目标对齐思维链管推理过程。比如做数据分析报告时先用APE设定目标分析转化率下降原因再在任务描述里加入“按影响程度从大到小排列可能原因每个原因列出可验证的数据指标”模型给出的推理链条会更扎实。3.4 框架选型对照表光说每个框架好不说怎么选等于白搭。我根据自己的使用体验整理了一张选型对照表可以直接拿来参考框架核心优势最适场景注意短板ICE简洁高效、易上手明确任务的单次生成缺少对复杂需求的结构支撑CRISPE上下文充分、发散性好策略策划、创意方案模板较重不适合简单任务APE目标清晰、防止跑偏跨部门沟通、效果对齐缺少输出格式控制能力思维链推理链路清晰、可验证数据分析、逻辑推理不适用于纯总结类任务自定义模板完全贴合业务高频重复的固定场景需要前期开发调优成本实际上框架服务于场景场景决定框架。每类任务配合一个框架好过任何“万能提示词”。这一点是我多次吃亏后终于搞明白的。4. 实操对比同一个任务三种写法的效果差异技巧和框架讲再多不实操验证一下总觉得缺了点什么。我设计了一个真实的“周报生成”场景用三种不同阶层的提示词写法生成结果直接对比差异。任务背景是我在某项目组负责数据模块本周完成了一个数据接口的联调、处理了线上反馈的两个数据异常、还和算法团队对齐了下周的埋点需求。模型是同一个只改变提示词。4.1 基础写法一句话指令提示词很简单“帮我写一份周报包含这周完成的工作。”模型输出了一堆常见空话比如“推进了项目进展”“完成了相关任务”之类。要用可以但是几乎每个词都得改。这代表了很多人的日常用法——提示词给的信息量太少模型只能用“通用知识”来补全产出自然没有针对性。4.2 进阶写法加入角色和格式约束提示词改成了你是一名数据开发工程师请基于以下周报素材生成一份结构清晰的周报 素材完成了数据接口联调处理了数据异常反馈和算法团队对齐了埋点需求。 要求按本周完成、问题与风险、下周计划三个板块输出每个板块3-5个要点语言简洁。这次的输出比第一版好了一个档次内容条理清晰有板块结构语言也干练。但还是有比较空的部分比如“提升数据稳定性”这种结论性描述太多具体动作不够。这是素材提炼的问题提示词里给了杂乱的素材模型需要自己去判断哪些重要、哪些不重要能力上还不够。4.3 结构化框架写法详细指令加示例第三次的提示词是任务生成一份以结果为导向的项目周报。 角色你是项目组的数据模块负责人熟悉数据链路和数据质量保障工作。 背景本周重点工作内容素材 1. 完成订单数据接口的联调测试修复了两个超时问题联调通过率从75%提升到96%。 2. 处理线上用户反馈的两类异常数据重复下单记录、金额字段缺失排查后确认均为上游清洗逻辑问题已同步修复。 3. 与算法团队对齐了行为埋点的新增需求确认了事件命名规范和上报时机排期在下周二的开发窗口。 要求 - 周报以“结论先行”风格撰写先写结果和影响再写具体动作。 - 每个事项用“结果数据/事实下一步”的结构。 - 语言要具体不要出现“完成了相关工作”这类模糊表述。 - 总字数控制在300字以内。 示例 事项修复订单数据接口超时 结果联调通过率提升至96% 具体动作定位两个超时点调整连接池配置 下一步持续观察稳定运行一周后提交测试报告这次输出质量确实是最高的。模型把素材里的三个事项拆成了三个段落每段都有结果、动作和下一步而且通篇没有空话。更细节的是模型还主动把“重复下单记录、金额字段缺失”做了归类写成“两类数据异常”比我给的素材更精炼。这说明提示词给的约束越完整模型的表现空间被压缩到恰好合适的范围时输出质量是最稳的。4.4 对比结论三层写法的本质差异写法输出质量可用性核心问题一句话指令低基本不可直接使用信息量不足模型用通用知识补全角色格式中少量修改可用结构清晰但细节缺失结构化完整版高基本可提交结果导向、数据支撑、动作清晰这个对比实验结束后我最大的感悟是提示词的质量提高带来的收益不是线性的是指数级的。从基础写法升级到进阶写法质量提升也许只有30%但从进阶写法升级到结构化完整版质量提升可能有50%以上。因为第三个版本里角色、背景、格式、示例、约束全部对齐模型能输出的“模糊空间”已经被压得很小剩下的输出自然就更精准。5. 常见问题与排查技巧实录用了大半年踩过的坑可以绕工位一圈。这里整理出几个最高频的问题附上排查思路和解决方案希望能帮你少走弯路。5.1 现象一输出质量不稳定同一提示词结果忽好忽坏这个问题几乎每个人都遇到过。首先要区分是“随机性”还是“提示词设计缺陷”。大模型解码本身带有采样随机性temperature参数不为0时同样的提示词产生不同输出是正常的。如果不稳定程度在可接受范围内可以先调低temperature值一般0.3到0.5之间可以在稳定性和创造性之间取一个平衡。排除掉随机性之后再审视提示词本身。我用一个原则来排查如果提示词里包含模糊形容词比如“合适”“高质量”“尽可能”那输出的不稳定性大概率来自这里。模型对“高质量”的理解和你对“高质量”的理解可能完全是两回事。解决办法是把模糊要求转化为可衡量的具体描述。比如“高质量的数据分析报告”可以改成“包含数据概览、问题诊断、归因分析、建议方案四个部分每部分有至少一个数据指标支撑”。5.2 现象二格式总是乱字段缺失或结构不对这个在开发场景中出现得最多。常见的三种原因提示词里没有给出严格的格式模板、模板中放了示例数据导致模型照抄、上下文长度超出窗口导致后半部分格式被截断。排查思路按照“格式模板是否给足→模板示例是否污染→上下文是否超窗口”这个顺序依次检查。我之前做日志解析时模型偶尔会输出字段缺失排查了半天最后发现是我给的示例模板里字段顺序和描述里写的不一致模型学着示例里的顺序生成导致程序按描述中的顺序解析时找不到字段。把两边统一之后问题立刻消失。5.3 现象三模型“听不见”你的要求这是最让人头疼的明明在提示词里写了“不要瞎编”模型还是给你编得有模有样。这种问题的本质是模型的指令遵循能力和任务难度之间的落差。你不让它编造但任务本身需要它填补大量空白信息它只能生成一些看似合理的内容来完成任务。应对办法是把“禁止瞎编”变成“要求引用证据”。比如将“不要编造数据”改为“所有数据必须来自提供的材料如果材料中不存在该数据请明确标注‘原文未提及’”。这类带有兜底应答策略的提示词比单纯禁止效果更好。因为模型的任务从“寻找缺失的信息”变成了“识别缺失信息并输出特定标记”后者是更容易完成的任务。5.4 现象四上下文太长成本高且容易被截断长文档处理是另一个高频问题。上下文窗口有限提示词太长不仅成本涨还会让模型“注意力分散”。在长文档摘要场景里我首选的方法是“分块摘要再合并”。先把文档切成多个块每个块单独精炼成摘要再写一个总提示词把各块摘要拼接成完整摘要。这个方法比一次性丢整个文档进去效果更可控也不容易超出上下文窗口。另一个技巧是“压缩背景信息”。比如把一份2000字的项目背景浓缩成“背景某电商平台日单量10万当前转化率2.3%本周重点关心支付环节流失率变化”——这种高度压缩的结构化描述能有效降低token消耗同时不损失关键信息。6. 个人经验提示词工程提升的关键路径最后说点心里话。我见过很多朋友拿着各种“万能提示词模板”到处复制效果不好就觉得是模型不行。但我的经验是提示词工程的关键根本不在模板而在“目标建模能力”。你能不能把脑中的需求拆解成模型能理解的指令、背景、格式、约束这决定了你能不能用好大模型。我自己的进步路径和复盘是这样的第一阶段收集模板对照使用效果时好时坏。第二阶段开始分析模板的结构理解了指令、上下文、示例各自的角色。第三阶段遇到输出质量问题时不再怀疑模板而是从“信息是否充分”“格式是否明确”“约束是否可执行”三个角度自查。第四阶段开始为自己的高频场景定制专属提示词通过少量测试调整达到稳定效果。现在我的日常做法是维持一个“提示词模板库”每个模板都带有适用场景和已知问题说明。每当遇到新任务类型时会先判断它属于新增模板还是复用现有模板。这个习惯帮我节约了大量重复设计提示词的时间。如果你也长期和模型打交道我非常建议从今天开始建设自己的模板库——刚开始可能没什么感觉坚持两三个月后你会发现它的复利效应远超预期。最后分享一个小细节我在每版提示词的末尾都会加一句“如果以上要求与你的实际能力冲突请在开头注明无法执行的原因”。这句话看似鸡肋实际能有效减少模型“生硬完成任务”的概率大幅提升交互效率。这个技巧是我在调试过程中偶然发现的实测很好用。 
长河君 · 2026/10/21 12:55:08 · 阅读 1.2k 提示词工程实战指南：技巧框架与稳定输出方法论
提示词工程这个事儿我断断续续研究了大半年踩了不少坑也攒了不少心得。最近在做项目复盘的时候发现很多新手朋友最大的困惑不是“不会写提示词”而是“不知道怎么写才稳定、可复用”。市面上各种技巧分享零零散散什么角色扮演、思维链、少样本示例单个看都有道理凑在一起反而不知道怎么组合。这篇内容算是我自己的一份学习笔记把提示词工程的技巧和常用框架做了系统梳理希望能给同样在摸索的人一些参考。这篇内容适合谁如果你是刚接触大模型应用开发或者已经在日常工作中依赖AI辅助但经常觉得输出不稳定、质量忽高忽低那这篇大概率对你有帮助。我会把技巧背后的原理讲清楚也会给出可以直接抄作业的框架模板和对比案例让你不只知道“怎么问”更知道“为什么这么问”。1. 先解决一个根本问题提示词工程到底在调什么很多人把提示词工程简单理解为“把需求说清楚”实际远不止如此。我在反复实验后意识到提示词本质上是在做一件事控制模型的条件概率分布。大模型本身就是下一个词的概率预测器你给它什么样的上下文它就在什么样的概率空间里采样。提示词工程调的不是模型参数而是采样空间本身。这个认知非常关键。一旦你想明白了这一点很多之前觉得玄学的问题就有了分析框架。比如说为什么加了“让我们一步步思考”之后推理正确率会提升因为这句话把输出分布往后验推理的方向偏移了模型更倾向于生成链式的中间步骤而不是直接跳到最后结论。为什么角色设定有效因为它改变了模型“以谁的口吻、按什么标准”来组织语言等于给输出分布加了一个强约束条件。再往下拆提示词里的信息其实可以分为几个层级指令层你要模型做什么是翻译、总结、改写、分类还是生成代码。上下文层模型需要知道的背景信息、业务场景、数据材料。格式层输出应该长什么样是JSON、Markdown表格还是纯文本分段。约束层不能做什么比如字数限制、禁止编造、必须引用原文等。示例层给出输入输出的范例让模型“照葫芦画瓢”。我之前犯过的错误就是把这些层全混在一起想到哪写到哪。后来发现每次写提示词之前先在脑子里过一遍这五个层级检查有没有缺项输出质量会有本质性提升。这比背十个“万能模板”都管用。还有一个值得注意的点提示词工程和微调的分工。提示词解决的是“模型已经会了但你没有正确引导它展示出来”的问题微调解决的是“模型根本不会这个任务”的问题。如果你发现怎么调提示词输出都在瞎编大概率不是你写提示词的姿势不对而是任务本身就超出了模型的能力边界。这时候就别在提示词上死磕了换个模型或者考虑微调效率更高。2. 五类高频实用的提示词技巧技巧这个东西单独记是记不住的一定得理解它解决了什么问题才能在实际场景中用得出来。我把自己常用到的技巧归纳成五大类每一类都对应一个具体痛点。2.1 角色设定给模型一个“视角锚点”这是最基础也最容易被低估的技巧。很多人的角色设定写得跟“COSPLAY”一样只写了“你是一个文案专家”然后就没有然后了。但真正有效的角色设定必须包含能力边界、语言风格、专业标准、任务目标四个要素。我之前写一段小红书风格的文案用了两种写法对比。第一种“你是一个小红书博主帮我写一篇保湿面霜的种草笔记。”第二种“你是一位有五年护肤经验的小红书博主擅长用日常化语言分享真实体验文案风格偏口语化多用感叹号和emoji重点是让普通女孩觉得‘这个我买得起且真的有用’避免夸大功效宣传。请用40到60字写一篇保湿面霜的种草笔记。”后者的效果明显好于前者不是玄学而是第二种提示词把采样的约束空间压得更小了模型更容易生成符合预期的文本。实操下来角色设定还有一个隐藏作用降低模型“胡说八道”的概率。当角色被限定为“五年经验的护肤博主”时模型对护肤品成分的描述会变得谨慎因为这个角色预期中带着专业背景胡扯会有“身份冲突”。这个机制对垂直领域内容生成非常管用。2.2 少样本示例用“照葫芦画瓢”约束输出少样本示例是目前我用过的最能保证输出格式稳定的方法没有之一。原理很简单模型在预训练中学过海量文本模式你对齐了几个输入输出对之后它会强行去拟合你给的模式。让我印象最深的一次是我要做客服工单分类。当时试了各种描述性的分类规则准确率一直在70%左右徘徊。后来我改成每个分类配两条示例分类规则 - 物流相关涉及快递配送、发货时效、运输异常 - 产品咨询涉及规格参数、使用方式、功能疑问 - 售后申请涉及退货退款、换货维修、补偿诉求 示例 问我的快递都三天了没有任何物流更新怎么回事 答物流相关 问你们的耳机支持双设备连接吗 答产品咨询 问收到货发现包装破损了能换一台吗 答售后申请加了这几个示例之后分类准确率直接上了90%。原因是示例比规则“更具体”模型从示例中归纳出的边界比从抽象文字中理解的边界更贴近你想要的那个。少样本示例有三个关键细节示例要和真实任务同分布、示例数量不要太多3到5个足够、示例之间的差异性要大。如果示例太相似模型会把它们归成同一个模式泛化能力会变差。我见过有人一口气给了20个示例反而把模型搞糊涂了因为示例之间的噪声干扰了模式提取。2.3 思维链让推理过程显性化思维链是我在数学和逻辑推理场景中使用率最高的技巧。它的核心是让模型把隐式的推理过程变成显式的文字步骤本质上是在“引导模型逐步解码”。我做过一个数据验证任务给出一份销售记录和退货记录判断是否对得上。直接问模型“请核对数据是否有出入”模型经常会直接给个“数据一致”或者“存在差异”的结论但说不清楚差异在哪。加上思维链提示之后请逐步核对以下两组数据 1. 先逐项列出每个订单号的销售金额和退货金额 2. 对比两项数值标记出不一致的订单号 3. 汇总差异总金额并得出结论模型给出的答案质量完全变了不仅能指出哪几个订单有问题还能附带计算过程方便我人工复核。这就是思维链的核心价值——它既提升了答案的准确率也让答案变得可验证。思维链还有一个变体叫“零样本思维链”Zero-shot CoT就是加一句简单的“让我们逐步思考”或“请一步一步推理”。这个方法在很多推理类任务上都有奇效。但注意思维链适用于有明确推理链条的任务千万别用在总结归纳类的任务上否则模型会输出一堆没必要的中间步骤反而显得啰嗦。2.4 格式约束让输出“规规矩矩”做应用开发的朋友一定深有体会模型输出格式乱了后面的代码解析直接爆炸。格式约束是提示词工程里最不能偷懒的一环。我的做法是在提示词里明确指定输出结构同时给出一个模板。比如请从以下会议纪要中提取关键信息严格按下面的JSON结构输出不要输出其他任何内容 { 会议时间: , 参会人员: [], 核心议题: , 决议事项: [], 待办任务: [{负责人: , 截止时间: , 内容: }] }这样写比“用JSON输出”管用得多。因为模型对JSON结构有自己的默认理解你不明确的话它可能输出嵌套层级不同、字段名不一致的JSON这会导致下游解析出错。模板一给字段名和结构都被定死了后续代码解析就稳了。格式约束这里有个容易忽视的点给出的示例模板里不要放实际数据。我之前吃过亏在模板里填了一个示例日期“2024-01-15”结果模型输出时原样照抄了这个日期导致数据污染。模板字段保持空值或者用占位符效果会好很多。2.5 任务分解一次只说一件事这个技巧看似简单实际是很多人忽略的“隐形杀手”。我刚开始用大模型的时候喜欢把多个任务塞进一个提示词里比如“请总结这段文章并提取三个关键词然后翻译成英文最后写一句评价”。结果模型往往哪个任务都做得不够好。原因也不复杂多个任务混在一起会分散采样的概率空间。模型在每个子任务上的专注度被稀释了输出质量自然会下降。我现在养成了一个习惯复杂需求先拆成多个独立的提示词调用或者一个主任务带多个明确编号的子任务。如果因为成本或延迟原因必须在一个提示词里完成多任务那就给每个任务编号并明确每个任务对输入的处理方式请依次完成以下三个任务每一步的输出都用“任务一结果”、“任务二结果”、“任务三结果”开头 任务一提取这段话的中心论点 任务二判断该论点是否包含具体数据支撑 任务三将中心论点改写为一句反问句分步指令和统一格式开头的组合能最大限度减少任务间彼此干扰。实测下来比直接堆需求的效果好很多。3. 常用框架深度拆解与选型建议技巧是零件框架是把零件组装起来的方法。这两年网上流行的提示词框架不少我逐个都试用过选几个真正好用的拆开讲讲。3.1 ICE最基础的四要素框架ICE是我用过的最简洁好上手的框架四个字母对应四个要素IInstruction明确指令告诉模型你要干什么。CContext提供背景信息给模型理解任务的足够上下文。EExample给出输入输出示例约束模型的输出风格和结构。这个框架最大的优势是轻量、无脑、容易记。适合那些需求明确、不需要过多花哨技巧的任务。比如写一封邮件、翻译一段话、整理一份会议摘要ICE框架两三分钟就能组装完。我自己用ICE时的一个心得是把Context写充分远比Instruction写得华丽更重要。很多背景信息你觉得模型“应该知道”但大模型的知识截止时间和你不一样你不给它补充它就真的不知道。尤其是涉及你业务内部的术语、缩写、流程时Context写不写到位效果是两倍差距。用一个我常用的模板示意一下I指令把下面的客服对话记录改写为一封升级投诉邮件语气正式且有理有据。 C背景用户已连续两次反映快递损坏客服均只提供优惠券补偿用户要求全额退款。公司关于此类客诉的升级标准是“货物损毁影响使用且客诉不低于两次”。 E示例 输入用户包装全坏了这谁还敢用 输出尊敬的客服团队我的包裹收到时外包装严重破损内物已经受损影响到正常使用这已是第二次出现类似情况……3.2 CRISPE适合复杂需求的分步骤框架CRISPE框架比我上面讲到的ICE重一些但功能也更全。它有五个步骤CRCapacity Role设定模型的能力和角色。IInsight提供背景信息和深层语境。SStatement陈述具体任务和期望结果。PPersonality定义输出风格或个性。EExperiment要求模型给出多个版本或方案再从中迭代。这个框架适合的典型场景是内容创作、方案策划、市场分析报告这类需要“创意发散”的任务。CRISPE的独特之处在于最后那个“Experiment”它会要求模型给出多个备选方案这在做选题、定策略的时候特别好用。我用CRISPE写过一个产品推广方案的策划实际效果确实比直接“帮我想三个推广方案”好很多。因为在“Insight”环节你把竞品情况、目标用户、预算限制都交代清楚了模型产出的方案明显更贴合实际情况而不是泛泛而谈的空话。3.3 APE框架和思维链的配合APE框架非常轻巧只有三个动作AAction做什么。PPurpose为什么做。EExpectation期待什么结果。别小看这三个词它们的本质是在强制你把“任务目标”和“成功标准”说清楚。我发现在很多真实场景里用户自己并没有想清楚“我让AI干这件事是为了什么”导致输出的东西方向就跑偏了。比如“帮我把这篇技术文章翻译成英文”和“帮我把这篇技术文章翻译成英文目的是让海外技术社区读者能快速理解核心架构设计所以术语要准确但句子不必逐字对应可以适当调整为英文母语者的表达习惯”两者的产出质量天差地别。APE和思维链配合使用的效果也很不错。APE管目标对齐思维链管推理过程。比如做数据分析报告时先用APE设定目标分析转化率下降原因再在任务描述里加入“按影响程度从大到小排列可能原因每个原因列出可验证的数据指标”模型给出的推理链条会更扎实。3.4 框架选型对照表光说每个框架好不说怎么选等于白搭。我根据自己的使用体验整理了一张选型对照表可以直接拿来参考框架核心优势最适场景注意短板ICE简洁高效、易上手明确任务的单次生成缺少对复杂需求的结构支撑CRISPE上下文充分、发散性好策略策划、创意方案模板较重不适合简单任务APE目标清晰、防止跑偏跨部门沟通、效果对齐缺少输出格式控制能力思维链推理链路清晰、可验证数据分析、逻辑推理不适用于纯总结类任务自定义模板完全贴合业务高频重复的固定场景需要前期开发调优成本实际上框架服务于场景场景决定框架。每类任务配合一个框架好过任何“万能提示词”。这一点是我多次吃亏后终于搞明白的。4. 实操对比同一个任务三种写法的效果差异技巧和框架讲再多不实操验证一下总觉得缺了点什么。我设计了一个真实的“周报生成”场景用三种不同阶层的提示词写法生成结果直接对比差异。任务背景是我在某项目组负责数据模块本周完成了一个数据接口的联调、处理了线上反馈的两个数据异常、还和算法团队对齐了下周的埋点需求。模型是同一个只改变提示词。4.1 基础写法一句话指令提示词很简单“帮我写一份周报包含这周完成的工作。”模型输出了一堆常见空话比如“推进了项目进展”“完成了相关任务”之类。要用可以但是几乎每个词都得改。这代表了很多人的日常用法——提示词给的信息量太少模型只能用“通用知识”来补全产出自然没有针对性。4.2 进阶写法加入角色和格式约束提示词改成了你是一名数据开发工程师请基于以下周报素材生成一份结构清晰的周报 素材完成了数据接口联调处理了数据异常反馈和算法团队对齐了埋点需求。 要求按本周完成、问题与风险、下周计划三个板块输出每个板块3-5个要点语言简洁。这次的输出比第一版好了一个档次内容条理清晰有板块结构语言也干练。但还是有比较空的部分比如“提升数据稳定性”这种结论性描述太多具体动作不够。这是素材提炼的问题提示词里给了杂乱的素材模型需要自己去判断哪些重要、哪些不重要能力上还不够。4.3 结构化框架写法详细指令加示例第三次的提示词是任务生成一份以结果为导向的项目周报。 角色你是项目组的数据模块负责人熟悉数据链路和数据质量保障工作。 背景本周重点工作内容素材 1. 完成订单数据接口的联调测试修复了两个超时问题联调通过率从75%提升到96%。 2. 处理线上用户反馈的两类异常数据重复下单记录、金额字段缺失排查后确认均为上游清洗逻辑问题已同步修复。 3. 与算法团队对齐了行为埋点的新增需求确认了事件命名规范和上报时机排期在下周二的开发窗口。 要求 - 周报以“结论先行”风格撰写先写结果和影响再写具体动作。 - 每个事项用“结果数据/事实下一步”的结构。 - 语言要具体不要出现“完成了相关工作”这类模糊表述。 - 总字数控制在300字以内。 示例 事项修复订单数据接口超时 结果联调通过率提升至96% 具体动作定位两个超时点调整连接池配置 下一步持续观察稳定运行一周后提交测试报告这次输出质量确实是最高的。模型把素材里的三个事项拆成了三个段落每段都有结果、动作和下一步而且通篇没有空话。更细节的是模型还主动把“重复下单记录、金额字段缺失”做了归类写成“两类数据异常”比我给的素材更精炼。这说明提示词给的约束越完整模型的表现空间被压缩到恰好合适的范围时输出质量是最稳的。4.4 对比结论三层写法的本质差异写法输出质量可用性核心问题一句话指令低基本不可直接使用信息量不足模型用通用知识补全角色格式中少量修改可用结构清晰但细节缺失结构化完整版高基本可提交结果导向、数据支撑、动作清晰这个对比实验结束后我最大的感悟是提示词的质量提高带来的收益不是线性的是指数级的。从基础写法升级到进阶写法质量提升也许只有30%但从进阶写法升级到结构化完整版质量提升可能有50%以上。因为第三个版本里角色、背景、格式、示例、约束全部对齐模型能输出的“模糊空间”已经被压得很小剩下的输出自然就更精准。5. 常见问题与排查技巧实录用了大半年踩过的坑可以绕工位一圈。这里整理出几个最高频的问题附上排查思路和解决方案希望能帮你少走弯路。5.1 现象一输出质量不稳定同一提示词结果忽好忽坏这个问题几乎每个人都遇到过。首先要区分是“随机性”还是“提示词设计缺陷”。大模型解码本身带有采样随机性temperature参数不为0时同样的提示词产生不同输出是正常的。如果不稳定程度在可接受范围内可以先调低temperature值一般0.3到0.5之间可以在稳定性和创造性之间取一个平衡。排除掉随机性之后再审视提示词本身。我用一个原则来排查如果提示词里包含模糊形容词比如“合适”“高质量”“尽可能”那输出的不稳定性大概率来自这里。模型对“高质量”的理解和你对“高质量”的理解可能完全是两回事。解决办法是把模糊要求转化为可衡量的具体描述。比如“高质量的数据分析报告”可以改成“包含数据概览、问题诊断、归因分析、建议方案四个部分每部分有至少一个数据指标支撑”。5.2 现象二格式总是乱字段缺失或结构不对这个在开发场景中出现得最多。常见的三种原因提示词里没有给出严格的格式模板、模板中放了示例数据导致模型照抄、上下文长度超出窗口导致后半部分格式被截断。排查思路按照“格式模板是否给足→模板示例是否污染→上下文是否超窗口”这个顺序依次检查。我之前做日志解析时模型偶尔会输出字段缺失排查了半天最后发现是我给的示例模板里字段顺序和描述里写的不一致模型学着示例里的顺序生成导致程序按描述中的顺序解析时找不到字段。把两边统一之后问题立刻消失。5.3 现象三模型“听不见”你的要求这是最让人头疼的明明在提示词里写了“不要瞎编”模型还是给你编得有模有样。这种问题的本质是模型的指令遵循能力和任务难度之间的落差。你不让它编造但任务本身需要它填补大量空白信息它只能生成一些看似合理的内容来完成任务。应对办法是把“禁止瞎编”变成“要求引用证据”。比如将“不要编造数据”改为“所有数据必须来自提供的材料如果材料中不存在该数据请明确标注‘原文未提及’”。这类带有兜底应答策略的提示词比单纯禁止效果更好。因为模型的任务从“寻找缺失的信息”变成了“识别缺失信息并输出特定标记”后者是更容易完成的任务。5.4 现象四上下文太长成本高且容易被截断长文档处理是另一个高频问题。上下文窗口有限提示词太长不仅成本涨还会让模型“注意力分散”。在长文档摘要场景里我首选的方法是“分块摘要再合并”。先把文档切成多个块每个块单独精炼成摘要再写一个总提示词把各块摘要拼接成完整摘要。这个方法比一次性丢整个文档进去效果更可控也不容易超出上下文窗口。另一个技巧是“压缩背景信息”。比如把一份2000字的项目背景浓缩成“背景某电商平台日单量10万当前转化率2.3%本周重点关心支付环节流失率变化”——这种高度压缩的结构化描述能有效降低token消耗同时不损失关键信息。6. 个人经验提示词工程提升的关键路径最后说点心里话。我见过很多朋友拿着各种“万能提示词模板”到处复制效果不好就觉得是模型不行。但我的经验是提示词工程的关键根本不在模板而在“目标建模能力”。你能不能把脑中的需求拆解成模型能理解的指令、背景、格式、约束这决定了你能不能用好大模型。我自己的进步路径和复盘是这样的第一阶段收集模板对照使用效果时好时坏。第二阶段开始分析模板的结构理解了指令、上下文、示例各自的角色。第三阶段遇到输出质量问题时不再怀疑模板而是从“信息是否充分”“格式是否明确”“约束是否可执行”三个角度自查。第四阶段开始为自己的高频场景定制专属提示词通过少量测试调整达到稳定效果。现在我的日常做法是维持一个“提示词模板库”每个模板都带有适用场景和已知问题说明。每当遇到新任务类型时会先判断它属于新增模板还是复用现有模板。这个习惯帮我节约了大量重复设计提示词的时间。如果你也长期和模型打交道我非常建议从今天开始建设自己的模板库——刚开始可能没什么感觉坚持两三个月后你会发现它的复利效应远超预期。最后分享一个小细节我在每版提示词的末尾都会加一句“如果以上要求与你的实际能力冲突请在开头注明无法执行的原因”。这句话看似鸡肋实际能有效减少模型“生硬完成任务”的概率大幅提升交互效率。这个技巧是我在调试过程中偶然发现的实测很好用。