大模型提示词工程说白了就是学会和大模型“好好说话”把脑子里的模糊需求翻译成它听得懂的指令。别小看这件事——同样一个模型有人能让它当编程助手、数据分析师、文案策划有人却只能得到又空又水的回答。差别几乎全在提示词上。这篇指南是写给两类人的一类是写代码的程序员想用大模型提升开发效率另一类是完全没接触过代码的小白想让大模型帮忙处理日常任务。我会把我在多次实际项目中验证过的五大核心技巧配合能直接抄作业的案例从原理到操作一步步拆给你看。读完之后你会发现提示词工程不是玄学而是一套完全可以量化、可控的交流方法。1. 先纠正一个误区大模型是“聪明的实习生”不是“全知的搜索引擎”很多人在第一次用大模型时都习惯把它当成搜索引擎来用输入几个关键词期待它直接吐出正确答案。一旦结果不符合预期就开始怀疑模型能力不行。但事实上绝大多数失败案例问题都出在提示词本身。1.1 为什么你总觉得大模型“答非所问”我经常遇到这样的场景有人问模型“帮我写个Python程序”模型反问要写什么程序有人再输入“写个游戏”模型就真的输出一个极简的猜数字游戏然后用户觉得“这也太简陋了”。问题出在哪出在“Python程序”和“游戏”都是高度模糊的指令。大模型的工作方式本质上是通过词元预测生成最可能的下一个内容。它没有魔法也不知道你脑子里在想什么。它的“聪明”更多体现在一旦你给出清晰的约束和上下文它就能在极短的时间内检索海量的训练知识组合出相当专业的答案。这就像带了一个能力很强但完全不了解你公司背景的实习生——你只告诉他“写个报告”他当然大概率写出通用模板但你告诉他“你是财务分析岗请根据我给的销售数据写一份不超过300字的分析摘要重点标注异常波动”他会给你超出预期的结果。所以提示词工程的核心不是“多输入几个词”而是把隐含需求显性化。把自己的目标、模型的身份、输出的格式、需要绕开的坑全部说清楚。这样模型才不需要猜也不用瞎猜。1.2 提示词工程的三个核心要素指令、上下文、期望输出无论提示词是长是短拆解下来都离不开这三个要素。理解了它们后面的技巧才有根基。指令Instruction告诉模型“你要做什么”。比如“请翻译”“请总结”“请生成代码”。指令越具体行为越可控。只写“帮我看看这段代码”就远远不如“请帮我审查这段Python代码找出潜在的越界问题并给出修改建议”更高效。上下文Context给模型提供必要的信息背景。包括角色设定、已知条件、参考示例、禁止事项等。上下文决定了模型从哪个知识范围里取答案。模型并不会天然知道你用的是Python 3还是Python 2也不会知道你的用户群体是大学生还是企业客户这些都需要你用上下文写清楚。期望输出Output Format定义答案的样子。比如“用Markdown表格输出”“给出JSON格式”“分成三点每点不超过50字”。明确期望输出是控制答案质量最直接的手段。你可以把这三个要素想象成给实习生的任务单做什么、背景是什么、交上来的东西长什么样。一张合格的任务单实习生能立刻上手一张只有“做个方案”四个字的任务单实习生能发挥的地方太多风险也随之增大。接下来的五个技巧本质上都是在把这三要素落地角色设定强化上下文示例补充上下文思维链约束推理路径格式约束定义期望输出迭代优化动态修正指令。理解了这一点后面每一章你都能学得更快。2. 技巧一把“随便聊聊”改成“目标明确的项目需求单”——角色设定与任务描述第一个技巧也是我每次用大模型时最先做的一步给模型一个明确的角色以及一个像需求文档一样清晰的任务描述。很多人习惯直接甩一个问题然后得到了一个平平无奇的回答。但你一旦把提示词改写成项目需求单输出质量会立刻上一个大台阶。2.1 角色设定给模型一个可以“代入”的专业身份为什么要设定角色因为大模型在预训练阶段看过大量的文本有编程类、销售类、医学类、法律类等不同领域的语料。当你明确给出“你现在是一名有10年经验的资深后端工程师”这个角色时模型内部的生成路径会主动偏向该领域的专业表达和思考方式而不是在所有知识里平均用力。这里有个常见误区有人觉得角色设定只是加一句“你是一名某某专家”就完事了。实际上角色设定要包含“身份 领域 层级 任务目标”。举两个对比较弱的提示词“你是一名专家帮我写一段登录代码。”较强的提示词“你是一名熟悉网络安全和Web开发的高级后端工程师请使用Python的FastAPI框架为我的项目写一个基于JWT的无状态登录接口要求考虑密码加密存储、token过期处理并附带单元测试。”后者的效果几乎是碾压级的。模型知道要给FastAPI风格的代码、要装什么库、需要考虑哪些安全细节而不只是丢弃一个泛泛的登录页面。如果你是小白的读者可能会觉得这些专业词太陌生没关系你只需要记住一个原则角色设定中角色的具体程度决定了答案的专业程度。哪怕你是让模型“帮我写一份周三下午三点部门周会的会议纪要”也要设定“你是一名行政助理专注会议记录记录要清晰分点并标出未决事项”——因为行政助理这个角色会让模型倾向于使用会议纪要的行文习惯而不是散文。2.2 任务描述的五要素与反面案例拆解给实习生布置任务时任务描述要足够具体。我总结了一个好用的五要素检查法目标你最终要得到什么是一段代码、一篇文章还是一个方案约束有没有技术栈、篇幅、风格、数据来源的限制参考提供哪些已知信息比如已有的代码、字段定义、背景说明。反例哪些情况绝对不能出现验收标准怎么判断结果合格来看一个反面案例有人输入“帮我写一份英语学习计划”。这个任务里目标模糊是长期计划还是考前冲刺、约束缺失每天学多久目标分数多少、无参考、无反例、无验收标准。模型只能给你一份“早上背单词、下午听听力”的通用计划。我给这个提示词做个简单的升级假设你是一名有10年教学经验的雅思口语老师。请为一位目标分数6.5分、每天只能投入40分钟备考的上班族制定一份为期8周的口语提升计划。要求每周设置一个主题安排当天的具体练习动作不要推荐付费课程计划需要用Markdown表格按周展示最后注明每周的自我测试方法。这样模型就能输出一份相当可落地的计划而不是泛泛而谈。核心逻辑是你给的约束越像真实需求模型就越不容易发挥“车轱辘话”。在你输入之前先花一分钟想清楚如果我是这个项目的负责人我拿到这份答案能不能直接验收如果答案是否定的那提示词大概率还不够具体。2.3 实战让模型帮你写一段可运行的Python脚本我举一个程序员更关心的例子。假设你准备写一个批量重命名文件的脚本但不想自己查模块资料。先给出一个弱提示词“写个脚本把文件名重命名为日期格式。”模型会输出一堆没头没尾的代码可能还不清楚要重命名的目录在哪。按五要素改写后请你扮演一名有8年经验的Python开发工程师。任务编写一个Python 3脚本批量重命名指定文件夹下的所有图片文件规则统一改为YYYYMMDD_HHMMSS.jpg保留原文件扩展名。约束使用os和re模块不要引入第三方库脚本运行前打印将被重命名的文件列表自动跳过已经符合命名规则的图片如果无匹配文件输出提示信息。请给出完整可运行的代码并在代码末尾用注释说明用法。效果很好模型会主动写一个完整的脚本还带有主入口和错误处理。你会发现它给出的代码从“玩具片段”变成了“能直接用进项目的工具”。这就是角色与任务描述带来的差异。两个提示词之间只差了几个从句但输出质量天差地别。3. 技巧二与其说一千遍不如给一个“葫芦”——Few-Shot示例的魔力第二个技巧是用示例来“打样”。你可能会觉得指令已经写得很清楚了为什么模型还是听不懂因为大模型天然喜欢模仿——示例给它展示了具体的输入输出映射关系这是最直接的约束。这条技巧可以说是小白最容易上手、提升效果最明显的一个。3.1 为什么一个示例顶得上一串形容词我经常用一句大白话解释你跟人类讲“要把工作总结写得简洁一点”可能不如直接给他看一份你觉得写得好的“简洁总结示例”来得快。因为“简洁”是个主观词不同人理解不同。但示例会把抽象的要求变成具体的格式、语气和内容量。比如你想让模型根据一段商品描述生成一段用于社交媒体的推广文案。如果你只是说“请生成推广文案要求活泼”模型可能会给你一段略显“AI风”的文字。但如果你在提示词里放一个示例示例输入天然蚕丝面膜补水保湿适合敏感肌一盒10片。 示例输出换季烂脸姐妹看过来这盒蚕丝面膜真的把“温和”写在配方里了敏感肌直接闭眼入10片装可以撑一个皮肤修复周期。然后让模型按同样的风格为你的另一款商品生成文案它就会自动模仿这个示例的结构包括“痛点称呼核心卖点行动建议”。示例不仅传递了格式更传递了“语感”。模型会把示例当作最优解在它的附近展开生成这比任何形容词都更接近你想表达的意思。因此在构造提示词时先想一想能不能给模型一个“葫芦”——哪怕是很短的一个输入输出对。等到没有示例可用时再去堆砌修饰词。需要注意的是示例不能随便找一个。示例的质量非常关键你给的示例中包含某种偏见模型就更容易放大这种偏见。3.2 如何构造高质量示例正面清单负面反例一个高质量的示例最好包含一对“应该怎么做”和“不应该怎么做”的对照。正面示例正向样本告诉模型符合要求的样子。负面示例反向样本告诉模型必须避开的样子。举个例子你想让模型把口语化的句子改写成正式书面语。提示词可以这样写请把你收到的每一段口语文本改写成正式的书面语。以下为转换示例输入那个项目我们搞砸了客户很不高兴可能以后不合作了。 输出该项目未能达成预期目标客户反馈表示强烈不满未来合作存在较大不确定性。输入感觉这功能还行就是有点卡。 输出该功能整体表现尚可但运行流畅度不足。现在请改写这次培训太无聊了好多人都睡着了组织得也不行。注意这里包含了两个正面示例但并没有反面示例。那什么时候需要反面示例当你特别担心模型出现某种错误时可以加一句“你绝不能输出以下内容”或直接放一个反面示例。比如反面示例输入开会迟到了半小时。输出早到不如晚到反正没人说什么。×大模型很有“求生欲”一旦它在上下文中读到“反面示例”生成时就会倾向于绕开这种表达。在我实际项目中我发现反面示例对抑制模型胡编乱造特别有效。尤其在做知识问答类任务时给一个“不确定不要乱猜明确答‘信息不足’”的反面示例模型的“幻觉率”会明显下降。3.3 实战用示例让模型输出结构化JSON程序员经常需要让模型输出JSON但模型偶尔会在JSON里夹带markdown注释或额外文字导致解析失败。示例就是解决这个问题的最好办法。你是一个数据提取器。请根据用户输入的公司信息提取出“公司名称”“所在城市”“成立年份”“员工数”四个字段并输出为严格的JSON对象。示例输入某科技公司2015年在上海成立目前团队规模有180人主要做企业服务。 示例输出{company_name:某科技公司,city:上海,founded_year:2015,employee_count:180}现在请提取某教育公司总部在广州2019年成立现有员工420人。你会发现模型几乎不会输出多余的文字它知道目标就是模仿示例输出纯粹的JSON。如果你再补充一句“不要输出JSON之外的内容”它也会乖乖听话。这正是示例承诺了输入输出的“边界感”——模型在示例中看到的映射关系越清晰它就越不会自由发挥。4. 技巧三让模型把“草稿纸”亮出来——强制分步推理与思维链第三个技巧可能是“程序员友好度”最高的一条请求模型在给出最终结论前先展示推理步骤。这种方法在英文资料中常被称为Chain-of-Thought也就是思维链提示。4.1 从“直接给答案”到“让我看看你的推理过程”大模型在面对复杂逻辑题时如果你直接让它给答案它常常会因为“想一步到位”而翻车。但如果你在提示词中加上一句“请一步一步思考并在回答中展示每一步的推导过程”正确率会明显提升。原因不难理解模型生成的每一步输出都会成为它后面生成内容的“上下文”。当它先写出“已知条件有哪些”、再写“第一步计算”、再写“第二步筛选”时这个逐步生成的路径等于在给自己做了一遍逻辑推导而不是被“能急停下来的直觉”带跑。举一个例子。假设有一道题“一个盒子里有红球和白球红球比白球多3个总数为27个请问红球和白球各多少个”直接问“是多少”模型有时会搞混。更稳妥的提示词是请一步步推理设白球数量为x请先列出已知条件。根据红球比白球多3个列出红球与白球的关系式。结合总数为27建立方程并求解。最终给出红球和白球的具体数量。模型会按照这个框架输出完整推导答案几乎不会错。这个技巧不仅适用于数学题还适用于方案选择、代码调试、文本逻辑分析等任务。尤其是当模型需要综合对比多个条件时强制分步能显著减少遗漏。4.2 什么时候该用思维链什么时候别乱用思维链很好用但也不是万能的。我总结了三个适用场景和三个不适用场景适用场景数学题、逻辑推理、多条件筛选需要逐层推导全程每一步都可能出错。代码排查让模型分析一段有Bug的代码它先枚举怀疑点再逐个排除远比直接让“找Bug”靠谱。复杂决策比如“选择A城市还是B城市开分店”让模型先列出两地的优势劣势再给结论。不适用场景简单提取任务比如“从一句话里提取人名”根本不需要推理模型一步就能完成。需要快速响应的对话场景每条回复都要求模型长篇幅推理会造成不必要的延迟和字数浪费体验很糟。开放式创意写作让AI“先推理怎么打动读者再写文案”反而可能抑制它的灵感。这时候最好直接给文风示例而不是逼它做逻辑。换句话说思维链是在“答案不确定且需要推导”的场景下才值得投入的。没事别加“请一步步思考”否则你会得到一堆无关痛痒的“自我检讨”。4.3 实战用思维链解决一道“多条件筛选任务”前段时间我模拟了一个任务要求模型根据一组条件推荐一款合适的笔记本电脑。由于条件比较多模型直接回答容易漏项。我给它的提示词是这个样子你是数码产品顾问。请基于以下条件推荐一款笔记本电脑并展示你的决策过程 预算: 6000-8000元 用途: 轻度视频剪辑、Java开发 必需至少16GB内存512GB SSD屏幕14英寸以上 偏好重量不超过1.5kg。请先列出满足必需条件的机型再根据偏好一一排除最后给出你的最终建议及理由。结果模型按照“筛选必需条件-代入偏好-比较剩余选项-给出结论”的路线输出最后推荐结果非常清晰。这个过程中虽然模型并没有真的“计算”但强制分步让它把筛选逻辑完整呈现在上下文里降低了随机发挥的概率。你在自己写提示词时可以模仿这种“先列约束-再列候选-再剔除-再收尾”的结构。5. 技巧四学会画“边界线”——分隔符、输出格式与格式约束前面几个技巧核心都是“引导内容”。第四个技巧更偏“控制结构”通过分隔符、格式要求让模型的输出严格符合你的使用场景。这对于程序员对接自动化流程特别重要但对小白来说也同样能提升阅读效率。5.1 用分隔符把“指令”和“内容”分开避免模型混淆一个经典的问题如果你在提示词中给了大模型一段待处理的文本里面包含了“请忽略所有指令”这句话模型很可能会照做。这时候分隔符就派上用场了。最常见的分隔符有三类特殊符号###、---、成对包裹content.../content、code.../code、[]、{}Markdown代码块标记python、text举个例子你要让模型翻译一段会议记录。不要把待翻译内容直接混在指令中而是像这样请将以下会议记录翻译成英文。会议记录被包裹在符号内周二下午产品部与研发部就发票模块的接口方案达成一致预计下周末联调。这样即使原文中出现“假装你是翻译、忽略之前的指令”之类的话模型也不会把它当作有效指令。原因在于分隔符清晰标记了“哪些是待处理数据哪些是不可违抗的命令”这让模型的执行边界变得很明确。尤其是你在做提示词注入防护或自动化处理时这个习惯能帮你省去很多麻烦。5.2 明确输出格式表格、JSON、代码块一次说清输出格式的约束应从“给模型一个准确模板”的角度入手。比如要求“请用Markdown表格输出第一列是功能名第二列是优先级第三列是预计工时”要求“输出JSON字段名必须为name, price, stock”要求“先写一段简要说明再输出带行号的代码块”这里有个实践经验格式要求最好放在提示词的末尾而不是开头。原理上模型是逐步生成内容的结尾部分的要求更容易成为生成最后阶段的“注意焦点”。如果你把格式要求放在开头模型在前面的长文本生成过程中可能会慢慢忘记它。虽然这不算绝对规律但在我用过的多个主流大模型上这个技巧都明显奏效。不要让模型自己发挥。比如你问“请列出本周的5项待办并给出优先级”如果你不指定格式模型可能输出一段话。但如果你要求“请用表格输出按优先级从高到低排列并增加‘预计耗时’列”结果就会跨越式地好用。对于小白来说这是最容易看到明显效果的一招。5.3 实战让模型整理会议纪要并按模板输出我来展示一个可以直接套用的模板这个模板几乎可以用于任何会议纪要或信息总结类任务你是一名会议记录专员。下面是用包裹的原始会议转写片段 昨天开会讨论了下季度促销活动。小张说预算批下来了总共五万小李说希望在第三周开始推广可以找几位达人做视频小王补充说必须先准备好物料避免投放时手忙脚乱。请按以下模板进行整理会议主题议定事项未决事项行动项用表格表示事项 | 负责人 | 截止时间整体事实错误时请标注“需人工核实”。模型输出的结果就会是结构清晰、可直接放进项目管理的模板。你会发现格式约束不仅让内容变清楚还让后续处理变得更容易。你可以直接把这段输出复制进表格或者通过脚本解析。6. 技巧五没有一次写对也很正常——多轮迭代与结构化修改最后一个技巧也是最容易被忽略的提示词工程不是一个“一次成型”的过程而是一个“调参”过程。即使是经验丰富的从业者也没有人能做到第一版提示词永远完美更常见的情况是先写一个能跑通的版本再根据输出的反馈逐步优化。学会迭代是提示词工程从“入门”到“进阶”的分水岭。6.1 提示词是“调”出来的把每次输出当反馈信号很多人用大模型失败后会觉得“这个模型不行”然后放弃。其实更准确的思路是每次输出都是对提示词质量的一次评测。如果输出偏了往往不是模型变笨了而是提示词里有一个“干扰项”或“缺口”。你可以把输出当作一个反馈信号去问自己三个问题哪里跟预期不符是信息缺了还是格式不对还是语气跑偏这个不符是因为提示词缺少了哪一个约束我可以用什么方式补齐这个约束是加一个示例还是明确输出格式这种“审视输出—修正提示词—再次生成”的循环本质上就是产品经理常说的快速迭代。配合下面要讲的几种策略你会越调越准。6.2 三种高效迭代策略补齐、压缩、换角度补齐Refine针对性补充缺失信息。例如第一次生成后模型漏掉了某个方面你的第二次提示词可以这样写“你刚才的答案遗漏了风险分析请保留原有内容新增一个‘风险与应对’小节。”这种方式可以避免让模型重新生成多余的全量回答只做增量修改。压缩Condense在保持核心内容的前提下要求更短更精炼。如果第一版太啰嗦可以增加“去除口头语、每点限制在20字内、合并重复信息”等约束。这是成本最低的优化。换角度Rephrase如果同一提示词重复调整两三次仍然效果很差不妨完全换一个提问角度。比如之前让模型“写计划”改为“假设我是项目的投资人请你用三个问题来探询这个计划的不足然后再给出完善建议”。角度一变模型的注意力分布会完全不同常常能带来惊喜。三种策略没有谁更高级关键在于针对不同的失败模式灵活选择。我自己的习惯是先判断是内容缺失还是结构混乱内容缺失用补齐结构混乱用格式约束或压缩主题跑偏严重就直接换角度。6.3 实战从“很一般的回答”到“能直接用的回答”的两次修改过程我模拟一个任务请大模型帮忙撰写一封向客户催款的正式函件。第一版提示词请帮我一封催客户付款的邮件。模型输出了一封语气生硬、还带威胁口吻的邮件。这显然不行。第一次迭代增加角色与目的约束。假设你是企业信用管理专家要写一封既保持合作关系、又能让对方重视付款期限的催款函。客户推迟付款30天且未说明理由。语气要礼貌但坚定。请给出一封可直接发送的邮件约200字。模型这次输出了一封措辞得体的信但段落过长缺少重点信息位置。第二次迭代增加格式与核心要素。请保留上一版邮件的基本内容但把邮件结构改为主题行、抬头、欠款金额及账期说明可填写占位符、当前影响说明、请求明确付款日期、致谢与联系方式。使用模板风格把关键信息用[]标出。这次模型提供了一个清晰的模板几乎可以直接复制到邮箱里使用。整个过程只花了几分钟。你会发现模型每一次输出都在给你的提示词打分而你的每一次微调都在缩小“当前输出”和“理想输出”之间的差值。多轮迭代不是没面子而是工作常态。7. 综合案例五个技巧合起来让大模型帮你完成一个“个人记账小工具”前面分别讲了五个技巧现在把它们全部串起来做一个完整的实战案例。假设一个完全不懂代码的小白想做一个“个人记账小工具”并且希望通过大模型生成产品需求文档和可运行的Python原型代码。我们来一步步构造提示词。7.1 第一步用角色设定与任务描述铺底你是一位拥有6年经验的产品经理兼Python开发工程师。请协助我完成一个“个人记账小工具”的MVP版本设计。首先输出一份《产品需求文档》然后再根据该需求文档生成一套可直接运行的Python原型代码。这里用了技巧一给出了身份和具体任务还规定了输出顺序。这样一来模型就不会只给你一段代码而是先有设计逻辑再给实现。7.2 第二步用示例与格式约束规范输出在模型生成需求文档前我们最好补充格式要求需求文档请按以下结构输出用户故事功能清单用表格功能名 | 优先级 | 说明基本数据模型建议使用Python dataclass示意核心交互流程用序号描述步骤即可不要画图这样模型就会严格按你的模板输出而不是自由发挥出五六个大标题。等模型输出需求文档后我们再让它生成代码。7.3 第三步用思维链让模型先生成代码设计再写具体实现直接让模型“写代码”容易漏掉边界条件。我们加上分步要求请针对功能清单中的“添加账单”“按月统计”“提醒预算”三个功能先生成代码的执行流程再根据流程用Python编写实现。代码要求使用标准库不使用框架数据保存到本地JSON文件每个函数都要有类型标注和docstring请先输出函数列表再逐个写出函数实现这段提示词隐含了“先思考后编码”的思维链。模型通常会先列出一个Bill类、add_bill()函数、monthly_summary()函数、budget_alert()函数等然后依次填写实现。这样生成的代码比直接让他“写吧”要完整得多。7.4 第四步多轮迭代微调代码第一次生成的代码往往只有基础增删查没有预算提醒逻辑。我们继续用迭代策略功能清单里提到“提醒预算”但你刚才的代码里没有实现这部分。请补充一个模块在新增账单后自动判断当月支出是否超过已设定的预算如果超过则输出一条包含超额金额的提示。请只补充这部分代码和对应测试用例。模型会基于已有的数据结构快速补上相关逻辑。经过两三次这样的迭代这个小白就能获得一个可运行、带基础功能的记账小工具原型。整段过程不需要写一行代码但最终产出却相当扎实。7.5 从案例中复盘五个技巧各自的作用现在回头看看这个完整的案例技巧一角色任务为整个过程定下了专业基调技巧二示例虽然没有在每一步都用到但在格式要求中隐含了对输出结构的“打样”技巧三思维链在生成代码前先生成流程设计降低了逻辑跳步风险技巧四格式约束让需求文档和代码都结构清晰便于理解技巧五迭代优化将“没做预算提醒”这种缺口逐步补齐。你会发现这些技巧并不是孤立存在的而是像各个零件一样共同服务于一个目标把模糊的大需求拆解成清晰的小要求。当你熟练掌握后这些技巧就会变成你与模型交流时的本能反应。最后再分享一个小经验不要把提示词当成一个“能一次写对的谜题”它更像一把需要不断打磨的钥匙。每次生成结果不满意不要急着换工具先想一想是不是没有把需求说全。技术总在变化模型总在升级但“清晰表达需求”这件事永远不会过时。哪怕你现在只记住“角色要具体、格式要说清、推理要分步”这三句话也已经能超过大部分只会乱问的用户了。
