前言¶
做智能体开发的同行大概都处理过这类问题：一份很长的规范、手册或流程文档，希望智能体严格按里面的规则办事。直接整份塞进上下文，成本高，注意力也被稀释；改用 RAG，检索回来的片段往往只剩知识点，流程和约束被打散，智能体每次都要从散落的原文里重新推断「该做什么、不该做什么」，行为不够稳定。
问题的根源在于：文档是写给人看的，技能是给智能体执行的，两者之间缺一道转换工序。在 DSH「一切皆插件」的思路下，这道工序本身也可以做成 skill。下面介绍的 satan9394/dsh-doc-compiled-skills，做的就是这件事：把文档预先编译成可执行技能，而不是每次运行时现场检索。
这是什么¶
dsh-doc-compiled-skills 是一个 DSH skill，作者 satan9394，在社区目录里归入「工作流」类。目录页给它的定位是：把文档预编译成可执行技能，内容涵盖「提取→分类→按需揭示」「预编译 vs RAG」「动作/选择/护栏结构化」，思路受 MicrosoftDocs/Agent-Skills 启发。
需要先交代资料边界：截至本文写作（2026-09-07），该仓库的 README 未能成功抓取，上面这些描述来自社区目录页的介绍，没有和 README 原文逐条核对过。目录页显示的星标等数据也可能已有变化。下文围绕目录页描述的方法展开，具体实现以仓库内容为准。
它覆盖的三个部分¶
按目录页的描述，这个 skill 围绕「文档 → 技能」的编译过程组织，主要讲三块内容。
提取、分类、按需揭示¶
先做提取，把文档里的规则、流程、约束从叙述性文字里拆出来；再做分类，按用途归组；最后用按需揭示的方式组织结果——智能体平时只加载概要，执行到具体环节时再展开对应细节。这样常驻上下文的只是必要部分，而不是整份文档。
预编译 vs RAG¶
skill 里把两条路线放在一起对比：预编译是在构建期把文档转成技能，运行时按需加载；RAG 是运行时按查询去检索原文片段。前者换来的是行为更确定、运行时开销更小，代价是要维护一道编译工序；文档频繁变动时，重编译的频率也要算进成本。这个对比的用途，是帮你判断手头的文档适合编译成技能，还是适合交给检索。
动作、选择、护栏的结构化¶
编译的目标不是生成摘要，而是结构化：动作对应「该做什么」，选择对应「遇到分支怎么判」，护栏对应「什么不能做」。原文里的自然语言描述，经过这一步变成边界清晰、可执行的条目，智能体照着走即可，不需要每次重新理解整篇文档。
安装与启用¶
截至 2026-09-07，能拿到的资料里没有可核实的安装命令：README 抓取失败，目录页也没有给出可直接复制的命令，所以这里不臆造一条。安装前建议先做两件事：
1、打开 GitHub 仓库，从 README 确认当前的安装方式和文件结构：https://github.com/satan9394/dsh-doc-compiled-skills
2、到社区目录页核对介绍与分类：https://www.skillhub.cn/plugins/satan9394/dsh-doc-compiled-skills
另外，目录与抓取结果里都没有核实到许可证信息，商用或二次分发前务必先到仓库确认授权条款。
适用场景与注意¶
适合的场景：手头有相对稳定的长文档——规范、操作手册、流程约定——需要智能体长期遵守；希望行为可预期，而不是每次检索后现场推断；并且愿意维护一道「文档变更 → 重新编译」的工序。
不太适合的情况：文档高频变动、没有人手维护编译产物。这类场景下，直接检索原文可能更省事，仓库里「预编译 vs RAG」的对比部分也是为此准备的。
注意事项：
1、skill 安装后会以当前 dsh 进程的权限运行，启用前先通读源码，确认没有超出预期的操作；
2、许可证未核实到，使用前到仓库确认；
3、本文的功能描述来自社区目录页，未能与 README 原文交叉核对，一切以仓库最新内容为准。
顺带说明背景：文中提到的社区目录是独立站点，与 DeepSeek、幻方没有官方从属关系；DSH 的插件生态由社区贡献，本文介绍的 skill 是其中之一。
小结¶
经过上面的步骤可以看到，dsh-doc-compiled-skills 的价值在于把「文档 → 技能」这道工序方法化：提取、分类、按需揭示，以动作、选择、护栏的结构落地，并给出与 RAG 的取舍判断。项目目前还很早期，目录页显示的星标为个位数且可能已有变化，实际能力以仓库内容为准。
仓库地址：https://github.com/satan9394/dsh-doc-compiled-skills
目录页：https://www.skillhub.cn/plugins/satan9394/dsh-doc-compiled-skills
