1. 先聊聊为什么要单独研究盘古大模型的提示词工程
盘古大模型这个名字，圈内做AI应用的人应该都不陌生。华为这套大模型体系从底层芯片到训练框架都是自研的，它跟ChatGPT这类国外模型在训练数据、对齐策略、底座能力上都有差异，这就导致一个非常现实的问题：你在别的模型上跑得好好的提示词模板，搬到盘古上未必work。我刚开始接触盘古的时候，直接把之前调过的一套GPT风格提示词丢过去，结果输出质量明显打折，回答风格也不对路，这才意识到提示词工程不是"一套话术走天下"，必须针对模型特性做适配。
提示词工程（Prompt Engineering）说白了，就是通过设计输入给模型的指令内容，让大模型输出更贴近你的预期。它解决的痛点很直接：大模型不是搜索引擎，不是你问什么它就老老实实答什么，它的输出高度依赖你对它的"引导方式"。同样一个任务，指令写得模糊，它就给你模糊的回答；指令写得清晰、有结构、有约束，它就能给你一份可以直接拿去用的结果。
这篇笔记适合三类人：一是刚接触盘古大模型、想快速上手的开发者；二是企业内部做AI落地方案、需要稳定调用大模型能力的工程师；三是做AI产品设计、需要把提示词模板沉淀成团队资产的产品经理。我会把自己踩过的坑、验证过的技巧、最终沉淀下来的模板结构都摊开来写，供你直接参考复现。
2. 盘古大模型提示词工程的整体认知框架
2.1 先建立正确认知：提示词是在"对齐预期"，不是"命令机器"
我刚做提示词工程的时候，犯过一个典型的错误：把大模型当成传统软件系统，以为指令写得越简短越"高效"。后来连续试了几个任务，发现简短指令的输出质量波动非常大，同一个prompt跑三次，三次结果差得离谱。原因在于，盘古这类大模型本质上是一个概率化的文本生成系统，它对指令的理解取决于指令中携带的上下文信息量和约束强度。你给的上下文越充分、约束越明确，它的生成空间就越收窄，输出自然越稳定。
打个生活化的比方：你跟一个刚入职的新人交代工作，只说"把这份报告处理一下"，他大概率会懵，不知道该按什么格式、该重点突出什么、该输出成什么样子。但如果你说"把这份报告里的核心指标提取出来，按表格格式输出，只保留最近三个月的趋势数据，最后给出结论建议"，他就能干得跟老员工一样利索。提示词工程干的就是这件事，把你脑子里的完整需求，翻译成大模型能精确理解的"工作说明书"。
另外要特别注意一点：提示词工程不是一次性的，它是一个持续迭代的过程。我见过很多团队把prompt写一版就上线，出问题就靠模型随机抽奖，这是完全不健康的做法。合适的做法是像做代码一样管理提示词——每次修改都记录版本、标注变更原因、保留回归测试样本，这样你的提示词质量才能稳步上升。
2.2 盘古大模型的特性差异：为什么不能照搬其他模型的提示词
我在实践中总结出盘古大模型在提示词适配上有几个明显的特点，这些差异直接决定了你写提示词时的策略：
第一，盘古对中文语境的理解深度明显优于英文。这跟它的训练语料分布有关，所以如果你的业务场景是中文内容处理，盘古是很好的选择；但反过来，如果你的提示词是用英文写的，输出质量和中文写的有可见差距。我建议一律用中文写提示词，哪怕只是内部测试也优先中文。
第二，盘古对结构化指令的格式敏感度较高。它更适应逻辑清晰的指令排列，比如"先做什么、再做什么、最后输出什么"这种带顺序的指令，它执行起来比一句混在一起的长段落更稳定。
第三，盘古在长上下文场景下的召回能力需要主动引导。如果你给它一段很长的背景材料，直接问问题，它有概率忽略材料中关键细节；但如果你在提示词里明确说"请优先参考背景材料中的第X部分"，效果会好很多。
这些差异说起来简单，但在实际调优过程中非常关键。我后面讲的所有技巧，本质上都是围绕"盘古更擅长什么、不擅长什么"来设计的。
2.3 提示词工程的完整流程：设计-验证-迭代-沉淀
在做盘古提示词实践的这段时间里，我沉淀出一套可复用的工作流，总共四步：
第一步是需求拆解。把业务需求翻译成"模型任务"，明确你到底要让模型做什么——是分类、抽取、生成、改写还是问答？这一步决定你后续prompt的结构。第二步是初版设计。按角色的设定、任务指令、输入数据、输出格式、约束条件五个要素来搭建提示词结构，这一步我会在下一节详细展开。第三步是验证评估。准备一组覆盖典型场景的测试用例，让模型逐个跑，看输出是否满足预期，记录失败案例。第四步是迭代优化。针对失败案例调整提示词表述、补充示例、收紧约束，改完后重新跑测试用例验证。
这套流程看起来不复杂，但坚持做下来的人很少。很多人写prompt是"感觉不对就重写一版"，完全没有测试基准和版本记录，这样调出来的prompt最终只能靠运气。我更推荐像管理代码一样管理prompt：每个版本存一份，测试集不变，改一处跑一遍全量回归，这样你才能清楚地知道哪次修改带来了真正的提升。
3. 提示词结构化设计的核心技巧：五个要素逐个拆解
3.1 角色设定：让模型进入正确的"工作状态"
角色设定是提示词里投入产出比最高的一个要素。一个合理的角色设定能让模型的输出风格、用词习惯、思考角度瞬间切换到对应的模式。我实测下来的体感是：给盘古设定角色前后的输出质量差异，比我想象的大得多。
比如你要做一份产品分析报告，如果提示词直接写"帮我分析一下这个产品"，模型输出的内容会比较泛，什么都说一点，但什么都不深入。但如果你写"你是一名有十年经验的产品战略分析师，请从市场定位、用户需求、竞争格局、商业模式四个维度分析以下产品"，模型的输出就会明显更有框架感、用词更专业、分析更聚焦。
在设定角色时，我总结了一个原则：角色描述不要太虚，要包含"领域+经验层级+分析视角"。光说"你是产品分析师"是不够的，加上"有十年经验"和"从市场定位、用户需求、竞争格局、商业模式四个维度"这种约束，模型的输出才真正有质量。角色设定相当于给模型一个"身份锚点"，它后续的整个生成过程都会被这个锚点牵引。
3.2 任务指令：把"做什么"说清楚，把"怎么做"说透
任务指令是整个提示词的核心。写任务指令最常见的坑有两个：一是任务太笼统，二是任务指令里混入了太多无关信息。
我一般推荐用"动词开头+宾语+补充条件"的句式。比如"提取这份合同中的付款条款、违约责任和争议解决方式三项关键信息，并分别用简洁的一句话概括"，这个指令比"帮我看看合同里有什么重要内容"靠谱得多。关键信息、概括方式、输出范围全都在指令里限定了。
还有一个细节：任务指令尽量放在"输入数据之前"。很多新手爱把提示词写成"以下是某合同全文，请你提取关键信息：合同内容……"，这其实削弱了指令的权重。更合适的结构是"先给出任务指令，再交代输入数据来源，再贴数据"，让模型先理解要执行什么任务，再去读数据，它的处理逻辑会更清晰。
3.3 约束条件：用边界限定减少"自由发挥"
约束条件是控制输出质量稳定性的关键。大模型在没有约束的情况下倾向于生成"看起来合理但未必可用"的内容，你必须在提示词里明确定义边界。
我常用的约束手段有这么几类：
- 格式约束："用表格输出""每项不超过50字""用JSON格式返回"
- 内容范围约束："只基于提供的数据回答，不要补充外部信息""不要涉及与问题无关的内容"
- 负面约束："不要输出空话套话""不要编造不存在的条款""不要输出分析步骤，直接给结论"
- 数量约束："最多列出5条""只提取最近一条"
约束条件的写法要注意一个平衡：约束太少模型自由发挥空间大，输出飘；约束太多模型可能被指令束缚，输出变得僵硬、机械。我的经验是优先用"正面约束"说清楚要什么，再用少量"负面约束"堵住常见问题点。一上来就写一堆"不要这样、不要那样"，模型容易糊涂，反而影响执行效果。
3.4 示例引导：给一个样板，胜过解释一百句
如果你希望模型输出的格式、风格、结构符合某种特定预期，最有效的方式不是文字描述，而是直接给一个示例。这本质上是利用了大模型的上下文学习能力，你在提示词里给它一个"标准答案"，它就会朝着这个方向模仿。
举例来说，你要让模型做"观点摘要"，文字描述写"用简洁的语言概括观点，提炼核心论点"，模型给出的结果可能五花八门。但如果你在提示词里附上一条示例：
输入："我认为远程办公降低了团队沟通效率，但也提升了员工的时间自主性。" 输出："观点摘要：远程办公提高了员工自主性，但降低了团队沟通效率。"
模型就会明白，你要的是这种"先结论、后结构"的精简摘要风格，而不是一段完整的叙述。经过我多次实测，带示例的prompt在输出格式稳定性上比纯文字描述高出很多，这个技巧值得每个做盘古提示词工程的人熟练掌握。
3.5 输出格式设定：让结果可解析、可复用
如果你调用盘古不只是给人看，还要接入业务系统做下游处理，那输出格式设计就不能忽略。我在实际项目中强烈推荐在提示词里显式声明输出格式，尤其是让模型输出JSON时，一定要给出完整的JSON结构示例。
比如你让模型做合同关键信息抽取，输出格式可以这样设定：
{ "付款条款": "", "违约责任": "", "争议解决方式": "" }然后把这段JSON结构直接放进提示词里。盘古看到具体结构后，输出的结果基本能保证字段名一致、格式可解析。如果只写"输出JSON格式"，模型有可能把字段名改了、嵌套层级乱了，你在下游解析时就得写一堆容错代码，成本非常高。
关于输出格式我还有一个经验：如果业务系统要稳定解析，最好在提示词末尾重复一遍"严格按照上述JSON结构输出，不要添加任何额外文字"。这个"最后强调"动作看起来多余，实测下来能显著减少模型输出前言后语的情况。
4. 盘古提示词工程实操：从需求分析到稳定输出的完整链路
4.1 场景选择与需求拆解：先想清楚让模型做什么
理论技巧说到底还是要落到具体场景里。我拿一个实际做过的项目来拆解——用盘古大模型做电商评论分析。这个场景很典型，既有文本抽取、又有情感判断、还有结构化输出，覆盖了提示词工程的大部分核心知识点。
需求拆解环节，我先问自己三个问题：第一，这个任务涉及几个子任务？第二，每个子任务的输入是什么、输出是什么？第三，输出的质量标准是什么？
电商评论分析拆完后是这样的：任务一是从评论中抽取商品属性（如"屏幕""电池""手感"）；任务二是判断每个属性的情感倾向（正、中、负）；任务三是对负面评价生成简短的改进建议。三个子任务有先后关系，输入都是同一条评论，输出是一个结构化结果。
拆解完需求，我才开始设计提示词。很多新手跳过需求拆解直接写prompt，写到一半发现任务边界不清，改来改去浪费时间。先拆需求再写提示词，看起来多了一步，实际省的时间远超成本。
4.2 初版提示词编写：完整示例与设计思路
基于上面的需求拆解，我写出的初版提示词是这样：
你是一名电商产品分析专家。以下是用户对某商品的评论，请完成以下三个任务： 任务一：从评论中抽取提到的商品属性词汇，如"屏幕""电池""手感""物流"等。 任务二：判断每个属性的情感倾向，只输出正面/中性/负面三种结果。 任务三：对情感倾向为"负面"的属性，输出一条不超过20字的改进建议。 请严格按照以下JSON格式输出，不要添加任何额外文字： { "属性": ["属性1", "属性2"], "情感": {"属性1": "正面/中性/负面"}, "改进建议": {"属性1": "建议内容"} } 评论内容： "手机屏幕很清晰，但电池掉电太快了，一天两充，手感倒是挺舒服的。"这个提示词的结构是：角色设定（电商产品分析专家）→任务拆解（三个明确的子任务）→输出约束（严格JSON格式）→输入数据（评论内容）。每条指令都对应一个明确的执行预期，模型拿到这个提示词后，完成度会高很多。
实测下来，这个初版提示词已经能完成大部分评论的分析，但我也发现了一些问题：比如模型有时候把"物流"识别为属性，哪怕评论里根本没提物流，这是模型基于训练先验脑补出来的。针对这类问题，我在后续迭代中增加了创作出的约束条件"只抽取评论中明确提到的属性，禁止补充评论中未出现的词汇"。
4.3 测试集构建与回归验证：用数据说话才能持续优化
提示词写完了，不能直接上线，先构建测试集做验证。我构建了50条真实评论作为测试集，覆盖了不同商品品类、不同情感倾向、不同长度、不同口语化程度的评论。每次调整提示词，都用这50条数据跑一遍回归，统计三件事：属性抽取的准确率、情感判断的正确率、输出格式的可解析率。
这里我要特别强调测试集固化的重要性。没有固定测试集，你改了一版prompt，感觉"好像好了一些"，但根本说不清好在哪。有了固定测试集和指标统计，每次改动都能量化评估，优化方向自然就清晰了。我建议做提示词工程的团队都建一个这样的回归测试集，哪怕先搞30条，也远胜于没有。
第一版提示词跑完回归后，我看指标的统计数据发现，情感判断正确率大约在82%，格式可解析率95%，属性抽取准确率只有76%，主要误差来源就是模型脑补评论中不存在的属性。根据这个数据，我做了一次针对性迭代，在提示词里加入了限制条件，并且增加了一条示例，把模型"聪明"的脑补行为约束住。
4.4 迭代优化实录：一次真实的提示词调优过程
迭代的过程我完整记录下来说明问题。第二次修改的提示词加了两处：一是在任务一后面追加了"只抽取评论中明确提到的属性，禁止补充评论中未出现的词汇"；二是在任务描述后面给了一条示例作为引导。
改完后重跑50条测试集，属性抽取准确率从76%升到了89%，情感判断正确率稳定在88%，格式可解析率到了98%。这个提升说明一个道理：提示词优化的空间确实很大，但前提是你知道问题出在哪。如果我没有测试集，只看两条输出就下结论"差不多行了"，那这个提升永远发现不了。
第三轮迭代时，我发现一个更隐蔽的问题：有些评论包含了"卖家服务态度好"这类跟商品本身无关的内容，但我的提示词只要求抽取"商品属性"，模型会把"服务"也抽取进来，导致下游分析时商品维度和服务维度混在一起。于是我在提示词里加了一个维度限定："仅抽取商品本身的属性，不包括服务、物流、包装等非商品维度"。这一轮改完，准确率达到了94%。
三轮回合下来，提示词从初版变成了接近终版的形态，每次改动都有明确的问题指向和验证数据支持。整个过程恰好印证了我前面强调的工作流：设计、验证、迭代、沉淀，一步都不能少。
4.5 场景扩展：提示词工程在更多业务场景中的落地方式
电商评论分析只是其中一个场景。我在盘古大模型的实践中还跑过几个不同类型的任务，这里简单列几个供你参考：
文本分类场景：比如工单智能分类。提示词设定"你是工单处理专家，请将以下工单分类为账号问题、支付问题、技术故障、咨询建议四类之一，输出类别名称和置信度评分"。
内容生成场景：比如营销文案生成。提示词设定"你是资深电商文案策划，请根据以下商品卖点生成三版不同风格的商品详情页文案，每版不超过100字，分别侧重性价比、品质感、差异化"。
信息抽取场景：比如发票信息录入。提示词设定"你是一名财务票据录入员，请从以下发票图片文字识别结果中提取开票日期、发票号码、金额、商品名称四个字段，按JSON格式输出"。
这些场景的共同点是：都有明确的结构化输出需求，都靠角色设定引导方向，都用约束条件控制输出边界。你只要掌握了五个要素的组合方法，任何文本处理类任务都能套用这个思路快速上手。
5. 常见问题与排查技巧实录
5.1 问题一：输出不稳定，同一提示词多次执行结果差异大
我刚开始调盘古提示词时，遇到最烦人的问题是输出不稳定。同一个提示词跑五次，三次结果可接受，两次结果跑偏。排查下来主要有三个原因：
第一是提示词约束过弱。模型生成空间太大，每次采样都在不同方向上游走，输出自然不稳定。解决办法是增加约束条件，尤其是数量约束和格式约束，收窄生成空间。第二是输入数据过长。评论输入超过模型的有效处理长度后，模型对关键信息的关注度会下降，输出随机性增加。解决办法是预处理输入数据，先截取关键段落再让模型处理。第三是温度参数设置过高。如果你调用的是API，可以调低温度参数（盘古API一般支持配置），温度越低输出越稳定，代价是创造性降低。这三项排查下来，基本能解决80%的输出不稳定问题。
5.2 问题二：模型"一本正经地胡说八道"，幻觉问题如何处理
幻觉问题在任何大模型上都存在，盘古也不例外。它会在你不知道的地方编造不存在的细节，尤其是涉及数字、人名、条款、金额时特别容易出现幻觉。
我在合同信息抽取项目中遇到一个典型案例：合同里明明没写违约金条款，模型却根据训练先验"补全"了一条违约金比例，这个比例完全不存在，差点造成业务误判。针对这个问题的解法，我总结了三层防护：
第一层是提示词约束："只根据提供的材料内容回答，如果材料中未提及相关信息，请明确输出'未提及'，禁止编造或推测"。这一句话就能显著降低幻觉概率。第二层是对输出做规则校验，比如金额、日期这类字段，可以用正则表达式和数据字典校验合法性。第三层是对关键信息设置人工复核环节，涉及重大金额和条款的内容不依赖模型一次性输出，安排人工确认。
5.3 问题三：输出格式不符合预期，解析失败怎么办
格式解析失败是调用大模型做业务系统时最让人头疼的问题之一。模型输出了一堆JSON，但字段名变了、多了引号"前言"、嵌套层级错了，下游代码直接崩。
我的排查思路是先从提示词层面解决。核心手段是把输出格式的约束写在任务指令之后、输入数据之前，同时给出一个完整的JSON结构示例。这一步能让格式可解析率从70%左右提升到95%以上。第二步是做好降级方案，即解析失败时自动重试一次，重试时在提示词末尾追加强调"严格按照上述格式输出"。如果连续两次都失败，则记录原始输出到日志，方便人工排查。
在项目里我还会做一个轻量级后处理：正则替换掉模型可能加的"```json"标记和首尾空行，提高解析容错率。这套组合拳下来，格式解析基本就不太会成为卡点。
5.4 问题四：提示词越来越长，效果却在退化
提示词不是越长越好。我把提示词从100字加到500字的过程中，发现输出质量有一个"先升后降"的曲线。原因在于模型对指令的关注是有限的，冗长的提示词会让核心指令被淹没在大量背景信息里。
解决这个问题的方法是学会"做减法"。每一版prompt写完都问自己三个问题：这句话对约束输出有实际作用吗？去掉它结果会明显变差吗？这句话是不是可以用一个更精确的词替代？我的经验是，一段prompt里保留角色设定、任务指令、输入位置、输出格式、必要约束五件事就足够了，其他修饰性描述能省则省。
5.5 常见问题速查表
我在实践中把高频问题整理成了一个排查表，分享出来可以直接对照使用：
| 问题现象 | 可能原因 | 首选排查手段 |
|---|---|---|
| 输出内容发散、不聚焦 | 约束条件不足 | 增加数量、范围、负面约束 |
| 同一输入多次输出差异大 | 温度参数偏高/约束过弱 | 调低温度参数、收紧指令 |
| 模型编造不存在的信息 | 推理脑补 | 增加"禁止编造、未提及就写未提及"约束 |
| 输出格式解析失败 | 格式约束不明确 | 提示词中显式给出JSON结构示例 |
| 对长文本关键信息漏抓 | 上下文过长 | 预处理切片+提示词引导优先看某部分 |
| 提示词过长导致效果退化 | 指令被淹没 | 精简提示词，只保留核心要素 |
| 中文任务输出夹杂英文 | 语言指令不强 | 增加"全程使用中文回答"约束 |
这张表我建议贴在你写提示词的工作区旁边，遇到输出问题先对照排查，比从头到尾读一遍prompt逐个猜效率高得多。
6. 把提示词工程当成一项长期资产来经营
6.1 提示词版本管理：像管理代码一样管理prompt
提示词工程做到后期，最大的痛点不是写不出好prompt，而是改坏了不知道回退到哪一版。我在项目中吃过大亏：精心调了一个月的prompt集，被一次不谨慎的批量修改全部破坏，回退无门，只能凭记忆重写，浪费了两天时间。
从那以后我开始用版本管理的思路处置提示词。每次改动前先存一份快照，命名规则是"场景名_版本号_日期"，比如"评论分析_v3_20250115"。改动说明也同步记录：这次改了什么、解决什么问题、测试集指标变化。这样即使改坏了，也能快速回退到上一个稳定版本，不至于推倒重来。
如果你的团队有多个人同时维护提示词，建议把prompt存到支持协作的地方，用类似代码评审的方式合并修改。这个习惯刚开始会觉得啰嗦，但它能让提示词资产从"个人经验"变成"团队资产"，价值完全不同。
6.2 提示词模板化：把可复用的模式沉淀成工具
当一个场景的提示词调通之后，我建议顺手做模板化改造，把可变的输入部分和固定的逻辑部分分离。比如评论分析场景，固定部分是角色设定、任务拆解、格式约束；可变部分是商品类型、评论内容、情感分类维度。把固定部分做成模板，可变部分用参数填充，这样换一个商品品类、换一批评论，只需要换参数就能跑，不需要重新设计提示词。
我在实际项目里就把评论分析模板用在了手机、家电、美妆三个品类的评论数据分析上，五分钟就能切换一个品类，效率提升非常明显。产品经理拿着这套模板去验证新场景需求，几乎不用开发介入就能输出初步结论。
6.3 与模型协作的正确心态
做了几个月盘古大模型的提示词工程，我最大的体会是：不要把这个过程理解成"驾驭模型"，而是理解成"与模型协作"。提示词不是命令，是一种沟通方式。你需要像一个优秀的项目经理，把需求描述清楚、把边界划定明白、把验收标准讲透，模型才能发挥出它的能力上限。
在这个过程中，失败是常态，迭代是主旋律。我第一次做评论分析任务时，花了整整两天才把准确率从76%提到94%。但积累下来的不只是那一条调好的prompt，而是一整套方法论：如何拆需求、如何设计提示词结构、如何构建测试集、如何做回归验证。这套方法论才是提示词工程最核心的资产，换一个场景、换一种模型，它都能复用。
根据我个人经验，判断一条提示词是否调好的标准很简单：连续跑十次，输出结果的一致性够不够高？格式能不能稳定解析？关键内容有没有明显错误？如果这三个问题的答案都让人满意，那这条提示词就可以交付了。至于要不要继续优化到99%以上的准确率，取决于业务需要，不必追求一刀切的完美。
