cangjie-skill 怎麼用：把書、影片和播客變成可執行 Agent Skills

很多人收藏了大量書、長影片和播客，最後只留下摘要，真正做事時仍然想不起該用哪條方法。cangjie-skill 的目標是把高價值內容轉換成 Agent 可以在具體場景呼叫的 Skills，而不只是壓縮成一篇讀書筆記。

專案地址：kangarooking/cangjie-skill

快速答案

適合輸入的材料包括：

• 書籍或完整章節；
• 有字幕或轉寫文字的長影片；
• 播客、訪談和課程文字稿；
• 方法論密集的長文和資料集。

如果材料只有觀點、新聞或情緒表達，沒有可驗證、可遷移的操作方法，就不適合強行做成 Skill。

它和普通摘要有什麼區別

普通摘要回答“這份內容說了什麼”，Skill 還要回答：

1. 什麼場景應該觸發；
2. 應按哪些步驟執行；
3. 哪些條件下不適用；
4. 容易和什麼方法混淆；
5. 如何用測試證明它真的可用。

專案採用 RIA-TV++ 流程，包含整體理解、並行提取、三重驗證、結構化構造、Skill 間連結、壓力測試和最終交付。

一次完整轉換會生成什麼

典型輸出不是單個 SKILL.md，而是一組檔案：

這套結構適合後續維護：更新原材料時，可以只重做受影響的 Skill，而不是重寫整份摘要。

推薦工作流

1. 先取得合法可用的原文、字幕或個人轉寫；
2. 清理廣告、重複片段和轉寫錯誤；
3. 明確希望解決的真實問題；
4. 讓 cangjie-skill 提取候選方法；
5. 刪除常識、單一案例和無法驗證的觀點；
6. 為保留的 Skill 增加觸發條件與邊界；
7. 用容易混淆的測試題驗證。

處理影片時，應先完成字幕提取或語音轉寫，再輸入純文字。不要讓 Agent 僅憑標題和簡介推斷整段內容。

什麼內容值得蒸餾

一份材料適合轉成 Skill，通常具備以下特徵：

• 包含可以重複執行的步驟；
• 給出了適用條件和反例；
• 方法能遷移到原案例之外；
• 原文有多處證據支援；
• 能回答“什麼時候用”和“什麼時候不用”；
• 可以設計測試驗證結果。

純新聞、個人感想、故事合集和缺少方法的觀點文章，通常更適合摘要或筆記。強行 Skill 化會生成看似正式、實際無法觸發的空殼規則。

輸入材料怎樣整理

書籍

儘量提供合法取得、結構完整的文字，並保留章節標題。掃描 PDF 應先做 OCR 抽查，修正頁首、腳註和斷行，否則提取器會把噪聲當正文。

長影片

優先使用官方字幕；沒有字幕時再做語音轉寫。保留時間戳有利於回查來源，刪除片頭廣告、重複口播和與主題無關的互動。

播客與訪談

標明說話人。方法論可能只代表某位嘉賓，不應被錯誤歸因於主持人或整個節目。

資料集

記錄每份來源的標題、作者、日期和許可。多來源內容尤其需要區分共同結論和互相沖突的觀點。

RIA-TV++ 七個階段詳解

1. 整體內容理解

先做結構、解釋、批判和應用四步拆解，生成 BOOK_OVERVIEW.md。這一步不是摘要比賽，而是建立後續提取所需的全域性上下文。

2. 並行提取

分別尋找框架、原則、案例、反例和術語。多視角能減少只提取醒目金句、忽略邊界條件的問題。

3. 三重驗證

候選方法至少需要多處獨立佐證、具有預測力，並且不是普通常識。大量候選在這裡被淘汰是正常現象。

4. RIA++ 構造

保留原文依據，用自己的話解釋，補充書中案例、未來觸發場景、執行步驟和適用邊界。一個可用 Skill 必須同時有做法和禁區。

5. Zettelkasten 連結

建立 Skill 之間的依賴、對比和組合關係，生成 INDEX.md。否則幾十個孤立 Skill 只會變成另一種收藏夾。

6. 壓力測試

設計正常題、邊界題和誘餌題。測試不僅要證明該 Skill 會觸發，也要證明在不適用時不會誤觸發。

7. 交付與安裝

生成 DIGEST.md、術語表、Skill 模組和測試檔案，再安裝到 Agent 的技能目錄。安裝前仍要人工複查版權、觸發範圍和指令碼許可權。

一個好的 SKILL.md 應包含什麼

至少應說明：

1. Skill 名稱和目標；
2. 明確的觸發條件；
3. 不應觸發的場景；
4. 輸入要求；
5. 可執行步驟；
6. 判斷與停止條件；
7. 輸出格式；
8. 來源與邊界；
9. 測試例子。

如果一個 Skill 只有一段“請認真分析並給出建議”的提示詞，它仍然是泛化提示詞，不是可靠的執行模組。

怎樣設計測試題

正向觸發

給出典型適用場景，檢查 Agent 是否正確識別並按步驟執行。

負向觸發

提供表面關鍵詞相似、實際不適用的任務，確認 Skill 不會搶佔其他方法。

邊界條件

刪除關鍵輸入、製造證據不足或目標衝突，檢查 Agent 是否會停止並請求補充資訊。

跨 Skill 混淆

讓兩個相關方法都看似可用，檢查 Agent 能否解釋選擇和組合順序。

test-prompts.json 應記錄預期觸發、預期拒絕和驗收點，而不是隻儲存幾個演示問題。

安裝到 Agent 前的審查

從書和影片生成的 Skill 也可能包含指令碼或外部連結。安裝前檢查：

• 是否引用大段受版權保護內容；
• 是否把個人隱私寫進示例；
• 是否要求讀取過寬目錄；
• 是否會上傳原始材料；
• 觸發描述是否會覆蓋無關任務；
• 是否存在無法驗證的作者歸因；
• 測試是否包含失敗路徑。

版本管理和更新

原材料更新、字幕修正或方法論被新證據推翻時，需要知道哪些 Skill 受影響。建議在每個模組中儲存來源定位和版本，並在 INDEX.md 維護依賴關係。

不要靜默改寫已經用於生產決策的 Skill。重要更新應記錄變更內容、原因和重新測試結果。

常見失敗模式

常見問題

可以把整本書直接公開成 Skill 嗎？

要考慮版權和許可。個人學習與公開分發是兩回事。公開倉庫應保留方法論抽取和必要短引文，避免複製大段受版權保護的原文。

為什麼生成了很多 Skill，卻沒有一個好用？

通常是篩選不夠嚴格。不是每個章節都值得變成 Skill。優先保留能跨場景遷移、具有明確步驟和邊界的少數方法。

一次應該處理多長的材料？

取決於模型上下文、文字質量和結構。超長材料應按章節處理，同時保留全域性 Overview；不能簡單切塊後讓各塊互不知情。

可以把多個作者的方法合成一個 Skill 嗎？

可以，但要標明共同點、衝突和各自證據。不要把互相矛盾的方法強行平均成一句空泛原則。

生成的 Skill 可以直接用於重要決策嗎？

不應未經驗證直接使用。投資、醫療、法律和安全等高風險內容需要專業稽核、最新資料和明確責任邊界。

從一段影片做 Skill 的實際例子

假設輸入是一段“如何覆盤專案失敗”的兩小時訪談。不要直接要求生成十個 Skills，可以這樣處理：

1. 取得字幕並保留時間戳、說話人；
2. 刪除廣告和重複寒暄；
3. 先生成訪談結構和主要論點；
4. 提取“失敗分類”“證據收集”“行動覆盤”等候選；
5. 檢查每個候選是否在訪談中有多處依據；
6. 把單一人物經歷降級為案例，不當作普遍規律；
7. 為每個方法補充適用專案規模與停止條件；
8. 設計“普通週報”“事故覆盤”“員工績效”等混淆題；
9. 只保留能正確區分場景的模組；
10. 生成索引、Digest 和來源定位。

最終可能只得到三個可靠 Skills，這比十五個缺少邊界的提示詞更有用。

交付前的質量評分

可以為每個候選按 0–2 分評估：

低分候選應回爐或刪除，不要為了保持數量降低標準。

如何與原作者觀點保持距離

Skill 應明確區分“原作者主張”“提取器解釋”和“可驗證操作”。有爭議或時代背景明顯的方法，要在邊界中寫明來源時間與反方證據。Agent 不應把一本書的觀點包裝成普遍事實。

總結

cangjie-skill 適合把“看過但用不起來”的內容改造成 Agent 工作流。質量關鍵不在生成數量，而在來源完整、驗證嚴格、觸發清楚，並且敢於淘汰不具備獨立價值的候選 Skill。