dsh-zh-thinking

dsh-zh-thinking

⭐ 如果这个插件帮到了你，欢迎点个 [Star](https://github.com/yingjian666/dsh-zh-thinking) 支持一下 —— 一个星标就是对作者最直接的鼓励。

> 项目状态：这是一次个人学习性质的尝试，作者不承诺持续维护。

> 如果将来 DSH 内核升级导致它失效，欢迎自行 fork 修改——

> 逻辑只有一个文件 lib/index.js，做的事就是往系统提示词里注册一段「用简体中文思考」的要求。

>

> 📝 历次「内核升级导致失效」的原因与修法都记在 [CHANGELOG.md](./CHANGELOG.md)，

> 包括 0.2.0 那次被静默禁用的完整分析 —— 如果你的插件也遇到同样症状，可以直接对照。

让 [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) 里 Agent 的内部思考过程——思维链（chain-of-thought）、逐步规划、工具调用前后的推理、自我审查——始终使用简体中文的宿主插件（host plugin）。

> 声明：本项目参考 / 灵感来自 [wodongx123/dsh-language-control](https://github.com/wodongx123/dsh-language-control)（其 npm 包为 @deepseek-ai/dsh-language-control），在其「让 Agent 用中文思考」的思路基础上独立重写，并解决了本地目录挂载时的依赖加载问题。两者的关系与差异见下文「[与原插件的关系](#与原插件的关系)」。

---

快速安装（DSH Desktop 4.1+）

设置 → 插件 → 从其他来源安装：

| 字段 | 填什么 |

|---|---|

| 插件来源 | github:yingjian666/dsh-zh-thinking |

| 高级选项 | ✅ 勾选「这是来自本地、Git 或其他外部来源的高级插件」 |

确认该来源为全权访问 → 安装 → 重启 DSH。

不需要 npm 账号，也不需要手工建目录链接。

> 连不上 GitHub？直接下载[打包好的 .tgz](https://github.com/yingjian666/dsh-zh-thinking/releases/latest) 再填文件路径即可（同样要勾选那个复选框）。细节见[安装](#安装)。

为什么会有这个插件

DeepSeek 这类推理模型，其「思考」由同一份系统提示词（system prompt）驱动。当工具返回英文内容（例如网页抓取、文档、报错信息）时，Agent 的思维链容易发生语言漂移（language drift）——思考逐步切到英文，导致后续推理与最终回答的语言不稳定。

本插件在启动时向系统提示词注册一段「必须用简体中文思考」的规则，让模型的内部思考保持中文，而最终回答是否默认中文则交给模型自身判断（可保留英文专有名词、代码标识符等）。

与原插件的关系

| 维度 | 原插件 @deepseek-ai/dsh-language-control | 本插件 dsh-zh-thinking |

|---|---|---|

| 注入机制 | systemPrompt.section()，order -200（最顶部） | systemPrompt.section()，order 20（persona 之后） |

| 外部依赖 | 有 peer 依赖（@deepseek-ai/cordis、@deepseek-ai/dsh-host-webserver） | 零外部依赖，只依赖 cordis 运行时注入的 ctx |

| 设置面板 | 有（HTTP 路由 + 客户端注入可视化面板） | 无（极简，见[配置](#配置)） |

| 安装方式 | 必须经 npm（dsh plugin add @deepseek-ai/dsh-language-control） | GitHub / 本地目录 / .tgz 均可，无需发布 npm |

相对原插件主要优化 / 解决的问题：

1. 零外部依赖，规避「本地目录挂载崩溃」。当插件通过 link: 从 profile / app 的 node_modules 树之外的目录挂载时，Node 无法解析插件自身 import 的 npm 包（如 schemastery），会导致整棵插件树加载失败（fatal plugin-tree load failure）。本插件不 import 任何第三方包，只使用宿主运行时提供的服务，因此从任意路径挂载都能正常加载。

2. 不依赖 npm 发布。原插件必须先从 npm 安装（且易因包名带不带 @deepseek-ai/ scope 而装错）；本插件 git clone 后即可本地挂载，或直接从 GitHub 安装。

3. 极简、易读易审。单文件、几十行代码，无 HTTP 路由、无客户端面板，行为一目了然。

功能特性

• 中文思考强制：链式推理、规划、工具调用推理、内部思考全部要求使用简体中文
• 注入位置固定在 persona 之后，稳定可预期
• 生命周期自动回收：插件卸载 / 上下文停止时干净地移除注册的 section
• 零依赖、零配置、即装即用

兼容性

| DSH 内核（@deepseek-ai/dsh-system-prompt） | 状态 |

|---|---|

| 0.1.1-rc.1 … 0.1.5.x | 兼容（最初的目标版本） |

| 0.1.6-alpha.1 / 0.1.6-alpha.2 | 兼容，已在真实内核上实测 |

| 0.2.0-rc.2（Desktop 5.0.0） | 兼容，已在真实内核上实测 |

section({ name, order, text }) 的契约从 0.1.1-rc.1 一路到 0.2.0-rc.2 没有变化过，所以插件的实现代码从来没有因为内核升级改过。真正需要维护的只有 package.json 里的两个版本声明：

• peerDependencies["@deepseek-ai/dsh-system-prompt"] → ">=0.1.6-alpha.1"（只写下限，不写上界）
• dsh.compatibility.runtime → ">=0.1.1-rc.1 <0.3.0-0"

⚠️ 为什么 peer 范围千万别写 ^

这是 0.2.0 上真实踩到的坑：

// ✗ 这样写，内核一升到 0.2.0 的预发布版，插件就会被静默禁用
"@deepseek-ai/dsh-system-prompt": "^0.1.6-alpha.1"

^0.1.6-alpha.1 在 semver 里展开成的上界不是 <0.2.0，而是 <0.2.0-0 —— 那个 -0 把 0.2.0-rc.1、0.2.0-rc.2 这类所有 0.2.0 的预发布版全部排除掉了。

而 DSH 0.2.0 新增了一道 profile 兼容性预检（dsh-app-boot 的 prepareProfileEntries）：加载 profile 之前逐行检查，peerDependencies 里任何 @deepseek-ai/dsh-* 范围不满足当前 runtime 的行会被直接 disabled = true，只在 stderr 打一行 disabling profile plugin ...。结果就是——插件装得好好的、界面还显示 compatible，但就是不生效。

而且这里有两套判定口径不一致，这正是它难排查的原因：

| 判定方 | 依据 | 对 0.2.0-rc.2 的结论 |

|---|---|---|

| Desktop 界面 / desktop-plugins.lock.json | dsh.compatibility.runtime，上界 <0.2.0（无 -0） | compatible |

| 运行时预检（真正决定是否加载） | peerDependencies 的 range | incompatible → 静默禁用 |

还有两个容易踩的点：

• peerDependenciesMeta.optional: true 对运行时预检无效 —— 它只读 peerDependencies 的 range，不看 optional 标记。
• 完全**不声明任何 dsh-* peer**（只留 dsh.compatibility.runtime）也永远不会被预检拦下；本插件选择保留 >=0.1.6-alpha.1 这种写法，兼顾"最低内核版本"的语义。

如果插件在 0.2.x 上不生效，怎么恢复