企业官网建设流程全解析

1. 为什么需要 workbuddy-to-dsh：迁移的核心场景

最近我把自己常用的开发辅助工具从 workbuddy 切换到了 dsh，整个过程比预想中复杂得多。如果你也在这两个工具之间徘徊，会发现一个尴尬的事实：它们在功能上有重叠，但配置体系、插件系统、skill 管理方式完全是两套逻辑，根本没有"直接换个启动器"这种好事。

先说清楚 workbuddy-to-dsh 到底解决什么问题。简单来说，它是一套从 workbuddy 生态向 dsh 生态迁移的转换流程和工具集，负责把你在 workbuddy 里积累的配置、自定义 skill、会话历史甚至部分记忆数据，转换成 dsh 能识别的格式。为什么要做转换而不是直接复制？因为两个工具的存储结构不一样：workbuddy 偏好用 JSON 块保存一段完整的技能描述，dsh 则更倾向于将每个 skill 拆成独立的指令文件，再加一个索引元数据。直接把 JSON 塞进 dsh 的插件目录，dsh 只会当成一串无法解析的文本，根本不会加载。

我最初也以为这是件小事，结果第一次迁移时丢了不少自定义 skill，后来花了两个晚上重新调试。这篇文章就把我踩过的坑和可复用的步骤完整写出来，适合谁看？如果你正在从 workbuddy 转向 dsh，或者手头有一堆 workbuddy 配置想做个清理和归档，再或者纯粹想搞清楚这两个工具之间到底差在哪，那么这篇内容能帮你省下不少试错时间。

2. 迁移前必须弄懂的两个生态差异

2.1 workbuddy 与 dsh 的定位差异

很多人刚开始会混淆 workbuddy 和 dsh，因为它们看起来都在做"AI 辅助编程助手"这件事。实际用下来你会发现，两者重心完全不同。workbuddy 更像是一个集成了大量 AI 能力的个人工作台，主打对话管理、知识库沉淀和多轮任务的记忆保持。你可以在里面维护一套长期有效的记忆规则，让它越用越懂你的项目偏好。而 dsh 则更强调"插件体系"，它把几乎所有能力都拆成插件和 skill 的组合，用户通过一条命令就能把新插件拉进市场，再通过 skill 的组合拼装出一整套工作流。

这种差异直接决定了迁移时的难点。workbuddy 里的记忆规则是跟着账号走的，云端同步，而 dsh 更偏向本地配置 + 可编程插件。你在 workbuddy 里积累的"它对某个框架的特殊偏好"这类记忆，dsh 并不会自动继承，需要你把它们改写成规则文件或者 skill 指令。workbuddy-to-dsh 能做的，是尽可能帮你把这些规则和 skill 的原始内容捞出来，但具体改写还得靠迁移后的人工校对。

2.2 配置存储路径与格式差异

我把两个工具在常见系统下的默认存储路径整理了一下，迁移前先对照确认你的数据在哪个版本：

这个表格看着简单，实际影响很大。workbuddy 的 JSON 文件里一条 skill 和另一条 skill 之间没有文件级别的隔离，你很难单独导出某一条。而 dsh 要求每个 skill 有自己的目录结构，还得有必要的元数据声明。所以迁移时不能只是"文件搬家"，而是要做一个"格式翻译"。

2.3 直接复制为什么不行

我测试过最简单的 rm -rf 加 cp -r 方案，结果只有一个词：惨烈。workbuddy 的 skill 内容会全部堆在一个大 JSON 里，复制过去后 dsh 根本识别不出任何插件元数据。更麻烦的是，workbuddy 里有些 skill 依赖它自己的内置变量和上下文注入机制，这些机制在 dsh 里不存在，导致复制过来的 skill 即使语法没坏，运行时也会报变量未定义。

这就是 workbuddy-to-dsh 这类转换工具存在的根本原因。它需要处理四个方面：把 JSON 块拆分成文件结构、转换 skill 的元数据格式、把 workbuddy 特有的变量调用改写为 dsh 可用的形式、以及尽可能保留对话记忆和规则配置。每一步听着不难，但组合在一起就是个典型的"数据迁移工程"。

3. 迁移前准备：备份和版本核对不能省

3.1 确认版本与依赖

我建议你先把两个工具的版本查清楚，避免迁移工具和你本地版本不匹配。打开终端分别执行：

workbuddy --version dsh --version

理论上 workbuddy-to-dsh 支持目前主流版本，但我建议你至少保证 workbuddy 在较新的正式版上，dsh 也尽量用最新版本，因为 dsh 的插件市场机制迭代比较快，旧版本可能缺少迁移后需要的某些命令参数。

另外我遇到过一种情况：workbuddy 装在机器上但 PATH 没配置好，导致workbuddy --version直接报 command not found，但程序明明能打开。这种情况通常是安装包没有自动写环境变量，尤其是 Linux 手动解压安装时很常见。建议先确认两个命令都能正常输出版本号，再进行后续操作。

3.2 备份 workbuddy 数据

备份是整个迁移流程的底线。你永远不知道自己会不会因为一个错误参数把积累了几个月的 skill 和记忆规则扫进回收站。我习惯先复制一份完整的 workbuddy 配置目录，放到专门的备份文件夹里：

# Windows PowerShell Copy-Item -Recurse "$env:APPDATA\workbuddy" "$env:USERPROFILE\workbuddy-backup" # Linux/macOS cp -r ~/.workbuddy ~/workbuddy-backup

备份完成后，至少确认备份目录里能看到几个关键文件：主配置、包含所有 skill 的 JSON 文件、以及会话记录目录。如果在备份目录里找不到这些内容，说明原本的存储路径就不在这个位置，需要根据实际安装情况调整。

3.3 记录自定义项：快捷键、规则、模型配置

相比 skill 和会话记录，快捷键和模型配置这种零散自定义项更容易被遗漏。我个人的经验是，迁移前先建一个清单，把你想保留的东西逐项列出来。以我自己的迁移清单为例：

• 自定义 skill：约 12 条，涉及代码审查、提交信息生成、文档整理
• 会话记忆：重点保留最近一个月内的项目讨论记录
• 规则配置：包括代码风格偏好、忽略文件规则
• 快捷键映射：5 个高频操作的自定义键位
• 模型相关配置：默认模型、API 地址、超时参数

为什么要专门记录？因为 workbuddy 的账号记忆和本地会话记录有时不同步，你在云端看到的内容不一定完整落到本地。先列出来，迁移后再逐项对照检查，可以有效避免"看似迁移成功，实际丢了一半"的错觉。

4. 核心迁移流程：workbuddy-to-dsh 实际动手

4.1 安装 dsh 并确认基础运行

如果你还没安装 dsh，先装好并保证命令可用。不同系统的安装方式略有差异，常见的是通过包管理器安装或者从发布页下载二进制。安装完成后跑一次初始化：

dsh init

初始化会生成 dsh 的基础目录结构和默认配置文件。这一步非常重要，因为迁移工具需要往 dsh 的配置目录里写入内容，如果 dsh 从未初始化过，目标目录可能根本不存在的。我在第一次迁移时就吃过这个亏，没初始化直接跑迁移，结果工具报"目标目录不存在"，我还以为是工具坏了。

4.2 执行 workbuddy-to-dsh 转换

这个工具的调用方式一般是命令行参数一对一定位源目录和目标目录。我用的命令结构如下（具体参数名以你实际拿到的工具版本为准，但思路一致）：

workbuddy-to-dsh --source %APPDATA%/workbuddy --target ~/.config/dsh

Linux/macOS 就把 source 路径换成对应的 workbuddy 目录，Windows 上注意转义。启动后它会自动扫描 workbuddy 目录下的配置和 skill 文件，然后开始逐条转换。正常情况下会在终端输出进度条和日志，类似：

[INFO] 扫描到 12 个 skill [INFO] 转换 skill: code-review 完成 [INFO] 转换 skill: commit-helper 完成 [WARN] skill: doc-organizer 存在未支持的变量引用，已跳过 [INFO] 会话记录转换完成，共 45 条 [DONE] 迁移结束，生成报告文件

看到 WARN 级别的信息不要慌，先记录下了哪些内容被跳过，迁移结束后逐条处理。

4.3 迁移日志与警告的处理思路

迁移完成后，工具通常会在目标目录生成一份迁移报告或者日志文件。我的建议是你花十分钟把这份报告完整看一遍，尤其是里面标 WARN 和 ERROR 的条目。

上述示例里的doc-organizer被跳过，就是因为里面用了 workbuddy 特有的上下文变量，dsh 的 skill 体系里没有对应实现。遇到这种情况，需要打开原 JSON 文件定位这个 skill，把带 workbuddy 特色的变量替换成 dsh 支持的参数引用方式，然后手动放到 dsh 的 skill 目录下，再重新加载验证。

有些警告可以直接忽略，比如"配置文件中的历史版本字段已废弃"这类提示，不影响 dsh 加载。但凡是涉及"未支持""已跳过""无法识别"的警告，我强烈建议逐个解决，不然后续用到某个 skill 时才发现坏了，排查成本更高。

4.4 验证迁移结果

迁移完成不等于迁移成功，验证这一步能省下后续大量返工时间。我常用的验证方式有三步：

启动 dsh 后先查插件和 skill 列表，确认迁移过来的 skill 都在：

dsh skill list

然后随机挑一两个核心 skill 实际触发一下，看能不能正常响应。最后查会话记录，抽查一下其中一条历史会话能否被正确检索。

如果你之前用 workbuddy 积累了很关键的对话记忆，这一步尤其重要。我在验证时发现部分会话记录的时间戳字段转换后变成了乱码，虽然不影响搜索，但显示很难看。这种问题通常是编码格式不一致导致的，把迁移后的会话文件改成 UTF-8 编码一般就能解决。

5. 迁移后的插件市场与 skill 配置：这才算真正落地

5.1 配置 dshmarket 等插件市场

dsh 的能力相当依赖插件市场，迁移完成后第一件事就是把插件市场配置好。官方常见的市场地址示例是：

dsh plugin --profile web add dshmarket

执行成功后，dsh plugin list就能看到市场里的插件列表了。我建议在配置市场时用 profile 参数区分不同来源，避免多个市场来源的插件出现同名冲突。这里说一句，你完全可以结合自己的项目类型去选插件，不必一开始就装一大堆，按需配置反而是最有效率的工作流。

5.2 必备插件与 skill 的安装逻辑

以归档管理这个需求为例，dsh 的插件体系里通常能找到归档管理相关的插件或 skill，用于把历史文档、旧版本笔记分类整理。安装命令一般是：

dsh plugin install archive-manager

装完后在配置文件里声明对应的启用项，重启 dsh 后生效。我个人比较偏爱这种方式，因为每个插件都是独立单元，哪个出了问题直接禁用就行，不会影响整体使用。

如果你之前用的 skill 偏"全功能"型，迁移到 dsh 后可以考虑拆分成更细的 skill 组合。比如把一个"全能文档助手"拆成"文档归档""文档摘要""文档翻译"三个 skill，这样每个 skill 的职责清楚了，组合起来使用也更灵活，调试时定位问题也更快。

5.3 skill 调试中的常见问题

迁移过来的 skill 第一次加载失败是很常见的事，别急着怀疑迁移工具坏了。最常见的原因是元数据声明不完整。dsh 的 skill 文件头部通常需要声明 name、description 等基础字段，而 workbuddy 的 JSON 里这些字段的命名规则不同。转换工具一般会做映射，但偶尔会有漏网之鱼。查一下 skill 文件头部，手动补齐字段就能解决。

另一种情况是字符编码。如果你的 workbuddy 配置里有中文内容，而编辑环境保存成了 GBK 编码，dsh 加载时可能报乱码错误。统一转成 UTF-8 是个好习惯。我在迁移后的检查中专门写了一条命令批量转码，一次性解决了三个 skill 的加载问题。

5.4 缓存目录调整：别让系统盘吃紧

在关键词里我注意到不少人在问 workbuddy 缓存目录怎么更改，其实 dsh 也面临同样的问题。尤其当你处理大量文档和会话数据时，默认缓存目录如果在 C 盘或系统盘，很容易膨胀。dsh 一般支持通过环境变量或配置文件修改缓存路径，我通常是找一个空间充裕的固态硬盘目录：

# 示例：在配置文件中指定缓存目录 cache_dir = "D:/dsh-cache"

修改完重启 dsh，确认新缓存目录开始写入之后再清理旧缓存。这里有个容易忽略的点：旧缓存目录里可能还有正在被插件引用的临时文件，不要一上来就删，先停掉 dsh，再整体移动旧目录，确认新目录工作正常后再删除旧目录。

6. 常见问题与排查思路

6.1 商店版 PowerShell 执行命令出错

这个问题在 Windows 上很典型，尤其是通过 Microsoft Store 安装的 PowerShell 版本，有时候会出现权限受限的沙箱环境，导致 dsh 相关命令在调用插件时执行失败。如果你在商店版 PowerShell 里跑dsh plugin或workbuddy-to-dsh遇到各种奇怪的权限错误，先不要纠结命令本身，大概率是商店版 PowerShell 的 PATH 隔离机制在捣乱。

最简单的解决方案是改用传统版本 PowerShell 7 或 Windows Terminal。装完传统版 PowerShell 后重新打开终端，确认 dsh 命令能正常执行，这个问题基本上就绕开了。如果你确实需要在商店版环境里工作，也可以尝试用管理员权限执行Set-ExecutionPolicy RemoteSigned放行本地脚本，但说实话不如直接换环境省心。

6.2 迁移后 skill 无法加载

skill 无法加载的排查链路，我一般按顺序走：

先看 skill 列表里有没有这条记录，如果没有，说明 dsh 根本没扫到该文件，检查文件是否放在正确的插件目录下；如果有记录但加载失败，打开 skill 文件看元数据头是否完整，name、description 字段是否存在；元数据没问题再看正文是否有不支持的变量引用，这个可以通过手动执行一条简化指令来验证；最后看配置文件有没有对该 skill 做显式的启用声明。

有一次我排查了半天，结果发现是文件末尾多了一个不可见字符，导致解析器读取失败。用编辑器把文件重新保存为 UTF-8 无 BOM 格式后问题立刻消失。这类问题不容易被一眼识破，但遇到加载异常时值得留意。

6.3 更换账号后的记忆恢复问题

有用户在相关热词里问"workbuddy 换账号如何获得原来账号的记忆"，这个问题的核心在于，workbuddy 的记忆通常和账号绑定，本地配置目录里虽然有会话记录，但账号切换后这些记录不会自动出现在新账号下。

要保住记忆，靠 workbuddy-to-dsh 是不够的，还需要在迁移前手动导出。workbuddy 通常支持把记忆、规则导出为独立文件，导出后可以打包保存。切到 dsh 后，这些导出的规则文件可以直接放进 dsh 对应的规则目录里，等 dsh 支持账号体系后再做一次同步。目前比较务实的做法是：以本地文件为权威数据源，账号云端同步作为补充，而不是完全依赖单一账号的云端记忆。

6.4 Windows 下搬迁项目的路径问题

做项目搬迁时，Windows 上最常见的坑是路径过长和权限不足。workbuddy 或 dsh 的项目目录如果嵌套很深，Windows 默认会触发 MAX_PATH 限制，导致读写失败。此外有些目录被 OneDrive 同步占用，文件处于云端占位状态，本地读到的内容可能不是最新版。

我的建议是把项目迁移到一个干净的本地目录，比如D:\dev或C:\projects，避免放在桌面、文档这类系统特殊目录下。如果路径仍然过长，可以在组策略中启用长路径支持，或者干脆精简目录层级。别信什么"Windows 10 之后就自动支持长路径了"，实测很多情况下还得手动开启。

7. 迁移之外：把这次切换变成工作流优化的机会

转完工具之后，我最大的体会是：迁移不只是数据的搬运，更是对你原来工作流的一次彻底梳理。workbuddy 时期我积累了很多大而全的 skill，什么场景都往里面加逻辑。迁移到 dsh 后，每个 skill 独立成一个文件，我不得不重新审视每一条指令，拆分掉了很多模糊的规则。这种"被迫的裁剪"反而让我的使用效率提升了一截。

如果你也刚完成迁移，我建议先别急着把以前所有 skill 一股脑恢复，而是先用一两周，记录下自己最常用的操作和指令，再针对性地配置 dsh 的插件和 skill。这比盲目追求"迁移后和原来功能一模一样"要更实用。毕竟工具切换的最终目的不是复刻过去，而是换一个更清晰、更可组合的工作方式。

最后说一个我比较坚持的习惯：配置目录一定要纳入版本管理。迁移完成后，我会定期对 dsh 的配置目录做一次快照提交。工具总在迭代，插件市场也在不断变化，哪天更新出了问题，一条命令就能回滚到昨天的可用状态。迁移本身是一次性的，但迁移后的维护意识和习惯，才是让新工具真正稳定的关键。