前言¶
做智能體開發的同行大概都處理過這類問題：一份很長的規範、手冊或流程文檔，希望智能體嚴格按裏面的規則辦事。直接整份塞進上下文，成本高，注意力也被稀釋；改用 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
