研究方法・知識管理
33 篇論文、4 個工作主題
接成一個會自己長大的研究庫
選研究題目、寫文獻回顧，是研究前期最耗時的兩件事。我把每週收到的論文和跟 AI 討論出的結論放進同一個知識庫，這兩件事大半變成整理好的草稿，我只需要做判斷。
知識管理的價值不在存下多少，而在下次需要時，找得回當初的判斷，也找得到它的根據。
01從七個研究題目到一份文獻回顧，隔了九分鐘
11 月 15 日早上，我在研究庫裡問 Claude Code 一個問題：依照目前收進來的文獻，有哪些主題值得研究。
它沒有憑空發想。它逐一翻過 12 個概念頁裡「尚未解決的問題」，再對照我過去和 AI 討論工作時留下的洞見，整理出 7 個題目。每個題目都附上研究問題、文獻依據與頁碼、我自己過去的判斷、可行做法，以及證據強度。最後它還建議了順序：先用 AI 從新聞與通報補齊災害紀錄的發生時刻，才能用「發生前的雨量」重算雨量門檻，最後再做預警成效的連續驗證。三個題目是一條鏈。
我選了鏈條的第一題「災害紀錄的時空資訊品質」。它先交出大綱，我回一句「照大綱寫」。產出的 Word 檔有 6 節、9 頁、引用 13 篇論文，參考文獻依 APA 格式排好，每筆都帶 DOI。主題清單存檔的時間是 10 點 25 分，Word 檔是 10 點 34 分。
左邊是第一頁，文中引用連章節或頁碼都標出來。右邊是結尾，作者觀點的段落之後直接接上參考文獻。
九分鐘不是重點。這九分鐘能成立，是因為前面已經有 33 篇論文被讀過、寫成附頁碼的筆記，也掛進了概念頁。真正省下時間的，是這個一直在累積的結構。
02研究前期的時間，都花在哪裡
做過研究的人都熟悉這段路。找論文、下載 PDF、讀完寫筆記，過兩個月忘了哪篇說過什麼，再翻一次。找研究缺口要把十幾篇論文的結論攤在一起比對。寫文獻回顧時，參考文獻要一筆一筆排格式，請 AI 代勞又怕它編出不存在的文獻。
不寫論文的知識工作者也一樣。寫計畫書的背景、準備政策說帖、回答長官「這件事以前怎麼決定的」，需要的都是兩樣東西：外部的證據，和自己過去的判斷。
我手上原本就有這兩個抽屜。一個是論文，一個是今年 9 月開始整理的 AI 對話知識庫，把定稿的討論拆成決策、洞見、參考資料三個檔案。問題是兩個抽屜之間沒有通道。討論裡提到的論文只是一行字，論文裡能支持或推翻我判斷的證據，也連不回那場討論。
03一套架構，三個工具各守一層
這套做法的概念來自 Andrej Karpathy 今年 4 月公開的 LLM Wiki 構想：讓 AI 持續維護一個 Markdown 知識庫，替資料寫摘要、建立交互連結、定期檢查矛盾。我把它落實成三層分工。
Zotero 保管論文 PDF 與書目，外掛 Better BibTeX 給每篇論文一個固定代碼，稱為 citekey，例如 liou2026regional。Obsidian 是知識庫本體，所有筆記都是一般文字檔。Claude Code 依照一份寫好的規則檔讀論文、寫筆記、建連結，桌面版或指令列版本都可以用。
原文不改寫。PDF 與對話逐字稿永遠保留原樣，摘要和筆記另外存放。
citekey 是唯一的引用依據。citekey 只由 Zotero 產生，AI 不得自己編，也不得依標題猜 DOI。
判斷留給人。AI 的推論一律標成「LLM 歸納，待確認」，我的看法寫在它不能修改的區塊。
04讓論文和工作討論接上線的，是概念頁
論文和討論要連得起來，靠的是中間多一層概念頁。「降雨誘發預警」「預警成效評估」「崩塌目錄品質」，每個概念一頁，由 Claude Code 維護。
論文入庫時，它讀全文寫筆記，重要發現附上頁碼，再把這篇掛到相關的概念頁，標明和其他論文的關係是支持、反駁、延伸，還是方法不同。和 AI 討論出結論時，歸檔技能會替每則洞見附上相關概念，連結時把原句引用到概念頁的「使用者判斷」區塊，一字不改。概念頁裡每一句話都分成文獻主張、使用者判斷、LLM 歸納三種出處。
接上線之後，事情會自己找上門。有一篇以小林村與台 7 線為研究區、回推埋藏滑動面的預印本入庫時，Claude Code 在報告最後提醒我，這篇可以對照「警戒模式及發布機制」那個工作主題。我沒有要求它比對，是它在建立連結時自己發現兩邊談的是同一件事。
草稿裡 Claude Code 只能寫 [@citekey] 這種標記，而且只能用書目檔裡真的存在的代碼。參考文獻由 Pandoc 依 APA 格式產生，再用一支小程式比對每個代碼。AI 沒有機會自己寫出任何一筆書目，參考文獻不會出現捏造的文獻。
05題目從缺口長出來，判斷仍然是我的
那份主題清單之所以可信，是因為它的來源看得見。每週入庫時，Claude Code 會把論文之間的矛盾記在概念頁。例如計算雨量門檻的最佳時窗，一篇認為 168 小時內的前期雨量貢獻最大，另一篇則是 2 小時加 3 小時最好。它記下矛盾，也註明兩篇的研究區、資料尺度與問題都不同，未必真的衝突。
台灣全島的一篇研究則指出，用整場颱風期間計算時，約 78% 紀錄的 24 小時最大雨量其實包含崩塌發生後的雨。這些未解的問題累積在概念頁裡，選題時就成了現成的缺口。
它也會說出自己的底氣有多少。主題清單裡，大規模崩塌活動性那一題被標為證據最薄弱，本庫只有 3 篇、沒有台灣案例。它也提醒，「本庫尚無文獻」只代表這 33 篇裡沒有，動手前仍要補做文獻搜尋。
文獻回顧裡也分得很清楚。有幾段論述方向來自我過去的工作洞見，它以作者觀點撰寫，不掛文獻引用；它自己的推論標成待確認；文末附上待確認清單，列出只有單一來源的論點和只讀過摘要的引用。這些正是定稿前我要逐一處理的地方。
這套系統最重要的設計不是自動化，而是把「這句話是誰說的」標清楚。
06省下的時間，落在哪裡
從建立研究庫骨架到現在大約三天。目前的規模如下。
11 月 14 日晚上，一次就有 22 篇新論文分六批入庫，第一篇筆記寫入到最後一篇約半小時。四份文獻回顧草稿分別處理溢淹範圍劃設、機器學習潛勢模型的方法論、潛勢與預警的銜接，以及災害紀錄的時空資訊品質，每一份都已轉成 Word。
交給 AI 的
讀全文、寫附頁碼的筆記、掛概念頁、標出論文之間的矛盾、檢查引用代碼、從缺口整理題目、依大綱寫初稿、排 APA 參考文獻。這些原本最耗時的工作，現在多半在一次對話裡完成。
留給自己的
篩選每週送來的論文、決定研究題目、確認大綱、精讀關鍵論文、處理待確認清單、決定最後的論述與結論。時間省下來，就是為了花在這幾件事上。
對知識工作者來說，好處不只在寫論文。要寫計畫書背景或政策說帖時，外部文獻和我自己過去的判斷都在同一處，而且每一句都查得到出處。
33 篇裡有 10 篇拿不到全文，其中 6 篇連摘要都沒有，只建了書目。多數論點目前仍只有一兩篇論文支撐。一份九分鐘寫成的文獻回顧，是讓我開始查證的起點，不是可以直接交出去的成果。這套系統不是開關，而是累積，論文與討論越多，概念頁之間的關係才會真正長出來。
建置過程中遇到的每個問題，我都整理進操作手冊，從安裝、每週例行作業到常見問題，讓沒碰過這些工具的人也能照著做。研究庫骨架解壓縮後，資料夾、規則檔與每週指令都已設定好。
手冊附實際操作截圖與三十多個常見問題。骨架可直接作為 Obsidian 研究庫使用。
07它做不到的事
把邊界講清楚，這套方法才用得久。
它不能取代閱讀。筆記寫得再完整，精讀與判斷仍然要自己來。AI 寫的文獻回顧只是起點，用詞、論述取捨與結論都必須是自己的，投稿前也要確認期刊對 AI 輔助寫作的揭露規定。
它不適合放機敏資料。知識庫的內容會送到雲端模型處理，未公開的內部報告、個資與審查中的資料，應該留在不上雲的地方。
它挑論文的眼光有限。AI 查不到正確的影響係數，坡地災害領域的核心期刊影響係數也普遍不高。我改成給它一份期刊分層清單，加上單篇品質條件，再由自己做最後一關篩選。
付費期刊的 PDF 仍有相當比例要手動補，中文文獻的書目格式也還要手動調整。
兩個抽屜，合成一棵會長大的樹
從散落在信箱的論文清單，到每篇附頁碼的筆記；從淹沒在聊天紀錄裡的結論，到能被新論文支持或挑戰的洞見；從找不到題目的空白頁，到一份引用 13 篇論文、格式排好的文獻回顧草稿。
知識管理的價值不在存下多少，而在下次需要時，找得回當初的判斷，也找得到它的根據。
前一篇：【知識管理】每週十幾篇論文、和 AI 討論出的結論，我把它們放進同一個知識庫（2026 年 11 月）。
相關文章：AI 對話知識庫整理 SOP（2026 年 9 月）。
文中數字統計至 2026 年 11 月 15 日。「九分鐘」是研究主題清單與文獻回顧 Word 檔的存檔時間差，包含我確認大綱的時間；入庫時間依筆記檔案的修改時間估算。文中提到的論文結論引自研究庫的文獻筆記。LLM Wiki 構想出自 Andrej Karpathy 於 2026 年 4 月公開的說明文件。使用工具：Zotero、Better BibTeX、Obsidian、Claude Code、Pandoc。
沒有留言:
張貼留言