提示词优化 ClockworkParrot/dsh-prompt-optimize

dsh-prompt-optimize

一个 DSH Web UI 原生插件：在输入框发送按钮的左侧放一个 优化提示词 按钮，点一下就用当前会话自己的模型路由改写草稿，并通过编辑器原有路径原地回填——一次撤销即可还原原文。

输入区工具行：[引号 ▾] [思考强度 ▾] [优化提示词] [发送]
^ conversation.input.right

安装

在 DSH Web GUI / Agent 里把本目录作为 bundle 安装
plugin_manager({ action: "install_bundle", target: "<本包的绝对路径>" })

Bundle patch 只插入自己这一行（cordis.patch.yml），不改动任何 DSH 核心文件，dsh.bundle.patch 保持为一个自包含的 insert。

日常构建可以跳过重启：plugin_manager({ action: "set_plugin", target: "include:prompt-optimize",
enabled: false }) → 覆盖新文件 → set_plugin … enabled: true。首次安装，以及新增 npm 依赖后的重装，仍然需要重启 dsh web（Host 的模块表在启动时就固定了）。纯客户端改动会被客户端重载器直接拾取，两种方式都不用。

安装时的两个坑（DSH 行为，不是本插件的问题）

1. 会话中途安装的 bundle 只在“下一次重载”时挂载。 启动时，如果 Loader 行对应的包还不在 profile 的运行时解析表里，这一行就拿不到 entry，也不会被 import；host 只会在那一次启动打印 dsh: warning: 1 entry did not activate，之后的重载不再提示。所以当 plugin_manager list_plugins 里看不到 include:prompt-optimize 行、而 Config inspect 仍然列着这个包时，重启 dsh web——任何会话内开关都补不出缺失的 entry。
2. 任何 plugin_manager 包操作都会清理包内的 node_modules。 dsh-prompt-optimize 是以 link: 方式指向本目录安装的，但 pnpm 仍会管理 link 目标内部 的 node_modules，并在每次 install/remove/upgrade 时清理它，留下失效符号链接。Host 半边需要 @deepseek-ai/cordis（应用自己的那份）和 @deepseek-ai/schemastery；链接一断，entry 就会以 ERR_MODULE_NOT_FOUND: Cannot find package '@deepseek-ai/schemastery' 停止 import。任何 plugin-manager 操作之后重建链接即可，无需重启：

cd <本包目录>
rm -rf node_modules && mkdir -p node_modules/@deepseek-ai
dsh 指向 <npx root>/node_modules/@deepseek-ai/dsh/lib/bin.js
NPXROOT="$(dirname "$(dirname "$(dirname "$(dirname "$(readlink -f "$(command -v dsh)")")")")")"
ln -s "$NPXROOT/@deepseek-ai/cordis" node_modules/@deepseek-ai/cordis
ln -s "$HOME/.dsh/profiles/web/node_modules/@deepseek-ai/schemastery" \
node_modules/@deepseek-ai/schemastery

按钮行为

| 场景 | 按钮 |
| 草稿为空 | 禁用（提示「草稿为空」） |
| 含附件、引用 chip（文件/选区），或以 /命令 开头 | 禁用 |
| 输入框正在提交 / 判定中 / 已被认领 | 禁用 |
| 请求进行中 | 旋转图标 +「优化中…」，无法重复触发 |
| 调用成功 | 原地替换草稿（或追加），一次撤销即还原 |
| 调用失败 | 草稿保持原样，按钮旁只显示一行短错误 |

如果请求期间草稿被改动（你继续打字），结果不会覆盖你的编辑，按钮提示 草稿在优化期间被改动，未回填。

配置

Host 与 Client 读同一份 Config schema，默认值直接写在 schema 里，因此 apply(ctx, config) 拿到的就是「用户值或默认值」。在设置里改完立即热替换，无需重启。

设置页

插件在 设置 → 通用设置 → 提示词优化 贡献自己的一行（settings.general.item，id prompt-optimize，order 5）。这一行直接编辑本插件 Config 的全部六个字段，带 保存 和 恢复默认 按钮，并额外提供：

- Provider / 模型下拉框，选项来自 ctx.remote.session.modelCatalog()——部署已知能连通的 provider 与模型清单。选 provider 之后模型下拉才启用。
- 推理强度下拉框，仅当所选模型声明了可选强度时出现。
- 目录加载失败或尚未就绪时，下拉框自动退化为文本框，可以手填任意 provider/model id。

几个实现细节：

- 这一行通过共享设置镜像（ctx.configForms）读写，键是本插件的设置命名空间 prompt-optimize——也就是 cordis.patch.yml 里的 Loader 行 id，这是设置文档给 entry 命名的方式（entry.options.id），不是带前缀的 include:…。Host 文档始终是事实来源，所以你手改 profile patch 后，下一次 describe 会在行里同步显示。
- 「恢复默认」是清空字段，而不是把默认值写回去。清空后字段直接读 schema，profile patch 里只留你真正选择过的值。
- 行由 ctx.inject(['slots', 'configForms', 'remote', 'remote.session'], …) 注册；万一某个部署没有 settings 域，还有一条兜底注册，让这一行以「当前无法读取这项配置」的状态出现，而不是整行消失。
- schema 里三个基础字段带 .volatile()，这不只是热替换通道，还是这一行能存在的前提：settings.describe() 只投影 volatile 字段（volatileForm），没有 volatile 字段的 schema 不会暴露命名空间，那一行就永远不会被服务。apply() 随后拿到的是活的 { get() } 引用，resolveOptions() 在每次点击时读取。
- 值在离开页面前校验：占位符非空且不超过 64 字符，超时是 1000…2147483647 的整数。值非法时保存按钮禁用，并在按钮下方给出原因。

| 字段 | 类型 | 默认值 | 含义 |
| datePlaceholder | string | {{DSH}} | 草稿中提到日期/时间的位置替换成的文本。 |
| replaceMode | 'replace' \| 'append' | 'replace' | 原地写回；或保留草稿，空一行后追加优化结果。 |
| timeoutMs | number（1000…2147483647） | 30000 | 单次模型调用的端到端超时。 |
| provider | string | '' | 固定 provider 路由。留空则跟随会话自己的模型。 |
| model | string | '' | 固定模型 id。provider 未设时忽略。 |
| reasoningEffort | string | '' | 固定路由下的推理强度。留空则跟随路由。 |

provider 与 model 是一对：两个都填才固定路由，两个都空则跟随当前会话（取不到时回退部署默认）。半填的组合会被设置页拒绝，因为它实际上固定不了任何东西。

插件从不接收 base URL 和 API Key，也从不存储它们：鉴权始终留在 ctx.llm 背后那层 provider 适配器里。如果某个 provider 的目录加载失败，设置页会说明原因，固定路由字段在那里改不了，但 patch 文件仍接受任何 Host 认的标识符。

也可以在 profile patch 里直接固定：

- id: prompt-optimize
name: dsh-prompt-optimize
config:
datePlaceholder: '[[DATE]]'
replaceMode: append
timeoutMs: 20000
provider: deepseek-account
model: deepseek-flash

优化规则（system prompt）

模型被要求只回优化后的提示词正文——没有前言、引号或代码围栏——并遵守六条硬约束：

1. 不添加任何情景假设：不得出现 假设你是…、设想…、在某个场景中…、Imagine…、Suppose…、Pretend you are…、In a scenario where…。只针对提示词本身做结构化、明确化，不为它编造使用场景。
2. 不写具体日期、时间、地点。草稿中每个日期时间位置都替换成 datePlaceholder。
3. 保留原草稿的语言。
4. 路径、标识符、命令、参数、代码、数字、单位、URL、版本号原样保留。
5. 只补充原稿隐含的具体信息，不加别的。
6. 只输出提示词正文。

错误与日志

| reason | 按钮旁文案 | 触发条件 |
| EMPTY_DRAFT | 草稿为空 | 没有可优化的内容 |
| NO_MODEL | 没有可用的模型 | 会话无路由且部署无默认路由，或该路由没有适配器 |
| TIMEOUT | 模型调用超时 | timeoutMs 用尽 |
| EMPTY_RESULT | 模型没有返回内容 | 模型结束但没有文本 |
| TRUNCATED | 结果被截断，未回填 | 输出撞到 token 上限 |
| TOO_LARGE | 草稿太长，超出模型上限 | 草稿超过 20000 字符或超过模型上下文窗口 |
| PROVIDER | 模型调用失败 | 其它上游失败 |
| CANCELLED | 优化已取消 | 调用被中止 |
| DISCONNECTED | 与后台的连接已断开 | 页面失去 RPC 通道 |
| BUSY | 上一次优化还没结束 | 已有调用在飞时再点 |
| CHANGED | 草稿在优化期间被改动，未回填 | 调用期间继续打字，结果被丢弃 |

按钮旁的文案保持简短。鼠标悬停显示 Host 返回的诊断事实，不打开日志也能定位 provider 故障：

按会话路由 deepseek-account/deepseek-flash · HTTP 429 · RATE_LIMITED · 842ms

它由这些字段拼成：route（是哪条规则选出来的——config / session / default——以及 provider 和模型）、status（上游 HTTP 状态）、code（模型层自己的错误码）、message、elapsedMs。失败没带的字段直接省略，不会瞎猜。

调用日志

错误行右侧有一个 详情 / 收起 按钮，点开弹出调用日志面板（最多保留最近 20 条，仅内存，刷新即清空）：

调用日志 [复制]
12:03:41 started request · 42 chars · session abc123 12:03:42 failed model · PROVIDER · HTTP 401 · 会话:deepseek-account/x · 1204ms 12:03:58 ok model · model:deepseek-account/deepseek-flash · 42 → 380 chars

- 每次调用都记录：stage（request / model / client / guard）、outcome （started / ok / failed / skipped）、reason、code、HTTP、实际路由及其来源、字数变化、耗时。
- 成功后也记录，方便确认占位符替换和路由是否符合预期。
- 「复制」一键复制全部记录，便于报障。
- 同时向浏览器 Console 输出一条 [prompt-optimize] <outcome> <stage> — <detail> （中文说明「它因何失败」，常见问题是 setError 覆盖了更具体的信息）。

模型路由

没有任何硬编码。Host 半边每次调用按以下顺序解析路由：

0. 显式配置的 provider + model（两个都设）——错误提示里来源显示为 config；
1. 会话待生效的模型选择（modelSelection 投影）；
2. 否则取会话 header 里记录的选择（其中自带的 reasoningEffort 只在适配器没有默认值时使用）；
3. 否则 agentDefaultModel.currentSelection()——部署默认模型。

随后调用走 ctx.llm.prepareCall / PreparedLlmCall.stream，因此插件永远看不到 provider 密钥，并继承部署已有的重试与凭据策略。

文件

| 路径 | 作用 |
| lib/index.js | Host 半边：Config、PromptOptimizeService（promptOptimize.optimize Remote）、apply。 |
| lib/index.d.ts | Host 半边的纯类型面。 |
| lib/client.js | Client 半边：输入区按钮（conversation.input.right）、通用设置行（settings.general.item）、样式、文案、RPC 调用、日志面板。 |
| src/index.ts | Host 半边的源码，npm run build（tsc）编译成 lib/index.js。 |
| tsconfig.json | src/index.ts 的构建/类型检查配置。 |
| cordis.patch.yml | Bundle patch：对本包的一次 insert（不修改任何核心文件）。 |
| locale/*.json | 插件管理器里显示的 bundle 标题/描述。 |

构建

npm run typecheck # tsc --noEmit
npm run build # tsc -p tsconfig.json -> lib/index.js + lib/index.d.ts

@deepseek-ai/schemastery 是唯一声明的运行时依赖。@deepseek-ai/cordis 是 dev 依赖： Host 本来就在跑 Cordis，编译后的 entry 必须解析到应用自己的那份（应用的 node_modules 是本包的祖先目录），绝不能装第二份。其余 Host 服务（llm、agents、agentDefaultModel、 sessionProjections）全部通过 ctx.get() 获取并在 src/index.ts 里以结构类型描述，所以编译后的 entry 不再 import 别的包。

entry 故意声明 export const inject = []：服务在每次调用时解析，模型路由不可用会变成一条 NO_MODEL 回执。反过来，硬写 inject: ['llm'] 会让端点在等一个只有完整重启才重新评估的依赖。

src/index.ts 刻意只使用 Node 能剥离的语法（没有 enum、namespace、参数属性），并拆分类型导入（import type { Context } …），因此同一份源码既能被 Node 22 直接 import，也能被编译。
DSH 实际加载的 entry 始终是 tsc 的输出 lib/index.js。

重载行为

Entry.refresh() 在 fiber 已存在时直接返回，所以一次重载会重跑 init() 并再次挂载
apply()，而旧实例仍占着 promptOptimize 这个名字。与其销毁旧实例（它的 provide effect 属于
父 fiber，在 apply 内部释放不了这个名字），apply() 捕获重复注册失败，通过
reconfigure() 把最新的 Config 交给正在运行的服务。浏览器已经持有的端点因此在每次重载后
依然可达，新配置在下一次点击时就生效。