★ FEATURED ARTICLE 开门见山说一句把大模型用好真正的分水岭不在模型选得有多新而在提示工程做得有多扎实。这些年我接手过不少大模型实战项目也带过团队发现一个非常普遍的现象同一位开发者用同一个模型写提示的方式不同产出质量能差出好几倍。提示工程不是网上传的“念几句咒语”它是一套可以被学习、被复现、被迭代的方法也是目前普通人驾驭大模型投入产出比最高的技能。这篇文章不聊虚的主要讲清楚三件事提示词为什么能改变模型输出、一套结构化提示词怎么写、遇到模型不听话时怎么排查和修正。无论你是做研发、做产品、做运营还是纯粹想用大模型提效率的内容创作者这篇文章都值得你花二十分钟读完。先说一个我常跟团队打的比方。大模型就像一个知识面极广但极度依赖指令的同事你只跟他说“把方案写了”他大概率会交给你一份四平八稳但毫无亮点的东西你告诉他目标、受众、结构、风格、禁忌和参考样例他就能交出一份接近可用的初稿。提示工程干的事情就是把需求从“随口一提”变成“结构化任务书”。这话听着简单做起来有大量细节下面我从原理到实操一层层拆开讲。1. 为什么提示工程是大模型实战的第一道门槛1.1 提示工程到底是什么一句话版本提示工程是通过设计输入给模型的自然语言指令来稳定、可控地激发模型能力的技术。很多人第一次用大模型觉得这东西“有手就行”能打字就能用。确实使用门槛很低但“能用”和“用好”是两回事。早期的模型能力有限随便问和精心设计提示差距没那么明显现在的模型能力上来了反而更考验使用者的表达水平。就像一辆动力很强的车排量摆在那但你能不能把这股动力平顺地发挥出来取决于驾驶技术。提示就是你的方向盘和油门。我在实际项目中会把提示词当成“需求文档”来看待。一份好的需求文档要有背景、目标、范围、验收标准、注意事项一份好的提示词同样要有任务指令、上下文信息、输出格式、约束条件和参考样例。把这几样写清楚模型才能稳定输出你想要的东西。1.2 模型越强越考验“问问题”的水平我做过一个粗糙但很有说服力的对比测试随便挑了二十个日常任务包括写周报、提炼会议纪要、生成SQL、分析数据、给产品起名等一半用非常口语化的提问比如“帮我写个周报”一半用结构化的完整提示。同样跑一遍结构化提示的一次通过率比口语化提问高出一倍以上而且输出内容的可用性差距很大。口语化提问得到的回答常常要二次修改结构化提示得到的回答基本贴脸可用。这里有个值得注意的趋势模型的基础能力在快速提升但提示工程的杠杆作用没有变小反而变大了。原因很简单模型越强它能完成的任务跨度越大如果你给的信息足够清楚它就能把更强的能力发挥出来反过来指令模糊它能力再强也只能靠猜。猜对了算运气猜错了你还要返工。从投入产出来看提示工程也是性价比最高的方向。它不需要你懂模型训练不需要标注数据不需要部署复杂框架只需要你把自然语言表达这件事做到极致。对一个团队来说花两周时间把核心成员的提示工程水平拉齐比换一个更大的模型带来的收益往往更明显。1.3 先认清提示的边界才不会被反噬强调提示工程重要不代表它是万能的。我见过一些人误以为“只要提示写得好什么都能搞定”结果踩坑之后反过来抱怨大模型不行。提示工程的边界最好提前说清楚。提示词改变不了三样东西一是模型训练时的知识截止时间它不知道截止日期之后的新事件二是模型本身的推理上限一个模型如果原本就解不出某类复杂数学题提示写得再花哨也没用三是模型没有外部实时信息除非你另外接上检索工具或外部数据源。提示工程能做到的是把模型已经具备的能力稳定地激发出来控制它输出的格式和风格引导它使用更可靠的推理路径并在一定程度上抑制幻觉和错误。所以正确的心态是提示工程能帮你把模型的能力用到八成以上但不能无中生有地创造模型不具备的能力。理解了这一点你才能真正把精力花在“通过提示把需求表达清楚”上而不是对着模型念咒语。2. 提示词结构化把需求说清楚的底层框架2.1 建议所有提示词都包含的五个部件我拆解过大量实战效果稳定的提示词发现它们基本都离不开五个部件角色、背景、任务指令、输出规则、参考示例。角色告诉模型“你现在以什么身份来回答”比如“你是一名有十年经验的资深数据库工程师”。背景补充任务相关的前置信息包括目标读者是谁、这个任务用在什么场景、你已经做过哪些尝试。任务指令用一两句话把要模型做的事情说清楚比如“请从以下会议记录中提炼出行动项”。输出规则规定回答的结构、格式、长度、语言风格、不能出现什么。参考示例给一个“输入什么、期望输出什么”的样例帮助模型对齐你的期望。不是所有任务都要写满五件套。任务越复杂、越重要越值得把五个部件补全简单任务比如“把这段话润色得更口语化”只需要任务指令加一句输出规则就够了。但只要你遇到一次“输出完全跑偏”的情况大概率就是这五件套里缺了某一块。2.2 角色与背景到底怎么写才有效角色设定的作用是引导模型调用特定领域的词汇、思维方式和表达习惯。同一句话你让“你是AI助手”去回答和让“你是一名专注于企业服务领域的资深产品顾问”去回答后者给出的用词、分析维度、结论颗粒度都会明显更专业。这不是玄学而是模型在训练阶段学习过大量不同角色的语料角色设定相当于帮它选择了更合适的“说话频道”。我自己测试下来角色写得越具体效果越明显。比如“你是有十年企业数字化转型咨询经验的专家”就比“你是专家”要好。但注意不要过度堆砌头衔一大串“资深的、顶级的、业界知名的”反而会让模型输出油腔滑调。写角色时也要和任务匹配你让模型写代码就别给它设置“文学评论家”的角色这是常识但在实际提示词里经常能看到这种错位。背景信息的作用是减少模型猜谜的空间。我曾经让模型写一份“市场推广方案”结果它默认目标受众是C端用户产出的方案完全不适用因为这是个B端SaaS产品发布会。后来我在背景里明确写上“产品是面向企业客户的办公协同软件推广对象是企业IT负责人预算约十万元周期一个月”产出立刻就可用了。背景信息里最值钱的内容是谁在用、解决什么问题、用什么口径、有哪些限制条件。2.3 输出规则把模型的回答从“可用”变“好用”很多人写提示词只写了任务忘了写输出规则模型就按照它最习惯的“总分总”文章结构给出一大段正确的废话。输出规则至少应该包含三点格式、长度、风格。格式方面你可以要求“用Markdown表格输出”“按JSON格式返回”“每一条要点前面加序号”等等。这里有一个小技巧如果你需要结构化程度很高的输出直接给模型一个模板让它填比用语言描述格式高效得多。比如做信息提取你给它一个JSON样例它就能照着样例输出。长度方面与其说“写短一点”不如给具体约束。“控制在300字以内”“每条不超过一百字”“只输出结论不输出过程”效果都要比模糊的“简洁一点”好得多。风格方面也是如此你可以要求“使用口语化表达”“避免‘首先其次再次’式结构”“每一段都用一个生活化类比开头”这些规则会让输出明显更有个性。我强烈建议在输出规则里加上“不做的事”。比如“不要道歉”“不要解释你的思路”“不要输出与结论无关的内容”。模型有个毛病特别喜欢在前面加一句“作为一名AI助手我无法……”或者在回答结束后来一段总结升华这些都可以用明确的“不做清单”压掉。2.4 用分隔符和结构标记降低指令混淆当提示词里既有背景、又有资料、又有好几条要求时模型有时会搞不清哪些是“要处理的内容”、哪些是“要执行的指令”。一个简单且有效的做法是用明确的标记把不同区块分隔开。比如我常用的模板是请完成以下任务。 ### 任务 写一段200字以内的产品功能说明。 ### 背景 产品是一款面向企业用户的在线表单工具用户多为行政和人事人员非技术背景。 ### 要求 - 说明“表单逻辑设置”这个功能的价值 - 用生活化类比解释 - 不要使用专业术语 - 输出只包含正文不要标题。 ### 参考样例 这里放一段你期望风格相近的文字我用###这样的符号而不是仅仅换行是为了让模型更明确地识别“指令边界”。你还可以用三引号把参考资料包起来用破折号分割不同章节。对于超过一个屏幕的长提示这些标记能明显减少“模型把指令和资料混在一起”的情况。另外有一个容易被忽略的点提示词越长指令越容易被淹没在中间位置所以最重要的任务指令要么放在最前面要么放在最后面尽量别卡在中间。3. 实战五个高频场景的提示词方案3.1 内容创作场景从“正确的废话”到可用初稿内容创作是大模型最常用的场景之一但也是“正确的废话”重灾区。直接说“帮我写一篇公众号推文”模型通常会给你一篇结构工整、内容空洞的文章。我用来救场的提示词框架大致是这样你是一名资深自媒体编辑公众号主攻职场效率方向读者是25-35岁职场白领。 请围绕“高效开晨会”这个话题写一篇公众号推文初稿。 要求 1. 标题给出3个候选风格要有反差 2. 开头100字内直接抛出一个让读者有共鸣的场景 3. 正文分3个部分每部分先给操作步骤再配一个反例和正例的对比 4. 每个部分结尾用一句话总结 5. 语气口语化不要用“总而言之”这类总结词 6. 全文1200字左右。 参考风格 粘贴一段你平时觉得不错的文章开头这个提示的关键在于既定义了读者画像又锁定了结构还给出风格锚点。很多人写内容类提示时只关心“写什么主题”不关心“写给谁、什么结构、什么语气”模型就只能按它默认的方式输出。另外初稿是用来改的别指望模型一稿定型。我会在初稿基础上继续发几个迭代指令比如“第二部分的例子换成财务人员工作场景”“结尾加一句行动号召”这样出来的稿子已经接近可直接发布的水平。3.2 代码生成与调试场景让模型先分析原因再动手让大模型写代码最忌讳的是直接甩一段报错让它“修复”。模型经常不分析原因直接给你一个表面能过、实际埋雷的改动。我在代码类提示中会强制加入两个步骤先解释问题根因再给出修改后的代码。你是一名资深后端开发工程师。 请分析下面这段Python代码中存在的问题并修复它。 ### 代码 粘贴你的代码 ### 报错信息 粘贴完整报错栈 ### 环境 Python 3.10使用pandas 2.0运行在Linux服务器。 ### 要求 1. 先列出可能导致报错的3个原因并说明哪个最可能 2. 给出修复后的完整代码只输出代码块不要额外解释 3. 如果修复涉及外部依赖变化额外用一行说明 4. 不要修改原始函数的签名。“先列出可能原因再给代码”这个设计是为了逼模型走一遍推理而不是凭检索凑答案。我在实践中发现只要加上这一步修复正确率明显提升。还有一个细节务必提供代码运行环境和依赖库版本。模型对版本差异很敏感明明是新版API移除了某个参数它可能还在给你旧版写法。调试场景还有一个容易踩的坑不要一次性塞入几百行代码让模型“找问题”。模型处理超长代码时会顾此失彼建议只保留相关的函数和调用点把无关的初始化过程用注释代替。你帮模型减轻负担模型才能帮你看清问题。3.3 数据分析场景先算后说结论要有依据让模型从一堆数据里找洞察很容易得到“销售额逐月上升说明业务增长良好”这类正确但无用的结论。真正有用的分析提示必须要求模型“先给出计算依据再给出结论”并且明确数据口径。你是一名商业数据分析师。 以下是某电商店铺近6个月的订单数据字段包括日期、订单量、销售额、客单价。 ### 数据 粘贴CSV格式数据 请完成以下分析 1. 按月汇总订单量、销售额、客单价并计算环比变化率 2. 指出变化最明显的月份并分析可能与哪些因素相关 3. 基于数据给出3条可执行的经营建议 4. 每条结论必须标注依据哪一行数据得出禁止编造数据。 ### 输出格式 表格展示汇总结果后面用列表给出结论和建议。这里有一条铁律所有结论必须和输入数据对得上号。模型在生成文本时天然倾向于“顺滑表达”如果数据给得不完整它会自己脑补数字。通过在提示里强制“必须标注数据依据”能显著降低这种幻觉。顺便说一句很多人在分析场景犯的错是给模型一堆原始数据却不告诉它“什么是关键指标”。你可以在提示里帮它圈定重点“重点关注客单价的环比变化因为最近有调价动作”——这个前置信息往往比任何参数调节都管用。3.4 信息提取场景用字段清单逼模型交出结构化结果合同、简历、病例、工单、评论……这些非结构化文本里提取信息是大模型最拿手的任务之一前提是你把“要提取哪些字段”定义得足够清楚。你是一名信息抽取引擎。 从下面这份会议纪要中提取结构化信息只输出JSON不要输出其他内容。 ### 会议纪要 粘贴文本 ### 需要提取的字段 - meeting_topic会议主题字符串 - date会议日期格式YYYY-MM-DD缺失则填空字符串 - participants参会人姓名列表数组 - decisions决策事项列表每个元素包含“content”和“owner”两个字段 - action_items行动项列表每个元素包含“task”“assignee”“due_date”三个字段 - risks风险列表数组无风险则返回空数组 ### 输出格式 严格按以下JSON结构返回不要添加JSON以外的任何内容 { meeting_topic: , date: , participants: [], decisions: [], action_items: [], risks: [] }这个方案的核心是“把字段数据结构化给到模型”。你不需要教它什么是JSON只要给出清晰的字段定义和示例结构它就能稳定输出。我在多个合同提取项目里都用这套写法准确率比一开始“帮我提取一下重点信息”要高得多。需要注意两个坑。第一长文本可能超窗口模型只看到头尾就丢失中间内容。解决办法是分段提取再合并或者先让模型做分块摘要再对摘要做最终提取。第二提取结果必须做校验。模型偶尔会输出非法的JSON少个逗号、多个字段都发生过。稳妥的做法是把模型输出接入一个JSON解析器解析失败就重试一次重试时把“上一次输出非法JSON”作为错误信息反馈给它模型通常会自己修正。3.5 复杂推理场景让模型把推导过程明明白白写出来遇到逻辑推理、数学题、策略分析这类任务最怕模型“一口报答案”。它在生成时是按概率逐词预测的跳过中间推理直接给答案非常容易错。让模型把推导过程一步步写出来相当于强制它多走几步路正确率会明显上升。请解决以下问题。在输出最终答案之前先一步一步地写下你的推理过程。 ### 问题 某公司有三个部门A部门人数是B部门的2倍C部门比B部门多5人。三个部门总人数为45人。问B部门有多少人 ### 要求 1. 先列方程再逐步计算 2. 推导过程写完后空一行输出最终答案格式为“答案XX” 3. 如果过程中发现矛盾单独标注。这种“先过程后结论”的写法在处理分析类任务时同样适用。比如让模型给你一份产品改进建议你可以要求它“先列出用户反馈中出现的5类问题及证据再排序最后给改进建议”这样它就没办法直接编一个看似合理的结论。另外我还常用一招叫“自我验证”在提示的最后加上一句“完成之后请检查你的推导过程是否存在逻辑漏洞如果有修正后再输出”。就这么简单的一句话常常能让模型自己发现并纠正错误。当然它不能保证百分之百正确但它能有效减少那些“一眼假”的错误。4. 参数调节提示词之外的半张控制面板4.1 temperature创意与稳定的旋钮提示词决定了模型“往哪个方向跑”参数则决定了它“跑得多稳、多野”。其中最常用的是temperature你可以把它理解为“混乱程度旋钮”。temperature的常见取值在0到1之间有的接口允许更高。数值越低模型越倾向于选择概率最高的下一个词输出更稳定、更可预测适合代码生成、信息提取、数学计算这类追求准确的任务数值越高模型越愿意选概率不那么高的词输出更多样、更有惊喜感适合头脑风暴、文案创作、起名这类任务。我的经验值信息提取和代码任务设在0.1以下最好直接设0以获得确定性输出常规写作和润色设在0.5到0.7需要创意发散时可以设到0.8到1.0但要有心理准备它可能给你一句惊艳的句子也可能给你一段偏离主题的废话。记住一句话高temperature不等于高质量它只是高随机。如果你发现模型输出“很嗨但很空”先检查temperature是不是调太高了。4.2 top_p核采样另一个随机性开关top_p是另一种控制随机性的参数它的含义是采样时只从累积概率达到某个阈值的候选词里选。比如top_p0.9表示模型只从概率最高的、累积占比90%的词里挑剩下那10%的低概率词根本没机会被选中。从效果上讲top_p调低会让输出更保守调高会让输出更多样。很多主流模型的接口文档里都有一条建议temperature和top_p通常只需要改其中一个不要同时大幅调整。原因很简单两个参数都是控制随机性的同时调高会叠加出不稳定的输出同时调低又会把模型压得太死。我个人的习惯是固定top_p在0.9左右不动主要调temperature来改变输出风格。4.3 max_tokens给输出定个预算max_tokens控制模型最多能输出多少个token。token不是字一个token大概对应0.7到1个汉字英文一个单词通常一两个token。这个参数很多人不重视但它直接影响生成结果的完整度和成本。如果你设置太小模型会把结果截断在中间输出一段没有尾巴的话设置太大不仅吃掉更多计算量和时间还容易出现“生成到后面开始重复”的问题。我建议先估算任务需要的输出长度再做设置。比如提取十个字段的JSON给1000 token就足够了写一篇两千字文章给3000 token比较稳妥。工程上宁可在拿到结果后自行检查是否截断也别图省事给一个太大或太小的值。4.4 频率惩罚与存在惩罚控制重复与话题广度还有两个参数虽然不如前两个常用但在特定场景很关键。频率惩罚frequency_penalty用来惩罚反复出现的词值越高模型越不敢重复自己说过的话。这个参数对缓解“模型来回绕圈、同一句话反复说”有明显效果。存在惩罚presence_penalty用来鼓励模型聊新话题值越高模型越倾向于引入新的词和话题。我曾在做长文本生成时遇到模型在第三段开始复读第一段内容的情况把频率惩罚提高到0.3左右后问题立刻缓解。但这两个参数也是要慎用的。惩罚太高输出会变得东一榔头西一棒子缺乏连贯性。我的建议是因为它们的交互效果比较微妙先固定其他参数只动其中一个观察变化再决定要不要保留。4.5 参数组合速查表这里整理一份我常用的参数组合给你当参考起点任务类型temperaturetop_pmax_tokens备注代码生成 / SQL查询0.0 - 0.20.9按需求估低随机保证语法稳定信息提取 / 分类0.0 - 0.20.8 - 0.9按字段数量估低随机避免格式漂移数据总结 / 分析0.2 - 0.40.9按报告长度估有一点灵活性但保住逻辑营销文案 / 起名0.7 - 1.00.9偏大高随机接受发散日常对话 / 润色0.5 - 0.70.9中等平衡稳定和自然这表不是标准答案但它能帮你省去很多从零试起的成本。实际项目里参数和提示词要一起调提示词越清晰参数就可以越激进提示词模糊参数再低也救不回来。5. 常见问题与排查技巧实录5.1 模型不听话先查指令冲突再查提示位置“我明明说了要输出JSON它偏偏给我一段解释”这类抱怨我在项目里听过无数次。遇到这种情况我的排查顺序是固定的。第一步查指令冲突。提示词里有没有两个要求互相打架比如既要“详细展开”又要“控制在100字内”既要“口语化”又要“学术严谨”模型在这种互相矛盾的要求面前往往会取一个它认为合理的中间值结果两边都不满意。解决方法是删除次要要求保留最关键的那一个。第二步查指令位置。模型对长提示的注意力并不均匀它更关注开头和结尾的内容中间的指令容易被忽略。如果你关键要求写在了一大段背景资料的中间位置模型很可能“看是看到了但没当重点”。解决办法是把最重要的指令放到开头或者在结尾再强调一遍比如在提示最后加一句“再次强调只输出JSON不要任何其他内容”。我自己测试过同样一句规则放在结尾比放在中间的效果好很多。5.2 同样提示结果忽好忽坏控制随机性很多人遇到过“同样的提示词上午跑出来很好下午跑出来很烂”的情况。如果模型本身的更新没变大概率是随机性在作怪。排查步骤很直接先看你的temperature是不是设高了。如果是把它降到0.2以下再试。如果你已经把temperature设为0还是不稳定那就说明问题不在随机性而在提示词本身或者任务难度。还有一个工程上的兜底手段我强烈推荐同一条提示跑三次或五次把结果拿来投票。对代码任务可以比较哪个结果通过率最高对文案任务可以挑最符合要求的一版。这个方法成本很低但对稳定性要求高的场景效果拔群。我在一个数据提取项目里就是靠“三次结果取多数”把准确率从93%提到了将近99%。5.3 模型一本正经地编答案四招压制幻觉幻觉是大模型绕不开的话题。模型不是数据库它没有“查不到就说不知道”的机制它只会生成“看起来合理的答案”。我在实战里总结出四招按效果从强到弱排序。第一招明确要求“只基于提供材料回答”。在提示里写“只能依据上文提供的资料回答资料中没有的信息一律回答‘未知’”。这一招能挡掉大部分幻觉。第二招给“不知道”一个出口。很多幻觉是因为模型不想承认自己不知道你要在提示里明确允许它说“无法回答”。比如写“如果信息不足直接回复‘信息不足无法判断’不要猜测”。第三招要求输出内容标注来源或依据。比如每一句分析后面括号注明来自哪一段原文。这一招让模型不敢随便编造。第四招在任务完成后让模型“自查一遍”。加上“请检查以上回答中是否存在编造信息如有请删除并修正”有时能触发模型自我纠正。5.4 长上下文任务内容丢失分段、定位、再汇总当输入内容很长时模型会表现“记头记尾忘中间”的现象——它能记得你最开始给的背景和最后给的指令但中间一大段内容里的关键细节会被忽略。这在处理几万字的文档时尤其明显。我常用的对策有三种按场景选择。第一种把关键信息前置。如果你知道某个细节很重要把它单独摘出来放在提示的最开头并在背景区重复一遍。第二种分段处理。把长文档切成若干块分别让模型提取要点或完成子任务再把每段结果交给模型做汇总。第三种检索增强。当文档实在太大时先用简单的关键词或向量检索找到最相关的段落只把相关段落喂给模型。这个方法效果最稳定但需要一点工程成本。5.5 提示词也要迭代从糟糕结果到稳定结果的复盘很多人以为提示词是一锤子买卖写出来不好用就觉得是模型不行。实际上我手上所有稳定可用的提示词几乎都经过至少三五轮迭代。迭代的方法非常朴素跑一次看错误改提示再跑一次。我举一个实际经历。某次让模型帮一个团队从客户访谈记录里提炼需求第一版提示只写了“提炼用户痛点”。结果模型给出的是十条“用户觉得体验不好”这种空话。我观察错误模式后发现模型缺乏两样东西评价标准和动作建议。于是我在提示里加了“每一条痛点必须对应一段访谈原文依据”并且要求“针对每条痛点给出一个可行的产品优化动作”。第三版跑出来的结果信息密度和可执行性立刻上了一个台阶。迭代提示词时我的节奏很固定先定位“模型在哪里跑偏”再猜测“是哪个信息没给够”然后修改对应的那一个部件而不是推翻重来。你改得越精准提示词迭代得越快。5.6 常见问题速查表问题可能原因建议解法输出内容与要求格式不符格式规则模糊或埋在中间给具体模板把规则放到开头或结尾回答太泛、没有深度缺少背景和角色约束补充读者画像、专业角色、明确分析维度结果不稳定、时好时坏temperature偏高或任务太难调低温度多次运行取多数或最优模型编造数据或事实没有约束信息范围强制基于材料回答、允许说“不知道”、要求标注依据长文本中间信息丢失上下文过长或位置效应关键信息前置、分段处理、检索增强输出被截断max_tokens 设置不足估算输出长度按任务加大预算反复重复已说内容解码偏差或惩罚不足适当提高频率惩罚检查输入是否重复这张表覆盖了大部分日常工作中的提示词问题。如果你遇到的不在上面不妨先把它拆成上面几类再对症下药。6. 进阶从提示词到提示体系的升级6.1 把提示词当代码管理模板化与版本化当你的项目里出现二三十个提示词之后继续靠聊天记草稿就是灾难。我的习惯是把提示词当成代码一样管理。每个提示词一个文件统一存放在项目目录下文件里标注清楚用途、适用模型、使用场景和变量占位符。需要动态注入的内容用{{变量}}这样的占位符标识调用时再替换。版本管理同样重要。改提示词之前先备份旧版本线上出现问题立刻回滚到上一个可用版本。很多团队在模型应用上线后遇到“这次改提示反而更差了”的情况如果没有版本记录你连“改之前是什么样”都说不清楚排查起来非常痛苦。我强烈建议从项目第一天就养成这个习惯。6.2 建立评估集改提示不再提心吊胆提示词改动有个很典型的风险“修好了一个case弄坏了一片case”。你为了修正某类错误改了提示词结果另外几类原本处理正常的任务开始输出烂结果。防止这个问题的唯一靠谱手段就是准备一个评估集。评估集不用很复杂收集20到30条代表性的输入每条配上“期望输出满足什么标准”的说明跑完一遍人工打分。每次改提示词跑完整套评估集对比分数变化。这个做法一开始会觉得很耗时但它能防止你在后面的迭代里反复踩同一个坑。对于追求稳定交付的团队效果非常明显。6.3 提示工程在大模型应用架构中的位置最后把视野拉高一点。提示工程不是只发生在聊天窗口里。在现代大模型应用架构里提示词几乎是无处不在的“最小单元”做检索增强生成需要设计“如何从检索结果中提炼答案”的提示做智能体需要设计“让模型决定调用哪个工具”的指令做数据标注需要设计“让模型按标注规范输出”的模板做模型评估也需要设计“让模型判断回答是否合格”的评分提示。换句话说提示工程是整座大模型应用大厦的砖块。你可以不会微调模型可以不会复杂架构但只要你能把提示词写得出色你就能在应用层创造大量价值。反过来如果提示词本身写得粗糙上层架构再精巧最后的输出质量也一样会被拖垮。写到最后分享一个我坚持了很久的习惯。每次我用大模型做一件自己不太熟悉的事都会先试着把这件事拆成“谁、什么背景、要什么结果、按什么结构、有什么限制”这五行字再发给模型。单看这五步都很简单但把它们变成肌肉记忆这需要刻意练习。大模型迭代得再快把需求表达清楚这件事永远不会过时。从你手头最常做的那类任务开始用这套方法重构一遍提示词跑几组对比你很快就能看到差别。
阅读完成 · 觉得有帮助？
