有一段时间我同时维护着几个不同团队的大模型应用，最直观的感受是：同一个模型，同一个接口，换一个人写提示词，结果能差出一大截。这真不是玄学。大语言模型提示词工程在过去两年里，从一套“看着像心理安慰的措辞技巧”逐渐变成了一门可以拆解、可以测试、可以复制的方法论。这篇是系列第03篇，前面已经聊过大模型的基本能力和部署选型，今天集中把提示词工程讲透：它到底在优化什么、底层机制是什么、怎么写才能稳定复现，以及在本地部署、视觉大模型、算力受限这些新场景里，提示词的写法又要怎么调整。

我不会给你一堆“神奇咒语式”的模板，因为脱离底层逻辑去背模板，换个模型、换个任务就会失灵。我们直接从模型的文本生成机制说起，再给出一套我自己在项目里反复验证过的写作框架，最后把这段时间踩过的坑和排查方法一起放出来。

1. 先把大模型的“理解”拆清楚：提示词工程的前提

1.1 提示词不是对话，是一次概率生成的约束条件

很多人写提示词的时候，脑子里默认的模型是“一个能听懂人话的助手”，所以会像跟同事聊天一样表达需求。这个直觉害了很多人。大语言模型本质上并不是在“听懂”指令，而是在根据当前所有输入端内容，计算下一个最可能的Token是什么。我说得再直白一点：模型不是一个理解者，而是一个超高维的概率预测器。

提示词工程做的事情，其实就是给这个概率预测器划出一条更窄、更明确的输出路径。你提供的信息越结构化、约束越清晰，模型可选的输出范围就越小，结果自然越稳定。这也是为什么同一个问题，你写“帮我写个方案”和写“你是产品负责人，请围绕以下三个板块输出一份项目立项方案，每个板块不超过200字，不要输出开场白和结束语”得到的结果完全不是一回事。

理解了这层机制，很多问题就能看明白了：为什么模型会一本正经地编造？因为它算出来那个编造的Token序列在当前语境下概率最高，它并没有一个“事实真理核验器”。为什么同一句提示词换个人名结果就差了？因为Token序列变了，概率分布就变了。提示词工程的本质是“约束概率分布”，不是“感动模型”。

1.2 上下文窗口与注意力：模型更“在意”靠后的内容

接着上面聊，大模型处理输入的时候，并不是把每一个字都同等看待。Transformer架构里有注意力机制，模型在生成每个Token时都会回头看上下文里的其他Token，但对不同位置的信息关注度是不一样的。实际项目里有一个非常普遍的现象：一段很长很长的输入中，提示词里写在前面的角色设定和任务说明可能被“冲淡”，而写在最后的约束条件往往效果最强。

这个现象跟模型结构的“近因偏好”有关，也和训练数据中文本位置规律有关。虽然不同模型、不同版本的具体表现有所差异，但有一条经验基本通用：上下文里位置越靠后的信息，对下一个Token生成的影响通常越大。这就导致两个非常实用的推论：

• 关键指令不要只写在开头，重要约束条件建议在末尾再强调一遍，或者在用户输入之后、生成内容之前直接插入一句“请严格按照以上要求执行”。
• 如果你有一个“无论如何不能被忽略”的规则，把它放在提示词的开头和结尾各写一次，但不要重复太多次。重复个两三次有助于强化，重复五次以上就会稀释信息密度，反而让模型把注意力平均分配。

在微调或者接API做产品的时候，我们还会用到一些更硬的手段来保证关键指令生效，比如用代码逻辑强制解析输出格式、做输出的规则校验，而不是全指望提示词。“提示词是概率约束，校验是确定性兜底”，这两句话我建议你抄下来。

1.3 解码策略：Temperature、Top_p这些参数怎么配合提示词

提示词工程经常忽略一个非常重要的变量：解码参数。很多人在产品里直接把temperature默认成1.0，然后抱怨模型不稳定，这其实是提示词工程的一部分没有做到位。

解码策略决定了模型从概率分布里“挑选Token”的方式。简单类比一下：如果把提示词比作一份菜谱，解码参数就是厨师的发挥尺度。Temperature低（比如0.2）意味着厨师严格按照菜谱做菜，发挥空间很小，输出稳定、刻板；Temperature高（比如0.9）意味着厨师自由发挥，菜品更有“创造力”，但你也得接受偶尔端上来一盘黑暗料理。

我的项目经验是这样的：

• 做信息抽取、分类、代码生成、结构化输出，Temperature设置在0.1到0.3之间最稳，同时把Top_p压到0.7左右，能有效减少无关Token。
• 做创意文案、头脑风暴、开放写作，Temperature可以放到0.7到0.9，但前提是你在提示词里已经给了足够的风格示例和边界约束，否则“创意”容易变成“跑题”。
• 如果预算不足，只允许你调一个参数，优先降Temperature。有时候同样的提示词，从1.0降到0.2，效果提升比改三版提示词还明显。

另外那个max_tokens参数很多人也理解错了。它不是“最多生成这么多字”那么简单，它同时是给模型的一个隐式信号：如果max_tokens设得太小，模型会倾向于加快结束速度，牺牲细节；如果设得太大，在Temperature偏高的情况下反而容易让模型在结尾处“放飞自我”。做线上服务的时候，建议max_tokens比预期输出长度留出15%到20%的余量，而不是卡得刚刚好。

2. 提示词五要素：一套能落地的编写框架

2.1 角色、任务、约束、输出格式、示例怎么组合

市面上讲提示词的文章特别多，但我实际用下来，真正稳定好用的提示词基本都能拆成五个要素，缺一个，效果就会打折扣。这五个要素是：角色设定、任务描述、约束条件、输出格式、示例（少样本）。我把它们的作用和常见错误整理成了一张表：

角色设定为什么放在第一位？因为角色本质上是在提示模型“用哪一部分参数空间里的先验知识”。你写“你是资深律师”和写“你是小学老师”，调动的知识侧重和表达风格是完全不同的。但角色设定一定得配合具体的任务描述，否则模型会陷入一种“表演角色”的状态，说一堆正确但没用的场面话。

任务描述是五要素里最重要的一个，也是最容易被写废的一个。判断一个任务描述好不好，有一个我常用的土办法：把它发给一个完全不懂背景的实习生，如果实习生看完了不知道怎么动手、不知道交什么结果，那这个任务描述就是不合格的。写任务描述的时候，动词要具体：不要写“分析一下”，要写“请对比以下三个方案的成本构成，输出差异列表”；不要写“帮我总结”，要写“请提取该文档中的决策项、负责人、截止时间，按时间顺序排列”。

约束条件通常是被新手忽略的。模型默认情况下有“过度生成”和“自作主张补充前提”的毛病，所以必须显式告诉它什么不能做、遇到边界情况怎么处理。比如“如果文章里没有明确提到截止时间，请输出‘未提及’而不是推测一个时间”“如果用户的问题不在你的知识范围内，请直接说不知道，不要编造”。

输出格式其实关乎工程可用性。在真实系统里，提示词输出的自由度越低越好。把“用JSON格式输出”写在提示词里，和写“输出一个包含时间、地点、金额的清单”得到的结果，在解析成本上天差地别。

2.2 一个具体案例：从一句话需求到规范任务说明

光讲理论没意思，直接上一个我最近在带的实际案例。假设我们需要让模型把一段会议纪要提炼成待办事项，并且按负责人分组输出。

最初的提示词是这样写的：

请帮我总结一下这个会议纪要，列出需要做的事。

这个提示词能跑，但输出结果很不稳定：有时候会说“大家需要跟进项目进度”这种空话，有时候又会把会议中的某个讨论内容强行变成待办，还经常漏掉责任人。

我把它改成五要素完整版之后，效果稳定了很多：

你是一名项目助理。请阅读以下会议纪要，完成两项任务：第一，提取所有明确的待办事项；第二，为每个待办事项标记负责人和希望完成时间。约束条件：只依据纪要中已经出现的信息，纪要中未提到的负责人和时间统一输出为“未提及”，禁止推测；不要输出任何总结性评价。输出格式：Markdown表格，列为“序号、待办事项、负责人、截止时间、来源段落编号”。示例：

序号	待办事项	负责人	截止时间	来源段落编号
1	完成新用户调研问卷设计	张三	3月5日	第2段

为什么这个提示词效果好？因为它做对了几件事：第一，角色“项目助理”让模型启用了工作场景的语料先验；第二，任务描述把“总结”变成了“提取待办事项”这个明确行为；第三，约束条件堵住了模型“猜测未知信息”的老毛病；第四，输出格式限定了最终产物，而且给出了示例做锚点。特别是那个“来源段落编号”，一旦加上，模型编造事实的概率大幅下降。

2.3 输出格式那点事：JSON、Markdown、代码块的副作用

我自己做应用的时候，80%的场景都要模型输出结构化数据。这里有三个直接能用的经验：

第一，JSON格式要配合“不要输出多余内容”的约束。只写“输出JSON”是不够的，很多模型会好心地在JSON外面加上```json代码块标记，或者输出一句“以下是您需要的JSON：”再开始正文。这对人阅读没什么，但对程序解析就是灾难。我一般在提示词末尾加一句话：“直接输出JSON对象本身，不要包裹在代码块中，不要输出任何解释文字。”这句话能消除超过90%的解析失败。

第二，Markdown表格虽然好看，但如果你要的数据量很大，表格会让Token消耗成倍增长。Markdown表格里的竖线、空格、对齐符号都是Token，而且模型在保持表格对齐时容易出错。数据量小、给人看的场景用表格没问题；数据量大、要入库的场景，强烈建议用JSON或CSV。

第三，代码块里的内容并不会自动规避格式错误。很多模型在输出JSON时会出现单引号代替双引号、末尾多一个逗号、缩进错位这类小问题。这没法单靠提示词100%保证，工程上必须在模型输出后面接一层解析校验，解析失败就重试一次。重试时的提示词不用改，直接说“上次输出格式不符合要求，请严格按照JSON格式重新输出，只输出JSON本体”通常就能解决问题。

3. 上下文工程：提示词工程的扩展层

3.1 不是提供得越多越好：信息密度与位置偏见

现在越来越多的人在讨论一个话题：上下文工程。它和提示词工程的区别，我理解成一句话：提示词工程管的是“怎么下达指令”，上下文工程管的是“往上下文里放什么内容”。两者是递进关系，你提示词写得再好，如果塞进上下文的内容本身杂乱无章，模型一样会输出垃圾。

我遇到过很多次这样的情况：为了让模型回答得更准确，业务方把几十页的文档原封不动塞进上下文，然后指望模型给出精准答案。结果模型被大量无关段落干扰，反而忽略了对回答真正有用的信息。

这里就引出一个很重要的概念：信息密度。上下文窗口再大，模型能同时“专注”的内容也是有限的。注意力机制并不是把所有Token平等对待，大量无关信息会稀释关键信息的注意力权重。所以上下文工程的第一原则是：在喂给模型之前，先自己做一轮信息筛选，而不是把原始材料一股脑丢进去。

实操上我一般这样做：先用便宜的小模型或规则脚本对长文档做预筛选，只保留跟当前问题相关的段落；然后把筛选结果交给大模型做最终生成。这样既省Token，又能让大模型把注意力集中在关键信息上。这个做法比单纯调大上下文窗口靠谱得多。

3.2 “迷失中间”与重排序：长上下文的实操应对

关于长上下文，有一个已经被很多实验证实过的现象：模型对上下文开头和结尾的内容记忆更好，对中间部分很容易“迷失”。这有点像人开会，会议开始和结束时的内容记得最清楚，中间糊里糊涂。

这个现象对上下文工程有两个直接指导意义：

• 关键内容要放到上下文的两端。如果你有一批背景材料，最核心的结论和要遵循的规则应该放在开头和结尾，而不是夹在文档中段。辅助性的论证材料放中间，即使被模型“遗失”了，影响也不大。
• 如果上下文很长，可以对内容做重排序。比如从一堆PDF里检索出的段落，不是按原始文档顺序拼接，而是按“与问题的相关度”从高到低排列。把最相关的段落放在上下文开头和结尾，能显著提升回答质量。

做过RAG（检索增强生成）项目的朋友应该会有共鸣：同样的embedding和检索链路，仅仅调整拼接顺序，回答准确率就能提升好几个点。这不是玄学，是位置偏见在起作用。

3.3 检索增强和上下文工程的关系

很多人把RAG理解成“给模型装了一个外挂知识库”，这没错，但容易忽略一个细节：RAG本身并不改变模型的推理方式，它只是决定了“把哪些文本放进上下文”。检索增强是上下文工程的一种实现手段。

我在做RAG系统时的经验是：别把所有希望都寄托在检索质量上，还要重视检索结果被送进大模型之前的“整理”环节。比如，把多个检索段落合并之前，先做去重；段落之间加上简洁的引文标识（“以下内容来自文档A”）；每个段落末尾附上来源信息。这些整理工作能让模型更清楚每段内容的性质，减少它张冠李戴的概率。

更进一步，上下文工程还包含一个很多人没有意识到的环节：后置指令。在用户问题之后、生成回答之前，可以插入一句“请基于以上提供的资料回答问题，如果资料中没有相关信息，请明确说明”。这句话相当于在模型开始生成之前再拉一次“紧箍咒”，能有效减少模型绕开上下文自由发挥的情况。

我理解提示词工程和上下文工程的关系是这样的：前者是给模型一个清晰的“做事方式”，后者是给模型提供一份干净的“作业材料”。两者都做扎实了，模型才可能稳定输出。

4. 系统提示词与Skill Agent：把提示词从“一次性”变成“常驻能力”

4.1 系统提示词为什么比对话首句更稳定

做产品的时候，我们通常不是靠用户自己写好提示词，而是要在后端配置一套系统提示词。系统提示词出现在上下文的头部，在架构上处于一个比较特殊的位置：它是模型开始处理所有用户消息之前就已经存在的指令。

系统提示词和普通首条消息最大的区别在于，它的“指令权重”被很多模型设计得更高。虽然具体实现细节各家不同，但在大部分主流API中，系统提示词都是被特别对待的。这就像你跟一个人做事之前先签了一份合同，后续沟通都得按合同条款来。

实际使用中有几个注意点：

• 系统提示词不要写用户视角的内容。常见错误是把系统提示词写成“如果你是用户，你会怎么选择”，搞乱了视角，结果模型输出就飘了。
• 系统提示词要写规则，不要写口号。“你必须帮助用户”这种话基本没用；“当用户请求违反安全政策时，礼貌拒绝并建议联系管理员”才有用。
• 系统提示词的长度要克制。有些团队在系统提示词里堆了上千字的公司介绍、产品背景、品牌调性，真正关键的指令被淹没在一堆背景材料里。真正重要的指令不超过300字最好，背景材料可以挪到上下文的信息区，而不是跟指令混在一起。

我在生产环境里还养成了一个习惯：不用单一的静态系统提示词，而是维护一套“规则库”，根据用户的请求类型动态组合系统提示词。比如用户在多轮对话中触发“写代码”意图，就注入代码生成相关的系统提示词；用户触发“总结”意图，就注入摘要规则。这其实就是把提示词工程从“手工编写”推向“工程化管理”。

4.2 Skill Agent的工作原理：提示词 + 工具 + 状态

最近很多人在讨论Skill Agent这个概念，其实它不是什么神秘的新东西。在我看来，Skill Agent是一种把提示词、工具调用、状态管理封装在一起的执行单元。传统提示词的输出只有“文本”，而Agent的每一次执行可以包含“决策”、“调工具”、“输出文本”等多个环节。

举个最简单的例子：一个“周报助理”技能。单靠提示词，我们只能让模型“生成一段周报文字”；但做成Skill Agent之后，它可以从日历工具里拉取本周安排，从协作工具里读取任务状态，再结合这些数据生成周报草稿。这里的核心不是提示词更多或更复杂，而是把“生成文本前的输入获取”和“生成文本后的动作执行”也纳入了流程。

Skill Agent里的“技能描述”本质上是一段高质量的提示词，但它多了一个重要字段：何时触发。系统在每轮对话开始时，会先判断用户意图是否匹配某个技能描述，匹配才加载对应的提示词和工具。这个机制解决了一个老问题：你没法在系统提示词里塞下所有场景的指令，塞多了互相打架；而技能化的管理方式让每个提示词保持精简，只在需要时被激活。

此外Skill Agent还有一个“状态”维度。它可以记住技能执行到哪一步了，哪些信息已经确认、哪些工具返回过结果。这跟裸提示词一次性的问答有本质差别：裸提示词每次都是重新开始，而Agent能基于上一轮工具调用结果进行下一步决策。

4.3 我的选择标准：轻量提醒用系统提示词，完整流程用Agent技能

在项目里，我一般不追求所有功能都做成Agent。有一个很朴素的判断标准：

• 如果这个能力只需要“改一改写作文风、加几条规则”，那用系统提示词就够了，不需要引入Agent。比如客服系统的礼貌话术、问答机器人的答题规范，做成系统提示词已经能解决绝大部分问题。
• 如果这个能力需要“读取外部数据、做多步推理、调多个工具、给用户交付一个闭环结果”，那就值得做成Skill Agent。比如“查订单状态并生成退款建议”“从文档中提取指标并生成数据图表”，这些流程靠一个静态提示词是hold不住的。

还有一个容易被忽略的维度：可维护性。系统提示词一旦长了，规则之间容易产生冲突；模块化技能则允许你单独测试、替换某一个技能而不影响其他功能。所以当提示词超过500字，并且需要频繁迭代时，我强烈建议迁移到技能化的架构里去管理。

当然，Agent不是银弹，它引入了更多的不确定性：工具调用的顺序可能要规划，中间结果的格式要校验，失败要重试。你把把关口全部交给模型“自由发挥”，出错率可能比静态提示词还高。所以我的建议是：能用系统提示词解决的，不碰Agent；把Agent留给那些真正需要“动态决策”的场景。

5. 实测中的提示词翻车现场与排查方法论

5.1 翻车案例：角色设定过强导致幻觉

说几个我在真实项目里遇到的翻车现场，顺便复盘排查过程。

第一个案例是给一个金融问答产品写提示词，我一开始把角色设定成“你是一位拥有二十年经验的资深投资顾问”。结果模型在回答问题时，不仅语气变得傲慢，还开始编造投资收益率和产品条款。原因其实不难理解：角色设定一旦过强，模型会倾向于“扮演”这个角色，并且调用高频的角色刻板印象来完成输出，很多细节其实是从训练数据里“幻觉”出来的。

排查过程是这样：我先去掉了角色设定里“二十年经验”这类修饰词，只保留“投资顾问”这个功能角色；然后补充了一条约束：“所有涉及具体数字、条款的内容，如果知识库中没有可靠依据，必须使用上下文中提供的数据，并禁止使用训练数据中的案例充当本次回答依据。”这一改，幻觉大幅减少。

这个案例给我们的教训是：角色设定的作用是限定表达方式和知识领域，不是给模型贴一个“权威光环”。盲目堆砌角色资历，反而会让模型更自信地编造。

5.2 翻车案例：约束被“悄悄忽略”

第二个案例更有意思。我们在测试一个“合同风险提示”提示词时，明确写了“只依据本文本进行分析，不要使用外部法律知识”，结果模型依然时不时蹦出“根据《劳动法》第XX条”这样的表述。用户一旦看到法律条款会本能地信任，但事实上条款是错的。

我一开始以为是提示词位置不够靠后，就把约束挪到了末尾，效果有一些改善但仍有残留。真正解决问题的是两条腿走路：在提示词里约束“本文本之外的任何法律条文引用均属于违规行为”，同时在输出链路里加一个规则过滤器，凡是输出中包含“第XX条”“根据XX法”等危险模式，直接拦截并触发重写逻辑。

这种问题说明一个残酷的现实：提示词并不能杜绝一切错误，它只是显著降低错误概率。在关键业务场景里，你必须在提示词之外再加一道确定性的安全网。把提示词当成唯一的防线，是所有翻车里翻得最彻底的。

推而广之，我做了一个排查清单，每当模型输出行为不符合预期时，按下面的顺序检查：

• 第一步，确认解码参数：Temperature是不是太高了？Top_p是不是太大了？先把Temperature降到0.3以下试一次。
• 第二步，确认提示词位置：关键约束是否出现在中段，被大量内容包围导致“迷失”？
• 第三步，逐条删除约束，做消融测试：删掉某句话效果变了，说明这句话是关键；删掉没变化，说明它在信息上冗余。
• 第四步，检查示例：模型有没有可能照着示例的形式在硬套？示例和目标任务是否一致？
• 第五步，检查上下文：喂入的内容里是不是有互相矛盾的表述，让模型无所适从？

这套排查链路帮我在很多次“模型突然失灵”的情况下快速定位问题，比无头苍蝇式地改提示词高效得多。

5.3 排查方法论：消融、变量分离、基线对照

说到排查，其实可以总结成一套非常简单但好用的方法论。核心就是：一次只变一个变量，所有其他条件保持不变。

很多人改提示词是“大改”，一下子删了角色、加了格式要求、换了示例，然后发现效果变好了，但根本不知道是哪一步起的作用。下次遇到类似问题，还是不知道怎么改。正确做法是像做实验一样操作：先确认一个稳定的基线提示词，然后逐个调整要素。比如先只加角色设定，对比是否改善；再加输出格式，对比是否改善；再加示例，对比是否改善。每一步都记录效果，最后你手里会留下一份“这个任务依赖哪些要素”的清单。

另外要警惕“幸存者偏差”。你在一两个例子上测试觉得提示词效果好，不代表在真实分布上也好。我会在每次改动之后，至少用十到二十个覆盖典型情况的测试用例做回归，确认改动在整体质量上是正向的，而不是恰好改好了那一个用例。

消融测试还有一个妙用：如果你发现删除某个约束之后效果反而变好，说明这条约束在妨碍模型。比如有时候“请用专业术语”这类模糊的风格要求，会诱导模型启用大量空洞的套话，反而稀释了实际内容。这时候果断删掉它，让模型说人话，效果更好。

6. 算力受限与本地部署下的提示词省钱策略

6.1 小模型靠指令不靠寒暄：精简提示词实测

最后聊一个更现实的场景：算力约束和本地部署。并不是每个团队都用得上旗舰模型，很多场景里大家用的是量化后的7B、13B模型，部署在自己的机器上。这些模型的能力和旗舰模型有差距，对提示词的敏感度也完全不同，最直观的差异是：小模型更容易被冗长的提示词带偏。

我在本地部署的模型上做过对比：同样一个信息抽取任务，用一套“角色+详细背景+长指令+多个示例”的豪华提示词，7B模型经常丢字段；改用一套极简指令“从文本中提取人名、时间、地点，输出JSON列表，没有的字段填无”，效果反而好了不少。重型提示词在小模型上之所以效率低，是因为模型本身容量有限，注意力资源更少，你给它太多角色人设和背景信息，它反而抓不住重点。

所以本地部署场景下的提示词工程，核心思想可以概括成“少即是多”。背景信息能不塞就不塞；示例给一个高质量的就好，不要给三个互相干扰的；约束条件用最直白的肯定句和否定句，不要用委婉的“请尽量不要”这类说法，直接说“不要输出”。

6.2 减少Token消耗的四个技巧

既然谈到了算力约束，就不得不提Token消耗。Token就是钱，就是显存，就是延迟。我总结过四个直接能省的技巧：

第一，系统提示词按周定期修剪。很多系统提示词经过多次迭代后，会残留大量已经不再生效的旧规则。我习惯每周花半小时过一遍系统提示词，把“现在不用的”“只是表达的”“重复出现的”全部删掉，通常能瘦身30%左右。

第二，能用停止序列解决的，不要加提示词约束。生成代码时，让模型在遇到指定标记时停止生成；生成JSON时，用固定的结束符。这比在提示词里写“不要多说话”更省Token，而且效果更强。

第三，缓存的思路。如果你处理的任务是批量请求，且系统提示词相同，可以研究一下所用平台是否支持提示词缓存或前缀缓存。有缓存的情况下，重复的指令部分不再全额计费，长系统提示词的边际成本会显著下降。

第四，把示例做小做精。少样本示例中，每一句示范话术都是成本。示例的作用是传递模式和格式，不是展示文学才华。把示例压到“刚好能表达模式”的长度，能省下大量Token而不损失效果。

6.3 视觉大模型的提示词结构差异

多模态模型最近很火，我简单聊一下视觉大模型的提示词特点。很多团队在做“给一张图片+一段文字指令”的应用时，还是完全套用纯文本的提示词框架，结果效果很差。

视觉大语言模型的特殊之处在于：它是先通过视觉编码器把图片转成特征，再和文本指令一起进入语言模型的注意力层，而文本指令在后续的推理中扮演了“路标”角色。最近圈子里有研究者提到，某些多模态模型在纯语言先验足够强的时候，甚至能在一定程度上“蒙”出视觉问题的答案，这也说明文本指令对多模态模型的影响比很多人想象中大得多。

因此，在给视觉模型写提示词时，我会额外注意两点：

第一，把注意力引导到图片的具体细节上，而不是笼统地说“帮我看看这张图”。比如“请描述图中人物右上角手持物品的颜色、形状和文字内容”就比“这张图里有什么”更容易得到精确答案。第二，多模态任务的输出格式约束更加重要，因为模型在融合视觉特征和文本指令时，输出失控的概率更高。

总之，不管是纯文本模型还是多模态模型，提示词工程的核心逻辑没有变：它的本质是控制生成过程，压缩输出空间，把模型的强大能力引到我们需要的轨道上来。但也要清醒地认识到，提示词不是魔法，它只能降低出错的概率，永远替代不了工程上的校验机制和产品设计上的兜底逻辑。

我个人这几年的体会是，把这个领域玩明白，确实需要一点点啃原理、一次次看输出日志、一遍遍做消融测试。提示词工程这个方向，门槛不高但天花板极高，值得花时间。如果你也在搭建自己的大模型应用，不妨从今天开始，给你的提示词建一份变更记录，每次都记录改了什么、为什么改、效果有没有变好。半年之后回看，你会清楚看到自己在这条路上的成长轨迹。