做过提示词工程的朋友应该都有体会同一类问题换个问法结果可能天差地别。所谓“会问”比“懂”更重要并不是玄学而是提示词设计确实有方法论可循。如果你是做内容创作、产品运营、代码开发或者日常工作里经常需要借助大模型LLM来辅助完成任务那么你肯定能感同身受——很多时候模型输出不理想不是模型不行而是提示词本身没写好。这篇“Part04提示词示例”会围绕真实业务场景把我验证过的一批提示词示例、设计思路和踩坑经验拿出来做一次系统拆解适合想把提示词从“靠直觉”升级到“可复用、可沉淀”的读者参考。1. 提示词设计的基本逻辑与思路1.1 提示词的本质人和模型之间的翻译器很多人第一次接触提示词会把它理解为“一句清楚的指令”比如“帮我写一篇推文”。实际跑几次就会发现这种简单指令的产出质量波动非常大同样的指令换个时间跑结果可能完全不一样。我的理解是提示词本质上是人脑思维和模型推断之间的一层翻译器。人脑中隐含的上下文、意图、偏好、评价标准模型看不见它只能通过你写下的文字去推断。如果你只在提示词里写了“写一篇推文”那模型需要同时猜测推文给谁看、多长篇幅、什么风格、用什么平台语言、要不要加结论、要不要加数据支撑……这些猜测一旦和你的真实意图有偏差输出质量就会崩。所以提示词设计的第一性原理不是“把问题写清楚”而是“把模型推断时缺失的上下文补全”。越关键的任务提示词里越需要明确以下信息角色、受众、目标、约束、输出格式、评价标准。我把这六个要素叫做提示词的六维框架后面所有示例都是在补全这几个维度。1.2 为什么同一套提示词在不同模型上表现差异很大插一个很常见的问题很多朋友拿着同一套提示词去不同平台用发现效果差异很大。这不是提示词的问题是模型能力边界不同。有些小参数模型对长上下文的感知弱你的提示词写再长它也只会抓关键词有些新版本模型对指令遵循能力很强会严格执行你写的每一步。实操中我的建议是面向不同模型准备两套提示词模板——一套精简版适合轻量模型一套详细版适合强指令模型。如果是在某个具体平台上开发应用还需要专门针对该平台的行为特征做一次系统调优这个后面在实操章节里展开。2. 核心场景的提示词示例与解读2.1 内容写作类从“一句话”到“可发布的定稿”先看一个最常见的场景公众号推文、小红书笔记、知乎回答这类内容创作。大多数人的初版提示词长这样写一篇关于时间管理的文章。这个提示词的输出大概率是一篇“正确但平庸”的泛泛之谈。我实测过不下十次每次拿到的结构都差不多开头一个故事、中间几个方法论、结尾一句鸡汤。放在两年前还能用现在这种内容读者一眼就能识破。改进后的工作级提示词我常用的模板如下你是一名深耕职场效率领域的内容创作者公众号文章风格偏实用主义拒绝空话套话。 请围绕“时间管理”写一篇公众号推文目标读者是25-35岁互联网从业者日常加班多、碎片时间少希望看到可直接落地的方法而不是理论综述。 要求 1. 开头用1个真实的职场场景切入场景里要有具体细节 2. 正文给出3个可执行的时间管理动作每个动作需要说明适用场景、操作步骤、常见误区 3. 全文1500字左右段落不要太长多用短句 4. 结尾不要鸡汤可以给人一个具体的小任务 5. 禁止使用“高效”“自律”“成功人士”这类陈词滥调。 请直接输出正文不需要小标题前的引言。这里面有几个关键改造点角色从“内容创作者”细化到“职场效率领域的内容创作者”风格也一并限定了目标读者画像写清楚了模型在遣词造句时会自动向这个群体靠拢“3个动作适用场景操作步骤常见误区”这组约束把文章结构锁死了不会跑偏成散文“禁止使用……”这类负面约束很管用能滤掉模型最爱用的高频词。用这套模板替换第一版提示词之后我拿同一个话题跑过多次输出的稳定度明显提升至少从“泛泛而谈”变成了“可以说人话、有结构感的初稿”。当然它还不是直接可发的最终稿但作为初稿修改成本大概能降一半。2.2 代码开发类让模型当“结对程序员”而不是“搜索引擎”代码场景很多朋友也在用最常见的需求就是“帮我用Python写个爬虫”这类。但这类提示词有个通病模型会按自己的偏好去选库、选方案完全不管你的代码环境、依赖版本、性能要求结果就是一看能用实际跑不起来。我给代码任务设计提示词的核心思路是把模型当作一个熟悉你的技术栈、需要交接需求的结对程序员而不是搜索引擎。它需要知道的不只是“做什么”还有“用什么做”“什么算完成”。这里放一个实际用过的示例——写一个清洗销售数据的小脚本你是团队里的Python开发代码风格偏好简洁、类型注解齐全、处理逻辑带注释。 现在需要实现一个销售数据清洗脚本 - 输入CSV文件包含字段 order_id, customer_name, order_amount, order_date, status - 要求 1. 过滤掉 status 为 cancelled 的订单 2. order_amount 存在部分缺失值需按同客户的平均金额填充 3. order_date 格式不统一需要统一转换为 YYYY-MM-DD 4. 按客户维度输出汇总表包含订单数、总金额、最近下单日期 5. 考虑内存占用不要一次性加载全部数据用分批读取方案。 - 环境Python 3.10pandas 2.0禁止使用其它第三方库。 请给出可直接运行的完整代码包含必要的注释并在最后用表格说明每个函数的输入、输出和边界情况。这个提示词为什么好用因为它把“项目背景-技术要求-验收标准-环境限制”都补齐了。模型不再需要猜可以直接顺着约束条件设计方案。尤其是最后一句“用表格说明每个函数的输入、输出和边界情况”这个操作看似简单实际能逼着模型先把函数边界想清楚输出的代码自测通过率会高很多。还有一个补充技巧代码提示词里加上“失败处理”的说明。比如在清洗脚本里我还会附带一句如果某行数据存在严重损坏比如 order_id 缺失不要直接删除单独放在 error_log 里输出。这句话能让模型主动考虑异常处理路径而不是只在理想数据上写逻辑。做数据清洗的读者应该秒懂这个痛处。2.3 数据分析类把模型当“哑巴分析员”逼它给结论数据分析场景有个特点很多人拿数据给模型模型能给出一长串统计描述看着很全但没有重点。你知道它说了很多东西却不知道下一步该做什么。问题出在提示词没有定义“输出价值”。分析的价值不在于罗列事实而在于发现问题、定位原因、给出建议。我常用的分析类提示词结构是“数据目标输出限定”三段式这是一份电商平台最近30天的订单明细字段含义如下 - order_id订单编号 - user_id用户编号 - order_date下单日期 - amount订单金额 - channel来源渠道 - refunded是否退款 请以平台运营分析师的视角分析这份数据目标是找出退款率异常升高的原因。输出一份分析报告结构严格按以下四段 1. 核心结论用3句话以内说清楚最可能的退款原因 2. 证据链用数据交叉分析验证上述结论给出关键数字 3. 次要发现最多2条标注把握度 4. 行动建议给出3条可落地的运营策略每条不要超过50字。 注意禁止输出无数据支持的主观推测每条结论必须引用数据行级事实。注意“禁止输出无数据支持的主观推测”这句——这是整个提示词的灵魂。模型很多时候喜欢编因果关系加了这句之后它至少会在推测前面加一句“根据数据渠道A的退款率从X%上升到Y%”分析的可信度直接上一个台阶。再补充一个心得数据分析提示词里一定要把“字段含义”写清楚。很多朋友直接甩一张数据表给模型以为它能通过表头猜出来实际遇到缩写字段模型只能靠猜猜错结论就垮了。字段说明花30秒输出的准确率提升可以换回半小时。2.4 学习辅导类用提示词做“私人教练”而不是“答案机器”教育场景的提示词很有意思。我拿给家里小孩辅导数学的场景做个示例。大多数人的第一反应是直接把题目扔给模型让它做题。但这样做对学习没有帮助因为答案本身不具有训练价值。更好的用法是让模型扮演“苏格拉底式教练”引导人自己推导出答案你是一名耐心的数学辅导老师擅长用提问引导学生思考而不是直接给出答案。 现在学生正在学习一元二次方程的求解ta卡在了配方法这一步。当前题目是x^2 6x - 7 0。 请遵循以下教学流程 1. 第一步只问学生一个问题引导ta观察一次项系数和配方之间的关系 2. 等待学生回答后接着用一个小提示推进 3. 如果学生给出错误答案不要直接否定用“这个思路有意思但你看如果把它代进原式会怎样”的方式引导自查 4. 只有在学生连续两次求助时才给出完整解法 5. 每次回复限制在2-3句话避免长篇讲解。 记住目标是让学生自己想出解法不是展示你的解题能力。这里的关键设计是“每次回复限制在2-3句话”和“等待学生回答”。很多教育类提示词失败是因为模型一次性输出一大段讲解学生没有思考空间。加了互动约束之后对话模式从“老师讲课”变成“教练陪练”学习效果完全不同。3. 实操把提示词沉淀成自己的工具箱看完示例很多人会觉得“挺好的”但到真实使用时还是不知道从哪下手。这里分享一套我自己归档提示词的操作流分四步。3.1 先用旧数据做回测别直接上生产环境每设计一个新提示词我先不拿真实任务去试而是拿一批已经处理过的历史任务跑测试。比如我想改进写摘要的提示词就挑几篇已经发布过的文章让模型重新拆摘要然后对照人工摘要看差异。回测步骤建议固定为找10-20个历史样本同一套提示词跑两轮把输出结果贴进一个对照表人工标注“可用/需要小改/完全跑偏”。只有完全跑偏的情况低于20%时这个提示词才够格进入我的工具箱。这一步麻烦但能避免你把一个烂提示词当作“标准模板”反复用。3.2 按“任务-场景-版本”打标签不用文件夹堆文件保存提示词最忌只保存提示词本身不记录模型的输出。我建议库里的每条模板至少包括任务描述、完整提示词、适用模型、示例输出、迭代备注五项。里面“适用模型”很重要。我在同一类写作任务上发现不同模型对格式要求段落长短的感知能力不一样所以存储时能带上“这个提示词在哪个平台上实测过”的信息后续复用就会少走弯路。再补充一条同一个业务场景建议保留多个版本提示词。比如“标题生成”这种高频任务至少要保留一个“强调差异化版本”和一个“强调热点追踪版本”使用时按需求切换比临时改模板要稳定得多。3.3 迭代时一次只改一个变量别指望一步到位这是我最想强调的实操习惯。很多人拿着提示词跑了一版输出不满意立马大改——角色换了、结构换了、约束也换了一次改了三四个变量。跑完发现效果还是不行但完全不知道是哪一步导致的问题。标准做法是一次只改一个变量。比如这次测试把“角色设定”从“资深文案”改成“小红书博主”输出结构、格式约束都不动然后对比结果。跑完一轮记录差异再改下一个变量。虽然慢但每一轮的结论都是可控的迭代轮次多了之后你对“变量-效果”的因果关系会积累出很宝贵的直觉。3.4 建一个“禁忌词表”把模型爱犯的错提前堵死操作中我发现不同任务类型模型有各自的“惯性错误”。比如写英文邮件它喜欢在结尾加“Hope this helps”写代码它喜欢用“util”这种模糊命名写小红书笔记它喜欢“姐妹们冲鸭”。这些细枝末节光写在提示词里效果有限因为提示词原文太长了模型反而不容易记住。我的做法是另建一个“禁忌词表”每次在提示词末尾加上一句禁止使用以下词语/表达xxx, xxx, xxx根据实际表现动态更新这个表越维护越有用。它本质上是一个针对某个业务场景的“模型行为校准器”不用每次临时想直接引用已有的黑名单就行。4. 常见问题与排查技巧实录4.1 输出质量为什么忽好忽坏很多人遇到输出飘忽不定第一反应是“模型抽风了再跑一次”。但如果连续跑三五次还是飘大概率是提示词里的约束不够或者模型被某些测试时的高频干扰词带偏了。排查建议按这个顺序来先检查角色设定够不够具体再检查输出结构是否唯一比如“写一段话”就比“写一篇300字的推文”飘最后检查负面约束是否到位。这三个地方补严实之后输出稳定性会明显回到可控范围。4.2 提示词越来越长效果却越来越差这是很典型的“堆参数”问题。长提示词不一定有效因为模型对上下文的注意力是稀疏的——提示词里塞了十点要求实际能被执行的可能只有前四到五点。实操原则是限制在8个要点以内超过8个就把相对次要的约束拆出去用负面词表承接。比如你想控制文章风格、长度、结构、语气、平台口径、禁用词、引用方式、结尾方式要点数量就会超标。这时可以把禁用词表单独拉出来把平台口径作为角色设定的一部分提示词主体保持6个左右核心约束效果很明显比堆大段说明好。4.3 不同模型的行为差异怎么适配我在多个常见大模型平台上跑过同一套提示词发现能明显感受到差异。有些平台输出千篇一律像模板有些平台思维链能力突出详细步骤越多它表现越稳也有些平台偏好极简指令给多了干扰信息反而会带偏输出。所以适配策略就是有思维链能力的模型给足推理步骤偏好基础模型的给简短指令。实操上还不熟悉模型差异时养成先从平台文档找行为说明的习惯其次是对同一套能力表现做一次小规模对照测试记录完成时间、输出长度、格式遵循度后面选模型效率会高很多。4.4 模型“太听话”导致输出死板怎么解还有一类问题恰恰相反——因为你把格式、结构、语气全都锁死了模型输出看起来非常规矩但缺乏灵性读起来像模板生硬拼凑。我的解法是在提示词里保留一个“自由发挥位”。比如写作类提示词里加一句在完成上述结构要求的基础上允许你在每个章节里加入一段不超过30%篇幅的、有作者个人风格展开。也就是说核心结构严格约束边角细节留一点弹性空间让模型在框架内有一些自由度这样输出的既有骨感又有血肉比完全锁死舒服得多。5. 写在最后一点真心话提示词说到底是现代人跟大模型打交道的“基本功”但它不像背公式那样会一次到位。我自己的经验是真正有效地积累提示词靠的是反反复复用、遇到问题就回看、把一次失败的输出当作和模型的一次调试对话。最后分享一个还没有被广泛提到的技巧写完提示词先拿一个简单问题测试它看模型的回复是否能照常遵循结构如果连简单情况都不规范就说明这个提示词的结构约束写得太模糊了再拿给真实任务用只会更飘。我靠着这个习惯在投入使用之前就拦下了不少不成熟的提示词版本省下来的时间远大于建库花的工夫。提示词不要求一次完美关键是让它成为你持续迭代的帮手而不是每次临时重新踩坑的起点。