dsh-prompt-polish
Verified@benrong/dsh-prompt-polish · v0.2.4 · AGPL-3.0-or-later · Web UI
Prompt-polish button beside the composer model seat for DSH, porting linshenkx/prompt-optimizer's optimizationMode axis, mustache template engine, template registry and variable extraction.
Install
dsh plugin add @benrong/dsh-prompt-polish Confirm the layer applied with dsh --profile default --dump-config — see the install guide.
Source
Tags
Creators
Readme
dsh-prompt-polish
English · 中文
在 DSH 的输入框旁边加一个 ✨ 润色按钮:写下你的需求,点一下,几秒钟拿到一份带角色、目标、约束和输出格式的完整提示词。默认只写回输入框,发不发由你。
润色引擎移植自 linshenkx/prompt-optimizer(AGPL-3.0),十套模板逐字保留;按钮、面板、历史与对比由本仓库实现。
功能与实现
| 能力 | 说明 |
|---|---|
| 三种润色模式 | 系统提示词 / 用户提示词 / 迭代优化,对应上游三套模板族,流式输出 |
| 结果去向 | 复制 / 替换草稿(不发)/ 发送草稿,边界固定:不点击不写入、不发送 |
| 模型与时耗 | 可在面板里固定润色用的模型(默认跟随输入框);每次显示模型、耗时、字数、token |
| token 用量 | 逐次与按链汇总;模型未上报时显示"未提供",不显示假 0 |
| 本机历史 | 授权后每次生成存为版本,迭代自动成链;上限 50 条,支持逐条删、整链删、全清 |
| 版本对比 | 原稿|所选版本|最新版本 三列,附本机结构分析(行数增删、目标/背景/约束/格式覆盖),不再调用模型 |
| 变量提取 | 把结果中可变的片段抽成 `{{变量}}`,写回即成模板 |
润色效果:两组真实前后对照
以下两组对照来自本插件的真实使用记录:左边是输入的原话,右边是点一次润色后模型实际收到的任务。效果差异集中在角色、依据、约束、输出格式这四项——也正是原话里最难现想的部分。
例一:把"不要僵硬"翻译成七条标准。
| 原话 | 润色后 |
|---|---|
| 你不要僵硬,实际都是以具体内容为准的。你的目的在于梳理该章节的内容,以思维导图的形式呈现。 | 请以我提供的章节具体内容为唯一依据,梳理该章节的内容结构,并输出为思维导图。要求:①不套固定模板,章节实际讲了什么就按什么逻辑拆;②中心主题用章节标题或概括性短语;③一级分支按内容划分,3—7 个不凑数;④下级按实际逻辑展开,可到三四级;⑤节点用简洁短语,保留原文术语,不增不漏;⑥用 Markdown 嵌套列表输出;⑦多种梳理时选最贴合原文的一种。 |
"不要僵硬"五个字,展开成了七条可执行、可核查的要求——模型的发挥空间被限制住了,任务的验收标准立起来了。
点开看润色后的完整原文
请以我提供的章节具体内容为唯一依据,梳理该章节的内容结构,并输出为思维导图。要求如下:
- 不要套用固定模板、预设框架或僵化层级;章节实际讲了什么,就按什么逻辑拆分。
- 中心主题:使用章节标题或能够概括全章的核心主题。
- 一级分支:依据章节的主要部分、核心论点、关键问题或内容板块划分,数量随内容而定,通常为 3—7 个,不强行凑数。
- 下级分支:按分类、因果、流程、对比、例证、并列关系等实际逻辑展开;内容简单时可只到二级,内容复杂时可扩展至三级或四级。
- 节点表述:使用简洁的名词短语或短句,保留原文关键术语和核心概念;不添加原文没有的信息,不遗漏重要内容。
- 输出形式:使用 Markdown 嵌套列表或缩进大纲呈现,清晰体现父子层级关系,便于直接转换为思维导图。
- 若章节内容存在多种合理梳理方式,优先选择最贴合原文结构、最便于理解的一种;必要时可在节点后括注原文依据或关键词。
例二:把"帮我看看"变成一份评审任务书。
| 原话 | 润色后 |
|---|---|
| 我是想让你从产品经理的角度,看看我们这个作品设计的咋样,还有什么需要改进的 | 请以产品经理的视角评审本作品的设计并给出改进建议。作品信息(请按实际补充):名称/类型、目标用户、核心痛点、核心功能与流程、设计材料。评审维度:①目标用户与痛点是否明确、真实;②功能与场景是否匹配、有无冗余缺失;③流程与交互是否顺畅、上手成本;④与同类方案的差异和优势;⑤可行性与商业价值。输出:先整体评价(优点+最关键问题),再按高/中/低优先级列可落地建议(每条带理由与预期效果);信息不足先列出需补充项,不凭空假设。 |
"看看咋样"四个字,变成了一份带输入清单、评审维度和产出结构的任务书——模型不再客套,缺材料会开口要。
两个例子改的都是同一类东西:任务的目标、依据和验收标准。这些东西写清了,模型的回答才有着落——这正是每次点润色时,替你补上的部分。
使用成本
成本集中在一处:模型调用。除此之外没有账号、没有上传、没有后台进程。
- 一次模型调用。 每点一次润色就是一次流式调用,按 token 计费的环境真实产生开销,典型几百个 token(面板里可见:"本次 120 输入 + 45 输出 = 165 tokens")。打开面板、翻历史不产生调用。
- 几秒钟等待。 速度由模型决定,面板如实显示耗时;嫌慢可以在面板里换模型。
- 一段学习成本,接近零。 会打字就会用;三个模式(系统提示词/用户提示词/迭代优化)各管一类任务,默认模板由服务端下发,不需要你先研究。
安全边界
所有写操作都以你的点击为前提,边界如下:
- 不自动发送。结果只写回输入框,发送永远是你按回车或点"发送草稿"。
- 不偷存数据。历史要先征求你的同意,只存在这台设备的浏览器里;选"不保存"就一条不存,也不再问。
- 不替你补事实。它补的是结构——你忘了写的关键数据,它变不出来。
- 不碰已经写好的提示词。角色、约束、格式俱全的草稿,再润色收益很小。
典型工作流
- 随手写一句"帮我写个周报",点 ✨,得到一份带角色、输出要求的周报提示词,看一眼,发送。
- 结果不够好,切到「迭代优化」,输入"更口语一点,加个数据部分",在上一版上继续改。
- 打开历史(首次会先征求你的同意),看到每次的输入、结果和 token 消耗;点开一条链,三列对比原稿和各版本,确认哪版最好用。
- 周报模板用熟了,点「提取变量」,把"本周"这类常改的词抽成 `{{时间范围}}`,下次改一个词就能用。
隐私
历史(如果你开启)只写入这台设备的浏览器 localStorage,不上传、无遥测、无账号。删除是真删除。关闭后可随时在历史页重新开启。
安装
已在 DeepSeek Harness 0.2.1-rc.1(桌面版)实测:宿主路由、conversation.input.right 插槽与 llm 调用路径都和 0.2.0-rc.2 一致,这次升级不需要改插件代码。
需要 DSH(desktop 或 web profile)与 Node.js 18+。
git clone https://github.com/benrong2048-boop/dsh-prompt-polish.git
cd dsh-prompt-polish
pwsh -File install-plugin.ps1 -ProfileName desktop # 或 -ProfileName web
脚本把包复制进 %USERPROFILE%\.dsh\profiles\<profile>\node_modules\,做语法检查,并把插件行写进该 profile 的 cordis.patch.yml(会打印写入内容)。之后完整重启 DSH:桌面应用没有绑定刷新键,Ctrl+R 无效。
手动安装:把本目录复制到上述 node_modules 路径,并在 cordis.patch.yml 里加:
- insert:
- id: prompt-polish
name: "@benrong/dsh-prompt-polish"
卸载:删包目录、删那段 insert,重启 DSH。
测试
node mustache.test.mjs # 渲染引擎语义(34 项)
node smoke.mjs # 模板层(219 项)
node contract.test.mjs # 浏览器半:真 useEffect + 假流式 fetch(117 项)
node host.test.mjs # 宿主半:三条路由与失败路径(164 项)
node compare-upstream.mjs # 审计:模板正文与上游逐字比对(需 $env:UP=<上游检出>)
发布时 534 项断言全部通过。
上架 dshmarket
目录条目在 market/plugins-entry.json,上架步骤见 market/SUBMITTING.zh.md(先发 npm,再向 awesome-dsh-plugin 目录提 PR)。
协议
AGPL-3.0-or-later,见 LICENSE。润色引擎与模板来自 linshenkx/prompt-optimizer(同为 AGPL-3.0),其作者权益在此声明保留。