02 · Prompt Engineering：任务要求怎样进入模型

1. Prompt在Agent里处于什么位置？

上一课讲了Harness怎样组织模型完成任务。Prompt处在模型输入这一侧：把应用规则、本次任务和交付要求传达给模型，影响它怎样分析、选择下一步和回答用户。

Prompt就是提示词；Prompt Engineering是设计、验证和调整这些说明的过程。它承担的是表达要求的职责，工具执行、权限校验和任务停止仍由程序控制。

Prompt是Context的一部分。

已有事实提供分析依据，不能因为出现在输入中，就自动获得修改应用规则的权限。

在传统后端里，业务要求主要落实为字段、条件和处理规则。Agent还要把部分要求传达给模型。例如用户问“昨晚直播的成交额为什么下降”，应用就要说清店铺、比较场次、成交额口径、缺数据时怎么办，以及交付方式。

2. 同一个任务，要求可以差在哪里？

先看一段模糊的提示词：

你是资深电商专家。全面分析昨晚直播为什么卖得不好，
给出专业、深入、可落地的建议。

“卖得不好”按什么判断？和哪场比？有没有查到数据？这里都没有说明。“资深专家”可以提示模型采用某种分析视角，却不能替代缺失的事实和任务边界。

下面把要求写清。实际店铺与场次，要先由用户确认或从可信任务信息中取得。

任务：比较这家店昨晚与上周同一天的直播，分析成交额变化。

比较范围：两场直播的完整场次。
成交额口径：已支付订单金额，暂不扣退款。

先通过可用查询工具核对数据，再分析。
把查到的事实与可能的解释分开；每项事实标明数据来源。
关键数据查不到时，写清缺少什么，不自行补数。
如果店铺、场次或比较范围不明确，先向用户确认。

交付：一段摘要，以及“已确认事实、待验证原因、建议补查”三部分。
本次只做分析，不发送通知、不修改业务数据。

这段说明没有规定每一次查询的顺序。模型仍可根据结果选择下一步，但它知道比较范围、证据要求和交付方式。

3. 先把哪些要求写清楚？

写提示词时，可以用这几个问题检查遗漏，无须每次照抄一套固定模板。

如果某项要求容易被误解，可以补一个短例子。例如下面是虚构教学数据：

不合适：观看人数下降20%，所以成交额下降就是流量导致的。

更合适：成交额与观看人数均下降20%；流量变化值得进一步核查，尚缺转化和客单价等信息，暂不能确定原因。

示例要明确标记，避免数字被当作本次事实；也要覆盖不同情况，避免模型套用同一种结论。

4. 固定规则、本次任务和事实资料，分开管理

应用指令、用户要求和查询结果，可以分开管理：

不同模型接口的消息字段不同，这里先理解职责，不要求记住某一家API的参数。

本文用Prompt侧重指令，用Context指模型本轮能看到的整体信息，后者还包括对话、工具结果等。如何挑选和压缩这些信息，放在上下文工程篇讲。

5. 提示词互相冲突，先解决什么？

先分清冲突来自哪里。不要把所有要求拼成一段，再让模型自行猜测谁更重要。

应用规则应放进所用接口支持的系统或开发者指令位置，用户任务、外部资料保留各自来源。具体优先级遵循厂商协议；同一层的矛盾要求仍要主动消解，不能靠“最后一句生效”或加粗解决。

相对稳定的默认偏好，要写清用户能否覆盖。例如默认输出摘要，但允许用户要求详细版；固定禁止修改订单，则不属于用户可以覆盖的偏好。提示词修改时，也要检查旧示例有没有继续暗示相反做法。

6. 提示词的“注意力”，工程上怎么理解？

注意力机制是模型在计算时关联不同Token的方式，Token是模型处理的文本片段。它不是我们在Prompt里手动分配的一份“注意力额度”，指令优先级也不等于注意力权重。

工程上要关注的是：模型有没有用对关键要求和证据。能放进上下文窗口，不代表信息一定会被有效利用。长上下文研究曾观察到，中间位置的相关信息更容易被忽略。

直播分析时，如果输入里塞满无关订单明细、多份旧要求和重复日志，“只看新品”这项要求即使存在，也可能没被正确执行。可以这样调整：

• 稳定规则集中写清，删除互相重复或矛盾的说法。
• 本次任务明确范围；资料按来源和用途分段，只提供相关信息。
• 长资料后用一句简短指令点明当前任务，不重新复制整套规则。
• 用遗漏范围、误用示例数字等案例检查效果，而不只检查文字有没有出现。

具体放在哪里更好，要在所用模型和任务上比较。加粗、重复和“非常重要”都不能保证执行正确；检索、裁剪与压缩策略放在上下文工程篇展开。

7. Prompt会影响缓存命中吗？

会。常见的Prompt缓存，会复用相同输入前缀的中间计算结果，减少重复处理。前缀就是请求开头连续一致的部分；语义相近、换了措辞，不等于同一个前缀。命中缓存后，模型仍要生成本次答案。

直播分析的规则每天相同，店铺、场次和数据不断变化。常见做法是让稳定规则、示例和工具定义保持一致，再按接口结构加入本次任务和数据。

某处变化后，更早且满足条件的相同前缀仍可能复用。排查要看服务端完整输入，包括工具定义、消息顺序与配置，不能只对比提示词文件。

缓存有最小长度、有效期、路由与启用方式等条件。DeepSeek默认启用上下文缓存，但需要完整匹配已持久化的前缀单元；Claude支持通过cache_control配置自动缓存或显式边界。不能把一家厂商的阈值或有效期套到另一家，也不能保证第二次请求必然命中。

检查时看接口返回的用量，而不是凭响应速度猜：

按Token计算命中比例时，用“累计命中输入Token ÷ 累计全部输入Token”；不同厂商的总输入字段口径不一样，需要先统一。再一起看首个输出Token的等待时间、任务总耗时与实际费用，包含适用的缓存写入费用。

缓存命中不会缩短模型可见的上下文，也不会自动提升回答质量。不能为了凑长度而加无用内容，或为了维持前缀，保留过期规则和错误数据。正确性与权限边界优先，再优化复用。

8. 写在Prompt里的规则，哪些还要程序保证？

在传统后端里，你不会因为接口文档写着“只能看自己的订单”，就省掉权限校验。Agent也是一样：模型收到的说明，不能代替实际执行限制。

假如后端要把分析结果展示为卡片，可以约定返回摘要、已确认事实和待补数据等字段。这就是结构化输出，方便程序处理。提示词可以描述这种结构；接口提供相应约束能力时也可以使用，返回后仍要处理校验失败。

即使JSON完全合法，里面也可能写着“流量下降就是唯一原因”。结构正确与事实正确，是两件需要分别检查的事。字段和来源是否存在，可以由程序检查；证据是否足以支持结论，还可能需要业务规则或人工复核。

发现问题时，也要先判断发生在哪一层：没说清比较范围，就改任务说明；工具没提供退款口径，就补工具能力；数据确实缺失，就如实说明。一直给提示词加“请务必准确”，补不上缺少的数据与功能。

9. 改了一版，怎样知道有没有变好？

先保留旧提示词，用同一组任务比较新旧版本。至少覆盖几种有代表性的情况：

为了判断提示词本身的影响，比较时尽量固定模型版本、调用设置和工具返回数据，并记录这些条件。重复运行观察波动，一次好看不足以证明改善。

先保存prompt-v1.md和prompt-v2.md，记录执行版本即可，不必先建提示词数据库。

评估时先看事实、缺口与指令冲突是否处理正确，再看是否多查了无关资料、调用是否变多、缓存复用和费用是否变化。完整的评测方法后面再展开，这里先养成“保留版本，用同组任务比较”的习惯。

10. 这一篇先理解到哪里？

能把模糊要求写清，遇到冲突时分清来源和边界；知道长输入可能遗漏重点，稳定前缀会影响缓存；修改后用任务结果和用量记录检查效果。权限和执行限制仍由程序保障。

第二节是教学示例，未预设实测效果。试用时配上同一份虚构数据，比较事实、推测与缺口的处理。

下一篇讲Tool Calling：模型为什么需要工具，怎样把已有业务能力开放给它，以及工具设计中需要考虑哪些工程问题。