让 DSH 聊天助手少碰文件：custom-mode 如何分开管理提示与工具

DSH最新可核验标签为0.2.1-alpha.2预发布。custom-mode 2.2.3提供助手提示、基础模式与插件开关管理；当次核验到固定源码和Bundle声明，未完成安装与运行验收。

你改了一段提示，助手还能不能执行命令

想让AI只讨论文案，却发现它仍具备改文件和执行命令的工具，这不是提示写得不够礼貌，而是权限设置与任务目标没有对齐。DSH把模型放进带工具、文件和插件的工作环境；与普通聊天产品的区别，可以理解为“回答问题”与“拿着工具完成任务”的区别。工具多了，用户也要知道哪些动作允许发生。

10月11日当次读取官方release，最新观察标签是dsh-v0.2.1-alpha.2，10月9日发布，标为预发布。release标签、npm dist-tag与源码提交不能互换；本次npm接口读取失败，不声称核验了dist-tag。近期开发者讨论中，10月2日Desktop相关Hacker News帖子有417 points、227条评论，这是生态关注量，不是可用率。

今天选择custom-mode 2.2.3作为一个工作流案例。它把助手的提示、基础模式和插件开关放在可管理的设置里。它值得研究的不是增加一个聊天皮肤，而是让写作、讨论与编程场景拥有不同的工具组合。本文没有安装插件，没有重启Profile，也没有完成最终任务，不把源码与作者演示写成已验证可用。

固定这一份代码，才有可讨论的对象

原仓库为BOWLUNA/dsh-custom-mode，维护者BOWLUNA，当次固定提交cd04b97d0b36144860b5cbfb7d2984ca6decc15d，package.json版本2.2.3，仓库声明MIT。9个Star是当次仓库计数，不是增长率，也不是安全背书。近30天稿件与插件历史未发现同一仓库或功能换皮主题，这构成本次未重复的依据。

包内声明dsh.bundle.patch指向cordis.patch.yml，并提供client.js客户端入口。该补丁把设置页面插入Bundle加载路径；声明存在证明包的组织方式，不证明它已被某个本机Profile加载。页面能展示又是另一个状态，目标任务是否按约束完成还需要独立验收。

源码、Bundle、目录收录、安装、Profile重启和最终任务是六个状态。用户读到“支持DSH”时，应问作者证明了哪一个。本文读取固定源码、架构、故障说明与卸载脚本，能够解释声明和风险；没有后四个环节的运行输出，也就没有资格替读者承诺工作流效果。

一个助手的组成，为什么不止系统提示

作者文档区分基础模式、系统提示和插件覆盖。Write模式的作者说明关闭terminal、保留file；Chat模式说明关闭file和terminal。这是项目声明与代码组织信息，不是本文对所有工具调用路径做完安全测试的结论。一个工具关闭以后，仍要检查其他插件、钩子和模型路由是否提供相近能力。

源码中的保存路径涉及提示文件与agent.cordis.yml组成文件，设置页经私有HTTP路由交互。它在本地写文件，也会影响助手组成；不能因没有发现营销描述中的外部上传，就断言不存在网络风险。宿主连接路由、模型后端和其他插件的网络边界仍要共同审查。

这个设计提醒读者把“让模型不要做”与“不给模型做的工具”分开。提示是行为要求，工具开关是能力配置，宿主授权是执行边界。三层需要一致。提示里的禁止语句不能替代最小权限，关闭终端也不能证明文件系统不会由其他能力触及。

保存冲突，反而是一项值得保留的摩擦

README与源码说明，旧副本保存可能因冲突被拒绝，避免覆盖别处的更新。多个页面或模型同时修改提示时，这种拒绝是一种版本保护，不宜为了方便把它关闭。恢复动作应是重读当前内容、比较差异、再决定保存，而不是把旧文本强行写回。

文档还提到提示在后续模型步骤重读，以及通过custom_prompt修改时的授权条件。它们是实现与作者说明层面的证据，不能由此保证每个宿主、每个版本与每条工具路径都表现相同。本次没有实际触发模型授权弹窗或核验下一步行为，读者需要把这部分列入试验。

可用性也有边界。作者记录Windows web实验，不等于本机macOS验收；web页面与tui的宿主能力不同，缺少对应服务会阻止页面工作。把模式管理器当跨平台万能开关，会给排错带来方向错误。先确认Profile和宿主版本，再核对服务是否存在，比反复安装更有效。

安装前，先做能撤销的三项检查

第一，备份要变动的Profile配置和提示文件，并记录当前提交与包版本；第二，读Bundle补丁、客户端入口及本地文件写入范围；第三，在一次性Profile里定义一个无真实数据的任务。作者提供web安装命令dsh plugin --profile web add dsh-custom-mode@2.2.3；桌面版要求应用内Plugins页面，不能拿CLI命令替代桌面验收。

最小试验可以用一个空目录和一段虚构文本：Chat只回答问题，Write只处理允许的样本，Code的命令能力需要额外授权。每次重启Profile后检查实际助手组成，再看最终输出及文件差异。本文没有执行这套试验，所以不会说模式限制已生效；它是读者可以在隔离条件下实施的验证计划。

至少有三类失败要预留：宿主服务或版本不匹配导致设置页缺失；提示文件被外部更新导致保存冲突；模式名看似正确但工具组成不符。还要测试错误路径、旧配置和客户端缓存。发现权限越界，应停止试验、保留日志并恢复备份，而不是在生产目录继续试错。

回滚不是把页面关掉

项目的卸载脚本与Bundle注释说明了移除入口：删去包或对应Bundle项，会撤去设置页面。默认保留提示内容与彻底清理是不同动作；带purge的清理会涉及用户数据，应先读脚本、备份再决定。本文没有执行卸载或purge，也没有向用户全局配置写入内容。

卸载后的验收应检查旧助手组成、提示文件和默认模式，不能因按钮消失就判断变更全部撤销。如果另一个工具继续引用生成的配置，仍可能存在残留作用。可恢复管理要有变更前后差异、文件记录和恢复后的任务检查；一条卸载命令只是这条链中的一个动作。

对实际使用者，安全不是承诺插件永远无错，而是错的时候知道改了什么、影响哪里、如何退回。源码固定让问题能复核，备份让状态能恢复，任务验收让行为能确认。一个项目README越简短，用户越需要自己补足这三种证据；Star和推荐文字不能承担它们。

找插件时，几个入口各自回答不同问题

当次GitHub dsh-plugin Topic搜索返回18621个候选仓库；本次取到100条样本，不能把总量说成可安装Bundle数，更不能说成已审计插件数。Awesome清单与生态地图帮助导航，维护频率和收录标准需核对；网页目录支持搜索，却未必固定版本或提供运行记录。

Leaderboard回答关注度或排行问题，不能证明权限安全。内置或订阅式市场降低安装步骤，是否经过独立审查要看规则与记录，不能因按钮方便就默认完成审核。本次读取了Topic、Awesome、网页目录和市场页面，未取得Leaderboard可比较的完整数据，该入口保留覆盖缺口。

这些入口相互补充，却没有自然连成固定来源、权限可读、运行证据与可撤销变更的连续决策链。用户可以在一个页面发现名字，仍需到原仓库读版本，到宿主查配置，再到任务输出确认行为。这里缺的是证据如何随决定移动，而不是再增加一个展示数量。

精选目录进入决策链，也要接受相同核对

完成上面的安全检查与入口比较后，可以看DSH.Store国际站和国内站提供的发现层。当次两站目录JSON一致，更新时间为10月10日19:51:04 UTC：788条记录中approved为32、blocked为386、unlisted为370。两个访问入口不能重复算成两套生态，788也不是可安装或运行验收总数。

目录状态的实际价值，是让读者知道一条记录被怎样处理，而不是给“收录”套上安全结论。需要核对固定来源、权限、审查结果与兼容信息。本文未证明custom-mode在商城或本机的全部状态，也不使用“最安全”或“唯一可靠”等比较结论；机制能提供哪一步证据，就只说明哪一步。

插件使用者可以阅读安全插件管理器仓库，了解来源核验、权限审查与可恢复管理的实现，再按自己的Profile做隔离试验。觉得这些机制有帮助，可以Star跟踪更新。仓库存在、目录状态或安装成功，都不替代Profile重启后的真实任务验收。

开发者的出口，是把证据随包交出去

对插件开发者，build-dsh-plugin仓库提供制作、审查与打包工作流的研究入口；当次GitHub元数据识别MIT许可证，修改与再分发仍需读许可证正文及第三方依赖授权。可以使用、研究并Star跟踪，但不能因为工具生成了包，就把测试、许可和运行证明省去。

开发者最好随版本提交明确的Bundle路径、文件与网络边界、失败案例、卸载方法和验收任务。使用者则保留固定提交、一次性Profile和输出回读。这会让插件介绍从功能承诺变成可检查的工作流。custom-mode当前适合源码研究与受控试验，本文没有把未完成的运行部分补成结论。

这条报道的读者收益，是学会在改提示之前确认工具，在安装之前确认来源，在说可用之前确认任务。DSH的灵活性来自组件组合，责任也随着组合进入用户的项目。让每个助手只拿任务需要的能力，并为每次变更保留退路，是生态热度之外更有用的一项日常习惯。

用东方文化看懂现代科技