现在写代码用 AI 已经很常见了，但「让 AI 开发 DSH 插件」和「让 AI 写个脚本」不一样——插件有自己的一套规范和文件结构，如果提示词里不交代清楚，AI 很容易按通用思维写出「看起来对、但装不上」的代码。

下面给你一份可以直接复制修改的模板：

提示词模板（可直接使用）

请帮我为 DeepSeek Harness（DSH）开发一个插件，功能是：<在这里写清你要的功能>。
背景与规范：
1. DSH 是基于 Cordis 的插件框架，扩展功能只能通过写插件实现，不要修改平台核心代码。
2. 一个插件包必须包含：入口代码（export function apply(ctx)，内部用 ctx.effect() 注册功能）、
   inject 声明需要的服务、package.json 里的依赖声明、tsconfig/tsdown 编译配置。
3. 先判断我的功能属于哪种居住形态，只写需要的部分：
   - 纯 Host 端（后台能力，放 packages/host/ 下）
   - 纯 Client 端（界面，放 packages/client/ 下）
   - 两边都要（例如既要采集数据又要画界面，拆成 Host + Client 两个包，通过 RPC 通道连接：
     后台用 connection.rpc.handle() 注册通道，浏览器用 connection.rpc.call() 调用）
4. 浏览器插件要在 package.json 里加 dsh.client 声明，界面通过槽位注册（ctx.slots.register）挂载。
5. 所有注册都要用 ctx.effect() 包裹，保证插件卸载时自动回收。
6. 网络/平台相关调用必须做容错：失败只返回空数据，不能拖垮整个插件。
请按以下步骤交付：
1. 先给设计方案：包结构、Host/Client 划分、数据流；
2. 再给完整代码：每个文件的路径 + 内容；
3. 给"接线清单"：tsconfig 要加哪些引用、bundle 补丁要加哪些行、package.json 要加哪些依赖；
4. 给构建与测试命令；
5. 最后写一段"如何启动、使用、停止、卸载"的说明。
注意：如果你不确定 DSH 的具体 API 或规范，请先查阅项目的
docs/architecture.md、packages/AGENTS.md、docs/cookbook/adding-a-package.md，
不要凭空假设接口。

第一部分：认识 DSH 插件

1.1 DSH 是什么，插件又是什么

DeepSeek Harness（后面简称 DSH）是一个开源的 Agent 开发框架。你可以把它想象成一个「搭积木的平台」：平台本身提供了地基（比如和模型对话的能力、执行命令的能力、保存会话的能力），而插件就是一块块积木，你想让平台多一个功能，就往上搭一块积木，不想要了就拿掉，平台本身不用动。

在 DSH 里，这句话是字面意义上的真：连「和模型对话」「执行命令」这些基础能力，本身也是以插件的形式存在的。所以「写一个 DSH 插件」就是给这个平台增加新功能的正规方式，不需要去改平台的源码。

每个插件还有一个很贴心的特性：它是「可撤销的」。插件被卸载时，它注册的所有东西（命令、界面、数据通道）都会被自动清理干净，不会留下垃圾。

1.2 一个插件，必须包含哪些东西

新手最容易困惑的是「我到底要写哪些文件才算一个插件」。我们用大白话拆一下，一个插件 = 「插件本体」+「几份报名表」：

第一样：插件本体（入口代码）

每个插件都要有一个「入口文件」，里面有一个 apply 函数，可以理解成插件的「开机自启程序」：

注意 ctx.effect(...) 这个写法——它表示「我注册了一个功能，插件卸载时隧道也把它一起卸了」。这是 DSH 插件的固定动作，相当于给平台打了招呼：这个东西是我负责的，我走了它也得走。

第二样：报名表① —— 声明自己需要什么（inject）

export const inject = ['connection']   // 我要用 connection 这个服务相当于说：「我运行之前，先确保 connection 服务已经就绪。」平台会等它准备好再启动你的插件。

第三样：报名表② —— 声明自己在配置文件里的位置（补丁行）

插件写好了不会自己冒出来，必须在配置里「点名」：

这行就是插件的「花名册」，平台启动时会按这份名单逐个点名加载插件。

第四样：报名表③ —— 声明自己的依赖（package.json）

如果这个插件是要给 Web 界面用的，还要在 Web 层的包声明里写上它，否则加载器找不到它：

// packages/bundle/web-app/package.json "dependencies": {   "@deepseek-ai/dsh-host-system-monitor": "workspace:^" }**第五样：报名表④ —— 告诉编译器怎么编译它（tsconfig + tsdown）**

每个插件包都有自己的 tsconfig.json 和 tsdown.config.ts，声明编译规则，还要加进项目的构建清单（tsconfig.host.json / tsconfig.client.json）。

第六样（可选但常见）：浏览器端插件还要有「界面报名表」

如果插件要在浏览器里显示界面，除了上面这些，还要：

• 在 package.json 里声明 dsh.client（告诉平台「我是浏览器插件」）；
• 在代码里用「槽位注册」把界面挂到界面的某个位置（后面实战会看到）。

1.3 插件的「居住形态」

DSH 的 应用是「一个后台程序 + 一个浏览器页面」的结构。但一个插件具体住在哪边，完全由它的功能决定，不是每个插件都必须有 Host 和 Client 两部分。实际有三种形态：

形态说明例子纯 Host 端只在后台跑，不碰界面webserver（HTTP 服务）、plugin-inventory（插件清单）纯 Client 端只在浏览器跑，后台部分是个空壳ui-sidebar（侧边栏）、ui-settings（设置页）Dual-face（双面）同一个包里同时有后台和浏览器两部分connection（通信）、modules（插件加载器）

三者的通用规则：

• 后台部分能干什么：访问系统、读文件、跑命令、提供数据；
• 浏览器部分能干什么：渲染界面、展示数据、响应用户操作；
• 两边需要通信时：通过 RPC 通道——后台注册一个「接口」，浏览器通过接口问后台要数据。打个比方：后台是厨房，浏览器是餐厅，RPC 通道就是传菜口。

关键提醒：如果你只需要后台能力（比如一个日志清洗服务），那写一个纯 Host 插件就够了，不需要 Client 端；如果你只需要界面（比如一个纯展示组件），纯 Client 插件就行。「既要采集数据、又要画界面」的功能才需要两边配合——下面这个实战例子正是这种情况，但它只是「一种组合方式」，不是所有插件的标准模板。

第二部分：实战——亲手做一个「系统监控」插件

理论说完了，下面来展示一个真实例子。本次举例的插件是一个系统监控，功能是：实时显示电脑的 CPU、内存、磁盘、网络、进程、GPU 占用情况，还能看到最近 2 分钟的趋势图。点开有自己的面板界面。目的就是在使用DSH的时候可以同时看到电脑的CPU、内存情况

2.1 先设计：举例的插件采用了后端采集+前端呈现两部分组成

先说明：既要采集又要界面这类插件，不是所有插件的固定模板。如果你的插件只需要后台或只需要界面，参照第一部分 1.3 节的「三种居住形态」，只写后端或者前端就行了。

我们的系统监控功能既要在后台读系统数据，又要在浏览器里画仪表盘，所以拆成两个部分、各管一头：

packages/host/system-monitor/ # Host 端：负责采集系统数据（纯后台） packages/client/ui-system-monitor/ # Client 端：负责画界面（纯浏览器）

2.2 Host 端：采集数据 + 提供接口

第一步，定义数据长什么样（两端共用的「菜单」，src/types.ts）：

第二步，写采集器（src/collector.ts）。采集的原理很朴素：量两次，算差值。

• CPU 占用率 = 这段时间里 CPU 空闲时间减少的比例；
• 网络速率 = 这段时间里累计流量增加的量 ÷ 时间；
• 内存占用 = 总量减空闲。

平台命令（Windows 用 PowerShell，Linux 用系统命令）都加了超时和容错——任何一条命令失败，只返回空数据，绝不让整个插件崩溃。这一点很重要，我们开发时就踩过坑：一开始没做容错，一条命令被环境拦了，整个采集就报错。

第三步，注册接口（src/index.ts）。把采集器挂到一个名叫 /sysmon 的 RPC 通道上：

authority: 'loopback' 是「只允许本机访问」——系统数据不该让局域网里其他人随便读。

2.3 Client 端：画界面 + 每秒刷新

第一步，写一个「轮询器」（monitor-source.ts）：每秒向后台问一次数据，把最近 120 条 CPU 和内存记录存起来（刚好 2 分钟），画趋势图用。历史记录有上限，内存不会无限涨。

第二步，把界面挂到侧边栏底部（src/client/index.ts）：

「槽位」可以理解成界面上预留的「插座」：侧边栏底部有一个插座，我们把系统监控按钮插进去。按钮点击后展开整个仪表盘。

第三步，写面板组件（SystemMonitorPanel.tsx），包含：

• 一排概览卡片：CPU、内存、磁盘、网络、GPU、进程数、运行时长；
• 一张 2 分钟趋势折线图（手绘 SVG，不依赖图表库）；
• 磁盘分区进度条；
• 进程 Top 榜（可以切换按 CPU 或按内存排序）；
• 系统信息。

样式全部用平台提供的「语义颜色变量」，自动适配深色/浅色主题，不用自己写死颜色。

2.4 接线：让平台认识这两个包

代码写完不等于能用，还要完成「报名表」（第一部分说的那些）：

• 加入构建清单：tsconfig.host.json、tsconfig.client.json 里加引用，tsconfig.base.json 里加路径映射；
• 在 Web 层补丁里点名：packages/bundle/web-app/cordis.patch.yml 加两行（Host 一行、Client 一行）；
• 在 Web 层包声明依赖：packages/bundle/web-app/package.json 加两个依赖；
• Client 包声明自己是浏览器插件：package.json 里加 dsh.client 清单。

2.5 构建和测试

pnpm install      # 让 pnpm 认识新包 pnpm run build    # 全量构建 pnpm run test:gui # 跑测试我们还给插件写了测试：后台解析器单测、前端轮询逻辑测试、界面渲染测试。构建全绿、测试通过，插件才算真正「能跑」。

第三部分：插件做好之后——启动、使用、更新、停止、卸载

这一部分写给已经有一个插件的人（可能是你自己做的，也可能是别人给你的）。以系统监控插件为例，但操作步骤对所有 DSH 插件通用。

3.1 怎么启动

在项目根目录执行：

pnpm dsh web启动后，浏览器打开 http://127.0.0.1:3080（或 localhost:3080）。

⚠️ 有一个容易踩的坑：如果服务器是在插件改动之前启动的，它加载的是旧名单，看不到新插件。遇到这种情况，先停掉服务器再重新启动一次。

3.2 怎么更新

更新分两种，看你是「作者」还是「使用者」：

如果你是插件作者（改了源码）：

开发模式下推荐用热更新：

pnpm run dev:web   # 另开一个终端，监听源码变化，自动重新打包改完源码保存，浏览器里的插件会自动刷新，不用重启服务器，开发体验很顺畅。

如果你只是拿到一个新版本（别人改好了）：

pnpm install       # 更新依赖 pnpm run build     # 重新构建然后重启 pnpm dsh web，新版本就生效了。

3.3 怎么停止（临时停用，不用删代码）

DSH 有一个很实用的机制：用户配置层是热加载的——改完配置文件保存，立刻生效，不用重启。

找到用户配置文件

Windows 上默认在 C:\Users\\.dsh\profiles\web\cordis.patch.yml），加两行：

保存文件，插件立即停止工作；想恢复，删掉这两行再保存即可。

如果想连服务本身一起停：在启动 dsh 的终端按 Ctrl+C。

3.4 怎么卸载（彻底移除）

「停止」只是让插件不工作，代码还在；「卸载」是把插件从项目里彻底移除。步骤：

• 停掉服务器（终端里 Ctrl+C）；
• 从 packages/bundle/web-app/cordis.patch.yml 删掉插件对应的那几行；
• 从 packages/bundle/web-app/package.json 删掉对应的依赖；
• 删除插件的源码目录（比如 packages/host/system-monitor/ 和 packages/client/ui-system-monitor/；
• 从 tsconfig.host.json、tsconfig.client.json、tsconfig.base.json 里删掉对应引用；
• 执行 pnpm install 清理；
• 重新 pnpm dsh web。

这样插件就完全消失了，平台不会留任何残留。

结尾：一张图记住全文