前幾天，我們已經完成三件重要的事：
接下來，專題通常會遇到另一個問題：
找到的資料越來越多，卻越來越不知道放在哪裡。
可能有人把 PDF 放在下載資料夾、有人把連結貼到群組、有人將 AI 回答存在聊天紀錄，訪談筆記又放在另一份 Google 文件中。
等到要做企畫書或簡報時，大家開始問：
問題並不是「沒有資料」，而是資料無法追溯、比較與重複使用。
今天要建立的不是單純的檔案資料夾，而是一個可以回答問題、顯示引用，並保留專題決策依據的知識庫。
一般聊天工具適合發想、改寫及討論，但當資料開始增加時，可能出現三個問題。
AI 可能綜合內部知識、對話內容及你提供的資料回答。若沒有引用，很難確認某句話究竟來自哪裡。
假設資料夾中同時存在：
AI 和組員都可能引用到錯誤版本。
即使 AI 能指出引用位置，來源本身仍可能過期、偏頗或缺少上下文。
因此，專題知識庫必須同時做到：
Google 的官方說明頁面目前使用 Gemini Notebook 名稱，許多人仍習慣稱它為 NotebookLM。本文會以 NotebookLM 稱呼，實際入口為：
NotebookLM 是以來源為核心的 AI 研究工具。根據 Google 官方說明，它可以匯入 PDF、網頁、Google 文件、簡報、試算表、圖片、音訊、公開 YouTube 影片及其他常見檔案，並依據選取的來源回答問題。
它和一般聊天工具最大的差別是：
回答中會附上來源引用，讓使用者回到原文檢查。
截至 2026 年 9 月 18 日，Google 官方說明顯示，一般免費使用者可在單一筆記本加入最多 50 個來源；每個來源的字數與檔案大小也有上限。功能與額度可能調整，實際使用時仍應查看官方最新說明。
不過，今天不需要一次放入 50 份資料。對剛開始的專題來說，先整理好 5 份真正重要的來源，比一次上傳 50 份沒有分類的文件更有效。
我們今天採用以下流程：
圖 1：AI 專題知識庫流程。資料先經過來源紀錄與查證，再進入知識庫；AI 產出的主張、需求與決策必須通過引用檢查。製作方式：根據 Google Gemini Notebook 官方說明自行繪製 SVG，並輸出為 PNG。
圖片替代文字：
網頁、PDF、影片與訪談資料先製作來源卡，再進入專題知識庫，經由引用式問答產生專題需求與決策，最後回到原始資料進行品質檢查。
登入 NotebookLM 後，建立一個新的 Notebook。
命名不要只寫：
AI 專題
可以使用：
2026-AI競賽-校園剩食助手
建議格式為：
年份－活動或課程－專題名稱
這能避免日後同時參加多個活動時混淆資料。
不要把完全不同的專題塞進同一個 Notebook，例如不要把「校園剩食」「旅遊推薦」及「情緒辨識」的資料混在一起。
一個 Notebook 最好對應一個明確的研究問題或專題。
第一次建立知識庫時，可以先找以下五類來源：
| 來源角色 | 要回答的問題 | 例子 |
|---|---|---|
| 問題證據 | 問題真的存在嗎？ | 統計資料、政府報告 |
| 使用者聲音 | 使用者怎麼描述問題？ | 訪談、問卷、觀察紀錄 |
| 領域知識 | 問題背後有哪些專業概念？ | 論文、研究報告、官方指南 |
| 現有解法 | 現在別人怎麼處理？ | 產品網站、案例研究 |
| 技術可行性 | 我們做得出來嗎？ | API 文件、工具官方說明 |
以「校園剩食助手」為例，可以先收集：
這五類來源分別支撐問題、需求及實作，不會讓知識庫變成只有一堆新聞連結。
在匯入 NotebookLM 前，先為每份資料建立一張來源卡。
可使用以下格式：
【來源名稱】
彰師大學生校園用餐需求訪談
【來源類型】
半結構式訪談紀錄
【作者／蒐集者】
專題小組
【日期】
2026-09-18
【檔案名稱或網址】
interview_students_20260918.docx
【加入原因】
了解學生購買晚間餐點時遇到的問題
【關鍵發現】
受訪者常在餐廳打烊前不知道還有哪些餐點
【限制】
目前只有 5 位受訪者，不能代表全校學生
【個資處理】
已移除姓名、學號與聯絡方式
來源卡有兩個作用：
來源卡不一定要獨立成檔案，也可以放在原始文件的第一頁或開頭。
NotebookLM 支援多種來源，但「成功匯入」不代表內容完全相同。
匯入一般網頁時，系統主要擷取 HTML 中的文字。
這代表：
如果重要資訊在圖表中，應另外下載官方報告或保存圖表數值與說明。
公開 YouTube 影片需要具有字幕，NotebookLM 主要匯入影片的文字逐字稿。
因此：
NotebookLM 支援 PDF、DOCX、PPTX、TXT、Markdown、CSV 等常見格式。
如果 PDF 是掃描圖片，文字辨識結果可能不完整。匯入後應先詢問文件標題、章節及一個已知內容，確認系統是否正確讀取。
由 Google Drive 加入的支援文件可以自動同步更新，也可以手動要求同步。
但官方說明指出，Google 文件中的註腳與留言不會被匯入。因此，如果重要決策只寫在留言中，AI 可能看不到。
正式結論應移到文件正文或專門的決策紀錄中。
音訊可以在匯入時轉成文字來源，但聲音品質、多人同時說話、台灣口音及專有名詞都可能影響辨識。
建議在匯入前：
「摘要全部資料」通常會產生一篇看似完整，卻很難直接用於專題的文章。
應該提出能產生專題證據的問題。
請只根據目前選取的來源，建立「主張—證據表」。
欄位包含：
1. 可以支持的主張
2. 支持這項主張的來源
3. 原文重點
4. 適用範圍
5. 限制或不確定性
如果來源不足以支持某個主張，請標示「證據不足」，不要自行補充。
比較目前來源對於「學生是否願意購買即期餐點」的描述。
請列出：
- 一致的發現
- 互相矛盾的發現
- 可能造成差異的樣本、時間或情境
- 仍需補充的資料
每一項結論都必須附上來源引用。
請只根據選取的訪談與問卷來源，整理使用者需求。
使用以下格式：
- 使用者：
- 發生情境：
- 遇到的問題：
- 目前做法：
- 造成的影響：
- 可以驗證的需求：
- 引用來源：
不要提出功能或解決方案，這一輪只整理需求。
如果要證明「校園剩食助手值得開發」，目前來源還缺少哪些證據？
請依重要性排序，列出：
- 缺少的證據
- 為什麼重要
- 可以向誰詢問
- 可以用什麼方法取得
- 取得時要注意的倫理或個資問題
第四個問題非常重要。
知識庫的價值不只是回答已有資料，也要告訴我們「目前還不知道什麼」。
根據 Google 官方說明，NotebookLM 的回答可以使用來源中的文字、圖片或直接引文作為引用。點擊引用後，可以回到來源中的對應位置。
但引用存在不代表結論一定正確。
每次準備將內容放入企畫書前，至少檢查：
例如，來源可能寫：
在本次接受訪談的五位學生中，四位表示願意嘗試惜食餐點。
不能改寫成：
八成的大學生願意購買惜食餐點。
前者只描述五位受訪者，後者卻擴大成所有大學生。即使引用連結正確，推論仍然有問題。
當 AI 整理出有價值的內容後，不要讓它只留在聊天紀錄中。
建議保存三種筆記：
決定採用的主張：
學生在餐廳打烊前缺乏即時餐點資訊。
支持來源：
- 學生訪談 2026-09-18
- 餐廳訪談 2026-09-19
目前限制：
樣本數少，下一步需要問卷驗證。
需求編號：REQ-001
使用者：晚間留校學生
情境：晚上 7 點後尋找價格可接受的餐點
需求：快速知道仍在營業且有餐點的店家
證據：學生訪談來源 1、3、5
驗收方式：使用者可在 30 秒內找到至少一個選項
決策編號：DEC-001
決策：第一版不加入線上付款
原因：付款不是目前最核心的需求，且會增加金流與資安風險
依據：八週時程限制、訪談需求排序
日期：2026-09-18
負責人：專題小組
這些紀錄能在評審詢問時回答：
你們為什麼做這項功能？
而不是只能回答：
因為我們覺得應該不錯。
不要繼續使用：
新增文件
訪談最終版
報告新版
真的最終版2
可以改用：
YYYYMMDD_類型_主題_版本
例如：
20260918_INTERVIEW_學生晚餐需求_v01
20260919_REPORT_校園剩食統計_v01
20260920_REQUIREMENT_功能需求_v02
20260921_DECISION_MVP範圍_v01
如果資料會持續更新，建議保留：
這比單純依靠 AI 搜尋更加可靠。
來源越多，不一定越好。
如果放入大量重複、過期或無關資料，AI 可能需要在更多內容中判斷相關性，團隊也更難逐一查證。
加入來源前先問：
無法回答時，可以先留在「待整理區」，不要立即進入正式知識庫。
NotebookLM 的回答會依據你放入的資料。
如果來源錯誤、過期或彼此偏頗，產生的回答也會受到影響。
因此應延續 Day 2 的原則：
AI 可以協助尋找與連接證據，但原始來源才是最後判斷依據。
原始問卷、官方報告及訪談逐字稿屬於來源。
AI 產生的摘要、比較表及建議屬於衍生內容。
不要將 AI 摘要重新上傳，再把它當成新的原始證據，否則內容可能經過多次改寫後逐漸偏離原文。
可以使用以下標記：
SOURCE：原始來源
AI-DRAFT：AI 產生的草稿
VERIFIED：已人工對照來源
DECISION：團隊確認採用
不要因為工具方便，就直接上傳：
Google 官方隱私說明指出，Notebook 內容不會直接用於訓練基礎 AI 模型，除非使用者選擇提供意見回饋；提供回饋時，相關提示、來源與輸出可能一併被收集。學校及工作帳號另適用其組織和 Workspace 條款。
最安全的原則仍然是：
不需要上傳的敏感資料，就不要上傳。
對大一生的小型 AI 專題而言，免費版本通常足以完成：
真正的限制通常不是來源額度，而是團隊是否有整理與驗證資料。
付費方案比較適合：
方案名稱、額度與價格都可能變動，本文不列固定價格。使用前請查看 Google 官方最新方案頁面。
如果無法使用 NotebookLM，也可以採用免費替代流程：
真正重要的是工作流程，而不是一定要使用某個品牌。
請為你們的 AI 專題建立第一版知識庫。
命名格式：
2026-AI競賽-專題名稱
至少包含：
每份資料至少記錄：
請只根據目前選取的來源回答。
1. 我們能確定的三項事實是什麼？
2. 每項事實分別由哪些來源支持？
3. 哪些來源之間存在衝突？
4. 目前最重要的三個知識缺口是什麼？
5. 下一步應該蒐集什麼資料？
每項結論都附上引用。沒有足夠證據時，請明確標示「證據不足」。
| 驗收項目 | 合格標準 |
|---|---|
| 來源完整 | 五類核心來源至少各有一份 |
| 可追溯 | 每份資料都有作者、日期及連結或檔名 |
| 可引用 | AI 回答包含可開啟的引用 |
| 引用正確 | 引用原文確實支持回答中的主張 |
| 有限制 | 訪談樣本、資料年份等限制已被記錄 |
| 有缺口 | 系統能列出仍需補充的證據 |
| 有決策 | 至少保存一份團隊確認的決策筆記 |
| 無敏感資料 | 已移除不必要的個資與機密內容 |
如果只是成功上傳檔案，但無法通過以上檢查，就還不能算是可用的專題知識庫。
專題知識庫不是「把資料全部丟給 AI」，而是一條完整流程：
只要做好這套流程，日後撰寫企畫書、簡報、影片腳本或評審問答時，就不必重新翻找散落在各處的資料。
Day 5，我們將離開電腦裡的資料，真正去確認使用者的問題：利用 AI 設計訪談與問卷，把「我覺得大家需要」變成可以驗證的使用者需求。
以上官方資料於 2026 年 9 月 18 日查閱。產品名稱、支援格式、免費額度及功能可能更新，請以官方最新頁面為準。
iThome鐵人賽
看影片追技術