Claude Code 里，Skills 和自定义 Slash Commands 初看都很像一键触发固定工作流。视频从开发者视角拆开后，机制并不一样。斜杠命令更像快捷指令，把预设提示或步骤绑到斜杠入口，触发时整份 markdown 进上下文。Skills 把能力说明写在 SKILL.md 的描述里，启动时先读描述，真正用到的参考与脚本再按需加载。选型终裁若不拆这层，团队会把长说明书塞进斜杠，或把简单别名做成过重技能包。
材料来自早班对视频 D9auszpVMQY 的转述。正文不放外链。数字与机制按转述写，不编造测评分数。另有一条同题横评视频不在本文范围内，避免和只有观感的选型挤到一起。
图注 左侧为终裁三档与推荐拆分，右侧为错放后的典型代价。
目标说明
读完你应能勾选四件事。
- 说清斜杠命令与 Skills 的加载差异。
- 按频率、分层披露需求、错放成本做三档终裁。
- 识别「长说明书进斜杠」与「别名做成过重技能」两类错放。
- 用一份需求×写法 CSV 产出可复查的终裁表。
机制对照（据视频转述）
自定义斜杠命令保存在 commands 目录的 markdown 里。视频示例是 fix issue，接收 GitHub issue 号，描述里写明分析并修复，并可声明允许使用的工具。运行方式是手动输入斜杠加参数。触发后，Cloud 会加载该命令的元数据，并把整份 markdown 放入上下文。若描述缺失，会抓取文件开头一段充当说明。
Skills 的细节在 SKILL.md。描述被视频强调为关键，通常拆成能力说明与启用场景两段。技能目录里还可以放参考、代码片段、可执行脚本，形成一个迷你项目。启动 Claude Code 时，系统先读各技能的描述。文件本体按需加载，而不是一上来塞满上下文。技能可以自动被判定启用，也可以在提示里显式点名。
一句话收束。命令是手动、全量加载的快捷入口。技能是描述驱动、按需加载、可自动触发的能力包。
终裁维度
| 维度 | 偏向命令 | 偏向 Skills |
|---|---|---|
| 触发频率 | 高频、短动作 | 中低频也可，重在复用 |
| 说明长度 | 短，几步内说完 | 需要分层披露与参考资料 |
| 资源形态 | 单文件提示为主 | 多文件、脚本、参考 |
| 触发方式 | 用户主动斜杠 | 可自动，也可显式点名 |
| 错放代价 | 长文进上下文，挤掉任务信号 | 别名过重，维护与测试成本翻倍 |
能用、限场景、不能用三档如下。
能用。 高频短动作用斜杠命令。可复用且需要分层说明的能力封成 Skills。两者可以并存，但边界写进团队规范。视频主张的默认拆分就是这一档。
限场景。 团队已有清晰命令清单，且每条说明很短，暂时全部用斜杠也能转。一旦出现每次都要贴长安全说明，或必须附带脚本，就应升格为 Skills，别继续往命令文件末尾追加。
不能用。 把整份 SEO 或安全长说明书塞进斜杠，导致每次触发全量进上下文。或把只想要一个 fix 别名的需求，做成带一堆脚本的迷你项目技能，维护成本与触发条件都难测。
最小实验
脚本在 _w/skills-slash-smoke/。三行模拟需求如下。
text
R1 裸斜杠长说明书 -> 不能用（每次全量进上下文）
R2 过重 Skill 包简单别名 -> 不能用（维护成本翻倍）
R3 短命令+分层 Skill -> 能用（视频主张的默认拆分）错放对照表额外记下三种代价。上下文被说明书塞满。能力静默丢失（模型被长说明挤占后漏做关键步骤）。维护成本翻倍与触发条件难测。实验不打分，只产出可勾选的终裁与错放行，满足选型必须有失败对照表的硬要求。
团队落地时怎么写规范
规范里建议固定三栏。名称、类型（命令或技能）、一句话何时用。命令栏禁止超过约定长度的正文，超长就改技能。技能栏强制写启用场景，避免描述只有功能没有时机。视频里 SEO 技能把能力与启用场景拆开，就是为了自动启用时有可判定信号。
Code review 时多问两个问题。这次改动究竟缩短了入口，抑或又把说明书塞回命令。这次新增脚本究竟是技能资源，抑或别名的过度设计。两个问题都能在终裁表里找到对应行。
和「同题横评」差在哪
横评常见写法是两款工具打同一题，再凭观感分胜负。本文不走那条。材料只提供机制与适用判断，终裁靠频率、披露、错放成本三维度，并用 CSV 固化。若你的团队需要性能数字，应另开测量，不把未出现在视频里的分数写进正文。
预发检查
- 命令目录里没有超长说明书文件。
- 每个 Skill 的描述同时包含能力与启用场景。
- 简单别名没有附带无必要脚本树。
- 复跑 smoke，终裁表与错放表仍是三行可勾选结果。
接入顺序
先盘点现有斜杠命令，按长度与是否含脚本分成两堆。短且无脚本的留下。长或含脚本的迁到 Skills，并补「何时用」。再为高频动作补两条新命令，保持入口轻。最后把终裁表放进仓库，新人加入口先填表再写文件。
迁移期允许双入口，但要在描述里写明优先用技能版或优先用命令版，避免同一能力两套触发，行为漂移。稳定后删掉旧入口。
错放成本怎么估
上下文被说明书塞满时，模型仍可能看起来在工作，只是关键工具调用变少，或安全步骤被挤掉。这种失败叫静默丢失，监控若只看是否返回了文字，会判成功。终裁表要把这类成本写出来，避免评审时只争论用着方便。
别名做成过重技能时，成本在人。每次改一行脚本都要回归技能描述、触发条件、权限。简单的 fix 斜杠本可是二十行命令，结果变成迷你项目。视频明确提醒，别把简单别名做成过重技能，也别把长说明书塞进命令。两极都贵。
限场景档不是永久豁免。团队命令清单一变长，就要重新终裁。建议每个季度用 smoke 的三行需求再跑一次，看看有没有新的 R1、R2 出现。
描述怎么写才像技能
能力段要具体到任务类型，例如对变更做 SEO 相关检查，覆盖标题、元描述、内链。启用段要写触发信号，例如用户修改了面向公开站点的页面文案或路由。只有功能没有场景，自动启用会乱。只有场景没有功能，人读着也没法复用。
命令的描述可以更短，因为它本来就要手动点。技能的描述承担分类器角色，短到含糊会误触发，长到像论文又浪费启动读取。视频把它拆成两段，是可抄的结构。
什么时候该重做终裁
出现下列信号之一，就应重跑终裁表。命令文件平均长度明显变长。技能目录里开始出现「只为了一个别名」的空壳项目。自动启用的技能互相抢触发，用户抱怨没叫它却跑了。新成员靠复制旧命令上手，而不理解类型差异。
重做时不要只改文档。用 smoke 的三行需求再跑，把新的 R1、R2 样本加进 CSV。终裁是活的验收，不是贴一次墙纸。
若团队同时使用其他助手产品的技能概念，不要假设同名同义。本文结论只覆盖视频所讲的 Claude Code Skills 与自定义 Slash Commands。跨产品迁移时，重新做机制对照，再套三档终裁。
验收时怎么演示
给评审看三样东西就够。一份短命令的全文。一份技能的描述两段。一张终裁表，含 R1 到 R3。演示顺序先错放后正解。先打开长说明书命令，指出它会整份进上下文。再打开过重别名技能，指出维护面。最后落到短命令加分层技能。评审若只听概念，容易点头了事。对着文件与 CSV，终裁才压得住。
视频还提到技能可以带脚本。脚本权限应与普通工具权限一并评审。不要因为文件落在技能目录就绕过代码审核。按需加载减少的是上下文压力，不是安全审查。
和命令清单一起维护
终裁表应和命令清单、技能清单放在同一目录。清单变更 PR 必须附带终裁行更新。否则清单越写越长，终裁还停在上个季度。视频给的判断句很短。高频短动作用命令，可复用且需分层说明的封成技能。把它写成仓库里的验收句，比写在聊天记录里更耐用。
小结
Skills 与 Slash Commands 都能一键触发，加载与披露方式不同。能用的默认拆分是短命令加分层技能。不能用的两极是长说明书进斜杠，以及别名做成过重技能。按视频机制做终裁，并用最小实验留对照表，选型才站得住。