大模型用多了就会发现一个非常扎心的现象你明明把需求写得清清楚楚甚至把背景资料都贴全了结果模型给出的答案还是天马行空、格式混乱或者干脆自说自话。问题多半不在模型本身而在于你给的提示词是“散装”的——想到什么写什么没有结构没有层次模型自然只能从混沌中猜你的意图。我过去大半年反复调试各种场景的提示词最终沉淀下一套六模块结构不敢说能让模型100%听话但至少能让输出质量稳定上一个台阶尤其适合文档总结、代码生成、数据分析这类对结果格式和内容边界要求高的任务。这套结构说穿了并不复杂就是把提示词拆成“角色、目标、上下文、约束、格式、示例”六个部件按顺序组合成一个完整的指令包。它解决的核心问题是模型在执行任务时到底需要哪些信息以及这些信息以什么顺序组织最不容易产生歧义。我把这套方法用于团队内部的多个项目某跨平台系统的接口文档自动生成、某图像处理Demo的实验报告总结都靠它把模型输出从“勉强能用”提升到了“直接可用”。这篇文章把我自己的写法、踩过的坑、调优的过程都梳理出来适合两类人看一是刚接触提示词工程、觉得“提示词不就是把话说清楚”的新手二是已经在用提示词但总觉得结果不稳定、想建立一套可复用方法论的进阶玩家。文章不涉及模型内部原理纯讲实操照着复制就能用。1. 六模块结构的设计思路为什么散装提示词永远差一口气1.1 散装提示词的三个典型毛病先说说我为什么非要搞出一套结构来。早期我用提示词基本靠“堆”——把背景、要求、格式一股脑塞进去中间用几个换行隔开以为这样模型就能看懂。实测下来这种散装写法的毛病非常集中第一个毛病是目标与背景混淆。很多人写提示词喜欢先讲一大段背景故事再在最后轻描淡写带一句“帮我总结一下”。模型读的时候会把大部分注意力放在前面的背景描述上因为它要预测的下一段文本大概率是在延续背景的语境而不是去执行那个藏在最后的小指令。于是输出的内容往往是背景信息的复述而非真正的任务结果。第二个毛病是约束与输出格式纠缠。比如有人写“用简洁的语言总结不要超过500字分条列出包括核心观点”。这句话看起来信息齐全但“简洁”“分条列出”“核心观点”三个要求挤在一起模型不知道该优先满足哪一个结果每条都打了个折扣输出出来既不简洁分条也分得稀碎。第三个毛病是没有给模型一个可以对齐的“标尺”。你光说“要专业”模型不知道你心里说的“专业”是什么样。但如果你给一个示例哪怕只是一个很短的片段模型立刻就能从词汇密度、句式结构、详略分布上校准方向输出的稳定性会明显提升。这三大毛病的根源是同一个人类语言是线性的但模型对指令的解析是概率性的。你把信息混在一起它就按照概率把信息混着处理。六模块结构做的事情就是反其道而行把每一种信息放在固定的槽位里让模型每次都能在同一个位置找到同一种信息。1.2 六模块各自的定位与关系我常用的六模块分别是角色Role、目标Task、上下文Context、约束Constraints、格式Format、示例Example。它们各有分工缺一不可。角色是模型执行任务时的“人格滤镜”决定它用什么身份、什么语气、什么知识背景来读后面的内容。同一段需求让“资深编辑”总结和让“初级助理”总结输出的详略和用词会明显不同。目标是整个提示词的核心引擎告诉模型需要完成什么任务。它必须是一个动词短语比如“提取关键信息”“生成代码”“评估风险”而不是一个名词比如“关于XX的分析”。动词才能驱动行为。上下文是为目标服务的素材库提供模型完成任务所需的信息。它可以是原始文本、数据表格、对话历史也可以是背景说明。没有上下文的提示词等于让模型凭空捏造。约束是边界条件告诉模型什么不能做、必须满足什么硬性标准。比如字数范围、禁用术语、必须包含哪些维度。约束存在意义不是限制模型而是收敛输出空间减少瞎编概率。格式是输出模板描述最终结果的排版形式。可以是“分条列出”“表格”“JSON结构”“技术报告”越明确越好。很多模型输出乱就是因为指定得太模糊。示例是给模型做示范它比任何描述都更有说服力。一个高质量的示例胜过大段文字解释尤其适合格式复杂或风格要求高的任务。六个模块的编排顺序也有讲究角色引导全局接着用目标告诉模型“这次要做什么”再给上下文让它“有料可做”然后用约束和格式限定“怎么做、做成什么样”最后用示例兜底。这个顺序基本沿袭了人类接受任务时的信息处理路径先知道自己是谁再知道要干什么然后看素材最后明确标准。1.3 六模块结构适用的场景边界任何方法论都有适用边界。六模块结构在处理复杂、多步骤、输出要求高的任务时效果最好比如长文档总结、跨文件代码生成、数据报表解析、多轮对话的角色扮演等。但如果是极简单的任务比如“用一句话解释什么是区块链”套六模块反而显得笨重角色、示例这些模块可以直接省略。另外要注意这套结构更适合一次性生成型任务不太适合需要多轮交互的对话场景。多轮对话的关键是上下文管理而六模块结构更像是一份完整的需求说明书更适合在每一轮独立给出而不是每次都重复全套。我在实际使用中会把六模块结构做成模板每次填入不同内容而不是让模型“记住”一个固定的角色设定。2. 六模块逐层拆解每一个模块的写法与实操要点2.1 角色模块人格滤镜决定了整段输出的“味道”很多新手觉得角色模块可有可无随手写个“你是专家”就完事了。但角色定义的质量直接影响模型输出整个语体的走向。同一份代码审查任务角色设定为“资深架构师”和“初级开发人员”给出的审阅意见在深度、措辞、关注点上会截然不同。我总结出的角色写法三要素是身份 经验范围 任务视角。举例来说单纯写“你是一名数据分析师”这是不合格的因为信息量太低。更好的写法是“你是一名有五年互联网行业经验的数据分析师擅长从用户行为数据中找出业务增长的机会点看待数据时会同时关注数据可信度、业务相关性和可落地的建议。”这样一来模型不仅知道了自己的身份还知道了自己的“人设背景”输出时会更自然地往这个方向靠拢。实操上有一个容易忽略的细节角色描述要和目标保持一致。如果角色写的是“严谨的技术文档工程师”目标却是“写一段幽默的产品宣传文案”模型内部会产生冲突最后输出的内容往往两头不讨好。我在调优时会把角色和目标放一起审视看是否存在气质上的矛盾。2.2 目标模块一句话说清楚“要干什么”目标模块是整个提示词里最不能含糊的部分也是最容易被写废的部分。常见的失败写法有两种一种是太泛比如“分析这份报告”模型不知道你期望什么维度的分析一种是太长把约束、背景全堆进目标里模型读完反而失去了焦点。我推荐的目标写法遵循一个公式动词 对象 预期产出。比如“总结这份季度报告的核心结论输出5条要点”“审查这段代码的潜在内存泄漏风险给出修改建议”。动词决定了动作类型对象限定了工作范围预期产出则告诉模型最后要交什么东西。写目标时还有一个进阶技巧如果任务包含多个子步骤按顺序列出来。比如“先识别文本中的论点再评估每个论点的证据充分性最后按置信度从高到低排序输出”。这样模型相当于拿到一张操作流程图每一步的输出都是下一步的输入比让它“一气呵成”要稳定得多。我实际测试过多步骤列明后复杂任务的成功率比一次性输出高出不少。2.3 上下文模块给足素材但不要变成信息垃圾场上下文模块是六模块里最容易“膨胀”的。很多人担心模型不了解背景就拼命粘贴资料结果上下文长到模型处理不过来注意力被稀释关键信息反而被淹没。上下文不是越多越好而是要与目标直接相关。我在处理长文档时常用一个预处理技巧先把原文里与任务无关的章节删掉只保留目标涉及的段落如果内容仍然太长就先让模型做一次“预压缩”提取出粗颗粒度的要点再把要点作为上下文输入生成最终结果。这套两段式处理的好处很明显——模型在第一步只需要理解大意第二步基于要点深入加工每一步的负担都小输出质量自然更好。上下文的组织方式也要留意如果是多条信息建议用编号或列表排好如果是对话历史要标明说话人如果是数据表格直接把Markdown表格贴进去比用自然语言描述更高效。模型的文本理解能力对结构化格式更敏感你给的信息越规整它提取的准确率越高。2.4 约束模块边界写清楚但别把路全堵死约束模块是六模块里最看功力的部分。写得太少模型输出会发散写得太具体模型又会显得僵硬、失去灵活性。我摸索出的原则是硬约束和软约束分开写。硬约束是必须满足的底线比如“字数不超过200字”“不得编造数据”“必须给出至少3个备选方案”软约束是倾向性建议比如“优先考虑成本较低的方案”“可以适当补充背景说明”。为什么会这样区分因为模型在解码时是根据概率选词的如果所有要求都以绝对语气出现它在生成时会把大部分注意力放在“避免违反规则”上反而降低了内容质量。把约束分成硬软两类模型就能明确区分哪些是红线、哪些是参考方向输出时自然张弛有度。另一个容易被忽视的点是约束要与格式、示例相互一致。假如约束里写了“用表格输出”示例却给了分条文本模型会无所适从。我在设计提示词时会把约束、格式、示例当成一个整体来看先想好输出长什么样再反推约束条目和示例选型。2.5 格式模块输出结构越具体后期加工成本越低格式模块是提高“可用性”的关键。很多模型输出内容本身是对的但排版乱七八糟用户还要花时间重新整理。这完全可以在提示词阶段规避。格式描述要具体到“能想象出最终长什么样”的程度而不是模糊地说“请分条列出”。举例来说与其写“用表格呈现”不如写“输出一个包含三列的表格列名分别为指标名称、当前数值、较上月变化并对变化幅度超过10%的行用*标注”。这种格式描述虽然长了点但模型完全能理解而且生成的表格结构基本不需要二次修改。对于需要程序化处理的任务我会明确要求输出JSON等结构化格式并给出字段定义和类型说明。比如“输出JSON对象包含summary和details两个字段summary为字符串details为字符串数组”。模型对这种明确的结构定义非常敏感基本不会跑偏。2.6 示例模块用“别人家的答案”校准模型的手感示例模块是整个结构里最能提升输出质量的杠杆。它的原理很简单模型在做few-shot学习时能从示例中提取规律——风格、结构、详略、语气甚至隐含的判断标准——然后迁移到新任务上。理解了这一点就知道示例选得好不好直接决定了输出质量的上下限。示例的关键是选“标准答案”而不是随意挑一段内容。我一般会自己手写一个理想输出或者从历史结果中挑一份表现最好的作为示例放进去。如果任务输出较长示例不需要完整截取有代表性的片段即可比如给一段开头、一个条目、一个表格行让模型掌握结构框架剩余部分它自己会顺着填。示例放在最后还有一个隐藏作用它相当于给模型一个“起点参照”。模型生成时会受到最近文本的强影响紧跟在示例后面的输出其风格会自然向示例靠拢。实操中我甚至见过仅靠一个高质量示例、删掉大量文字约束模型输出就莫名其妙地变好了。所以能用示例的地方尽量别用形容词。3. 三个场景的完整实战演示从零搭出一份能直接用的提示词3.1 场景一长文档核心内容提炼我拿一个真实工作中很常见的场景来演示——输入一份产品需求文档让模型输出核心要点给团队做评审。这是我当时实际写过的提示词去掉敏感信息后保留了完整结构角色你是一名资深的互联网产品评审专家有五年以上的需求评审经验擅长从需求文档中快速提取业务逻辑、技术可行性和风险点。 目标阅读以下产品需求文档提炼出核心业务逻辑、关键技术约束、潜在风险点并整理成一份评审备忘。 上下文 [此处粘贴产品需求文档正文] 约束 1. 只基于原文信息不得补充任何外部知识推测。 2. 每个要点不超过50字用词精简。 3. 潜在风险点必须判断风险等级高/中/低。 4. 如原文信息不足标注“原文未说明”。 格式按以下结构输出—— 一、核心业务逻辑 二、关键技术约束 三、潜在风险点含等级 四、待确认事项 示例 一、核心业务逻辑用户提交订单后系统在支付成功后自动触发库存锁定若超时未支付则释放库存。 二、关键技术约束订单服务需与库存服务保持最终一致性。 三、潜在风险点含等级超时未支付与库存释放之间存在竞态条件风险等级中。 四、待确认事项支付回调失败后的重试策略未定义。这套提示词我实际用了很多次稳定性非常好。核心要诀在于文档内容放到上下文模块模型没有必要从其他地方找信息约束里明确写了“只基于原文信息”就堵住了模型胡编的通道给的一段示例高度贴近真实场景模型照着它生成格式和详略都不会偏差太远。如果文档特别长我会先让模型分段提取要点再汇总成完整备忘避免一次处理过长文本导致信息丢失。3.2 场景二代码审查与Bug检测代码审查是提示词工程性价比最高的应用场景之一。你要是直接跟模型说“帮我看下这段代码有没有问题”它只会泛泛给一些建议。但把六模块结构套上之后模型输出的审查意见会专业非常多。下面是我在某跨平台系统的模块代码审查时用过的提示词框架角色你是一名资深后端开发工程师熟悉多线程、内存管理、异常处理有丰富的代码走查经验。 目标审查以下C代码找出潜在的逻辑错误、内存泄漏风险、并发安全问题和可读性缺陷按照严重程度顺序输出。 上下文 [此处粘贴待审查的代码] 约束 1. 每个问题必须标注严重程度严重/中等/轻微和所在行号。 2. 对每个问题必须给出具体修复建议禁止只说“有问题”。 3. 不得修改代码逻辑本身只做评审。 4. 如果某些行存在多类问题合并描述。 格式按以下表格输出—— | 行号 | 严重程度 | 问题描述 | 修复建议 | |------|---------|---------|---------| |示例行| 中等 | 第45行动态分配的内存在异常分支中未释放 | 使用智能指针或在异常处理中释放 | 示例 | 22 | 严重 | 第22行的互斥锁在提前返回分支中未解锁 | 使用RAII封装锁确保所有路径都解锁 | | 37 | 轻微 | 第37行的变量命名过于模糊难以理解用途 | 重命名为更能表达用途的名称如pending_ requests_ |模型对表格格式的解析能力比很多人想象中强很多给定表头之后它会自动按行填充内容很少出现格式漂移。代码审查场景里最要紧的是约束里的第1、2条强制标注严重程度和给出修复建议。如果这两条不写死模型就会说一堆正确但无用的废话比如“注意不要出现内存泄漏”——这句话本身毫无操作价值。如果你要审的代码很长我建议拆成多个函数片段分批审查最后让模型汇总报告。一次塞几千行代码既容易超长又容易让模型关注点发散效果不如分片来得好。3.3 场景三数据分析与业务洞察最后一个示例是数据分析场景。模型本身不能运行复杂计算但它在“解读数据”这件事上非常有价值——只要你给它足够结构化的数据。这个场景中的提示词框架如下角色你是一名电商业务分析师擅长从销售数据中识别趋势和异常对数据敏感结论务实。 目标基于以下销售数据分析各品类的销售趋势、发现异常波动并给出可执行的优化建议。 上下文 [此处粘贴数据表格包含日期、品类、销售额、订单量、转化率等字段] 约束 1. 所有分析结论必须有数据支撑引用数据时标注具体数值。 2. 如果发现异常需要判断异常原因并说明数据上体现的线索。 3. 每个建议必须说明预期效果。 格式按以下结构输出—— 一、整体销售概览 二、品类趋势分析 三、异常波动检测 四、优化建议含预期效果 示例 一、整体销售概览本月总销售额为58万元环比增长6.2%主要由3C品类贡献。 二、品类趋势分析3C品类持续增长月中受新型号发布影响出现峰值家居品类连续两周下滑转化率从3.1%降至2.4%。 三、异常波动检测10月18日订单量突降25%可能与促销活动结束有关。 四、优化建议对家居品类做一次流量诊断预期可挽回15%的销售额下滑。这类提示词的关键在于约束1——“所有结论必须有数据支撑”。数据场景最怕模型编造或泛泛而谈加了这条约束之后模型会习惯性地去引用数值哪怕引用错了你也能快速核对修正。如果想让模型做更深入的归因分析可以在上下文里多补充一些背景信息比如营销活动时间表、库存变动记录等分析维度会更丰富。3.4 三个场景的横向差异与通用模板看似三个场景差别很大但结构骨架完全一致只是每个模块的侧重点不同。文档总结侧重约束的精炼性和格式的严谨性代码审查侧重输出的表格化和修复建议的可操作性数据分析侧重数据支撑的强制要求。它们的共同点是每一个模块都在为下一个模块铺垫环环相扣没有一句废话。为了方便复用我整理了一个通用模板你拿过去替换模块内容就能用于绝大多数任务角色你是一名[领域][经验年限][擅长方向][任务视角]的[身份]。 目标[动词][对象][预期产出]。 上下文[与目标直接相关的资料信息]。 约束 1. [硬性红线1] 2. [硬性红线2] 3. [软性建议1] 格式[描述输出结构列出章节、字段或表格列名]。 示例[一段可以给模型做参照的完整输出片段]4. 常见问题与排查技巧这五个坑我全踩过4.1 模型不听指令先检查约束冲突很多人在模型输出不听话时第一反应是“这模型不行”但实际原因往往是提示词里存在约束冲突。比如约束里写了“内容要专业严谨”示例里却用了大量口语化表达或者约束里要求“不超过500字”格式里却指定了五六个章节每个都要详写。模型面对相互矛盾的指令只能自己找平衡点结果自然两边不讨好。排查方法是通读一遍提示词把角色、约束、格式、示例当成一个整体看想象它们是同一个人说的话。如果发现语气、风格、详略要求存在分层优先调整示例去匹配约束因为示例对模型行为的影响通常比文字描述更直接。我自己遇到类似问题时会在约束和示例之间反复对齐两三轮直到它们叙事一致为止。4.2 输出内容总是在细节上胡编收紧上下文边界如果你发现模型输出的核心内容成立但细节经常出现原文没有的信息说明上下文边界写得不够死。模型会在你给的素材之外动用它的“通用知识”去补全细节——这些补全有时候看起来合理但对你来说就是胡编。解决办法有两个方向一是在约束里明确加一条“只允许使用上下文中出现的信息”二是处理完上下文素材本身把与任务无关的背景段落删掉或用占位符替代。比如你只需要文档中某几个章节的信息就把其他章节替换成“[此处信息与任务无关已省略]”模型就不会跨章节找线索了。4.3 格式永远达不到要求把期望输出写成模板很多人抱怨模型生成的表格缺列、JSON少字段、分条混乱根源是格式模块描述得太抽象。你写“请用表格输出”模型理解不了你到底想要几列、列名是什么、需不需要合并单元格。与其描述不如直接把一个有内容的模板放进去。我现在的习惯是遇到需要固定格式的任务在格式模块里直接放一段“空模板”比如| 序号 | 指标名称 | 当前值 | 变化幅度 | 备注 | |------|---------|-------|---------|------| | 1 |待填充|待填充|待填充|待填充|模型看到这种结构会自动明白要照着生成几行、每行填什么内容。这个方法同样适用于JSON结构定义、摘要格式、邮件模板等效果远好于干巴巴的文字描述。4.4 多次运行结果不稳定固定示例并增加收敛条件同一段提示词每次运行结果差别大这种“随机性”是模型采样机制导致的。想收敛输出你可以做两件事一是把采样温度参数调低。如果你用APItemperature设到0.2以下输出会稳定很多二是确保示例出现在靠近输出的位置并且示例本身足够详细为模型提供更强的锚定效应。另外还有一个容易被忽略的点如果你在提示词里用了模糊程度很高的词比如“一些”“各种”“适当”模型每次生成的取舍就会有差异。把这些词替换成明确的数字或范围比如“至少列出5条”“不超过3个方案”“按收入排序取前10”输出的确定感会明显增强。4.5 上下文太长模型开始抽象流失分段处理比硬扛有效当你有一段很长的文本需要处理比如几十页的行业报告一次全部塞进提示词里往往效果不佳模型被超长上下文淹没总结出来的内容容易漏掉重要细节。我常用的做法是“分段法”先让模型对每一章生成一两个要点再把所有要点汇总成完整摘要。这样做多了一步操作但准确性提升非常明显。还有一种进阶做法是“多轮精炼”第一轮让模型从原文中提取关键数据与结论第二轮再让模型基于这些中间结果做深入分析或撰写报告。这样不仅绕开了上下文长度限制还能在中间步骤人为检查输出质量避免最后结果跑偏。我用这种方法处理某行业白皮书时最终输出的报告质量远超一次性生成的版本。4.6 内容过于平淡或缺乏专业深度用角色与示例叠加破局当模型输出“什么都对但毫无亮点”时问题通常出在角色和示例过于平庸。我之前遇到过一个场景让模型分析用户流失原因输出的内容全是常识没有任何洞察。后来把角色从“数据分析师”改成“有十年用户增长经验的增长负责人擅长从数据指标中挖掘用户行为动机”再配上一个深度分析示例输出立刻不一样了——它开始考虑用户心理、行为路径、激励时机这些维度。这个变化背后的原理是角色设定提供了模型调取相关领域知识的“检索入口”而示例提供了输出深度的“模板”。两者叠加比单纯写“要深刻一点”管用得多。5. 六模块结构的进阶用法让它从模板进化为思维框架5.1 省略与简化不是所有任务都要六模块齐全六模块结构是一个完整框架但不是所有场景都需要全部套用。简单任务用简版复杂任务用全版这才是正确的打开方式。比如让人解释一个概念只需要“角色目标格式”三个模块就够了让人写邮件加上“约束”即可只有那些多步骤、强格式、高风险的任务才需要六个模块全部上阵。我在实际工作时会根据任务的“容错成本”来决定投入多少提示词设计精力。容错成本低的任务比如写一段社交媒体文案花30秒写提示词就行容错成本高的任务比如生成合同条款摘要或自动化测试脚本我宁愿多花五分钟把六模块写完整。这套取舍逻辑比机械地套模板效率高得多。5.2 模块间的动态耦合让提示词拥有“上下文记忆”六模块结构的高阶用法是在模块内部嵌入“动态引用”让后文可以指向前文的内容。比如在约束模块写“在格式模块定义的表格中对异常数据行用红色标注”这就是让约束和格式产生耦合。模型对这种引用关系的理解能力很强一旦掌握了这种写法提示词表达能力会增强一个量级。同样示例模块可以反向影响约束模块。如果你准备了两个风格迥异的示例可以在约束里写“参考示例2的风格”模型就会精确切换到示例2对应的输出模式。熟练之后你可以设计出“多示例分支”的提示词——同一任务根据用户输入的不同走不同示例的生成路径这在构建复杂应用时非常实用。5.3 用六模块结构驱动对话式应用如果你在做对话式AI应用而不是一次性的文本生成六模块结构依然有它的用武之地。我建议把六模块作为“系统提示词”放在对话的开头全局约束模型在所有轮次中的行为每一轮用户的新输入则是动态变化的上下文模块。这样模型的角色、约束、格式在整段对话中保持稳定而上下文随对话推进实时更新既保留了灵活度又保证了输出一致性。有一个需要注意的细节在对话式应用里示例模块不应该只给一次而是要在关键节点重复给。比如用户输入了新文档要总结你就把“正确输出样式”的示例再放一次模型会立刻重新校准方向。这种方式比单纯强调“记住之前的指示”有效得多。6. 最后的建议与我的个人习惯这套六模块结构是我在大量调试和项目实战中逐渐打磨出来的。它不算什么秘密本质上就是把人类写需求文档时本来就该有的逻辑移植到提示词里。但我想强调的是再好的提示词结构也替代不了对任务本身的理解。你需要先想清楚你要什么才能写清楚模型该做什么。很多人做不好提示词不是因为技巧不够而是因为根本没想清楚需求。我自己的习惯是每写一个复杂的提示词都会留一个备份文件记录当时的任务、版本号、效果评价。下次遇到类似的任务直接复制修改而不是从零开始。这样积累一年多我的提示词库已经覆盖了各种场景每次使用时微调一下就好工作效率提升得非常明显。最后分享一个小技巧拿到一个新的复杂任务先花两分钟用无序的方式写下你想到的所有要求然后再按照六模块的结构重新组织它们。这个过程本身就是在帮你理清思路很多时候写着写着你会发现原本模糊的需求目标自己变清晰了。提示词工程到最后练的不只是跟模型打交道的能力更是自己把问题想清楚的能力。