夜雨聆风前几天翻出一年前写的一份 system prompt，两千多字，从输出格式到异常分支，写得像一份需求文档。当时求稳，现在看，大半是在防一个已经不存在的笨模型。
OpenAI 面向普通人的提示词指南（openai.com/academy/prompting）思路相反：先说清要什么结果，规则只在需要处加。
这套思路，写 skill、搭 agent、大量用 agent 干活的人尤其用得上。
提示词是你喂给模型的一切
提示词不只是聊天框里那句话。system prompt 是提示词，工具的名字和描述是提示词，workflow 里一环传给下一环的中间结果也是提示词。Anthropic 对 context 的定义是：喂给模型采样的那组 token。按这个定义，整个 agent 在模型眼里就是一段拼接起来的长提示词。
模型变强，细节反而是负担
早期模型能力有限，要靠详尽的格式约束和步骤拆解才能稳定输出，长提示词是必要成本。如今模型能理解未明说的意图、在多条路径中自行选择，这类约束大多已无必要。Anthropic 在《Effective context engineering》（anthropic.com/engineering/effective-context-engineering-for-ai-agents）里说得直接：模型越强，越不需要事无巨细的规定。但多数人的默认动作，仍是先列规则。
写太细的三个代价
一是容易写错。你规定检索先查 A 再查 B，常常只因为自己习惯这么查；但很多问题查 B 一步就能确定，A 是绕路。路径写死，模型只能照着绕。
二是规则互相冲突。很常见的一对：一条要求回复简洁，一条要求每个结论都附依据。简单问题上无碍，复杂问题里两条直接冲突，模型只能牺牲一条，表现为时好时坏——看着像模型不稳定，其实是规则不稳定。
三是维护成本。规则写得越死，越经不起变化——业务细节调整、框架升级、数据变化，甚至模型换代，任何一项都可能让某条叮嘱失效，改一条还怕牵连另一条。几千字的规则，最后成了一段无人敢改的遗留代码。
不只提示词，agent 系统也一样
讲一个我个人的暴论：现在许多 agent 框架、harness、workflow 编排，可能设计得过重了。工程师的本能是不信任运行时——拆步骤、加校验、写死流程，把模型当成一个不可靠的函数来调用。这套做法两年前还站得住，但模型进步很快，很多“重”针对的短板已经不存在。框架尤其要警惕：多加的抽象层会盖住底层实际运行的 prompt，也容易把本可简单的事做复杂。当然不是所有“重”都多余——生产环境的审计、幂等、兜底该重就得重；多余的，只是那些因为“一直这么写系统”而存在的重。
少写，说清四件事
做业务系统时有个常用办法：需求反复改到混乱时，回到最原始的诉求，重新确认要解决什么。提示词同理——与其规定每一步，不如把目标、期望和原则讲清楚，其余交给模型。OpenAI 那份指南的方法，可以归纳成四件事：
目标：先说要什么结果，别先写步骤，步骤交给模型。
上下文：只给会改变答案的背景，无关信息会稀释重点。
输出：说清怎么用它——给谁、多长、什么形式。
边界：只留一两条最关键的硬规则，例如“不确定就说不确定”；“第二段不超过三行”这类多半不必写。
下次给 agent 加一条规则、补一段说明之前，先问一句：这条是模型需要，还是我们的惯性？多数时候，是后者。
