鸿影的博客

slash-commands-dsh-vs-zcode

13分钟阅读

斜杠指令的两种哲学：发给 AI 的提示词，还是确定性的触发器——ZCode 与 dsh 对比

日期：2026年10月20日

作者：Honlnk/鸿影

适用读者：用 ZCode / Claude Code / Codex 类 AI 编程工具的开发者、想做自己的 AI 工具产品的人、好奇斜杠命令背后机制的人

定位说明：敲了这么久的 /命令，你有没有想过——按下回车之后，这几个字到底去了哪？是 AI「看到」了你的命令，还是程序自己就把它处理掉了？本文对比两个开源项目（ZCode 与 deepseek-harness）的斜杠指令实现，发现它们代表两种截然不同的设计哲学。

一、两家的相同点：都有一类「纯操作命令」

两个项目的斜杠指令都不是单一机制，而是「不同命令走不同路径」。其中有一类命令，两家的做法本质相同——都是「敲命令 → 执行一段写死的代码 → 全程不碰 AI」。

这类命令就像用打字的方式点了一个界面按钮：

  • ZCode 的「纯操作命令」：如 /清空、/新建会话、/切换模型。敲 /清空，程序直接执行「清空当前会话」这段代码，AI 全程不知情。
  • dsh 的「纯界面命令」：如 /model（弹模型选择框）、/file（弹文件选择框）。敲了就在界面上弹窗，跟 AI 无关。

两者思想完全一致——用命令的形式触发一段确定的代码，AI 不参与。唯一差别是这段代码跑在哪台机器上（ZCode 跑在本地后台，dsh 跑在浏览器界面），但这是「代码放哪」的差别，不是思想的差别。

补充：ZCode 其实还有另一套面向聊天机器人（微信、飞书、Telegram 等）的斜杠命令，如 /bind、/status、/reply 等，语义是「远程控制会话」。这套命令和上面说的本地命令是两套完全独立的体系，各有自己的解析器，几乎不重叠。本文主要讨论本地交互场景下的斜杠指令，机器人那套只在此提一句，避免混淆。

二、两家的不同点（一）：命令的「本质」不同

这是两家最根本的分歧——「用户敲了一个命令」之后，程序是把它交给 AI 去理解，还是程序自己接住处理。

ZCode：命令 = 发给 AI 的提示词

核心思想：用户敲 /某命令，程序把这句话换成一段事先写好的指令文字，然后发给 AI，让 AI 照着做。最终做什么，取决于 AI 怎么理解那段提示词。

除了上面提到的「纯操作命令」，ZCode 还有两类会发给 AI 的命令：

内置的提示词命令（如 /init，扫描项目生成说明书）：程序把 /init 换成一大段事先精心写好的英文指令，大意是「你正在执行 /init 命令，你的任务是扫描这个项目并生成说明书……」，然后发给 AI。用户在命令后面补的话，会附在指令末尾一起发出。

用户自己写的 markdown 命令：ZCode 最灵活的一类。用户自己写一个 .md 文件，里面就是自定义的提示词模板，还能留「占位符」（类似写信时的「此处填姓名」）。敲命令时带的参数被填进占位符，然后整段发给 AI。

一个关键点：ZCode 里没有「命令直接触发某个工具」这回事。即便是要触发某个技能（skill），它也不是程序直接去触发，而是在提示词里写一句「请先调用某某技能」，让 AI 自己去调用。也就是说，ZCode 的一切都经过 AI。

dsh：命令被程序直接拦截，不让 AI 碰

先看它的架构（这决定了它为什么能这么做）：dsh 是桌面应用，由两部分组成——

┌──────────────────────────────┐
│  你看到的网页界面（浏览器）      │  ← 管显示和交互
└──────────────┬───────────────┘
               │ 两者之间有条「通道」
┌──────────────┴───────────────┐
│  你电脑本地的一个后台程序       │  ← 管真正的干活
│  （读写文件、调 AI、跑任务）    │
└──────────────────────────────┘

用餐厅打比方：网页界面是「顾客」，本地后台程序是「后厨」。顾客不能进厨房，只能「点菜」。这条「点菜」的通道技术词叫 RPC——可以理解为「界面喊后台干活的对讲机」。

核心思想：用户敲 /某命令，命令被程序直接拦下，交给一段写死的代码处理，AI 全程看不到这个命令。敲斜杠命令更像「按下一个功能按钮」，而不是「对 AI 说一句话」。每个命令对应一段明确的代码逻辑，敲了就执行，没有「AI 猜猜你想干嘛」这一步。

dsh 的命令按「要不要收参数、在哪边跑」再细分：纯界面动作（/选择文件）、弹窗收参数（/切换模型）、后台直接执行（/压缩历史）、带参数的命令（敲了命令后输入框出现一个「标签」，标签后接着敲的内容作为参数交给后台）。

最有代表性的例子：dsh 的 /plan

/plan 是「开启计划模式」。敲 /plan 我想重构一下登录功能 并发送后：

  1. 命令被程序拦下，/plan 这个词本身不会发给 AI。
  2. 处理这个命令的那段代码，自己主动、确定地把后面那句话「我想重构一下登录功能」作为一条普通消息放进对话里，AI 才能看到它。

要不要把内容给 AI 看、给什么内容，完全由代码决定，AI 没有发言权。这就是两家的本质区别：dsh 是「代码说了算」，ZCode 是「提示词说了算」。

三、两家的不同点（二）：「指令服务谁」不同

这是第二个、也是决定了「自由度」的分歧。

dsh 的指令清单：少而克制

dsh 的指令一共就 8 个，全是产品内置的「系统级开关/操作」：

跑在后台、真正干活的（6 个）：

命令干什么带参数吗
/plan进入/退出「计划模式」可选带一段话
/compact手动压缩会话历史不带
/feedback记录一条反馈带一段文字
/export把当前会话日志导出成 ZIP 下载不带
/permission切换权限档位带档位名
/goal设置/查看/暂停长期目标带目标内容

纯界面、不碰 AI 的（2 个）：

命令干什么
/model弹出模型选择框
/file弹出文件选择框上传附件

dsh 没有「随手造一个业务指令」的例子，全是克制的系统功能。

用户自定义能力：两家天壤之别

  • ZCode：用户写一个带占位符的 md 文件就造出一条新指令，想做什么做什么，零门槛。
  • dsh：完全不支持「写个文件就成指令」。想加指令只能写代码——写一个插件（代码模块），注册指令并写上处理逻辑，挂进应用、重启后台进程才生效。dsh 源码里没有「扫描目录读 md 文件」这类机制。命令名还有硬性约束（必须小写字母开头，只能用 小写字母/数字/下划线/横线，中文名不合法）。

这印证了 dsh 的「万物皆插件」哲学：一条指令不是独立的东西，而是一个插件的一部分。自定义指令 = 自己写一套配套的代码规则（插件）装进 dsh。

两种「自由度」：各占一头

「谁的自由度更高」要拆开看——「自由度」有两个意思，两家各占一头：

哪种「自由度」ZCodedsh谁更自由
「人人能不能随手造」写个 md 文件就行，零门槛必须写插件、重启进程ZCode（上手自由度高）
「指令能干什么事」只能发一段提示词给 AI能跑任意真实代码：读写文件、调服务、操作系统dsh（能力上限高）

dsh 的能力上限确实远超 ZCode（指令的处理逻辑是任意代码），但 ZCode 的「人人可造」也是 dsh 做不到的（准确说是 dsh 不愿做，不是不能）。

根本差异

两家在「指令该服务谁」上做了不同取舍：

  • ZCode：指令服务普通用户 → 做得零门槛（写 md），但能力限制在「只能给 AI 发话」
  • dsh：指令服务插件开发者 → 能力拉满（真代码），但门槛拉到「得会写插件」

没有绝对的好坏，区别只在于「希望指令是用户随手用的工具，还是开发者精准控制的开关」。

四、总结对照表

维度ZCodedsh
命令的本质发给 AI 的提示词确定性的功能触发器
命令文本发给 AI 吗大部分发（换成提示词后），少数纯操作不发不发
接下来做什么，谁说了算AI 读完提示词自己决定代码说了算，确定
结果可靠性看 AI 理解得对不对100% 可靠
触发工具的方式在提示词里写「请调用某工具」，AI 自己去调代码直接执行，可不调 AI
纯操作命令有（本地 CLI 用，另有一套机器人命令）有（纯界面弹窗/动作）
用户自定义写 md 文件即可，零门槛须写插件，不支持 md
指令服务对象普通用户插件开发者
实现复杂度中高

本文结论来自对两个项目源码的逐文件阅读（deepseek-harness 与 ZCode 源码仓库，均为开源可查）。

关系图谱