实际开发中，System prompt 由不同人在不同时期共同维护，那我们用什么办法可以防范 System prompt 的熵增

回复 Erfan： 多人协作维护 System Prompt 最容易变成“补丁摞补丁”的屎山：有人遇到一个 bad case 就往末尾塞一条“禁止做 X”，过半年没人敢删，还互相冲突。防范熵增的核心是把 System Prompt 当代码管，同时做架构拆分： 1. 拆分：常驻内核 vs 按需加载（Skills / 子模块） 把全局 System Prompt 锁死在最小集合，只放核心身份、通用底线和全局行为准则。具体业务场景的规范、特定工具的复杂用法，全部拆成按需加载的 Skill 或子模块（参考 Joye 讲过的渐进式披露）。谁负责哪块业务就维护哪个 Skill，平时不占主上下文，从物理上隔离不同人写的规则。 2. 能下沉到代码和 Schema 的，绝不写进 Prompt 很多人的第一反应是靠 Prompt 修 bug，比如在 System Prompt 里写“调用搜索工具时 query 不能超过 50 个字，且必须带时间”。这种约束应该直接写进工具的参数校验（Pydantic/JSON Schema）或前置 Hook 里，不合规直接报错拦截。用确定性代码替掉自然语言叮嘱，Prompt 自然就薄了。 3. 每一条规则必须绑定 Bad Case 回归测试（Eval-driven） 把 Prompt 纳入 Git 管理，规定不允许提“无测试的 Prompt PR”。任何人想往 System Prompt 里加一条规则，必须同时在评测集里提交对应的复现用例（证明不加这条就会挂，加了就能过）。这样后续别人重构或精简 Prompt 时，跑一遍回归测试就知道有没有把前人的坑踩回来，敢于放心删改。 4. 随模型升级定期做“减法测试” 很多早期加的啰嗦补丁，其实是旧模型太笨时的拐杖。每次底层模型升级（或者每个季度），专门做一次消融清理：把那些历史遗留的防御性规则一条条注释掉跑评测，只要新模型在不加提示的情况下也能自然做对，就立刻把旧规则删掉。