提示词该长还是短：研究揭示何时该补、何时该删

遇到一次失败，就补一条要求；担心遗漏，再加一轮自检；让大模型帮忙优化，又得到一份更长的说明。提示词常常这样越写越长，但新增的文字，究竟解决了什么问题？指令并非越长越好，也并非越短越好。必要条件要补齐，重复与冲突要清理，专用资料要在需要时可达。现有研究没有给出通用的最佳字数，但能帮助我们判断这三类改动是否值得。本文面向编写系统指令、Skill和工作流的开发者，重点讨论带工具、多步骤执行的Agent。下面先给出修改方法，再解释研究依据；研究结果的适用范围以各自任务与实验设置为准。

区分变长的根源

比较长短之前，先看任务规格和信息内容是否也变了。指令告诉模型做什么、遵守哪些要求；完整上下文还包括历史对话、工具说明与返回资料。Skill是可按任务加载的指令与资料包。一个Agent可能多次调用模型，每次带入的内容也不同。例如，把指令从500字补到800字，同时加入验收条件，即使效果提高，也不能说明「多写300字」本身有益。删除文字时若删掉必要例外，效果变差同样不能证明短指令不好。模型标注的上下文窗口表示可容纳的规模，不保证窗口内的每条规则都能稳定执行；讨论研究时，应保留原始计量单位。

补删加载三原则

先定位失败，再决定改动幅度。可以依次问：模型缺少必要条件吗？同一要求是否重复或冲突？这些资料是否每个任务都需要？假设问题是「模型给出了根因，但没有日志证据」，下面三种写法增加的信息并不相同。第三版是否更好，要看它有没有减少无证据断言。如果实际遗漏的是服务范围或时间范围，就应该补对应条件；如果选错了组件流程，就应该改善资料入口。修改应落在导致失败的具体条件上。删减时也要保留条件之间的关系，「满足A时执行B，否则执行C」不能简化成「执行B」。精简应减少表达冗余，同时保留必要边界、例外和可执行含义。

工程实践的证据

代码审计研究发现，大量增加上下文时通过次数下降，但继续加入明确检查清单时通过次数又提高。泛泛要求「全面检查」和重新列出必要检查项，作用可能不同。跨多步骤仍必须遵守的要求，可以尝试在相关决策点用短清单提醒，再验证是否减少关键遗漏。Anthropic官方文章报告：Claude Code移除了超过80%的system prompt，内部编码评测未出现可测损失。删减涉及跨层重复、过时绝对规则，以及可移入Skill的专用流程。这说明需要定期检查每条规则是否仍在解决真实问题。业务事实、权限边界和验收条件仍要按实际任务保留。Progressive Disclosure研究发现，单本书场景的收益依赖框架，多书场景中一层披露更稳，增加第二层路由有时损害准确率。这支持先改善信息入口，再评估是否需要更多层级。Agent Skills规范建议正文低于5000 token、主文件少于500行；OpenAI工程实践使用约100行AGENTS.md作为知识目录。这些是组织建议，可以借鉴「入口简洁、细节可达」，不能当作性能最优点。

落地分配的策略

分配内容时，既要看使用频率，也要看规则何时必须生效。必须在选择或执行前生效的限制，要在相应阶段可见；不要为了主文件变短，把它藏到可能永远不会被读取的资料里。按需加载需要同时设计「何时读」和「读不到怎么办」。让大模型帮忙修改指令时，也可以把要求从「扩写得更详细」改成：请找出这份指令中的遗漏、歧义、冲突和重复。保留必要边界与例外；每项修改说明它解决的具体问题、可能改变的行为，以及如何验证。无法从现有信息确认的业务条件，请标为待确认，不要自行补成规则。先明确要解决的是质量还是成本问题：遗漏条件、混淆规则、选错资料属于质量问题；重复输入过多、响应慢、维护困难属于成本问题。先定验收标准，例如日志分析至少检查服务与时间范围、原始证据引用、不确定性标注。固定比较条件，使用相同模型、设置和一组真实任务；避免同时更换模型、重写规则、改工具，否则难以判断收益来源。模型自称「已全面检查」、回答更长或更自信，都不能替代实际验收。

下一次准备给指令追加一段话时，先写清楚：它要修复哪个已观察到的问题？什么结果能证明它有用？删除或拆分内容时也做同样的判断。长度是需要观察的变量，是否解决问题才是保留改动的依据。