profile

别名:--profile、档案、配置档、profiles 目录

profile 是一套可切换的插件层栈,落在 $DSH_HOME/profiles/<name>;dsh 启动必须指定 profile,dsh web 只是 --profile web 的别名,插件按 profile 各装一份。

一句话

profile 是 DSH 的「一套装了什么」的边界。 它不是账号、不是主题、不是工作区,而是一份可切换的插件层栈:换 profile 就换了整套插件与配置,而用户数据(会话、技能、存储)默认还是同一份。

落点

profile 住在用户数据根下的 profiles/ 目录里:$DSH_HOME/profiles/<name>/(默认根见 concept/3)。每个 profile 目录里至少有两样东西:

  • package.json:里面的 dsh.profile.bundles 是这个 profile 的有序 bundle 列表,也就是层栈的骨架;
  • cordis.patch.yml:这个 profile 自己的用户补丁层。

外加一个 cordis.yml 根配置——它永远是一个空数组,只是给 Loader 一个真实文件当 baseUrl 锚点。树由补丁叠出来,原因见 concept/1。

命令行怎么用

  • dsh --profile <name> … 启动指定 profile;profile 是必填的,不给就报错 --profile <name> is required。
  • dsh web 是硬编码别名,等价于 dsh --profile web。所以「装到哪个 profile」和「用哪个界面起」在官方形态下是同一件事。
  • dsh plugin --profile <name> add <包> 把参数原样转发给 pnpm,pnpm 在该 profile 目录里跑——装插件是按 profile 装的,这就是「换了 profile 插件不见」的全部原因。
  • dsh --profile <name> --dump-config 打印组合后的树;--dump-default-config 不叠加用户层与 --patch,用来区分「包带的」与「你改的」。

生态里的三种用法

  1. 官方形态:web、headless、desktop、tui 这类 profile 名指形态;
  2. 整合包形态:一个整合包基本就是一个 profile,市场里包的 profileName 通常与包名一致;
  3. 激活指针:桌面生态里 profiles/desktop 被某些工具当作「当前激活 profile」的指针,切换靠改这个目录的指向来实现——这是实现约定,不是规范条款。

未核实

  • 本机 $DSH_HOME/profiles 下实测能列出 web、desktop、dsh-tui 等目录,但哪些 profile 名是 DSH 出厂自带、哪些由桌面壳创建,本轮未核实。
  • profile 之间的会话 / 存储隔离策略未核实:从机制上看数据根是单一的,但具体哪些状态随 profile 走、哪些全局共享,需要逐项验证。

出处

  • CLI 契约:@deepseek-ai/dsh 的 lib/bin.js(实测 0.1.0-rc.6),其中 --profile、web 别名、plugin 子命令的说明都在帮助文本里。
  • profile 目录与层栈解析:@deepseek-ai/dsh-app-boot 的 loadProfile / initProfile / PROFILE_PATCH_FILENAME。

相关教程

谁引用了这一条

信息表

category
concept.runtime
layer
runtime
spec
$DSH_HOME/profiles/node_modules/@deepseek-ai/dsh/lib/bin.js(--profile / web 别名 / plugin 子命令)与 @deepseek-ai/dsh-app-boot 的 loadProfile / initProfile
updatedAt
2026-10-02

被 2 篇教程引用 · 被 2 条词条引用

最后更新 2026-10-02