dsh-we-need-plugin

DSH We Need Plugin

> 0.7.1：seed 长度不再固定，插件按 seed.txt 的实际内容注入，非空即可；模型匹配仍保持 DeepSeek + Flash，Pro 暂不纳入。下文旧版 0.7 文档中的 728/728、以及把 Pro 纳入的示例仅作历史说明。

DeepSeek Harness（DSH）Host 插件：在模型请求的最后一条真实 user task 之前，插入一条长度由 seed.txt 决定的 WeNeed assistant seed，让 DeepSeek Flash 更容易进入 We need / Let's / We / Should 的思维风格。

> 这是概率性引导，不是硬开关。它提高触发概率，但不保证每一次都进入 WeNeed 寄存器。

• 项目主页：https://github.com/Lichadai/dsh-we-need-plugin
• 讨论区：https://github.com/Lichadai/dsh-we-need-plugin/discussions
• 安装包：https://github.com/Lichadai/dsh-we-need-plugin/releases

> 第一次使用请先读 [0.5 使用技巧](#05-使用技巧先读这个)：工具尽量后调用，先思考/计划，不要过早调用工具。

> 可选增强：如果你能修改 System Prompt，建议把 [5.3](#53-可选增强把-seed-放到-system-prompt-最后) 里的 seed 原样追加到 System Prompt 的最后，触发概率可能更高。它不是必选项，注意事项见 5.3。

---

先读（30 秒）

1. 使用技巧：工具尽量后调用；先分析问题、做计划，不要急着写文件或调用工具；可以先读 skill，但不要过早调用工具。详见 [0.5 使用技巧](#05-使用技巧先读这个)。

2. 模型筛选：只看发给上游的 model id（DSH 传给 provider 的 model）是否同时包含 deepseek 和 flash，大小写不敏感；provider 完全不参与，也不需要配置 provider 路由。默认不读界面显示名。详见 [0.6 模型筛选规则](#06-模型筛选规则什么时候生效)。

3. 怎么工作：命中后插件把带 seed 的 messages 交回 DSH 原来的 provider adapter，provider、baseURL、API key 都沿用原来的，所以任何供货商都行。详见 [0.7 它怎么工作](#07-它怎么工作provider-不限)。

---

0. 先看这个

0.1 WeNeed 不是某一个模型，而是一类思维风格

WeNeed 不是 DeepSeek 独有的私有开关，也不是只能由某一家模型产生。它是一类以 We need、Let's、We、Should 作为句子开头为主要特征的思维风格：

We need understand the task...
Need inspect the inputs...
Let's plan before acting...
Should verify against the requirement...

这种风格通常有三个特征：

• 注意力比较稳；
• 愿意连续调用工具推进任务；
• 很少陷入“雷霆大思考”——反复检查、反复自我修正、纠结细节。

一旦句子里大量出现 I、Let me、I will，通常说明模型的思维力被过多的混杂信息冲散了，开始从“推进任务”退化成“围着细节打转”。

0.2 三个最常见的干扰源

实际使用 DeepSeek 时，最容易把注意力冲散的是三类信息：

1. 工具信息过大：工具 schema、工具调用历史、工具结果太多；

2. 工作区文件夹混杂：长期在一个大目录里工作，项目多、文件多、临时文件多；

3. skill 信息过大：skill catalog 很长，或加载了很长的 skill 正文。

这些信息本身不是没用，但一旦过于庞大，就会把模型拉到细节里，失去对大局和任务清单的把控。表现就是“雷霆大思考”：反复读、反复比、反复改，迟迟不推进。

一个很实际的印证：

• 以 Let me 为主的涣散思维，完成任务时经常不知道自己该更新任务清单；
• 以 We need / Let's 为主的 WeNeed 模式，通常会主动完成任务，并知道更新任务清单；
• 但即使是 WeNeed 模式，有时也会忘记更新任务清单——这往往说明上下文里无意义、与思维不相关的混杂信息太多，已经影响了思维力和注意力。

0.3 使用 DeepSeek 的建议

• 工作区保持干净，项目尽量少；及时清空不必要的文件夹、临时文件和旧项目。
• 工具调用时间往后延：在 skill 目录不是特别大时，先让模型读 skill、做规划，最后再调用工具。不要让庞大的工具基座信息先冲散思维。
• 工具很多、文件夹很杂、skill 很长时，优先清理上下文；不要只依赖 seed。
• 出现 Let me、I、I will 时，先怀疑工具调用过多，或信息获取不当、过大；不要只怪模型。

0.4 适用边界：只适用于 DeepSeek Harness

本插件只针对 DeepSeek Harness。

测试过 Qoder：Qoder 在使用第三方 API 时，reasoning_content 不回传。上下文内容还在，但思维过程会丢失，所以同样的 seed 在 Qoder 上不能稳定生效。

那种情况只能走代理/镜像路线：把上下文里的内容克隆到思维字段里，让思维链不中断。这是另一条技术路线，不在本插件的范围内。

补丁说明：作者不是专业编程人员，对 reasoning 回传的底层机理可能理解不完整，也可能没有找到 Qoder 正确的回传方式，因此上面的判断可能是误判。如果 Qoder 后续版本提供了 reasoning 回传能力，请以实际版本为准。

---

0.5 使用技巧（先读这个）

这些技巧和 seed 一样重要。工具很多、工作区很杂、skill 很长时，它们比 seed 更能决定模型会不会进入 WeNeed。

0.5.1 工具尽量往后调用

• 先让模型分析问题、做计划、想清楚要改哪些文件；不要一上来就读一堆文件、跑一堆命令。
• 工具 schema 很多、skill catalog 很长时，先读 skill、做规划，再调用工具。
• 如果任务不需要工具，直接让模型思考/回答；不要为了“看起来在工作”而过早调用工具。
• 工具调用越早、越多，后面的 reasoning 越容易被工具结果和细节带偏。

0.5.2 先思考，不要急着写下来

• 先让模型想清楚“要解决什么、分几步、每一步怎么验证”，但不要要求它立刻写文件或改代码。
• 先让它思虑一段时间，再决定是否调用工具；尤其是大任务、跨文件任务。
• 计划可以先留在 reasoning 里，不必马上落盘；落盘会引入额外工具步骤和上下文。

0.5.3 Skill 可以看，但不要过早调用工具

• skill 目录不大时，先让模型读相关 skill，再做计划。
• 不要让模型在读 skill 的同时并行调用大量工具。
• skill 信息本身也会占上下文；读最相关的，不要把全部 skill 都塞进去。

0.5.4 其他

• 工作区保持干净，项目少，临时文件少。
• 工具多时，优先清理不用的工具和配置。
• 出现 Let me、I、I will 时，先减少工具和信息，不要只加 seed。
• seed 是概率性增强，不替代上下文管理。

0.6 模型筛选规则：什么时候生效

代码位置：index.js → isTarget()。

匹配文本默认只有：

const text = String(modelId ?? '').toLowerCase();

• modelId 是 DSH 传给 provider 的 model id，也就是请求里的 model 字段；我们的自定义 adapter 会原样写入 body.model，delegated 模式也保留它；
• 不是 UI 上看到的显示名；
• 只有显式 matchName: true 时，才把 interceptModels[].name 拼进来；
• provider 名称完全不参与匹配；
• 默认 targetRules: [deepseek, flash]，两个词必须同时出现；
• 大小写不敏感。

真正生效要同时满足：