阶段一收尾了：连得上、模式选对、参数会调、客户端能复用、上下文管得住、输出格式可控。进入阶段二，第一个要回答的是一个很多人私下纠结过、但很少被正面回答的问题——Prompt 工程到底值不值得投入？

一、两种流行说法，都不好操作

关于 Prompt 工程，网上大致两种论调。

一种是万能论：提示词写得好，什么问题都能解决，甚至不用微调、不用 RAG，改几句话就行。配套的内容就是各种"提示词模板大全""XX 个技巧"。

另一种是玄学论：提示词就是碰运气，纯属玩具，等模型能力上来都会被抹平。

这两种说法有个共同问题：它们给的是立场，不是判断标准。 你看完之后，仍然不知道手头这个具体问题该不该去改提示词。真正的工程决策需要的是可操作的判据，而不是"应该重视"或者"不必在意"这种态度。

所以这一篇不打算罗列技巧。想讲的是：什么时候提示词能解决问题、什么时候它解决不了、以及怎么判断你改的这一版到底有没有用。

二、先分清"不知道"和"没听懂"

这是整篇的核心区分，值得单独一节。

模型表现不对，原因基本落在两类：

• 模型不知道：它缺少完成任务所需的信息。比如你问的是公司内部的业务流程、昨天的订单数据、某个私有接口的字段含义。这些信息不在它的训练数据里，再怎么改提示词也变不出来。
• 模型没听懂：信息它都有，但你没说清要什么。比如你说"帮我分析一下这段数据"，它不知道你是要趋势、异常点、还是总结成一句话。

这两类的处理方式完全不同：

• "不知道" → 改提示词无用。要给它信息：把相关材料放进上下文（RAG）、或者调用接口取数据（工具调用）。
• "没听懂" → 这正是提示词能解决的。把要求写具体，收益立竿见影。

Prompt 工程的有效范围只在第二类。 把第一类问题当成第二类去改提示词，就是那种"改了十几版感觉都差不多"的典型场景——不是提示词没用，是方向错了。

一个快速区分方法：问自己"如果换一个很懂业务的人来回答这个问题，他还缺什么？" 如果他缺的是一份资料，那是第一类；如果他不缺资料、只是不知道你要哪种输出，那是第二类。

三、收益最大的几类场景

在这些地方，改提示词是最划算的手段，投入产出比明显高于其他选择。

任务描述模糊导致输出不稳定

最常见，也最容易见效。对比：

帮我看看这段日志有什么问题

和

分析这段日志，只输出以下三部分：
1. 报错发生的时间点
2. 涉及的服务名
3. 可能的直接原因（若无法判断则写"无法确定"）
不要输出其他内容。

后者的输出稳定得多。原因很简单：前者给了模型很大的解释空间，它每次会在不同理解之间摇摆；后者把范围收窄了，模型的选择空间小了，输出自然一致。

判断信号：同一个输入反复跑，输出结构每次都不一样 → 提示词描述不够具体，值得改。

格式与风格约束

要求固定的输出结构、语气、字数范围、面向的读者群体。这类需求用提示词表达成本最低，效果也直接。

但要记住上一篇文章的结论：格式这类要求如果必须严格保证，最终要靠参数（JSON Mode / schema）兜底，提示词只是第一道。 别把两者混为一谈。

领域术语对齐

同一个词在不同团队里含义不同。比如"订单"可能指下单记录，也可能指已支付的履约单。如果你不说清，模型会按大众理解走，输出里到处是用错的术语。

解决办法是在提示词里把关键术语定义一次，之后复用。这类改动的收益很实在，而且一次投入、长期有效。

提供一两个示例

比描述更有效的方式是直接给例子。想让模型按某种特定格式改写文案，与其用五句话描述格式，不如给一个输入输出的样例。

示例的作用是把抽象的格式要求变成具体的模式，模型照着模仿的准确度通常高于照文字理解。

四、收益很小的几类场景

模型确实不具备的信息

前面说过，不重复。只想补一句：这类问题硬改提示词，会消耗掉大量时间，而且会让你误判"提示词没用"这个结论。 不少人对 Prompt 工程的失望，源头就在这里——他们拿它去解决知识缺失的问题。

需要精确计算的任务

让模型做多位数运算、精确的日期推算、金额汇总，无论提示词怎么写都不稳定。这类任务应该交给代码去算，模型只负责理解题意和组织结果。

需要实时数据的问题

和第一类同源。模型没有当下的行情、库存、状态，改提示词不可能补上。

已经说得很清楚，输出还是不理想

如果一个要求你已经用无歧义的语言表达清楚了，模型仍然做不对，那大概是这件事本身就在这类模型的能力边界上。继续改措辞的收益会迅速趋近于零。

判断信号：改到第三、四版之后，每版的提升越来越小，且不稳定的部分每次换地方。到这一步就该停手了，换思路——换模型、拆任务、或者把这一步交给代码。

五、边际收益递减，而且来得比想象中早

这是实践经验里最值得记住的一条。

改提示词的收益不是线性的。第一版到第二版往往提升最明显，因为第一版通常太模糊。第二版到第三版还有改善。但从第四版左右开始，你改的东西更多是在"重新分配错误"，而不是减少错误——这一版的措辞让 A 类问题少了，同时让 B 类问题多了，整体看差不多。

这时候容易陷入一种循环：每次改完测一下，好像好了一点，再改一版又好像差了，来回摆动，几天过去没有实质进展。

要跳出这个循环，需要一个客观判断方式，也就是下一节要讲的。

六、怎么判断改的这一版到底有没有用

大多数人对提示词的验证方式是：改一版，跑一个问题，觉得"好像好多了"，就发上线。

这个方式有个致命缺陷：单次结果的差异，很大一部分来自随机性，而不是你的改动。

前面讲参数那篇说过，即使把 temperature 调到 0，输出也不会完全一致；正常设置下更是每次都有波动。这意味着"这次输出比上次好"这件事，可能纯粹是运气。

可行的做法不复杂，三步：

• 准备一个小的测试集：10~30 条真实业务输入，覆盖典型情况和几个边界情况。不用多，但必须来自真实场景，不能自己编。
• 每版都全量跑一遍：不是抽一两条看看，而是把测试集全部跑完。
• 看整体通过率，而不是看单个案例：比如"结构化输出能直接解析的比例"从 70% 到 85%，这是真提升；如果只是某两条变好了、另两条变差了，那就是在摆动。

这样做的额外好处是：测试集本身会成为资产。 以后换模型、换参数、加 RAG，都可以用它来对比，判断改动到底有没有价值。这件事的价值会随着系列推进越来越大。

顺带一个务实的提醒：跑 10~30 条乘以多轮，成本不高，但需要你先把测试集整理出来。这一步的投入往往是整件事里最"不划算"的部分——因为它不产出功能。 但它是唯一能让"提示词优化"从感觉变成判断的方法。

七、它和 RAG、微调的分工边界

很多人把这三个当成互相替代的方案，实际它们解决的是不同问题。一个简单的分工：

• 信息不在上下文里 → RAG 或工具调用（补信息）
• 行为不符合要求 → Prompt 或微调（改行为）
• 格式必须严格 → 参数约束（JSON Mode / schema）
• 精确计算 → 代码（别交给模型）

只有在"行为不符合要求"这一类里，才轮到 Prompt 和微调做取舍。而这两者之间，Prompt 的理由很硬：

• 改一次几秒钟，微调要准备数据、要训练、要维护版本；
• Prompt 随时可回滚，微调回滚是个工程问题；
• Prompt 能改的，绝大多数情况下不值得为它做微调。

微调真正有价值的场景比较窄：需要模型稳定掌握一种很难用语言描述的说话方式，或者要大幅压缩提示词长度来省成本。对多数业务来说，先把 Prompt 写到边际收益递减，再考虑微调，这个顺序基本不会错。

八、小结

回到开头那个问题：Prompt 工程值不值得投入？

值得，但它的有效范围比"万能论"说的窄，也比"玄学论"说的宽。

可操作的判断方式是：

• 先分清"不知道"还是"没听懂"——只有后者该改提示词；
• 收益最大的地方：描述模糊、格式约束、术语对齐、给示例；
• 到边际收益递减就停手——通常在第三、四版左右；
• 用测试集看整体通过率，而不是凭单次感觉；
• 别把它当成 RAG 或微调的替代品，它们解决的是不同问题。

如果说这篇只留一句：提示词解决"表达"，不解决"知识"，也不解决"能力"。 把这三件事分清楚，绝大部分犹豫都会消失。

下一篇

提示词的写法定下来之后，下一个工程问题是它怎么落地：写在代码里、还是放到配置文件里？多环境怎么区分？改了一版发现效果变差，怎么快速回滚？多个人一起维护时，怎么避免互相覆盖？下一篇讲提示词的模板化与版本管理。

本文是「用 Java 接入大模型」系列第七篇，阶段二首篇。前六篇分别讲了流式输出、流式与非流式的取舍、参数调优、客户端封装、多轮对话上下文管理、结构化输出，建议按顺序看。