系统提示是
怎么拼起来的

一次装配，四步

模型每走一步（每个 step），宿主调用一次 ctx.systemPrompt.assemble()。它把注册表里所有贡献收上来，做四件事：

拼出来长什么样

第一方贡献者不用自己挑数字，它们向宿主问 getSectionOrder(name)，拿到统一分配的座位。按这张座位表从前往后，一份完整的系统提示大致是这些段落：

座位表：32 档，稀疏分配

这张表是 SECTION_ORDERS，就在 dsh-system-prompt/lib/index.js 文件开头。数字是稀疏的：900 → 1000、3100 → 5000、9900 → 10000 中间都留着空档，插新段不必重排旧段。点任意一行看它负责什么。

封口：原版不给你改

这张表解释了为什么「改一句系统提示」在原版里很贵。官方文档自己把话说死了：

部署方编写的提示词文本只来自配置／组合……不存在终端用户提示词编辑 API。 @deepseek-ai/dsh-system-prompt · README.zh.md「已知限制」

原版里想动系统提示，只有三条路，每条都带着代价：

1. 改部署配置（personaPrefix / personaSuffix）。写在 profile patch 的 config 里，宿主启动时读。改完要重启；而且只有一个全局槽位，写进去就改不了形状。
2. 写一个插件注册一段。要有代码、要重装、要重启；段名不能撞、顺序要自己算。想改一句话，先改一个包。
3. 用运行期 context。它确实每步刷新，但进的是模型历史里带来源的 user 角色快照，不是系统提示段；它管的是工作目录、沙箱、审批这类事实，不是你想说的那句话。

于是「我那句话」落不进系统提示。这就是 dsh-enhance 存在的全部理由。

一条注册

全部接入就是这个调用。逐行拆开看，每一行的选择都对应第一幕里的一个约束。

// enhance-scope/index.js — 系统提示侧
ctx.effect(() => ctx.systemPrompt.section({
  name: SECTION_NAME,
  order: ctx.systemPrompt.getSectionOrder('DEPLOYMENT_PERSONA_SUFFIX'),
  interpolate: config.interpolate === true,
  text: () => {
    const { effective } = current()
    return effective.injecting ? lastGood.text : ''
  },
}), 'enhance-scope.section()')

为什么改完不用重启

关键就是第 4 条：text 是函数，不是字符串。宿主每次装配都会调用它，而它每次都重新读文件。所以「生效点」不是进程启动，而是下一次装配——也就是你下一条消息。

• T0 你改了 content-scope.txt 存盘。此刻进程里什么都没发生：没有文件监听，没有 IPC 推送。
• T1 你发下一条消息，宿主开始装配 assemble() 走到 10,200 这一档，调用我们的 text()。
• T2 text() 重读文件、重读开关、重新判定 读失败就沿用上一次的好值；判定不过就返回空字符串。
• T3 新文本作为 system 消息发给模型 从这条消息开始，模型看到的就是新文本。全程没有重启。

四道门，外加两条前提

一段文本想真的进系统提示，要过四道门；任何一道不过就不注入，而且给出人话理由。判定集中在 shared/state.mjs 的 derive() 一处，设置页的检查、路由快照用的是同一份判据。

位置：为什么正好是最后一段

order 问出来是 10200，和官方的 deployment:persona-suffix 同一档。同档位里按段名排序，deployment:persona-suffix 在 enhance:content-scope 之前——所以官方后缀先渲染，我们紧跟其后。这次装配里官方后缀是空的、被丢弃，于是我们就是整份提示的最后一段。

它仍然是「一段」，不是往字符串尾巴上 append。它参与排序、参与作用域遮蔽、参与装配 waterfall，所以不会把系统提示结构搞坏——它能被单独丢弃，也能被单独看见。

不接管整份系统提示

原版允许某一段声明 complete: true，成为完整系统提示（且只允许一段存在）。我们没用这条：用了它，20 多个工具说明和默认人格会被整份顶掉。我们只做加法。一个例外：声明层的「品牌人设」走的是「按 agent 遮蔽同名段」——它是在声明层做替换（把宿主那几项顶成空或顶成自定义文本），不是这条末尾加法链上的东西，也不接管整份提示词。

关掉、清空、超限——段变空，渲染器丢弃它，系统提示逐字回到原样，连空行都不留。这是「可退出」在系统提示层面的样子。

下面是这次会话里真实的 system 消息末尾。高亮的那行，就是 content-scope.txt 的全部内容：

设置页的「开始检查」做的就是这件事：取最近的会话日志（按修改时间倒序，一次最多 10 份），解压它们，在含 "system-prompt" 的行里找这段文字。任一份命中 = 这一次装配真的带上了它。（这一页写于 1.1.1；1.2.1 起「检查」把品牌人设那一路并进了同一项——`custom` 要命中自定义文本，`remove` 用反向探针确认最新一份装配记录里已无宿主原句。这里描述的仍是内容边界这一路。）

它会骗你的地方，先说清楚

• 扫的是最近 10 份会话文件，任一命中即过。多工作区并行时它们可能属于别的工作区——这是探针一次扫 10 份的原因，但没扫到的那次仍可能给出误导性的「未命中」。
• 它回答「有没有进系统提示」，不回答「模型有没有照做」。后者只能看回复。
• 日志是多帧追加的 zstd。宿主自带的 Node 24.21 流式解压只解第一帧（30 KB 只回 179 字符），所以探针按魔数切帧、逐帧解再拼起来。
• 字符数会随宿主版本和会话内容变。不变的是位置结论：它仍然落在整份提示的最后。