prompt-engineering

提示词只需说明目标，然后退居幕后。其余内容都是负担——每次运行都会消耗资源，占用模型原本可用于工作的注意力——因此，每一行都必须物有所值。接下来要决定四件事：运行时提供什么、是否需要某一行、它放在哪里，以及如何措辞。

运行时面对的内容

运行结果受其面对的内容限制：提示词及输入的一切内容——填入模板的输入、它读取的文件、检索到的材料、工具输出、截至目前的对话内容，以及交接给其他 Agent 的内容。模型通常具备足够的能力，因此糟糕的输出往往源于输入。当运行表现不佳时，在修改措辞前，先查看它实际收到的内容——运行轨迹或填充后的输入，而不只是模板——并检查四类问题：

• 缺失——任务所需的内容不存在，因此运行只能猜测。
• 冲突——两部分内容互相矛盾，因此运行会择其一。
• 错误或过时——某部分内容不真实或已过时，因此运行会照搬。
• 噪声——重要内容虽然存在，却被与任务无关的材料淹没。

先修正输入：补上所缺内容，或提供能找到它的指引；对于互相矛盾的来源，选定一个；纠正或删除错误内容；删去淹没关键信息的材料。这通常比其他任何改动都更能改善结果。措辞修改和事后纠正——例如复核、自检，或在失败后添加规则——都应放在之后。用来弥补错误输入的修正会让问题继续存在，下一次运行时仍会遇到它。

完整意味着针对任务而言完整：修正通常是用缺失内容替换噪声，而非单纯增加篇幅。如果输入已经完整、一致且干净，再检查指令；如果模型缺少任何输入都无法提供的能力，就应改动架构。

一行内容的来源

在询问这一行是否有帮助之前，先问它从何而来。一行内容即使真实、相关，也仍可能值得删掉，因此有用与否并不能解决问题。关键在于来源，而你可以凭记忆回答：

• 用户明确要求了这点——他们说过的决定、偏好或约束。没有其他推导来源。保留。
• 这是现实中的情况，但本次运行无法触及——未写明的惯例、你观察到的故障、运行将要读取的内容之外的事实。保留，并优先指向来源，而不是复制一份可能过时的内容。
• 它用来抵消你观察到的模型默认行为——当这种默认行为是实际观察到的，而非担心出来的，就保留。
• 你根据本次运行也会读取的材料推导出了它——删掉。语料中已有的结论，本次运行也能自行得出，因此写下来毫无收益，却会增加每次调用的负担。

最后这一类最容易让人觉得成果来之不易，因为你确实花力气才得出结论，而过度规定也正是由此而来。有两个迹象：一行内容可以依据运行所能获得的同一批来源来论证；一个句子只是为上文的指令辩护，却没有补充上文测试所认可的信息。

请求未明确的选择，应由提出请求的人决定。 你想补充的内容中，有些不是赘述，而是决定——如何给候选项排序、对方所给规则的例外，或超出其要求的交付物。它看起来像是周全，实际上却以对方的名义，把他们从未选择过的内容强加给他们，写进一个他们日后还会引用的文件中。想想答案会在哪些地方改变工作；如果不会改变，就不要写。

完成后的提示词看起来会比你预期的单薄，这恰恰是成果，而不是警示信号。 两项裁定和一个目标就能构成一份简短文档；此时你很容易想把它填满——加一节讲如何排序，为术语补上自定义义项，或再添一项没人要求的证据来源——而这些想法无一不来自上面那一类。当它看起来过于简略时，确认目标已经写明、裁定也已纳入，然后就交付。

反事实问题——没有这一行，模型会这样做吗？——要求预测模型自身的行为，而这无法从内部可靠判断。应当在确认来源已被认可后再问：它仍可删掉来源合格的一行，却绝不能保留来源不合格的一行。

如果两个人对某一行是否有实际作用意见不一，争论的焦点就是模型的默认行为，所以可以删掉这一行运行文档，再比较结果来定夺。这是一种值得费力时可用的决胜方法，并非每一行都必须通过的步骤。

自上而下地写

从目标句开始。只添加上文问题认可的内容，每次一行。

先泛泛地写，再事后删减，成本更高，最后的文档也更长：每一行你打算删掉的内容，都已经为它辩护过；而草稿本身的分量，也会让人误以为它们必不可少。

两种预算

你添加的每一项内容都会消耗以下两种资源之一：

• 上下文负担——始终加载的内容，无论是否触发，每轮都会消耗。技能说明、AGENTS.md 中的规则，以及任何常驻内容都属于此类。
• 认知负担——一个人必须记住的内容：有哪些文档，以及何时查阅各文档。它不是需要降至零的成本——它换来的是人的判断力。应在判断力发挥作用的地方投入。

放在指针所指内容中的材料，不计入上下文负担，但指针本身仍占一行。没有指针的材料，则完全依赖某个人记得。

内容所处层级

三个层级，按执行时对材料的即时需求排序：按顺序执行的步骤、按需查阅的参考资料，以及通过指针访问单独文件中的已披露参考资料。将材料下移能让顶层保持清晰；下移过多则会掩盖执行时真正需要的内容。由分支决定如何安排——所有路径都需要的内容内联，只供部分路径使用的内容则予以披露。

将一条规则的陈述、边界和例外放在同一标题下，确保读到其中一项时也能看到其他项。将一条规则拆散在文档各处，就可能让它逐渐分裂成两条。

指针是指明上下文之外的材料及其访问条件的那一行：例如技能描述、参考链接。决定执行时是否会访问目标的，是指针的措辞，而非目标本身——因此要把触发词放在前面，每种不同情况各给一个触发条件，并删去目标中已有的自我说明。如果必须访问某项材料，但指针不够明确，应先强化措辞，而不是直接将材料内联。

措辞

选用模型已有认知的词。 预训练词语——坚决、严谨、对抗性——能唤起先验认知，用一个词锚定某种行为模式；而一个短语要花上好几个词，效果反而更弱。指令太弱时，应换用更有力的词，而不是增加文字。新造的术语无法唤起任何认知，因此你得花篇幅解释，而现成词语无需解释就能发挥作用。

同一种激活效果，从一个词延伸到一套方法。 预训练概念——对抗性验证、相互竞争的解释、目标导向——能激活模型已有的相关实践认知，因此，明确的目标加上少数此类概念，就能替代数页流程说明；模型本来就会自行推导这些流程。整个提示词都应优先采用这种结构：陈述目标和必须遵守的裁定，用能唤起相应方法的词语点明每种方法，并将具体运用留给模型。主干之所以稳固，是因为目标和裁定具有约束力，而不是因为写下了每一个步骤；详尽列出的流程会将有能力的模型限制在单一路径上，而隐含的方法知识足以涵盖所有路径。

说明要实现什么，而不是禁止什么。 禁令会指出被禁止的行为，反而让模型想到这种行为——否定只是在强烈激活的概念上加了一个较弱的修饰。写一行注释胜过不要写很长的注释。只有无法改写成正向要求的禁令才应作为护栏保留，并同时给出正向目标。

每个步骤都以执行时可检查的条件收尾。 已充分理解容易让人过早停止，因为仍然可见的后续步骤会让注意力转向“完成”。先把边界说清；只有遇到真正的上下文边界时，拆分序列才有帮助，因为内联提及仍会让后续步骤保持在视野中。措辞也会决定步骤要求完成多少工作：枚举所有调用方会迫使执行者逐一检查，而列出调用方则不会。

对需要判断的情况给出规则，而非绝对要求。 假设前务必询问会导致过度触发；如果缺失的事实会改变行动，就先询问；否则继续并标明假设则具有可操作性。只有真正不容变更的条件才使用 MUST 和 NEVER。

保持低唤醒度。 紧迫感措辞、全大写祈使句和过度赞扬都会显著改变行为——压力之下会促使模型走捷径，奉承之下会促使模型迎合。在任何迭代过程中，都应将失败视为正常情况：如果这种方法不起作用，就试试别的方法。开头会为后续内容定下整体基调。

精简

• 一处表达一个意思。 同一条规则出现在两个文件中，就成了两份会逐渐偏离的文本，而且只有一份会被读到。（有意重复一个词语则恰恰相反，这样做没问题。）
• 环境是事实来源。 提示词若重述 package.json、配置文件或 --help 已经说明的内容，就像一份会过时的缓存。只缓存没有文件明确说明的内容：未成文的惯例、原因和易踩的坑。
• 逐行检查相关性，而不只是正确性——有一行即使属实，也可能已与文档的用途无关。若不检查，提示词就会不断堆积内容，没人敢删。
• 逐句排查无效内容。 模型本来就会遵循的指令，说了也只是增加负担而毫无作用。直接删掉整句话，不要只删减其中的字词。

边界情况

一行内容即使有保留的价值，也可能在提示词实际运行时出问题。请根据它会遇到的条件逐条检查：

• 本该用通俗语言说明能力、让模型自行寻找实现方式的地方，却指定了受执行环境限制的原语——例如特定工具、调度器或 CLI。
• 某个限定条件悄然排除了原则本应涵盖的情况（在模式 X 下、由另一位审核者）。
• 把某种机制说成唯一途径——例如固定步骤序列、硬编码数量——而原则本身本应独立成立，数量也应只是默认值。

更新

如果修改是针对不良结果，先从运行时可用的输入入手；只针对输入没有解释的部分修改提示词中的内容。动手修改前，先找出需要这一行来弥补的缺口。最好的补丁通常是替换一行，而不是在旁边再加一行；新增的明确规则往往也能取代旧有的模糊保留语。净改动可以是增加，也可以是减少；目标是平衡，而非某个方向。

更新后的提示词读起来应像是今天为它当前的用途写成的。某一行过去写了什么、何时或为何修改、是谁提出修改，都应写进提交说明或决策记录，放在提示词文件之外：这些内容会在每次运行时增加负担，也可能被当作指令执行。规则成立的原因可以保留。保留裁定，不要保留裁定过程的记录。

编辑后，请像新读者一样重读整个文件，而不只是检查改动过的行：每条规则只出现一次；没有内容与新行矛盾或重复；开篇仍在描述提示词的用途。删除历史说明，以及新规则取代的保留语，无论它们位于何处：删除这些内容不会改变任何规则，因此无需留给请求者选择。

避免围绕一次观察到的失败筑起高墙。一个实例对应一次修复；若为此专设一节，就是矫枉过正。

参考资料

• references/mechanics.md — 结构：技能的 frontmatter、命名和布局；Agent 的隔离与能力声明；缺口在于数据而非行为的知识技能。
• references/system-prompts.md — 在部署循环中交付的系统提示词，以及为此准备好的模块：验证轮次、工具调用预算、歧义处理、输出约定、高风险自检。仅适用于该类产物。
• references/metaprompting.md — 根据记录的轨迹诊断未能奏效的提示词。