别让System Prompt变成补丁仓库：AI任务管理新范式
当你长期使用一个智能代理（Agent）时，会发现它的系统提示词（System Prompt）总会越来越长：模型某次漏做了任务，就加一条规则；工具调用出错，再补一段说明；某次没有提前确认就修改了文件，于是把“先询问用户”的要求复制到了三个不同的位置。哪怕后续模型完成了升级，这些临时打上的“补丁”依然会留在提示词里，没有被清理。
据最新发布的大模型提示词优化指南，这类臃肿的系统提示词正是被点名的问题：为旧版本模型编写的规则、工具说明和流程补丁，在新模型上可能会出现冲突，不仅会消耗额外的Token、产生无意义的状态播报，还会让Agent对完全安全的本地操作都反复请示用户。
臃肿的提示词：从临时补丁到负担
很多长提示词都有相似的“成长轨迹”：权限边界分散在提示词的开头、工具说明和末尾区域；同一个要求一会儿说要自主完成，一会儿又要求所有修改都必须先确认；已经下线的工具，说明文字还留在列表里。模型越是认真遵循指令，这些冲突的规则带来的犹豫就越明显。
针对这个问题，指南给出了非常务实的清理思路：从一份可以正常运行的提示词出发，每次删除一组规则，再用同一套评测任务测试效果。优先需要清理的内容包括五类：
- 重复出现、含义完全相同的规则；
- 不会再改变模型行为的样式和流程说明；
- 没有实际作用的示例内容；
- 模型已经可以稳定完成的固定操作步骤；
- 当前运行环境中不再需要的工具及相关说明。
真正需要留在提示词里的内容其实非常精简：用户最终期望的交付结果、什么样的状态才算完成任务、任务何时可以停止、哪些安全和业务边界绝对不能突破、不同上下文场景下应该调用哪些工具，以及交付前如何验证结果是否合格。
指南还特别提醒，指令冲突带来的不稳定性，往往比少写一条细节的影响更严重。因此提示词的维护应该遵循一个实用的顺序：先删除重复和冲突的规则，再考虑添加新的约束条件。
测试效果的实际数据
指南中披露了一个内部代码智能代理的测试样例：在精简系统提示词后，模型的评测得分提升了10%到15%，总Token消耗量减少了41%到66%，对应的成本下降了33%到67%。
这个结果很容易让人产生“提示词越短越好”的错觉，但指南明确说明，这只是内部测试样例，具体效果会随着工作负载变化，团队需要在自己的代表性任务中进行验证。真正可以复制的是测试方法：保留原始的基线版本，每次只删除一组规则，用同一批任务对比模型的质量、Token消耗、成本和失败类型。单纯把2万字的提示词砍到2千字，并不代表系统已经变得更好。
以结果为导向的提示词设计
过长的提示词还有一个常见的问题：把任务拆成固定的第一步、第二步、第三步，甚至连模型何时读取文件、何时汇报进度、何时停止任务都预先钉死。指南更推荐“结果优先”的设计思路：先明确定义任务的结果和完成标准，只把安全、合规、证据和权限这类不会变化的内容作为绝对规则，对于需要模型自主判断的场景，只给出决策条件和默认动作。
比如一个代码修复任务，可以把提示词精简为以下内容：
目标：修复指定问题，并保持现有兼容性。 完成标准：相关测试通过，改动没有超出任务范围。 允许：读取和搜索仓库、修改范围内文件、运行非破坏性验证。 必须确认：外部写入、删除数据、付费操作或扩大任务范围。 停止：目标已验证完成，或遇到无法绕过的外部阻塞。这种写法没有替智能代理指定每一条执行命令，却清晰地明确了交付责任。现在我更倾向于把系统提示词看作一份任务合同：明确写清结果、边界和验收标准，把具体的执行路径留给模型自主选择。
权限规则的合理设计
当智能代理每修改一个文件都要举手请示用户时，可以先检查系统提示词：是不是“先询问我”的要求被重复写了三遍？指南在权限章节中给出了三档清晰的权限边界：
- 当用户要求回答、解释、审查、诊断或规划时，默认只进行检查并报告结果；
- 当用户明确要求修改、构建或修复时，可以在任务范围内完成本地改动和非破坏性验证；
- 涉及外部写入、破坏性操作、购买行为或扩大任务范围时，必须先获得用户确认。
这三档权限比一句笼统的“谨慎行事”更具可执行性。指南还建议把权限政策集中放在一个位置，其他章节只需要引用它即可。多处重复的ask first、do not mutate和wait for approval等要求，可能会让模型对本来安全、符合预期的操作也发起不必要的确认。
智能代理的权限设计目标，是让它在该停止的位置自然停止。如果常规的读取、范围内编辑、测试和检查都需要逐步确认，那么用户实际上依然在充当工作流的调度器，而不是真正依赖智能代理的自主能力。
明确的停止条件
像“尽可能多搜索”“持续改进”“完成所有必要工作”这类表述听起来很积极，但实际上很容易让任务陷入没有终点的循环。停止条件需要明确回答三个问题：什么样的证据已经足够证明任务完成？什么样的阻塞情况允许任务退出？最低可用的交付物是什么？
比如检索任务，找到可以直接回答问题的一手来源后就可以停止；代码修复任务需要通过与改动匹配的测试、类型检查、Lint、构建或冒烟验证；如果无法运行验证，需要把缺失的项和原因清晰地写出来。任务完成需要一个明确的证据门槛，不能只依靠智能代理自己说“已经完成”。
推理强度的调整也应该放在最后。指南建议把较低的推理强度（reasoning effort）作为明确任务后的自然起点，只有当代表性评测显示更高的推理强度能带来明显收益时，再进行调整。当任务定义含糊不清时，先优化提示词，比用更高的推理强度来弥补漏洞更划算。
现有提示词的优化步骤
如果你手里已经有一份使用了很久的系统提示词，可以按照以下五步进行优化：
- 选择一组真实的代表性任务，记录当前的模型质量、耗时、Token消耗量、成本和失败类型。
- 标记出重复的规则、过时的工具、无效的示例和旧模型留下的流程补丁，每次只删除一组。
- 把权限、证据和安全策略收拢到一个单独的位置，消除互相冲突的表述。
- 补齐任务目标、完成标准、停止条件、输出形态和验证动作，再用同一套任务进行测试。
- 等提示词变得清晰后，再调整推理强度；如果没有评测数据证明收益，就不要为了“看起来更聪明”支付额外的成本。
代码仓库会定期清理过时的兼容层，系统提示词也需要同样的维护纪律。下次更换模型时，不妨先让它用最少的规则运行一遍，再根据真实的失败样本加回必要的边界约束。
少写本身不值钱；每条规则都有清楚责任，才值钱。
