企业官网建设流程全解析

如果你只养了一条"蓝色大肥鱼"，那只是开始。开源桌宠项目 dsh-pet-indesktop 已把 AI 对话、主动识屏、歌词联动、节日彩蛋全部塞进同一个进程——功能越加越多，核心却越来越难维护。为此项目团队发布了 v5 插件化 DLC 路线图，用 7 个阶段把桌宠从"单体大肥鱼"改造成"Core + 插件生态"：角色素材独立更新、AI 能力隔离到 worker 进程、DLC 可签名分发，让第三方开发者也能安全地为你的桌宠装上新皮肤和新技能。本文带你逐阶段拆解这份完整路线图。

为什么桌宠需要插件化？

🐟 v5 要解决的核心矛盾一句话就能说清：Core 保持最小、稳定、可独立启动，所有可选能力外置为 DLC/插件。

路线图冻结了四条总体原则（见 PLUGIN-DLC-ROADMAP-v5.md）：

• content DLC 不执行代码——角色、动画、台词、音效、主题都是纯资源；
• 轻量官方能力才进入 in_process，网络、截图、AI、Agent 和外部程序默认进入 worker 独立进程；
• Core 更新与 DLC 更新分离——升级桌宠本体不会删掉你装的角色包；
• 第一阶段不兼容 VPet 文件格式，也不把 Steam Workshop 当前置依赖。

七阶段路线总览：一图看懂 v5 插件化

架构分层是整条路线的"地基"：

Core: 生命周期 / 桌宠窗口 / 动画抽象 / 基础交互 / 配置 / IPC content DLC: 角色、动画、台词、音效、主题、节日素材 in_process: 受限的提醒、台词、菜单、设置和展示扩展 worker: AI、Agent、视觉、歌词、余额、外部程序和网络服务

Phase 1：基础边界与资源 DLC，把"蓝色大肥鱼"变成官方 Starter DLC

第一阶段的目标是冻结 Core、content、in-process、worker 四类边界，先跑通"资源型 DLC"的最小闭环：外部角色目录扫描、manifest 校验、body_box/head_box/步幅数据读取、资源 fallback，以及本地安装、卸载、升级和回滚的接口设计。

亮点在于：现有的shenshen角色会被整体迁移成官方 Starter DLC，而迁移完成前 Core 会继续读取内置资源兜底——拆包绝不会破坏你现有的桌宠启动路径（见 PLUGIN-DLC-ARCHITECTURE.md）。

阶段出口非常务实：无 DLC 时 Core 可以启动、非法路径和损坏资源不会阻塞 Core。

Phase 2：Core 插件运行时，给插件装上"总开关"

进入第二阶段，Core 会获得一整套插件管理原语：PluginManifest、PluginRegistry、PluginContext、CoreEventBus，外加 capability 检查、插件配置命名空间和故障诊断（见 plugin-phase-02-runtime）。

对普通用户来说，最直观的改变是三条安全底线：

• 插件可以发现、启用、禁用和诊断；
• 插件异常不会阻塞主窗口；
• 插件不能直接修改全局 Core 配置，一切配置统一收进plugins.<plugin_id>命名空间。

至少一个 content 插件和一个官方 in-process 插件完成迁移，就算通过验收。

Phase 3：Worker 插件运行时，把"高风险能力"关进独立进程

这是稳定性提升最大的一阶段。AI Chat、Agent Link、主动识屏、DSH bridge、歌词网络请求等能力默认迁移到独立 worker 进程，Core 通过 JSON Lines 本地 IPC 通信，最小消息协议为：

hello → ready → config_push / event / heartbeat / error → shutdown

迁移有明确顺序：Agent Link → 主动识屏 → DSH bridge → AI Chat service → 歌词/余额/外部播放器等网络型能力（见 plugin-phase-03-worker）。

阶段出口用"崩溃隔离"来衡量：worker 崩溃不导致 Core 退出、协议错误可诊断、应用退出后没有残留 worker。

Phase 4：DLC 更新中心，下载、校验、回滚一条龙

DLC 从此拥有独立于 Core 的更新体系：plugins-index.jsoncatalog、多镜像源、staging 暂存区、文件大小 + SHA-256 + 签名三重校验、版本目录与 active 指针、原子切换和自动回滚（见 PLUGIN-UPDATE-PROTOCOL.md）。

验收标准对普通用户非常友好：

• ✅ Core 更新不删除 DLC，DLC 更新不修改 Core；
• ✅ 不兼容 DLC 自动禁用并显示原因；
• ✅ 激活失败自动回滚，下载中断可重试。

Phase 5：通用分发适配，DLC 从哪里来都行

第五阶段让分发来源与插件加载器解耦：本地开发目录、本地 zip、GitHub Release、静态 CDN 都能作为安装来源，通过统一的 catalog source adapter 接入（见 plugin-phase-05-distribution）。

这里有个清醒的约束：Steam Workshop 只作为未来独立 adapter 预留，没有 Steam 环境时，本地目录、zip 和 CDN 仍必须可用——桌宠插件生态不绑死任何单一平台。

Phase 6：第三方插件生态，SDK 与签名让社区安全入局

当 Core API 稳定后，项目会按顺序向社区开放：content DLC 文档和示例 → content DLC SDK → worker 插件 SDK → capability 授权 → 签名发布 → 社区 catalog → 作者信息、标签和兼容矩阵（见 plugin-phase-06-ecosystem）。

安全边界写得很硬：第三方插件默认运行在 worker，网络、截图、进程启动和文件访问必须声明 capability，并经过用户授权和平台策略检查。

Phase 7：跨平台正式发布，Windows / macOS / Linux 三端齐发

最后一阶段把插件化架构沉淀成稳定的发布和运维体系：三平台目录与权限适配、插件签名与公钥轮换、Starter DLC 独立发布、插件诊断导出、包体/启动时间/内存/下载体积基线、API 主版本和弃用策略，以及 v4 → v5 迁移报告（见 plugin-phase-07-release）。

阶段出口意味着：Core 与 Starter DLC 可以独立发布，插件升级、回滚和迁移可重复测试，API 版本策略公开给插件作者。

暂不实施清单：路线图同样告诉你"不做什么"

🚫 v5 路线图明确排除：任意 Python 模块热卸载、未签名正式插件、第三方代码默认进入 Core 进程、Chat UI 立即拆成独立 Qt 进程、机械搬运现有 Python 模块来制造插件边界。

提醒：该路线图基线日期为 2026-09-24，各阶段文档标注"设计基线/阶段预留"，不代表后续阶段代码已完成迁移。

快速导航：相关文档与模块路径

想深入了解，可以从总路线图 PLUGIN-DLC-ROADMAP-v5.md 出发，再按阶段查阅：

• Phase 1 架构与 API：PLUGIN-DLC-ARCHITECTURE.md、PLUGIN-API-CONTRACT.md、PLUGIN-MIGRATION-v4-to-v5.md
• Phase 3 进程插件调研：PHASE3_PROCESS_PLUGIN_RESEARCH.md
• Phase 4 更新协议：PLUGIN-UPDATE-PROTOCOL.md
• 现有更新模块（不在插件化覆盖范围）：pet/updater.py、pet/update_settings.py

从"一条蓝色大肥鱼"到"一个桌宠插件生态"，dsh-pet-indesktop 的 v5 路线图把每一步都拆成了可验证的阶段出口。无论你想换新角色皮肤，还是给桌宠接上更聪明的 AI 大脑，这条七阶段路线都会带你走到那里。