NotebookLM

從碎片到建築師：第九章的「定錨」與人機協作實錄 日期：2026-02-11 座標：數位書本施工現場 / 第九章 NotebookLM 對位完成日 這兩天，我與 AI 助手 Antigravity 共同完成了《個人賦能》第二篇 Step 2 —— 關於 NotebookLM 的全部練習設計（9.0 - 9.14）。如果說第八章的 Gemini Web 訓練是為了建立「手感」，那麼第九章則是真正的「硬核工程」，目標是教導讀者如何建立一座具備證據支持的知識堡壘。 以下是本次施工現場的四個核心紀錄： 🎨 1. 語氣的權威來自「在地體感」 在施工初期，AI 產出的內容雖然結構正確，但總帶著一股揮之不去的「官腔」。我對 Antigravity 下了一個強硬的指令：「我要這本書聞得到台灣實戰現場的味道。」 我們開始進行大規模的「口語校準」。我們談**「眉角」、談「懶人包」、談「乾貨」。我們將資訊處理比喻為「脫水」，將靈魂對話描述為「活魚」與「死魚」**的交鋒。 當 AI 能夠像一個深耕現場的專家一樣，說出「主動尋求打臉（紅軍測試）」或「政論節目降維打擊」時，這本書的權威感才真正成形。賦能不是高深莫測的術語，而是要在捷運上、在會議室中都能立即呼喚出來的數位本能。 🧱 2. 從「暫態」到「正規」的進化路徑 第九章的撰寫過程經歷了激烈的動態演化。最初，為了捕捉隨機湧現的靈感，我們保留了許多「暫態編號」（如 9.1a, 9.2b）。隨著練習題從 10 個自然加厚到 13 個，結構開始出現過荷。 今天早上，我們執行了一場**「結構正規化工程」**。這是一個極具象徵意義的時刻：將探索期的靈活性，轉化為交付期的嚴謹性。我們廢除了所有暫代編號，重推為正式的 9.1 到 9.14。 這個過程不只是改改檔名，而是重新梳理了讀者的認知進階：從**「物理定錨」開始，經過「形態幻化」，最終抵達「數位人格鏡像」**。沒有這場正規化，高品質的教學內容就只能是一堆雜亂的技巧堆疊。 ⚡ 3. 精彩的「人機補位」瞬間 今天的施工現場發生了一個極具啟發性的插曲：在執行批量重新命名的 shell 腳本時，因為系統環境的微小延遲，自動化指令卡住了。 在對話框的那一頭，我沒有在那裡乾等 AI 自我修復，而是直接接過了鍵盤，手動輸入了那一串 mv 命令。 這個動作意外地呼應了本書的核心價值：AI 負責邏輯推演示範，而人類負責最終的環境瓶頸突破。 這種「誰慢了，另一方就補上去」的同步律動，正是未來高效能協作的縮影。我們不再是單向的指令下達者，而是與 AI 同步演化的聯軍。 🏛️ 4. 結語：我們正在蓋一座房，而房中有證據 第九章完稿後，施工日誌上記錄下了 Part 21 里程碑。 ...

「Skill 優先」的 AI 協作新實踐：從需求定義到知識點萃取的自動化進化 🚀 序言：一個新的協作節奏 在過去的 AI 協作中，我通常是先遇到問題，發出指令，解決之後再考慮是否要將它整理成工具。但這一次，我試著調換順序：先說出一個「Skill」的構想，定義它的通用流程與腳本格式，然後直接用它來演練並修正。 這次的目標是：如何高效地將長達一個多小時的「哈爸實驗室雙周會」錄影，拆解成一個個有價值的「知識點 (Knowledge Points)」。 🏗️ 第一步：Skill 的定義與構建 (Defining the Skill) 與其說「幫我切影片」，我對 AI 下達的指令是：「我們來做一個 knowledge-point-distiller Skill」。這個 Skill 必須具備以下完整閉環： 影音處理自動化：能根據時間清單自動切割影片，並同步產出適合 NotebookLM (容量 < 20MB) 的優化 MP3。 資源歸檔結構化：每一個知識點 (KP) 都有自己的資料夾，包含 MP4 片段、MP3 音訊與 metadata.md。 SOP 化：將整套流程寫入 .agent/skills/ 目錄下的 SKILL.md，讓 AI 與我都能隨時查閱操作標準。 這種「先建工具，後打仗」的做法，讓我在還沒開始處理影片前，就已經擁有了整套「生產線」。 🧪 第二步：實戰演練與即時修正 (Practice & Refinement) 有了工具後，我們直接拿「2/6 哈爸實驗室雙周會」進行測試。這個階段的「修正」是重點： 全場音訊的需求：在切割子片段的過程中，我發現除了個別知識點，我也需要一份「全場完整錄音」上傳到 NotebookLM 進行全局綜整。於是，我們立刻將這個功能補進 Skill 的 SOP 中。 與 Git 的整合：歸檔不是終點，提交才是。我們在 Skill 流程中補上了 GitHub 的 Commit 與 Push 指引。 跨 Skill 調度：在這個過程中，新的 Skill 自動調用了先前的 media-processor Skill 來處理高品質音訊壓縮，展現了技術模組之間的協同能力。 💡 關鍵體驗：為什麼「先說出 Skill」很有用？ 這是我第一次嘗試「先定義、再運作、後修正」的模式，心得如下： ...

這不是一本傳統方式寫成的書。它始於一段散亂的口語錄音，透過 NotebookLM 的萃取技術，轉化為核心觀點清單，最終生長出完整的書籍架構。這篇文章紀錄了這個「從聲音到結構」的 AI 協作過程。

在繁忙的工作與移動中，最珍貴也最易逝的是那些「隨口說出」的靈感。最近我實驗了一套流程，成功將散落在手機錄音中的碎片思緒，轉化為生產力工具中實實在在的待辦事項。 這不只是一個工具鏈的組合，更是一場關於思緒如何被抽象化、結構化並最終落地的過程。 🛠️ 思緒落地的三階進化 1. 捕捉：低阻力的語音隨筆 在開車或行走時，順手用手機錄音直接錄下四段對話與想法。這些內容通常是發散的、充滿口語贅字，但包含了最原始的戰略直覺。 關鍵工具：手機錄音、NotebookLM。 抽象化：將音訊數位化，並利用 AI 跨越語音雜訊，提取出「執行摘要」。這一步是將「感性直覺」轉化為「理性文字」。 2. 展開：與 Agent 的對話與批判 單純的摘要只是死資料，真正的價值在於「追蹤展開」。我將摘要轉入 Antigravity (我的 AI Agent)，開始一段深度的對話。 互動過程：AI 根據摘要提出升級計畫 (Proposal)。在這個階段，人類扮演的是「裁判」的角色——判斷哪些點子目前要執行的（如虛擬 COE 指揮官），哪些則是需要暫緩或歸檔的。 抽象化：將「初步想法」轉化為「具體計畫」。這是一個過濾、分類與權重分配的過程。 3. 落地：ATC 任務帳本系統的建立 最後，也是最具突破性的一步：我們意識到，如果計畫只存在於對話紀錄中，它依然會隨著視窗關閉而消失。 解決方案：我與 AI 協作，在 GitHub 環境中建立了一個持久化的任務帳本——tasks/TASKS.md。 Agentic 互動：這不再是傳統的 Todo 清單。我們定義了 ATC (Agentic Task Context) 規範。AI 不僅是「記錄者」，更是「維護者」。它會自動將對話中被暫緩的點子塞進 Backlog，將正在執行的標記為 Ongoing。 抽象化：將「離線計畫」轉化為「在線上下文」。任務檔案變成了 AI 每次啟動工作的「記憶點」。 💡 核心洞見：從「對話」到「狀態」 這次實作讓我明白，與 AI 協作的終極態樣不是不斷地開啟新對話，而是建立一個共享的「狀態帳本」。 手機錄音是捕捉靈感的感測器。 NotebookLM 是粗略的過濾器。 Antigravity 是精確的執行器。 TASKS.md 則是兩者共享的記憶體。 當這條路徑被打通後，我驚覺自己產出的點子不再是遺落在錄音筆裡的塵埃。透過 Agent 的「手」和持久化的「儲存空間」，靈感開始具備了自我演進的生命週期。 這就是我們在轉型路徑中追求的——讓 AI 成為一個不間斷的思緒延伸器，讓每一個隨口說出的想法，都能找到它的數位歸宿。 🤖 AI 協作宣告 本文內容: 由哈爸口述核心脈絡與經驗，由 Antigravity 整理結構、進行內容抽象化並潤飾成文。 背景脈絡: 本文生成的動機，即源自於本對話中剛建立的 tasks/TASKS.md 實踐過程。

在「哈爸實驗室」的社群架構中，Wing Group（側翼組） 扮演著知識萃取與支撐的關鍵角色。很多人會問：側翼組具體要怎麼「動起來」？ 我們摸索出了一套極低門檻、高度自動化的運作模型。不疊床架屋，而是利用現有的 AI 工具，將每一次雙周會的「閃電分享」精煉成可長久留存的數位資產。 Wing Group 概念緣起 「企業生成式 AI 轉型全書：從知識底座到自主代理人的實踐路徑」- 5.3 AI 卓越中心 (CoE)：驅動轉型的跨部門中樞架構 中的一個推動企業賦能AI的慨念 🚀 Wing Group 的核心操作流程 這套流程的核心理念是「切片、轉換、賦能、歸檔」。 1. 內容切片 (Clipping) 每次雙周會長達一小時以上，包含了多個不同主題的閃電 Demo。 作法：Wing Group 成員不處理整場會議，而是針對某個「特定分享」進行截取。 價值：將長篇內容碎片化，讓每個分享都能獨立成為一個知識單元。 2. 轉檔與優化 (Audio Processing) 將錄影檔轉為 AI 最好消化的格式。 工具：使用我們發展出的錄音最佳化工具（如 mp4-to-mp3 腳本）。 目的：產生體積小、人聲清晰的 MP3，方便快速上傳至雲端 AI 調用。 3. NotebookLM 知識賦能 (AI Input) 這是整個流程的大腦。 匯入：將音檔匯入同一個 NotebookLM 專案。 代號管理：在 NotebookLM 裡面給予每個分享一個專屬代號（例如 S1）。 產出：利用 AI 產生摘要、結構化圖表以及初步的投影片大綱。 4. 數位歸檔 (Archiving) 最後將這些成果放入檔案庫。 成果物：分享投影片、錄影、分享摘要 Markdown + 一張視覺摘要圖 + 一個AI 投影片+ 一套歸檔代號。 意義：以後社群成員想找某個技術點，只要在WingGroup index 文件搜尋，就能取得，而不需要回去翻整小時的錄影。 💡 為什麼這是一個成功的運作模式？ 這套模式解決了社群經營的三大痛點： ...

在「哈爸實驗室」雙周會 #1 結束後，我嘗試建立了一套「低阻力」的會議後處理流程。目標很明確：不要讓產出會議記錄變成一種負擔，而是透過 AI 工具鏈，在幾分鐘內完成從音訊到 GitHub 存檔的全部動作。 以下是這次實戰的完整工作流： 🛠️ 五步驟 AI 自動化工作流 1. 音訊最佳化：從 MP4 到 Optimized MP3 會議是在 Google Meet 上進行錄影，產出的 MP4 原始檔通常很大（數百 MB），且不便直接上傳 AI 工具。 作法：我使用自製的 media-processor Skill，透過 ffmpeg 自動計算最佳位元率（Bitrate），將影片轉為單聲道、小於 20MB 的 MP3 檔。 關鍵點：這樣的大小最符合 Google NotebookLM 的上傳限制，且能保持語音的清晰度。 2. 建立 AI 脈絡：Agenda 與共筆雜記 AI 需要「背景知識」才能寫出好的紀錄，而不僅僅是逐字稿。 準備：我準備了預定的議程（Agenda）以及在會議中隨手記下的「成員自我介紹雜記」。 角色賦能：告訴 AI 位講者的背景（例如志全的水利專業、Jimmy 的軟體背景），這讓 AI 在辨識聲音與觀點對位時精準度大幅提升。 3. NotebookLM 的深度提煉 將 MP3 與背景雜記上傳至 NotebookLM。 Prompt 策略：不直接使用內建摘要，而是下一段特定的 Prompt，要求 AI 根據「議程框架」去搜尋錄音中的對應片段，並特別強調「Demo 亮點」與「跨界觀點的連結」。 成果：AI 成功抓住了關於「水利編碼有碼無座標」的痛點，以及對 AI Agent 協作中「Human-in-the-loop」的精彩討論。 4. 圖像化摘要：AI 幫你畫重點 NotebookLM 產出的摘要可以進一步產生視覺化的重點圖。將這張圖下載下來，作為會議記錄的封面或視覺補充，能讓讀者一眼看清本次會議的關鍵價值。 ...

這不是一篇理論文，而是一次真實的踩坑紀錄。本文記錄了我如何使用 WalkGIS Template，配合 AI Agent 的自動化任務，從零打造一份包含 16 個景點、具備 GPS 定位與詳細介紹的「清大夜市美食地圖」。文中包含基礎設施架設、AI 內容協作到最終資料治理的完整流程。

驗證 WalkGIS 系統的擴充性：透過標準化流程，快速部署「大甲溪水利溯源」與「智慧水圳」兩條全新路線，並整合 Google Maps 導航與 AI 內容生成。

如何將生硬的 GIS 數據變成生動的旅遊故事？本文分享我的 WalkGIS 自動化工作流：使用 Shell Script 從 SQLite 精準萃取地圖資料，餵給 Google NotebookLM，一鍵生成卡通風格導覽與投影片大綱。

這次來大阪旅遊，除了享受美食與美景，我還做了一個特別的實驗：練習使用生成式 AI (GenAI) 來輔助旅遊規劃與決策。這不僅僅是問 Gemini「大阪哪裡好玩」，而是更深入地利用 AI 的邏輯推演與資料整理能力，來解決旅遊中遇到的「資訊過載」與「複雜交通」問題。 以下分享我如何運用 NotebookLM 與 Agentic AI (Antigravity) 來理解大阪梅田站這座複雜的交通樞紐。 1. 出發前的深度規劃：Gemini 與 NotebookLM 的協奏曲 在規劃階段，我先利用 Gemini 進行初步的發散式探索，詢問關於一日行程、深度旅遊建議以及景點背後的歷史文化。 操作心法：我將 Gemini 生成的對話內容匯出成 Markdown 檔案個別匯入 NotebookLM 作為知識庫。 AI 產出： 視覺化理解：利用 NotebookLM 整理出的重點，可以產出更清楚、方便理解的旅遊重點圖表或指南。 這種「先用 Gemini 生成，再用 NotebookLM 固化知識」的方法，讓我對大阪的歷史脈絡與行程要點有了更紮實的認識，而不僅僅是走馬看花。 2. 行程當日的即時戰略：Agentic AI 的動態規劃 到了當天，行程往往需要彈性調整。例如第二天我想去「四個特定的地方」，但我只知道名字，不知道確切位置和順序。 我的指令：給 AI 四個地點（Samuhara 神社、@cosme、Motherhouse、Loft），請它確認地點、找官網、並建議順序。 AI 的價值： 地理邏輯判斷：AI 發現其中一家神社比較遠且早開，其他三家都在梅田商圈，因此建議「先去神社，再回梅田一網打盡」。 Google Maps 整合：它直接吐給我一個規劃好的 Google Maps 路線連結，點開就能導航。 3. 破解「梅田大迷宮」：結構化資訊的力量 大阪梅田車站被稱為「大迷宮」，地下地上錯綜複雜。一般的地圖看了一頭霧水，本來是一頭霧水，但跟 AI 詢問一些架構問題，能幫助自己理解交通網絡。 3.1 根據地圖詢問交通架構 我先給地圖照片問 AI：「大阪車站的交通架構是什麼？有哪些節點？」AI 幫我釐清了 JR 大阪站、阪急梅田、阪神梅田以及幾條地下鐵線路的相對關係，建立了我腦中的「骨架」。 ...