用系统架构思维，告别"意大利面条式"系统提示词

很多团队写系统提示词时，真正的问题不是“规则还不够多”，而是把所有东西都堆进了一个平面列表。规则一多，冲突就开始出现；改一条牵一片；模型的注意力还会被枝节约束分散，最后连产品真正想守住的价值都被稀释掉。

这篇文章最值得留下的判断是：复杂 system prompt 不能继续按“规则堆砌”来管，而要按系统来设计。也就是先回答三个问题，再决定具体写法：我是谁、我要做什么、我该怎么做。

传统提示词最常见的失控方式，其实可以压成三件事。

第一，没有仲裁层。像“回答要简洁”和“不要过度简化”这种要求，单看都对，放在一起却会打架。如果没有更高优先级的角色定位或目标定义，模型只能在局部语句之间摇摆，结果自然不稳定。

第二，没有模块边界。输入约束、输出格式、内部步骤和安全规则全糊在一起时，任何一次改动都可能牵出连锁反应。久而久之，提示词会变成一个谁都不想再碰的高塔。

第三，没有注意力主线。模型的上下文预算是有限的。次要规则写得太多、太散，核心目标反而会被埋掉，最后输出像“开盲盒”而不是执行产品策略。

这些问题看起来像提示词技巧不够，本质上更像系统设计缺位。

原文给出的四层架构，我觉得是这篇文章最能直接落地的部分。

第一层是核心定义，也就是整个系统的宪法。这里回答“我是谁”和“我为什么存在”，包括角色建模、目标定义、质量红线。它决定了冲突出现时谁说了算。

第二层是交互接口，处理输入和输出。输入规范负责告诉模型怎样理解外部信息，输出规格负责把交付物格式钉住。把“怎么思考”和“怎么呈现”拆开，维护成本会低很多。

第三层是内部处理，解决“具体怎么做”。这里通常要拆能力模块，再定义调用顺序。能力模块负责高内聚，流程设计负责可预测性，两者缺一不可。

第四层是全局约束，也就是硬边界。安全、合规、禁止动作、异常求助机制都应该放在这里，而且优先级要足够高。它不是普通建议，而是系统底线。

这四层真正解决的，不是排版漂亮，而是把不同性质的指令从一开始就放回正确位置。

把架构想清楚，只是第一步。真正进入提示词时，还要做一层“编译”。

原文总结的六个原则里，我觉得最关键的是这几条。

结构映射要显式。用标题、分块或清晰段落把层次标出来，别让模型自己猜哪里是目标、哪里是约束。

模块化封装要明确。相关规则放在同一块里，不要把同一个能力拆散到全文各处。

示例驱动要克制但要有。抽象流程配上 few-shot 或 in-context 示例，能把“理解要求”变成“识别模式”。

指令强度要编码。MUST、SHOULD、NEVER 这类词不是装饰，它们在告诉模型优先级。

格式化契约要稳定。像 XML 或类 XML 标签，本质上是在定义输入输出的数据契约，而不是为了看起来更工程化。

<input>
  <content>用户输入内容</content>
  <context>背景信息</context>
</input>

所谓“策略性冗余”也很重要，但边界要守住。重复关键要求是为了对抗注意力衰减，不是把整份提示词写成回声墙。

我读完后最认同的一点，是它把提示词工程重新拉回到了软件工程语境里。模块化、分层、高内聚低耦合、面向接口，这些并不是旧世界的方法论，放到智能体系统里一样成立。

这样做带来的收益也很直接。

可预测性会提高，因为角色、目标和流程不再混在一起。

可维护性会提高，因为改动可以更像外科手术，而不是整篇重写。

可扩展性也会提高，因为加一个新能力模块，不必连带重构整个 system prompt。

如果你最近正准备重写一份越来越长的系统提示词，我更建议先停一下，别急着继续补规则。先画四层骨架，再把它编译成可执行指令。提示词真正开始稳下来，通常就是从这一步开始的。