百科 DSH-PackForge/dshbaike

DSH 百科

一站式的 DeepSeek Harness 中文百科 · 域名 dshbaike.com · 仓库 DSH-PackForge/dshbaike

状态：设计阶段（设计稿待评审，尚无代码）。 本轮只交付设计文档，评审通过后再进入实现。

站名 DSH 百科，主标语 「一站式的 DeepSeek Harness 中文百科」；先上免费子域，域名可在 M4 前再买。品牌与命名规范见 08 §8。

仿 MC百科（mcmod.cn）的信息架构，为 DSH（DeepSeek Harness）生态做一部词条化的百科。主站是两个功能的合体：

1. 分区层（资源整合）：十一个一级分区，按装配位置分层——① 交互层：界面与客户端（官方 Web UI / 桌面端 / TUI / CLI）· ② 启动层：启动器 · ③ 扩展层：插件 · ④ 配置层：指令与配方 / 预设与人设 / 技能包 · ⑤ 外观层：主题与皮肤 / 素材与本地化 · ⑥ 分发层：整合包 · ⑦ 元层：规范与协议 / 工具链。卡片 + 一句介绍 + 外链到外部源，不编号、不写正文。
2. 词条层（解释与教程）：用户贡献的编号词条 /<kind>/<n>.html（参考 MC百科的 /class/<n>.html），写机制、关系、兼容性与教程。

两层之间靠红链连接：分区里还没有词条的条目显示「写这一条」，点进去就是领号命令与模板。详见 06 · 分区层与词条层。

这是什么 / 不是什么

| | 说明 |
| 是 | 一个两层的站点：分区层（十一个一级分区，按装配位置分层；卡片 + 外链，负责「去哪拿」）+ 词条层（编号词条，负责「看懂它」） |
| 是 | 一个静态百科站点：每个实体一页（MC百科式自增数字编号，如 /plugin/12.html），能搜索、能按分类浏览、能顺着关系往下翻 |
| 是 | 一个人工词条为主 + 外部源聚合为辅的 wiki：词条改动走 PR，git 历史即编辑历史 |
| 是 | 资源整合层：插件事实（star / 下载量 / 收录日期 / 安装命令）引用 awesome-dsh-plugin.com 等外部源并外链，不落元数据副本 |
| 是 | 市场（dsh-pack-market）的下游消费者：整合包数据直接读市场索引与 manifest，不重复采集 |
| 不是 | 第二个市场：不负责下载与安装分发，安装命令指回市场与 dspack install |
| 不是 | 第二个插件目录：不做插件全量收录（awesome 4400 条、dshbase 7800+ 条在做）；插件词条只收「被教程引用 / 被整合包使用 / 有人认领」的，十几到几十条量级 |
| 不是 | 入门教程站：dshbase.com 已占住「DSH 是什么、怎么装」；本百科侧重机制解释、关系、兼容性、包内容构成，并给外部教程做索引卡 |
| 不是 | 有后端的社区站：没有账号、积分、评论、评分、在线编辑器——这些需要服务端与运营，首版一律不做 |

设计文档

| 文档 | 内容 |
| 01 · 信息架构与页面模板 | 站点地图与数字编号路由、首页、词条页/插件聚合页/包成分表/兼容矩阵线框图、插件引用卡 |
| 02 · 数据契约 | 六类词条（概念/插件/教程/整合包/启动器/资源源）的 schema、编号契约与墓碑、分类、插件收录门槛、校验规则 |
| 03 · 目录结构、构建与部署 | 仓库形态、目录树、领号流程、数据流、人工优先合并规则、CI 与 Pages |
| 04 · MC百科参照与取舍 | MC百科逐页核实（模组页/资料页/合成表/关系星图/整合包/搜索/编辑机制）+ 抄什么不抄什么 |
| 05 · 首版内容计划 | 先写哪些：教程清单、插件词条门槛与起步 12 条、概念 16 条、资源源 7 条、整合包 8 条、启动器 5 条 |
| 06 · 分区层与词条层 | 主站两个功能的分工、十一个一级分区（按装配位置七层划分）与数据源策略、分区专属字段、分区页模板、红链机制；含「界面与客户端」分区的命名与边界 |
| 07 · 多源分区 | 一个分区里有多个做同一件事的源怎么办：源可插拔（adapter）、实体归并（entities.yml）、三级呈现；启动器分区的认领与血缘，以及通用方案与反模式 |
| 08 · 视觉系统 | 现代 Wiki / 索引式的视觉语言：颜色与字体令牌、布局断点、徽章与信息表等组件规范；明确不沿用市场的「纸墨朱砂」 |
| 09 · 条目页深挖 | 对 mcmod.cn/class/2021.html（机械动力）的逐块拆解：20 个区块的实测值与我们的对应物，直接采纳 4 条、改造后采纳 3 条、明确不抄 5 条 |
| 10 · M1 接口冻结 | 三条并行工作流（工具链 / 内容 / 站点外壳）共用的接口：文件所有权、CLI 行为、产物字段名、模板占位符、验收清单 |

与既有仓库的关系

| 仓库 | 关系 |
| dsh-pack-market | 数据上游。百科读它的 index.json（schemaVersion 2）与 packs/<owner>.<repo>/manifest.json 作为整合包词条的事实源，并与其互相深链 |
| DSH-PackForge | 规范上游。manifest / pack-structure / index 的字段定义是百科数据契约的依据；规范版本本身也会成为「元」类词条 |
| dsh-packforge-app | 打包与安装工具，百科的安装命令指向它产出的 CLI 用法 |
| dsh-pack-plugin | 插件 bundle，既是百科的词条对象，也是「整合包管理」类词条的实例 |
| all-about-whales | 参考实现整合包，可作为「一个规范包长什么样」的示例词条 |

里程碑

| 阶段 | 交付物 | 验收标准 |
| M0 · 设计评审（当前） | docs/ 五份设计文档 | 信息架构、数据契约、流水线、取舍、内容计划五件事无待决项；开放问题有结论 |
| M1 · 站点骨架 | 十一个一级分区页（界面与客户端 / 插件 / 整合包 / 启动器 四个先有内容，其余各放 1–3 条）+ 首页 + 词条页骨架（含墓碑态）+ 教程/插件/资源源三个模板 + 搜索；12 条真实词条 | 本地 npx serve web 能点通：十一个分区页均非空（标语承诺「一站式」，空页会当场打脸，见 08 §8.6）、分区筛选、专属字段渲染、红链入口、搜索命中、/plugin/12.html 直达、词条互链、反链与插件反向索引正确、墓碑页不 404 |
| M2 · 铺量与聚合 | new.mjs（领号）+ collect.mjs + validate.mjs；教程 12（自写 7 + 外部卡 5）、插件 12、概念 16、资源源 7、整合包 8、启动器 5 | 断网也能构建（用 collected/ 快照）；validate.mjs 全绿（含编号契约与插件收录门槛）；CI 在 PR 上跑通 |
| M3 · 差异化视图 | 包成分表、版本兼容矩阵、关系图；资料（resource）试点 | 每个整合包词条能看出组成；矩阵对每个插件给出三态兼容结论；试点验证半自动提取资料候选的通道 |
| M4 · 上线与贡献 | 部署（Cloudflare Pages，过渡期 dshbaike.pages.dev）+ 域名 dshbaike.com + CONTRIBUTING.md（含领号）+ 词条模板与 Issue 模板 | 站点可访问；新人能照模板提一条词条 PR |

首版不做（避免范围蔓延）：插件全量收录、账号体系、评论、积分等级、在线编辑器、全文检索引擎（用 JSON 索引 + 子串匹配）、英文站点、力导向关系图动画。

待确认项

来自各设计文档的问题汇总，评审时逐条给结论：

1. 插件收录门槛的松紧（门槛本身已定：被教程引用 / 被整合包使用 / 有人认领）。待定的是是否再加配额（例如首版插件词条不超过 30 条）；以及官方包 @deepseek-ai/ 走插件词条还是概念词条。
2. 热度数字的引用方式：awesome 的下载量与 star 是「建条时抓一次 + 页面标快照日期」，还是每次构建刷新（会破坏离线可构建）？倾向前者。
3. 市场页脚的许可证口径不一致（处理方式已定）：市场页脚称 awesome 站为 CC0 1.0，该站自述 MIT（04 §7.3）。百科侧已定：署名只写自愿鸣谢 + 外链、不写协议名；仍建议回报 dsh-pack-market 修正页脚。词条正文许可已定为 CC BY-SA 4.0（其余 CC0，见 LICENSE）。
4. 周期性空提交：collected/ 定时刷新会产生「只有快照时间变化」的提交，是否接受（03 §8）。
5. 词条正文的语言策略：首版只做「字段级可选英文」，不做双语正文——是否需要英文站点。
6. SKILL.md 的 invocation 字段：仓库里真实技能在用，实现侧的字段白名单里却没有（02 §3.2 标为冲突），需实机验证一次。
7. 资料（resource）二级词条是否在 M3 启动：取决于「从 cordis.patch.yml / dsh.client.inject 半自动提取资料候选」这条通道能否走通。
8. 分区划分与命名（06 §2）：分区改为按装配位置七层划分（交互/启动/扩展/配置/外观/分发/元），共十一个；新增的「界面与客户端」（官方 Web UI / 桌面端 / TUI / CLI / headless）命名是否合适？备选：/clients「客户端」、/forms「运行形态」——只需改一个目录名与标签，不影响其它设计。
9. 官方形态与第三方是否分区展示：界面与客户端分区里 official / third-party / launcher 用徽章区分（06 §2.3）。是否同意「第三方桌面壳默认展开风险提示」（它会拿到本机权限）？
10. 二级标签是否直接复用 awesome 的 24 个分类键（06 §3），避免造第三套体系。
11. 未认领的个人启动器是否收录（07 §6）：倾向收录并显式标「未在注册表认领」+ 认领引导；但要确认不会变成「收录 ≠ 背书」的口径问题。
12. 源的收录门槛（07 §3）：任何外部源只要提供可抓的 JSON 就能进「本分区的来源」区块，还是需要人工评审（避免接入野源、死源）。倾向后者 + reliability 分级。
13. 视觉配色（08 §2）：方案取「青绿品牌 + 靛蓝链接」（wiki 内链密度高，链接色最符合读者预期）。若你有偏好的主色（例如更接近 MC百科的观感），换掉两个令牌即可，不影响其它设计。
14. 完整度指标是否采纳（09 §3.1）：分母按 kind 定义（插件：定位/正文/关系/兼容/外部源指针/出现在哪些包），页面显示百分比 + 可点击的缺项清单。它把「这条写全了没有」变成公开数字，但也可能诱导为凑数而填字段——需要定「推荐级字段是否计入」。
15. 许可证是否独立成块（对应 MC百科的 Mod协议 分块，09 §1 第 16 项）：方案是插件/整合包词条都有 licenseRefs（可多条，如本体 MIT + 内置资源 CC BY）。要不要再进一步，把常见许可证本身做成概念词条（解释 MIT 与 CC 系的区别）？

许可证（已定，完整说明见 LICENSE）

分许可，按路径区分：

- 词条正文（data/<kind>/.md）：CC BY-SA 4.0（署名 + 相同方式共享）——正文是本站唯一的原创资产，需要防「被静默搬走再商业化」
- 其余全部 CC0 1.0：代码与脚本、结构化数据（registry / taxonomy / sources / entities / zones）、采集与构建产物（collected/、web/data/）、设计文档（docs/）——下游（市场 / 启动器 / 第三方工具）零法律摩擦**
- 外部源与上游仓库的元数据：只引用（带快照日期）与外链，不落副本；外部教程只做索引卡，不转载正文
- 不使用带 NC 的许可（MC百科用的是 BY-NC-SA）：NC 会让商业化客户端无法合法消费本站数据，站点会变成数据孤岛

⚠️ 另需处理一处既有的许可证不一致：dsh-pack-market 页脚称 awesome-dsh-plugin.com 为 CC0 1.0，而该站自述 MIT（04 §7.3）。百科的署名不写协议名，并把这条回报给市场修正。

本地预览

node scripts/validate.mjs # 校验词条、分区与编号契约（0 errors 才能提 PR）
node scripts/build.mjs # 离线构建：写 web/data/**、web/<kind>/<n>.html、web/<zone>.html
npx serve web # 任意静态服务器；也可直接开 web/index.html 看演示数据

构建完全离线（只读 data/ 与 collected/），零第三方依赖，同一输入两次构建产出逐字节一致。

参与

- 写一条词条：node scripts/new.mjs <kind> "<标题>" 领号 → 写正文 → 校验 → 提 PR
- 改分区层：data/zones/<zone>.yml（条目必填 name / blurb / links）
- 接入外部源：加一条 adapter 配置，见 07

完整流程、六类词条的写法与四条内容纪律见 CONTRIBUTING.md。