前言¶

长时间使用 DSH 做开发时，有价值的上下文往往散落在会话里：模块边界、设计决策、隐含约束、曾经失败的方案，以及关键文件之间的维护关系。新会话无法可靠继承这些信息，而把全部聊天记录重新塞进上下文，既昂贵，也容易引入过期结论。

下面介绍 yu-xin-c/dsh-project-wiki。这是一个面向 DeepSeek Harness 的本地优先项目 Wiki 插件，把已接受的项目知识沉淀为工作区内的 Markdown 页面，并支持原生 Web 查看、检索、提案审核、来源过期检查和知识图谱。

这是什么¶

yu-xin-c/dsh-project-wiki 由 yu-xin-c 维护，许可证为 MIT。它把 Agent 在开发过程中获得的架构知识、设计决策、代码约束和排障结论记录为工作区内的 Markdown 页面。

这些页面不是隐藏的聊天记忆：用户可以阅读、编辑、审查和搜索它们；当页面绑定的来源文件发生变化时，页面也会被标记为需要更新。

核心功能¶

插件当前提供以下能力：

• 原生 Web 界面：在 DSH Web 会话中提供 Wiki 视图。
• Markdown 编辑：创建、编辑和删除页面。
• 全文检索：基于 FTS5 的词法检索；不包含 embedding 或向量数据库。
• 提案审核：Agent 提案与正式页面分开处理，用户批准后进入正式知识库。
• 来源指纹：页面可以关联工作区内的相对来源文件，并记录来源指纹。
• 过期扫描：代码变化后，检查哪些页面需要更新。
• 知识图谱与双向链接：通过页面之间的链接建立关系，并生成可交互图谱。
• 修订记录：保留页面的创建、更新及操作信息。
• Agent 工具：支持 Agent 参与 Wiki 操作；持久化提案和提案接受需要人工批准。

安装与启用¶

Node.js 要求为：

22.19+ 或 24+

使用以下命令安装插件：

npx --yes @deepseek-ai/dsh@latest plugin --profile web add github:yu-xin-c/dsh-project-wiki

安装完成后，在 DSH Web 中注册或选择一个工作区，再进入绑定到该工作区的会话，就可以打开 Wiki 标签使用。

典型用法¶

按照下面的步骤使用：

1、在 DSH Web 中注册或选择一个工作区。
2、创建一个绑定到该工作区的会话。
3、打开会话顶部的 Wiki 标签。
4、使用“新建页面”记录事实、决策和约束，或让 Agent 创建待审核提案。
5、添加工作区相对的来源文件，例如 src/services/auth.ts。
6、代码变化后点击“扫描过期”，检查哪些页面需要更新。

适用场景¶

这个插件适合需要把项目知识固定在工作区内的场景：

• 长期维护同一个仓库，希望沉淀架构结论和维护约定。
• 希望 Agent 得到的知识可以被阅读、审查和追溯。
• 希望页面来源和代码变化之间有明确对应关系。
• 希望 Agent 的新结论先进入提案，而不是直接覆盖已有知识。

注意与安全边界¶

使用前需要关注以下边界：

• 这是项目级本地 Wiki，不提供云同步或跨工作区共享。
• 搜索目前是 FTS5 词法检索，不包含 embedding 或向量数据库。
• 插件会检测来源变化，但不会自动判断新代码应该如何改写结论。
• 页面必须由 Web 用户显式保存，或由用户批准 Agent 提案后进入正式知识库。
• Web API 仅通过 DSH loopback RPC 暴露。
• 每次调用都重新验证活动 Session 和已注册工作区。
• Wiki 目录必须是工作区内的相对目录。
• 来源路径不能通过 ..、绝对路径或符号链接逃出工作区。
• Agent 的持久化提案和提案接受操作需要人工批准。
• Node.js 要求为 22.19+ 或 24+。
• 许可证为 MIT。

插件会随当前 DSH 进程运行，并以该进程可访问的工作区文件为操作对象。安装前建议检查源码、依赖和许可证，确认其符合团队安全要求。

结尾¶

dsh-project-wiki 的价值，在于把 Agent 产生的项目知识变成可见、可审查、可追溯的工作区页面。它不追求自动替代人工判断，而是把“哪些结论来自哪些来源、何时需要复核”暴露出来。

GitHub 仓库：

https://github.com/yu-xin-c/dsh-project-wiki