提示词优化器 ViewWay/dsh-prompt-optimizer

dsh-prompt-optimizer

一个独立分发、单独发布的插件系列，面向 DeepSeek Harness。它把粗糙的想法草稿，经过多轮 改写 → 自审 → 修复，打磨成可直接交给智能体的提示词。

功能

- 输入框上有 优化 一键按钮，还有领域推荐标签；支持多轮优化，可重试，每轮都能预览差异
- 角色库（<slug>.md 文件）：包内自带 164 个角色的目录，rolesDir 未设置时就用它；可按需列出角色、按草稿推荐角色、指定角色重跑；在设置页设默认角色
- 技能感知（skillAware）：草稿命中已安装的技能时，把技能名称和描述折进元提示词，让输出引用这些技能——用精确名称约束防止模型编造。中英文草稿都能匹配：内置双语词表把「页面／接口／部署」这类中文词映射到英文描述的技能，也能反向映射
- 优化方向：预览面板上有五个标签（更简洁 / 更详细 / 更技术 / 重构结构 / 更强验收），点一下就让本轮朝选定方向重跑，并回显当前方向；方向是固定枚举，不接受自由文本，因此没有提示词注入风险
- 提示词库：一键保存任意结果；输入行上的库按钮打开管理面板——浏览、展开、插入草稿、从已存条目重新优化，或两步确认后删除（最新的排前面）
- 输出语言跟随智能体界面语言：中文界面出中文提示词，英文界面出英文，代码标识符、路径和命令保持原样
- 排队中（未发送）的对话条目上也有内联 优化 入口
- 验收标准：机械可判的标准自带可执行的检查命令模板

怎么判断一次优化好不好

结果不只是改写后的文本——预览面板里每一块都是评审材料：

| 面板区块 | 是什么 | 怎么用它判断 |
| 优化后文本 | 改写后的提示词 | 对照草稿栏，逐节读 |
| 变更 | 模型声称做过的每处修改 | 逐条问：它让任务更清楚了吗？有没有改了不该改的地方？ |
| 验收标准 | 定义「做完」的条件 | 机械可判的用检查按钮跑；其余按各自写明的判断点核对——一条都无法验证就可疑 |
| 技能 | 本轮匹配到的已安装技能 | 结果里提到的技能必须用列出的精确名称；列表为空时，结果不得凭空编造 |
| 评审 | 系统提示词第二轮的修订记录 | 每条修订是否说清了改了什么、为什么改？ |

快速检查清单：
1. 零细节丢失 —— 路径、版本、命令和数字原样保留；
2. 结构清晰 —— 目标、上下文、约束和预期输出分开陈述；
3. 不编造 —— 不添加草稿从未提及的事实（文件名、错误文本、需求）；
4. 验收可验证 —— 每条标准都能通过命令或判断点检查；
5. 技能引用合理 —— 点名的技能确实贴合任务，且名称完全一致。

任何一项检查不通过时：点 Regenerate —— 被驳回的结果会作为上一轮尝试带入下一轮，模型必须给出明显不同的修订；或点方向标签（更简洁 / 更详细 / 更技术 / 重构 / 更强验收）朝该方向重跑；或换一个角色重跑，或切换到 system-prompt 模式。用 Save to prompt library 保存好用的结果，之后随时可以从输入行的库按钮召回、重新优化或删除。

仓库结构

| 包 | npm | 用途 |
| packages/prompt-optimizer | @yimiliya/dsh-prompt-optimizer | 宿主服务：优化轮次、角色库、技能提示、模型路由 |
| packages/api-prompt-optimizer | @yimiliya/dsh-api-prompt-optimizer | 远程控制器和 Typert 描述符（宿主/客户端共享方法表） |
| packages/client-ui-prompt-optimizer | @yimiliya/dsh-client-ui-prompt-optimizer | 浏览器 UI：触发按钮、预览面板、队列条目、设置页 |
| packages/bundle | @yimiliya/dsh-prompt-optimizer-bundle | 配置档 bundle（cordis.patch.yml），一次装齐三个插件 |

每个包都有自己的 README，npm 会在包页面上渲染；本文是家族层面的总览。tools/tsdown.client.ts 是独立的客户端构建预设：它按 harness 的 window.__ModuleLoader__.load({id, factory}) 约定产出浏览器闭包产物，CSS Modules 由 lightningcss 编译成自包含的注入样式。

安装（用户）

发布到 npm 后，在任意已安装 dsh 的配置档上：

dsh plugin --profile web add @yimiliya/dsh-prompt-optimizer-bundle

bundle 会把 prompt-optimizer、api-prompt-optimizer 和 ui-prompt-optimizer 叠加进该配置档的 dsh.profile.bundles。你也可以从 Web 客户端的插件市场安装。
在正式发布之前，先从 tarball 安装。直接用本地路径或 git spec 不行：bundle 的 workspace: 依赖只在本仓库的 pnpm workspace 内解析，而 dsh plugin add 是在配置档自己的根目录里安装。打包会把那些版本范围改写成真实版本（pnpm -r pack），tarball 的依赖随后从 registry 解析——所以这条路要求另外三个包先发布：

pnpm -r pack # writes .tgz next to each package.json
dsh plugin --profile web add packages/bundle/yimiliya-dsh-prompt-optimizer-bundle-<version>.tgz

配置（可选——cordis.yml 中的 plugins > config > prompt-optimizer）

| 字段 | 默认值 | 说明 |
| verifyTimeoutMs | 见源码 | 验收检查命令的超时时间 |
| domainPriors | true | 按草稿的技术领域注入先验 |
| provider / model | 未设置 | 为优化显式指定模型路由；两项必须同时出现 |
| rolesDir | 内置目录 | 覆盖角色定义目录（<slug>.md）；未设置时使用随附的角色库，且该库保持只读，不能演化角色 |
| defaultRole | 未设置 | 未指定角色时的默认角色 slug；也可在设置页设置 |
| skillAware | true | 把匹配到的已安装技能并入元提示词 |

隐私

优化运行记录在会话自己的事件日志里；草稿也按此对待：

- 每轮优化都会追加一条 plugin:prompt-optimizer/llm-request 记录，包含完整草稿文本和辅助系统提示词。
- 每次检查运行都会追加一条 plugin:prompt-optimizer/verify 记录，包含执行的命令及其（脱敏后的）输出。
- 「改进此角色」会改写磁盘上配置的 rolesDir 下的角色定义文件 <slug>.md；旧版本保留在旁边，名为 <slug>.md.bak。内置默认目录只读：配置 rolesDir 才能启用角色演化。

如果把密钥粘贴进草稿，就要预期它们会出现在会话日志里。

开发

pnpm install
pnpm run check # lint + typecheck + build + test (the same gate CI runs)
pnpm run typecheck # TypeScript only
pnpm run lint # oxlint
pnpm run test # vitest (node + client projects)
pnpm run build # tsdown, dependency order

- node 项目（host + api 测试）开箱即跑。
- client 项目（jsdom 浏览器测试）通过 deepseek-harness 检出解析 @deepseek-ai/ 模块：已发布的 dsh 客户端包是浏览器闭包产物，只在真实 web 客户端内加载，所以测试按 harness tsconfig.base.json 的 paths 映射进入其源码树——这些测试套件在 harness 仓库内原生运行也是同样的方式。默认指向同级检出 ../deepseek-harness-latest，也可以显式指定：

DSH_HARNESS_ROOT=/path/to/deepseek-harness pnpm run test

仓库检出目录里必须已经跑过 pnpm install（源码从自己的目录树里解析依赖）。测试配置还把 react / react-dom / use-sync-external-store 固定为同一份副本，避免跨副本的钩子报错。

智能体和贡献者请阅读 AGENTS.md，了解仓库约定。

兼容性

支持的基线是 @deepseek-ai/dsh- 0.2.1-rc.3；更早的版本未经验证。细节——包括队列条目槽位要求和固定的 peer 依赖——见 docs/compatibility.md，那里是唯一权威来源。

发布（维护者）

四个包保持同一版本。打一个发布标签（git tag vX.Y.Z && git push origin vX.Y.Z），GitHub Actions 就会按依赖顺序构建、检查并把四个包全部发布到 npm（host → api → client → bundle）。见 .github/workflows/release.yml。

许可证

Apache-2.0