写在前面
给 DSH（DeepSeek Harness）开发插件，最省力的方式不是自己啃文档，而是把文档路径告诉 AI，让它读完后再动手开发。
这套方式成立的前提是：文档质量足够高。而 DSH 自带的开发文档恰好为此而设计。人工只需要做三件事：
- 告诉 AI 文档在哪
- 说清楚需求是什么
- 按标准验收
下文介绍这套流程的完整步骤。
一、文档藏在哪里
DSH 自带的开发文档位于安装目录下：
<DSH 安装目录>/resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-agent-preset/skills/
该目录包含四个技能文档，覆盖了全部开发场景：
| 技能 | 用途 |
|---|---|
cordis-plugin-development |
Host 插件开发（工具、事件、服务） |
editing-cordis-compositions |
Agent Preset 编写 |
cordis-composition-reference |
Patch YAML 语法与可挂载包清单 |
agent-experience |
工具定义与 Skill 设计 |
Desktop 版中，这些文档打包在 app.asar 归档内，普通文件工具和多数 AI 文件读取工具都无法直接穿透 asar 读取内部路径。如果 AI 报告读不到该路径，先把 skills/ 目录整体解包或复制到普通文件系统下（例如 asar extract 后放到工作目录），再让 AI 读取。
二、如何把文档交给 AI
你只需要让 AI 加载对应的技能，无需手动复制粘贴文档内容：
加载
cordis-plugin-development，然后帮我写一个插件：……
AI 会自动读取技能文档及其引用的全部参考资料。核心在于：文档的层级引用关系由文档自身维护，你只需指定入口文件。
- 开发 Preset 时，将技能名替换为
editing-cordis-compositions - 仅编写工具定义时，使用
agent-experience
如果你使用的不是 DSH，只需将这四个技能目录的路径告诉 AI，让它先读完文档再开始编码。
三、人工只需要说清楚三件事
文档负责”怎么做”，你负责”做什么”。描述需求时提供以下三类信息即可：
1. 目标
插件要解决什么问题？触发条件是什么？期望达到什么效果？
2. 边界
哪些行为必须保留？哪些必须避免？现有流程中有哪些部分不能改动？
3. 可调参数
哪些值需要用户自定义？这些参数会自动进入 Config 配置项，用户可在 cordis.patch.yml 中调整，DSH 升级后依然保留。
不需要描述的细节：命名规范、语言区域（locale）、图标格式、安装方式等——文档中已有明确规范，AI 读完会自动处理。
四、验收标准
开发完成后，按以下标准逐项检查：
application字段：是否为applied（而非restart-required）- 真实数据验证：用实际场景跑一遍端到端测试，不要只看单元测试
- 用户状态恢复：测试期间修改过的配置是否已恢复原状
如果 AI 报告某个约束无法满足，通常意味着需求与文档规范存在冲突。此时应让它解释原因，而不是强行通过。
五、为什么这套流程能成立
DSH 的开发文档不是给人阅读的散文，而是为 AI 消费设计的结构化资料：
- 每个技能文档配有明确的适用场景描述
- 详细规范拆分到独立的
references/文件，按需加载 - 关键约束通过
practices.md集中管理 - 配套
templates/目录可直接复制起步
因此，人工投入应尽量最小化——把需求讲清楚，剩下的交给文档和 AI。
六、一个关键前提
这套方式生效的前提有两个：文档本身足够准确，且 AI 确实会去读。
如果 AI 跳过了文档直接写代码，产出很容易踩中那些文档里已明确写过的约束。所以，第一句话永远是「加载 cordis-plugin-development」——先让它读完文档，再让它动手编码。