工作清單｜Token省下51倍！book-to-skill三步驟把技術書變AI技能

逐字稿文字預覽

今天我們要深度解析 GitHub 上的一個熱門專案：
book-to-skill，
一個能把任何技術書籍 PDF
轉換成 AI 代理專屬技能的 Python 工具。
它讓開發者不用再對著整本書搜尋或擔心 AI 幻覺，
只需按需載入相關章節，
就能大幅節省 Token
並隨時取用專家級知識。
一本厚達五百頁的技術書,讀完之後三個月
還記得第七章在講什麼嗎?
多數人的答案是搖頭。
有一個剛在 GitHub 上竄紅的專案,
選擇用程式碼來解決這個記憶力的老問題。
而且效果好到什麼程度?
查詢一本書的成本,
直接砍到只剩二十四分之一,
甚至五十一分之一。
它是怎麼辦到的,
值得花幾分鐘拆解一下。
這個專案叫做 book-to-skill,
開發者是 virgiliojr94,
用 Python 打造。
目前累積了兩萬四千六百三十七顆星,
光是最近一天就新增了四百一十七顆,
Fork 數也來到兩千五百七十八。
它的定位很直白,
就是把任何一本技術書的 PDF 檔案,
轉換成 AI 助理可以隨時呼叫的技能,
官方稱之為 Agent Skill。
不管是用 GitHub Copilot CLI、Amp,
還是 Claude Code 這類 AI 程式助理,
都能讀取它產生出來的同一種格式。
從星數成長曲線來看,
這顯然戳中了大量開發者的日常痛點。
問題出在哪?
把整本書丟給 AI 這件事,本身就很不划算。
技術書動輒數十萬字,
如果每次提問都要把全書塞進 AI 的上下文視窗,
代價是天文數字的運算成本,
也就是所謂的 token 消耗。
token 可以理解成
AI 處理文字時計價的最小單位。
更麻煩的是,
AI 常常會因為資訊量過大而產生幻覺,
一本正經地編造書裡根本沒寫過的內容。
過去開發者的解法無非三種:
搜尋 PDF 關鍵字,
只換來一堆頁碼;
直接問 AI,常常得到錯誤答案;
手動做筆記,
往往寫完就束之高閣。
book-to-skill 的切入點是換一個層次思考。
與其每次查詢都重新翻書,
不如把整理書本結構這件苦差事只做一次,
之後的每一次提問,
都站在這個結構之上快速取用。
它的架構分成兩個階段。
第一階段是一個確定性的萃取器,
負責把 PDF、EPUB、DOCX 等各種格式的原始檔案,
轉成乾淨的純文字與章節資訊。
遇到不同類型的書,
還會自動挑選最適合的解析工具,
比如文字為主的書
用速度快的 poppler,
含有大量表格和程式碼的技術書,
則改用能保留版面結構的 docling。
第二階段才是真正的核心,
交由 AI 代理本身,
根據專案內建的 SKILL.
md 規格書,
把萃取出來的文字提煉成一份結構化知識庫。
包含核心心智模型、
每章獨立的檔案、術語表和速查表。
可以把整個過程想像成
請一位專業編輯,
先把厚重的原文書拆解
重組成一套索引卡片。
AI 平常只翻閱那張總目錄卡片,
等到真正被問到某個具體主題,
才抽出對應的那一張細節卡片來讀。
這種按需載入的機制,
正是省下大量 token 的關鍵。
官方測試數據顯示,
相較於把全書塞進上下文,
這種做法能省下二十四到五十一倍的成本。
值得一提的是,
整個提取過程完全在本機執行,
原始檔案不會被上傳,
對隱私要求高的使用者是一大保障。
最直接的使用情境,
是開發者讀完一本架構設計
或效能調校的技術書後,
或效能調校的技術書後,
把它轉成技能。
之後寫程式
遇到相關概念,
直接在終端機打一行指令
就能叫出書中對應章節的內容
不用再翻書找頁碼。
它的應用範圍其實不止書籍。
企業團隊可以把內部的架構
決策紀錄、上線手冊
整個資料夾丟進去,
變成新人能隨時查詢的知識庫;
設計團隊也能把品牌指南轉成技能,
確保大家講的是同一套規範;
研究人員甚至能把一疊論文
合併成單一技能
做跨文件的比對分析。
上手門檻不算高,
一行安裝指令加上指向檔案路徑,
對熟悉命令列的開發者來說
幾乎沒有學習曲線。
但如果原始檔案是掃描版、
沒有文字層的 PDF,
就得先自行跑過光學文字辨識,
也就是 OCR,才能進入流程。
從目前能蒐集到的社群討論來看,
正面評價占了絕大多數。
不少使用者形容用起來像是解鎖了作弊碼,
終於把讀過就忘的書,
變成能隨時查詢的工具。
技術部落格普遍認可
它省下大量 token 成本的實測數據,
也肯定它同時支援多個主流
AI 助理平台的開放標準設計。
零星的提醒則集中在 PDF 轉換品質上,
有使用者反映,
如果原始檔案排版複雜,
抽取出來的結構可能不夠精準,
進而影響最終技能的表現。
往深一層看,
這個專案真正動搖的
不是某個工具
而是開發者累積知識的方式。
過去讀書筆記寫完就死在資料夾裡,
現在它變成能被 AI 主動調用的活資產,
這對強調長期學習與知識複利的工程師文化,
會有實質推動力。
但風險也不容忽視。
整個生成品質
高度仰賴背後 AI 模型的指令理解能力,
一旦模型版本更新或表現波動,
產出的技能品質可能跟著起伏,
而這是專案自身無法完全掌控的變數。
另外,
它高度依賴外部解析工具的穩定性,
一旦這些第三方工具介面或格式出現變動,
維護成本會隨之上升。
長期來看,
如果能持續打磨章節邊界偵測的準確度,
它有機會成為技術社群整理知識的
標準工作流程之一。
book-to-skill 真正的價值,
不在於又多了一個 PDF 轉換工具,
而在於它示範了
如何把一次性的結構化成本,
換成長期可重複調用的知識資產。
對經常需要回頭查閱厚重文件的開發者而言,
這種一次投資、
長期省力的思路,
值得認真評估,
納入日常工作流程。

來源：transcript.txt

本次執行流程與問題處理

下達指令
指令：videonote https://youtu.be/yRQSHUfVi24?si=XT9hjaPNWDbPXrvT --language zh --adopt-source-subtitles

來源：https://youtu.be/yRQSHUfVi24?si=XT9hjaPNWDbPXrvT

辨識語言：zh ｜參數：--language zh --adopt-source-subtitles
預期流程
依指令產生的處理順序：
1. 採用來源字幕（略過語音辨識）
2. 來源選擇與品質檢查
3. 文字校正與句子單元
4. 筆記與發布
5. 公開網頁發布
1. 下載與語音辨識
工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）
處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿
產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）
耗時：3.4 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：10.4 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.5 秒
關係：依序執行
結果：完成
4. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.5 秒
關係：依序執行
結果：完成
5. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.5 秒
關係：依序執行
結果：完成
6. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.6 秒
關係：依序執行
結果：完成
7. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.6 秒
關係：依序執行
結果：完成
8. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：96.4 秒
關係：依序執行
結果：完成
9. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.5 秒
關係：依序執行
結果：完成
10. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：0.6 秒
關係：依序執行
結果：完成

手動來源字幕

reference_subtitle.txt 下載5,862 bytes
reference_subtitle.vtt 下載10,892 bytes

自動來源字幕

source_subtitles.clean.json 下載31,851 bytes
subtitle_acquisition.json 下載960 bytes

Whisper 字幕

尚未產生

Qwen 字幕

尚未產生

Parakeet 字幕

尚未產生

MOSS 字幕

尚未產生

聲學時間證據（PyAnnote / WhisperX）

尚未產生

校正前後逐字稿

校正前 transcript.source.json 純文字 JSON 5,862 / 41,089 bytes
校正後 transcript.presegmentation_corrected.json 純文字 JSON 5,891 / 41,576 bytes

目前待解決問題與初步改善方向

⚠️ 全文快速校讀：已套用暫定修正，請確認待修正
segment=20 已先套用暫定修正：開發者是 virgiliojr九四, → 開發者是 virgiliojr94,；segment=89 已先套用暫定修正：是開發者讀完一本架構設計 → 是開發者讀完一本架構設計或效能調校的技術書後,；segment=89 待確認：原文「讀完一本架構設計」語意不通，「架構設計」應為書籍類型或主題，而非動作的直接受詞。推測原意為「讀完一本關於架構設計或效能調校的技術書後」，或「讀完一本架構設計或效能調校類的技術書後」。此處修正為補足語意，若原意為「讀完一本，針對架構設計或效能調校的技術書」則需確認，但基於上下文「把它轉成技能」，推測是形容書籍內容。；暫定：是開發者讀完一本架構設計或效能調校的技術書後,
逐字稿可先使用，但有待校正清單待修正
segment=1 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語；segment=4 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語；segment=5 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語；segment=70 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語；segment=89 embedded_newline: 逐字稿段落含換行，無法保證字幕單行；segment=111 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語；segment=157 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語；segment=89 rapid_semantic_review: 全文速讀上下文判斷；尚未回聽或交叉比對
Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。
音訊下載不穩定，需更新 cookies / PO token 後重試精進模式。

進一步精進字幕與筆記
使用 Workbench 上傳校正字幕、中文參考稿或回饋 SRT，重新產生雙語與學習單元。
開啟 Workbench

逐字稿文字預覽

本次執行流程與問題處理

下達指令

預期流程

1. 下載與語音辨識

2. 全文快速校讀

3. 建立句子單元

4. 時間軸稽核

5. 品質檢查

6. 播放時間軸回填

7. 來源句整理

8. 生成筆記摘要

9. 建立筆記頁面

10. 發布公開頁面

手動來源字幕

自動來源字幕

Whisper 字幕

Qwen 字幕

Parakeet 字幕

MOSS 字幕

聲學時間證據（PyAnnote / WhisperX）

校正前後逐字稿

目前待解決問題與初步改善方向