3 篇文章带有标签 “best-practices”

本文档以 @wangjunjian/dsh-artifact-viewer 为实例，系统梳理 DeepSeek Harness（DSH）bundle 插件的开发方法：工作原理、架构设计、构建打包、测试、发布自动化，以及开发和发布过程中实际踩过的坑。

1. 工作原理

Bundle 插件是什么

DSH 的 bundle 插件是一个普通 npm 包，通过 package.json 里的 dsh 字段声明自己：

{
  "dsh": {
    "bundle": { "patch": "./cordis.patch.yml" },
    "client": {
      "platform": "web",
      "inject": ["@deepseek-ai/dsh-client-runtime"],
      "external": ["@deepseek-ai/dsh-client-ui-primitives"]
    }
  }
}

• dsh.bundle.patch：指向一个 cordis patch 文件，负责把插件注册进 loader 树。
• dsh.client：声明浏览器半部分的运行平台、注入依赖和 external 包。

一份面向本仓库（DeepSeek Harness 外部 Bundle 插件）的全面开发规范。 内容均基于本仓库真实代码（src/、tsdown.config.ts、package.json、tests/ 等）提炼， 而非泛泛而谈的通用建议。改动代码前先读本文，能少踩 80% 的坑。

0. 项目定位速览

本仓库是一个 DeepSeek Harness（以下简称 DSH）外部 Bundle 插件，对外暴露一个面向模型（model-facing）的工具 github_trending，抓取 https://github.com/trending 的公开页面，返回结构化热门仓库列表。

研究编码智能体开源项目的最佳实践

基于 Kilo Code 的架构特征和当前编码智能体领域的生产实践 ，以下是系统研究此类项目的 方法论框架：

阶段 1：宏观定位（Why & Where）

研究维度	关键问题	Kilo Code 的启示
Fork 溯源	上游是谁？核心差异点？社区分裂原因？	Kilo 从 Roo Code 分叉，差异集中在 Cloud 集成和商业化功能
生态位	是「IDE 插件」「CLI 工具」还是「平台」？	Kilo 是「IDE 扩展 + CLI + Cloud」的三位一体
许可策略	是否存在 BSL/SSPL 等限制性条款？	MIT 许可证，无商业限制
模型绑定	是否硬编码单一提供商？	模型中立是核心卖点，避免供应商锁定

阶段 2：架构解构（How）

建议的代码阅读路径（以 Kilo 为例）：

1. 入口层 — src/extension/activate.ts（VS Code 生命周期）、src/extension/api.ts（IPC 外部 API）
2. 核心代理循环 — 查找 Cline/Roo/Kilo 主类，理解 Plan → Act → Verify 的循环
3. 工具调用层 — McpHub 如何集成外部工具（文件系统、终端、浏览器）
4. 上下文管理层 — Memory Bank、Context Mentions、自动索引的实现
5. 模式系统 — Custom Modes 的解析与切换逻辑
6. 差异标记 — 搜索 // kilocode_change 快速定位增量代码