# AI时代的Superpowers Skill教程17招-第1招-DeepSeek Harness怎么安装Superpowers并验证真的生效？

> 装完文件不等于生效，模型能加载才算数。

```text
[读者] 正在给企业数字人接入研发能力的架构师
[痛点] Skill 目录复制过去了，模型在新会话里却假装不认识
[现在读] DSH 的 Skill 子系统已经定型，旧的插件式装法不再适用
[读完] 拿到一套可复现的安装动作与可验证的生效判定
```

```text
[旧方案] 按 Claude/Codex 插件清单的方式安装 Superpowers
    |
    v
[新需求] 开发工具统一换成 DeepSeek Harness
    |
    v
[冲突] DSH 不读插件清单，它只认 Skill 发现目录
    |
    v
[后果] 文件都在，能力为零，团队还以为已经装好了
```

我是老李，在某公司的平台组做研发效能。去年我们给企业数字人项目接了一套 Skill 化的研发流程，用的是插件清单那套老办法，安装脚本一跑，目录里多出几十个文件夹，谁看都觉得稳。

今年工具换了。开发工具换成 DeepSeek Harness，研发方法论那一条则挂到 obra/superpowers 上。工具换了，装法的假设也就跟着换了，而这一点最初没人意识到。

第一周就出事了。演示现场，我在新会话里让模型先做一轮头脑风暴，它回我一句：没有可用的相关 Skill。文件明明躺在仓库里，模型却说没有。

复制文件就等于装好了吗？

到底是先把 Web UI 跑起来，还是先把 Skill 目录理顺？

如果验证标准只是复制命令没报错，我们会付出什么代价？

# 01、故事

企业数字人项目组有 6 个人，两条产品线共用一套代码仓，模型侧跑 DSH，研发侧要用 Superpowers 那套流程。任务是：把 Superpowers 的官方 Skill 装进 DSH，让模型在真实会话里能用上。

我第一版的做法很直接：把 superpowers 仓库里的 skills 目录整个复制进项目，按之前插件装法的经验，放到一个自认为「约定俗成」的位置，然后打开 DSH 的 Web UI，默认 Standard 模式，新建会话，输入一句「帮我做一次头脑风暴」。

模型回得很客气：没有找到相关能力。

同事小陈在旁边说，可能是模型抽风，再开一个会话。第二个会话还是一样。那一刻我才反应过来，问题不在模型，在我把文件放错了地方，或者放对了地方但没人告诉 DSH 去看。

这里有一个很容易被忽略的细节：DSH 的 Skill 不是被「安装」进去的，而是被「发现」进去的。发现路径写死在哪里，文件就必须落在哪里；发现之后还要有一个工具把目录清单交给模型。这两件事缺一件，装法就算失败。

那天下午我们做了一个决定，不再猜路径，先把 DSH 的 Skill 子系统文档读一遍，再动手。

> 装完不算完
> 加载才算数
> 目录先站稳
> 会话再验真

# 02、问题

旧方案的失效方式很有代表性：它依赖「插件清单 + 运行时扫描」这套组合。清单里写了什么，工具就去加载什么。

DSH 不是这么工作的。按官方仓库的 Skill 子系统说明，Skill 由文件系统发现组件扫描约定的目录，再由工具组件把可用清单和加载能力发布给模型。也就是说，你复制了多少文件不重要，重要的是文件是否落在被扫描的目录里，以及模型是否拿到了那份清单。

业务影响是直接的：演示失败一次，团队对「Skill 化研发」这件事的信任就掉一截。更麻烦的是它失败了还不报错，复制命令的返回码是 0，一切看起来都很正常。

技术表现可以归纳成三条。第一，文件存在但不可见，目录在仓库里，模型在新会话里看不到任何相关条目。第二，可见但不可加载，偶尔能看到名字，点进去却拿不到内容。第三，可加载但不可用，Skill 内容被读到了，但流程没被执行，模型依旧按自己习惯的方式写代码。

可验证的完成标准也应该写成三条：新会话里能列出 using-superpowers、brainstorming 这类目录项；能对其中任意一个执行一次真实的加载；加载后的内容确实进入了这次会话的上下文，并改变了模型接下来的行为。

注意最后一条。前两条是手段，第三条才是目的。

> 旧法已失效
> 新器不认单
> 标准先写死
> 验收才有底

# 03、原理

Skill 子系统其实是一条三段式的链路：发现、发布、加载。

发现由文件系统组件负责，它按约定目录扫描文件；发布由工具组件负责，它把「有哪些 Skill、每个 Skill 是什么」这份清单作为工具描述交给模型；加载是模型在需要时主动调用，把某个 Skill 的正文拉进当前会话上下文。

反直觉判断：Skill 的「安装」其实不是一次写操作，而是一次读路径的配置。你并没有把能力塞进模型，你只是让它知道去哪里读。写文件的那一步，在整个链路里最不值钱。

这个判断能解释后面所有的故障。因为写文件最不值钱，所以「文件复制成功」这个验证点几乎不产生信息量；因为读路径才是关键，所以目录名、扫描范围、发布方式任何一个错了，表现都是同一句「没有找到」。

它还能解释一个常见的误判。团队看到模型说没有 Skill，第一反应是模型能力问题或者版本问题，于是去升级模型、换会话、重启服务。这些动作在链路里对应的是加载这一段，而故障大概率发生在更前面的发现那一段。

要记住的顺序是：目录先对，清单再通，加载最后验。顺序反了，排查成本会成倍上升。

> 发现先于载
> 目录即契约
> 模型不问路
> 只因没登记

# 04、架构

```text
[输入] 项目仓库中的 Skill 目录 + 新会话中的用户请求
    |
    v
[模块] dsh-skill-filesystem（扫描约定目录，产出 Skill 清单）
    |
    v
[数据/状态] 可用 Skill 目录项（name / description / 位置）
    |
    v
[处理] dsh-tool-skill（把清单发布为工具描述，并在调用时读取正文）
    |
    v
[输出] 进入会话上下文的 Skill 内容 → 影响模型的研发动作
```

这条链路只管「能力怎么被模型看见和使用」，不管 Skill 本身写得好不好。这是边界，也是最容易被越界的地方：很多人把「Skill 内容写错」和「Skill 没装好」混成同一个问题。

收益很明确：一次配置，所有会话受益；Skill 是文件，可以进 Git，可以走 Code Review，可以被版本管理。

代价同样明确：目录约定是硬约束，换位置就得重配；清单里塞太多 Skill 会稀释模型的选择注意力；Skill 正文本身会占用上下文预算。

适用条件是：需要跨会话、跨成员共享同一套研发方法论时，这条链路价值最大。如果只是临时让模型做一件事，写进提示词更快。

> 一源入目录
> 一器布清单
> 一载回上下文
> 一边界要划清

# 05、实战一次

环境与依赖：Node.js 已安装，DSH 可以通过 npx 直接运行，也可以拉源码构建后运行。两种方式在 Web UI 上的表现一致，本文以方式一为主。

```bash

# 方式一：直接用 npx 启动 Web UI
npx @deepseek-ai/dsh web

# 方式二：从源码构建后启动
git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web
```

Web UI 默认使用 Standard 模式，本篇不需要切换模式。

接下来把 Superpowers 的官方 Skill 同步进项目。按当前官方说明，Skill 目录约定在项目内的 .agents/skills/ 或 .dsh/skills/ 下，具体目录名与扫描范围需按当前官方文档核验。

```bash
git clone https://github.com/obra/superpowers.git /tmp/superpowers
mkdir -p .agents/skills
cp -r /tmp/superpowers/skills/* .agents/skills/
ls .agents/skills
```

示例输出（目录项以官方仓库当前内容为准）：

```console
brainstorming
using-superpowers
writing-plans
test-driven-development
...
```

启动 Web UI，新建一个会话，第一步让它列出当前可见的 Skill 目录项。

```console
> 请列出当前可用的 Skill，并说明你打算用哪一个来做需求设计
```

未在当前环境实测，以下为预期结果：

```console
可用 Skill：using-superpowers、brainstorming、writing-plans ...
建议：先用 using-superpowers 做研发总入口，再进入 brainstorming 收需求
```

第二步做加载验证。这一步才是真正的验收动作：

```console
> 加载 brainstorming，并按其流程对我下面这个需求做一轮设计
```

如果模型的回应开始出现「先提问澄清、再收敛方案」这种结构，而不是直接抛代码，说明 Skill 正文确实进入了这次会话的上下文。判据是行为序列，不是文案是否一致。

V1 到这里跑通，但它留下了一个明显的问题：只要我不主动要求，模型并不会自己想起去查一遍 Skill 清单。

> 先跑通再看
> 先冒烟再信
> 一条命令起
> 一次加载证

# 06、排查

诊断链一。现象：新会话里模型说没有相关 Skill，但目录确实存在。怀疑：文件放错了目录。检查：对比项目根目录下实际存在的 Skill 目录名与官方文档描述的约定目录。证据：文件在项目根的 skills/ 下，而不是约定目录里。根因：发现组件只扫约定目录，非约定位置的文件不会被登记。修复：移动或建立软链到约定目录，新建会话再看清单。

诊断链二。现象：目录项出现了，但加载时拿不到正文。怀疑：目录项只是被列了出来，正文读取路径没通。检查：看条目下是否存在实际内容文件，是否存在大小写或扩展名差异。证据：某些条目只有一个空目录。根因：复制方式没有保留完整结构，或者上游仓库里该 Skill 的组织方式与预期不同。修复：按官方仓库的目录结构重新同步，逐个确认条目下存在可读内容。

**错误尝试：** 一开始我怀疑是 Web UI 缓存，于是反复重启服务、换浏览器、清会话，折腾了一个小时没有任何变化。这个方向错在把问题定位在加载这一段，而证据表明链路在更前面的发现那一段就已经断了。重启只能影响已经登记的内容，不能改变扫描结果。

教训很朴素：先确认清单里有没有它，再确认加载能不能拿到它，最后才怀疑会话和缓存。

> 现象先钉住
> 怀疑再排队
> 证据不出手
> 根因不松口

# 07、优化

根因归纳起来是两条：路径不对，导致发现失败；清单不被主动使用，导致发布形同虚设。

修改一：把 Skill 目录固定为项目内的约定目录，并提交进仓库，让每个成员 clone 下来就自带这套能力。

修改二：在项目约定里把 using-superpowers 定为研发总入口。任何开发任务开始前，先走一遍入口 Skill，由它决定接下来该用哪一个。

为什么这样改：发现这一段要的是确定性，所以把路径固化进仓库；发布这一段要的是命中率，所以给模型一个稳定的第一跳。前者解决「看不见」，后者解决「不想看」。

新行为：新会话开始时，模型不需要被反复提醒，也能按入口 Skill 的指引，先设计后编码。

验证方式：新会话里给一个模糊需求，观察模型是否先发起澄清提问、再给方案，而不是直接开始写代码。这一步未在当前环境实测，判据是行为序列是否出现。

> 根因在哪层
> 改动就落哪层
> 补丁不越界
> 新行为可验

# 08、演进

```text
[同一输入：新会话 + 一个模糊需求]
    |
    +--[V1] 手动复制文件 / 模型看不到 Skill，靠人反复提醒 / 代价：每次会话都要重新交代
    |
    +--[V2] 目录进仓库 + 入口 Skill 固定 / 模型按入口自解释 / 代价：多一层入口 Skill 的上下文开销
    |
[Trade-off]
得到：跨会话、跨成员一致的研发动作
失去：单次会话的启动开销与部分灵活性
边界：Skill 越多，清单越需要治理
```

正确性：V1 依赖人的记忆，V2 依赖仓库里的文件，后者可以被 Review。

稳定性：V1 的表现随会话波动，V2 的行为序列更容易复现。

复杂度：V2 多了一层目录约定和入口 Skill 的维护成本，这是它唯一的账。

成本：几乎为零，都是文本文件，随代码一起走版本管理。

适用范围：多人协作、需要长期沉淀方法论的项目收益最大。

遗留问题：Skill 数量上升之后，清单的排序与取舍还没有治理方案，这一点留到后面几招解决。

> 同一条输入
> 两条路分叉
> 一个要人手
> 一个要契约

# 09、洞见

## 9.1 文件不等于能力

反直觉判断：Skill 装没装好，和文件在不在没有关系，和读路径有没有配好有关系。判断一个 Skill 是否生效，唯一可靠的证据是新会话里的行为变化，而不是目录里有没有那个文件夹。

## 9.2 验证点要选在链路末端

反直觉判断：把验证点定在「复制成功」上，等于把验证点定在了链路最没有信息量的一环。验证点应该尽量靠近价值终点，也就是模型的行为。装得对不对不重要，用得对不对才重要。

## 9.3 目录约定是一种接口

一旦目录名被写进发现组件，它就不再是「随便放放」，而是接口。接口变更需要像改 API 一样走评审，因为改一个目录名，等于让所有依赖它的会话失效。

## 9.4 入口 Skill 解决的是选择问题

Skill 越多，模型越难选。一个固定的入口 Skill 把「选哪个」变成「按入口走」，这是治理，不是功能。它的价值不在内容多深，而在位置稳定。

> 反直觉之一
> 文件不是能力
> 反直觉之二
> 验证不是感觉

# 10、系统落地

原来有的：一份跑得起来的 DSH Web UI，一份散落在仓库里的 Skill 文件，以及一套靠人记的研发流程。

本篇新增的：一条明确的 Skill 目录约定，一次可复现的同步动作，一个基于新会话行为的生效判据。

现在能做的：新成员 clone 仓库、启动 Web UI，新会话里就能看到并使用约定好的 Skill 集合，不需要老人手把手带。

还缺的：Skill 清单的治理规则、入口 Skill 的版本策略、Skill 加载失败时的可观测信号。这三样决定了这套东西能不能撑到几十个 Skill。

下一步演进的方向是给 Skill 建立最小治理：目录里放什么、谁可以加、加了以后怎么验证。这属于工程约定，不需要新工具。

> 原来靠人工
> 现在靠目录
> 缺的是标准
> 下一步补它

# 11、小结

```text
Q1 → 复制文件不等于装好，生效判据是新会话里能看到目录项并真实加载
Q2 → 先跑通 Web UI 拿到可验证环境，再理顺 Skill 目录，顺序不能反
Q3 → 只看复制成功，代价是演示失败、信任受损、排查方向被带偏
状态 → 一套可复现的 DSH 与 Superpowers 接入及生效验证流程
```

> 三问皆有答
> 状态可交付
> 一装一验证
> 一招落地上

# 12、作业

## 12.1 理解题：为什么「文件复制成功」不能作为 Skill 安装完成的判据？

参考答案：文件复制只完成了一次写操作，而 Skill 生效依赖发现、发布、加载三段链路。写操作成功不代表发现组件扫描到了它，也不代表模型拿到了清单，更不代表加载后改变了行为。三段里任何一段断了，表现都是同一句「没有找到」。

## 12.2 实战题：在一个新项目里把 Superpowers 的 Skill 接入 DSH，并给出三条验证记录。

参考答案：先按官方文档确认约定目录，把官方 skills 同步进去并提交仓库；启动 Web UI 新建会话，记录三条证据：目录项列表、一次真实加载的返回、加载后模型行为的变化。三条都拿到才算完成，缺一条就是没装好。

## 12.3 排障题：目录项能列出来，但加载时拿不到内容，你的排查顺序是什么？

参考答案：先看条目下是否存在可读内容文件，再核对目录结构与官方仓库是否一致，然后确认读取路径与权限，最后才怀疑会话缓存。任何一步拿到证据之前，不做重启类操作，因为重启影响的是加载段，而故障大概率在发现段。

## 12.4 架构判断题：Skill 是不是越多越好？

参考答案：不是。清单越长，模型的选择成本越高，误选概率越大。Skill 的价值在于被正确使用，因此需要入口 Skill 与治理规则把数量控制在可维护的范围内。宁可少而稳，不要多而乱。

> 四题都照做
> 手上有实数
> 不抄现成论
> 只抄那方法

# 13、思考

这一篇真正解决的冲突，是「安装」这个动作在 Agent 工具链里被重新定义了。它不再是往容器里塞东西，而是让运行时知道去哪里读。

把这一点抽出来，就是一条可以复用的判断：凡是依赖发现的机制，验证点都必须放在被发现之后。文件、配置、清单，这些都只是前提条件，不是结果。

回到企业数字人项目，第 1 招交付的不是一个安装脚本，而是一条判据：新会话里能不能用得上。后面每一招，都要在这条判据之下展开。

> 一装辨真伪
> 一验定生死
> 一约成契约
> 一役见真章

我是老李，在某公司的平台组做研发效能。去年我们给企业数字人项目接了一套 Skill 化的研发流程，用的是插件清单那套老办法，安装脚本一跑，目录里多出几十个文件夹，谁看都觉得稳。

AI时代的Superpowers Skill教程17招-第1招-DeepSeek Harness怎么安装Superpowers并验证真的生效？

以老李的视角复盘 DeepSeek Harness 接入 Superpowers 的全过程，把验证点从文件复制挪到新会话行为，给出可复现的同步动作与生效判据。

架构师

人工智能

开发工具

架构设计

DSH安装Superpowers需三步验证：目录落地约定位置、新会话可列出Skill清单、真实加载后模型行为改变。复制文件不等于生效，验证点要放在链路末端，以新会话中的行为变化为准。先跑通WebUI再同步Skill目录，顺序不能反。

文件系统

代码解释

容器

Agent

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI时代的Superpowers Skill教程17招-第1招-DeepSeek Harness怎么安装Superpowers并验证真的生效？-腾讯云开发者社区-腾讯云

AI时代的Superpowers Skill教程17招-第1招-DeepSeek Harness怎么安装Superpowers并验证真的生效？

AI时代的Superpowers Skill教程17招-第1招-DeepSeek Harness怎么安装Superpowers并验证真的生效？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐