常见问题

September 6, 2026 · View on GitHub

本文收集 dsh-skill-forge 使用过程中的常见问题和解答。

安装与配置

安装后右侧边栏没有出现 Skill Forge 面板？

先确认以下几点：

插件是否成功安装：执行 dsh plugin --profile web list，列表中应有 dsh-skill-forge
DSH 版本是否符合要求：需要 0.1.0-rc.5 或更高版本
刷新浏览器页面，清除缓存后重试
打开浏览器开发者工具，查看 Console 中是否有报错信息

如果以上都正常但面板仍不出现，可以尝试重新安装插件：

dsh plugin --profile web remove dsh-skill-forge
dsh plugin --profile web add dsh-skill-forge

可以在多个 profile 中安装吗？

可以。每个 profile 的技能库和配置都是独立的，互不影响。安装命令中指定不同的 --profile 参数即可。

配置修改后需要重启 DSH 吗？

绝大多数配置项修改后即时生效，不需要重启。只有 workspaceRoot 涉及文件系统路径变更，修改后需要重启 DSH。

完整的生效时机列表见配置参考。

锻造流程

锻造一个技能需要多长时间？

通常在 30 秒到 2 分钟之间，主要取决于三个因素：

模型响应速度：不同模型的生成速度差异较大
迭代轮数：每增加一轮迭代，大约增加 20–40 秒
验证用例数量：验证阶段生成和执行测试用例的时间

默认配置下（3 轮迭代、5 个验证用例），大多数技能在 1 分钟左右完成。

锻造失败了怎么办？

锻造队列中点击失败的任务，可以看到具体的失败原因和错误码。常见情况和处理方式：

错误码	原因	处理方式
E101	提取阶段 LLM 调用失败	检查模型 API 是否正常，稍后重试
E102	提取结果 schema 校验失败	通常是模型输出格式问题，重试一次即可
E201	生成阶段 LLM 调用失败	检查 API key 和额度，稍后重试
E301	验证用例全部失败	技能草稿质量差，增加迭代轮数或降低通过阈值
E401	达到最大迭代轮数仍未通过	提高 `maxIterations` 或降低 `verificationPassThreshold`
E501	审计检测到危险模式	检查技能内容，确认安全后可手动强制批准
E502	检测到重复技能	查看已有技能，如需更新用 reforge 而不是新建

点击任务卡片上的「重试」按钮可以重新运行锻造流程。

自动触发太频繁/太不灵敏怎么办？

调整 triggerThreshold 配置项：

触发太频繁 → 提高阈值，比如从 0.3 调到 0.5
太不灵敏 → 降低阈值，比如调到 0.2

也可以直接关闭 autoTrigger，完全使用手动触发。如果使用增量式累积触发，还可以调整 densityThreshold 和 minForgingIntervalMinutes。

锻造的技能质量不高怎么办？

可以从以下几个方面优化：

提高验证阈值：将 verificationPassThreshold 从 0.9 调到 0.95
增加迭代轮数：将 maxIterations 从 3 调到 5，给 Refiner 更多优化机会
提高安全等级：设为 strict，审计阶段会更严格
提供更好的锻造输入：对话越完整、步骤越清晰，锻造出的技能质量越高
使用达尔文模式：对已有的技能启动达尔文进化，针对性优化低分维度
手动精修：批准后在技能库中手动编辑，补充遗漏的细节

技能库管理

技能文件存在哪里？

技能库默认保存在 DSH 第一个 workspace 路径下的 skills/ 目录中。也可以通过 workspaceRoot 配置项自定义存储路径。

每个技能是一个独立的目录，结构如下：

skills/
└── skill-name/
    ├── SKILL.md          # 当前版本的技能文件
    ├── versions/         # 历史版本
    │   ├── v0.1.0.md
    │   └── v0.2.0.md
    └── meta.json         # 元数据（状态、统计、来源等）

可以把技能库放到 git 仓库里吗？

完全可以。将 workspaceRoot 指向一个 git 仓库的路径，所有技能的版本变更都会以文件形式保存，方便用 git 做额外的版本追踪和团队协作。

注意 dsh-skill-forge 自身已经有版本管理功能，git 可以作为额外的备份和协作层。

技能会互相冲突或重复吗？

审计阶段会做重复技能检测。新生成的技能如果和已有技能的相似度超过阈值（strict 模式下 0.6，normal 模式下 0.8），会给出警告或直接拦截。

如果两个技能确实相似但用途不同，你可以在审核时手动批准。系统会在相似度检测结果中标注具体的重叠内容，帮助你判断。

如何归档不再使用的技能？

在技能库中找到目标技能，点击「归档」。归档后的技能：

不会被注入到对话中
不会出现在默认列表中（可以通过筛选查看）
文件仍然保留，可以随时「复活」恢复为激活状态

如果确定不再需要，可以删除。删除操作不可恢复，请谨慎操作。

什么是谱系追踪？

谱系追踪记录每个技能的完整家族树：

来源：这个技能是从哪段对话、哪次锻造中产生的
衍生技能：以这个技能为基础演化或融合出来的其他技能
相关技能：内容相似或适用场景重叠的技能

你可以在技能详情页查看谱系信息，也可以通过 API 查询完整的技能图谱。

智能注入

智能注入和全部注入有什么区别？

维度	全部注入 (`all`)	智能注入 (`smart`)
注入时机	启动时一次性注册	每轮对话前动态计算
Token 消耗	随技能数线性增长	受 token 预算限制
技能污染	技能多时干扰 Agent 判断	只注入最相关的技能
召回率	100%（所有技能都可用）	可能漏掉边缘相关的技能
适用场景	技能数 < 10 个	技能数 > 15 个

智能注入的评分是怎么算的？

综合得分是五个维度的加权和：

关键词匹配（40%）：用户消息与技能内容的词汇重合度
验证得分（30%）：技能最近一次验证的综合质量分
使用频率（10%）：历史使用次数的归一化值
新鲜度（10%）：最近使用时间的衰减值
反馈得分（10%）：用户显式 + 隐式反馈的归一化得分

五个维度分别计算 0–1 的分数，按权重相加得到最终得分，再从高到低排序。

为什么有时候我觉得相关的技能没有被注入？

可能的原因：

token 预算用尽：排在前面的技能已经用完了预算。可以调高 tokenBudgetRatio 或 injectionTokenBudget
相关度低于阈值：技能评分低于 injectionRelevanceThreshold。可以适当调低阈值
关键词匹配度低：用户消息中的关键词和技能描述差异较大。可以手动编辑技能，补充更多同义词和相关关键词
反馈拉低了权重：如果该技能收到较多负反馈，权重会降低。可以重置反馈统计

安全相关

自动生成的技能安全吗？

dsh-skill-forge 设计了四层安全防御：

生成时安全：Generator Agent 的 system prompt 中包含安全约束，禁止生成危险操作的技能
验证时安全：Verifier Agent 会检查技能内容是否包含危险模式
入库时安全：SecurityAuditor 做正则匹配 + 相似度检测，拦截危险和重复技能
使用时安全：所有自动生成的技能默认需要人工批准才能激活，不会自动生效

默认配置下，没有任何技能能不经人工审核就进入激活状态。

危险模式检测会误报吗？

有可能。一些合法的运维或调试操作可能匹配到危险模式（比如包含 rm 命令的清理脚本）。遇到误报时：

仔细检查技能内容，确认确实安全
在审核弹窗中手动批准（normal 及以下安全级别）
将该模式的变体添加到技能内容中时注意写法

strict 模式下误报率较高，normal 模式下平衡了安全性和误报率。

达尔文/饕餮/共进化模式会破坏现有技能吗？

不会。所有进化模式都遵循严格不回退原则：

每次变更都会生成新版本，旧版本完整保留
新版本必须通过验证且得分不低于旧版本才会被接受
连续多轮无进步会自动停止，不会无限循环
默认所有进化结果都需要人工批准，不会自动修改激活技能
Dreaming 模式永不自动删除技能

进化模式

达尔文模式和普通锻造有什么区别？

普通锻造是从零开始生成一个新技能，达尔文模式是对已有技能做定向优化：

只优化低分维度，高分维度保持不变
每轮只做小范围变异，不做整体重写
有 ratchet 机制确保质量严格不回退
适合对已在使用的技能做渐进式改进

饕餮模式（技能融合）什么时候有用？

当技能库中出现多个内容相似但各有侧重的技能时，饕餮模式可以将它们融合成一个更全面的技能：

自动检测高相似度技能对
五阶段融合流程（对齐 → 合并 → 去重 → 优化 → 验证）
沉淀成功的融合模式到模式库
融合失败自动回退，不影响原技能

共进化模式（CoEvo）有什么特别之处？

共进化让技能和测试套件双向进化：

奇数轮进化技能，让技能能通过更多测试
偶数轮进化测试套件，让测试能测出更多问题
双方互相博弈，共同提升
测试套件强度评估，弱用例自动淘汰
适合对质量要求极高的核心技能

这些进化模式消耗 token 多吗？

是的，进化模式比单次锻造消耗更多 token。粗略估计：

达尔文模式：10 轮约 30k–50k token
饕餮模式：一次融合约 20k–40k token
共进化模式：10 轮约 50k–80k token

建议在 Dreaming 闲时锻造中开启这些模式，利用空闲时间批量优化。

Dreaming 闲时锻造

Dreaming 模式会在什么时候运行？

有三种触发方式：

定时触发：按 dreamingSchedule 的 cron 表达式定时运行
空闲触发：DSH 空闲超过 dreamingIdleThresholdMinutes 后自动运行
手动触发：在设置面板或通过 API 手动触发

Dreaming 会做什么？

每次闲时锻造会执行以下任务：

健康体检：扫描技能库，生成质量分布、使用率、僵尸技能、重复率报告
批量优化：对质量分低于阈值的技能，调用达尔文模式批量优化
自动融合：检测高相似度技能对，调用饕餮模式融合
改进建议：生成改进建议列表（零 LLM 消耗，纯启发式）

所有操作默认都需要人工批准，不会自动修改激活技能。

Dreaming 会影响正常使用吗？

不会。Dreaming 有并发限制（dreamingMaxConcurrentOptimizations），并且会检测 DSH 是否在使用中。有活跃对话时会自动暂停，等空闲后再继续。

性能与资源

锻造会消耗很多 API token 吗？

一次完整的锻造流程大约消耗 8k–20k token，具体取决于：

源对话的长度
生成的技能长度
迭代轮数（每轮增加约 3k–5k）
验证用例的数量和复杂度

默认配置下，一次锻造大约 10k–15k token。

闲时锻造会不会消耗大量 token？

闲时锻造会扫描历史对话批量处理，token 消耗确实比单次锻造高。建议：

根据历史对话总量估算消耗，设置合理的调度频率
初次批量处理时限制每次处理的对话数量
处理完历史积累后降低频率，比如每周一次

技能很多会拖慢 DSH 吗？

智能注入模式下，技能数量对性能的影响很小。每次召回只做关键词匹配和排序，计算量可以忽略。

全部注入模式下，技能数量较多时会增加每轮对话的 token 消耗，但不会影响 DSH 本身的运行速度。

开发与扩展

如何参与开发？

欢迎贡献代码。仓库地址：https://github.com/Epiphany-Leon/dsh-skill-forge

git clone https://github.com/Epiphany-Leon/dsh-skill-forge.git
cd dsh-skill-forge
pnpm install
pnpm build
dsh plugin --profile web add .

开发过程中可以用 pnpm dev 监听文件变化自动重新构建。

可以自定义 Agent 的 prompt 吗？

目前版本的 system prompt 内置在代码中，后续版本会支持自定义 prompt 模板和第三方 Agent 接入。如果你有特定领域的锻造需求，可以提 Issue 讨论。

支持哪些模型？

理论上支持 DSH 接入的所有对话模型。不同模型的锻造质量会有差异，建议使用至少 70B 参数或同等能力的模型，以保证提取和生成的质量。

验证和迭代阶段对模型的推理能力要求更高，较弱的模型可能会出现验证不准确、迭代不收敛的问题。

有哪些 HTTP API 可用？

插件暴露了 50+ 个 HTTP API，主要分组：

技能管理：列表、搜索、详情、版本、回滚、编辑、删除、归档、反归档
锻造控制：触发、取消、重试、队列、详情、批准、驳回
统计数据：基础统计、详细统计、健康报告
进化模式：达尔文启动/停止/状态、饕餮融合、共进化控制
Dreaming：启动、停止、状态、建议
配置：获取、更新
文件浏览：文件树、文件内容
技能编排：分解、匹配、执行

具体 API 列表可以通过查看 src/services/routes.ts 源码获取。

其他

和 dsh-forge 有什么区别？

dsh-forge 是 DSH 生态中较早的技能自锻造插件，验证了从对话轨迹提炼技能的可行性。dsh-skill-forge 在其基础上做了几个关键的差异化设计：

多 Agent 协作：五个专职 Agent 分工协作，替代单一大模型调用
七层质量门：提取、生成、验证、迭代、审计、批准、激活，全流程工程化管控
验证驱动迭代：验证不通过时自动迭代优化，不是一次生成了事
完整谱系追踪：每个技能带完整的来源、版本、验证、反馈记录
智能召回引擎：五维加权评分 + token 预算，替代全量注入
四层安全体系：覆盖生成、验证、入库、使用全生命周期
进化模式：达尔文爬山、饕餮融合、共进化、闲时锻造，持续自我优化