dsh-lorebooklike-prompt-tool

dsh plugin --profile web add dsh-lorebooklike-prompt-tool

dsh-lorebooklike-prompt-tool

DSH的声明式提示词注入层。 把什么时候、往提示词的哪个位置、以多大把握、注入或改写哪段文本变成一份可编辑、可热重载、可复现的 JSON 规则文件，搭配一个类酒馆世界书的图形编辑器。

注：这不是酒馆的dsh插件或替代前端、不是酒馆模拟器、不和角色卡交互、不适用于角色扮演和小说创作场景——它是提示词工程工具。

灵感来源与致谢

这个插件的四项核心机制 全部源自 SillyTavern 的世界书机制。

从酒馆借鉴的机制 · 本插件的对应物

🔵 Constant（蓝灯）／🟢 Selective（绿灯） · mode: "constant" ／ mode: "selective"

Primary Keys ＋ Secondary Keys · keys ＋ keySecondary

Secondary 逻辑：AND Any / AND All / NOT Any / NOT All · keyLogic: "any" / "all" / "notAny" / "notAll"

Scan Depth（回看最近 N 条消息） · scanDepth

Probability（概率触发） · probability

Content 上的 Find/Replace 正则（含捕获组） · replaces

/pattern/flags 字面量写法，且正则优先于大小写与全词设置 · 同样的优先级规则

「绿灯没给主键就永不触发」这种安全默认 · 同样是默认

版权声明：本仓库不含任何一行酒馆代码，只参考其被开源社区验证过的行为逻辑和设计哲学。

---

（以下全部内容均由蓝色大肥鱼书写）

设计边界

• 不新增会话事件类型——所以旧版本 harness 仍能加载本插件产生的日志。
• 不改 agent-loop，不动任何框架源码。
• 所有注册走 ctx.effect() / 注册表 API，卸载时 section 会整批注销（冒烟测试里有专门一项断言）。
• 不注册任何工具。规则完全由人工编排——一个能自助改写注入规则的 Agent 不再可审计。
• **零 @deepseek-ai/* 运行时依赖**，只需要 node:*。
• 不做角色卡、不做 RP 前端、不做记忆——那些是别的插件的事。

和酒馆的区别

拿掉角色扮演这个使用背景之后，酒馆的很多设计在 DSH 里直接照搬是行不通的，这是宿主的注入面不同导致的必然结果。

能力 · 含义

分层提示词 · 每个条目声明一个语义化层锚点，精确插进系统提示的指定位置，与 DSH 自己的段落交错，而不是一律堆在末尾

蓝绿灯 · 蓝灯（constant）无条件常驻；绿灯（selective）按关键词/正则命中才激活

概率激活 · 条目可按概率抽取，且结果可复现——同一会话同一轮次永远得到同一个判定

正则替换 · 按作用面（条目正文 / 整段系统提示 / 用户消息）做正则改写，支持捕获组

1. 「位置」的含义完全不同

酒馆的位置是相对角色卡的：before/after char definition、AN top/bottom、at depth。它有一套聊天消息数组，投喂点就是其中几个插槽。

DSH 没有角色卡，但它有一个分段装配、有官方锚点序号的系统提示。所以本插件的 layer 直接对齐 @deepseek-ai/dsh-system-prompt 导出的 SECTION_ORDERS 常量——「插到工具指引之后、文件交付引用之前」这种意图可以精确表达，不用猜魔数：

 0  harness:identity              (-1000)
 1  lorebook-prompt:layer-early      (-500)   before-persona
 2  deployment:persona-prefix     (0)
 3  lorebook-prompt:sys-redact       (700)
 4  ref:middle                    (3000)
 5  lorebook-prompt:green-never      (3150)   tool-policy
 6  deployment:persona-suffix     (10200)
 7  lorebook-prompt:layer-late       (10300)  tail
 8  ref:hidden                    (11000)

（这是 test/integration.mjs 在真实 SystemPrompt 服务上装配出来的实际顺序，不是示意。）

2. 概率必须是确定性的

酒馆是直接获取随机数。本插件不能。

DSH 有一条硬规则：模型可见 ⟺ 已记录。会话日志必须能完整重放模型当时看到的内容。真随机会让重放得到与当初不同的结果，直接违反这条铁律；再叠加上下文缓存按前缀匹配，逐轮抖动的系统提示会把缓存全部打废。

所以概率门用的是 FNV-1a 稳定哈希而不是 Math.random()：同一 (条目 id, seedSalt, 会话, 轮次) 永远得到同一个判定。

「概率 30%」在本插件里的准确含义是「按轮次确定性抽取」，不是「每次掷骰子」。

对提示词工程来说这反而更好用：你得到的是可复现、可调试的行为，而不是一个无法复现的噪声源。

3. 多出来的一层：通道（channel）

酒馆只有一个注入面（聊天消息数组）。DSH 有两个：

· channel: "system" · channel: "message"

落点 · 系统提示的有序段落 · 转换成 user 角色快照的动态上下文（systemPrompt.context()）

作用域 · 每会话稳定 · 每轮独立

概率语义 · 按会话抽取（系统提示不逐轮抖动） · 按轮次抽取（可复现但会变）

适合 · 风格约束、工具约定、分层规则 · 关键词触发的临时指令、概率性提醒

你要的是「每轮有一定概率追加一段提示」，就用 message 通道。 详见下面的缓存安全一节。

4. 明确被移除的东西

酒馆有 · 本插件 · 为什么

Token Budget / 预算裁剪 · ❌ 不要 · DSH 自己管系统提示的分段装配与预算。插件再插一层预算分配，会和宿主打架，而且它不知道自己排在第几段之前。

Recursion（条目命中后触发更多条目） · ❌ 不要 · 递归注入会让扫描文本自己污染自己——这是个大坑：用已注入后的消息做扫描源，一条正文里含自身触发词的绿灯条目会永远自我续命。已修，并且有了回归断言。递归会把同一类问题放大到不可审计。

Sticky / Cooldown / Delay · ❌ 不要 · 这些是有状态的时序机制，与「日志可重放」冲突。

Group Scoring / 权重抽签 · ❌ 不要 · 组内抽签本质是随机，同上。

角色卡、Persona、RP 前端、聊天记忆 · ❌ 不要 · 那是别的插件的职责。见下一节。

Vectorized / 向量检索条目 · ❌ 暂不 · 需要 embedding 服务依赖；不想为了一个可选项把插件从「零依赖纯数据变换」变成「需要外部服务」。

---

生态位空缺

这个生态位不是空的。检索依据：市场自己的目录（awesome-dsh-plugin，npm 包 dsh-plugin-catalog，构建号 2026.1010.4974），共 4471 个插件，按「世界书/lorebook」「系统提示注入」「关键词触发注入」「正则改写」等关键词做了三轮全量检索。所以下面是按公开描述划出的功能范围。

插件 · 它做的事 · 和本插件的差别

…(truncated)