我相信，很多研究生的狀況類似：各種文獻和研究材料，散落在電腦裡的不同地方。舉例來說，我的 Zotero 裡有一百六十幾筆書目和一千兩百多則筆記，PaperBrain 這個論文腦裡有讀完的研究卡與概念，Obsidian 裡有 lit-summary 產出的論文筆記和知識庫，硬碟的 03_Research 目錄裡則躺著各個研究專案的草稿、調研報告與 BibTeX。每個工具都在自己的位置上做得很好，但沒有任何一個地方能回答我每天早上最想知道的問題：哪一條研究線在動、哪一條停了、今天該接哪一條。
這篇文章記錄我怎麼在一天之內做出 Research HQ，一個私人研究儀表板。它會從四個來源撈資料，算出六條研究線的燈號、文獻庫的健康、閱讀的節奏，以及卡片與概念之間的連結圖。我會講設計上的取捨、資料管線的長相、開發流程怎麼安排 AI 撰寫與審核，還有一路踩到的坑。你如果也在用 Zotero 或 Obsidian 做研究，可以參考這套做法。
先講靈感從哪來
今年七月時，我曾開發過一個叫 Pulse HQ 的一人公司儀表板：業務線卡片牆、燈號、變現數字、風險與工單，一頁看完。用了一個月之後，我發現它最有價值的地方其實只有一句話：每天早上打開，它告訴我哪條線放緩了、哪條線卡住了。
學術研究這件事的痛法，其實一模一樣。文獻讀到一半換了主題、卡片建到一半停了、Zotero 收了一批書目卻從沒回頭讀，這些都不會有人提醒你。所以 Research HQ 的第一個決定就是：不重新設計，直接把 Pulse HQ 的設計語言、資料管線與部署方式整套搬過來，只換資料來源與區塊。暖羊皮紙底色、卡片牆、右側抽屜、頂部匯出列，全部沿用。省下來的不只是樣式的時間，還有一整套已經踩過坑的部署腳本與密碼閘。
三個先決定不做的事
動手之前先決定不做什麼，比決定做什麼更能讓一天內完工。
第一，不做即時查詢。Zotero 的本機 API 只在我這臺 Mac 上聽 localhost:23119，PaperBrain 與 Obsidian 也都是本機檔案。要做即時，就得把 Zotero 的雲端 API 金鑰放上 Cloudflare，而 PaperBrain 還是搬不上去，最多做到四分之一即時。所以整套架構定調為本機建置快照、上傳一份 JSON，儀表板永遠顯示上次建置的時間，超過 72 小時就掛出過期橫幅。
第二，不靠 AI 判讀。燈號、注意事項、統計數字全部由程式機械計算，不讓語言模型看一眼資料再告訴我這條線是綠是紅。Pulse HQ 早期版本是讓 AI 讀覆盤再判燈號，八月改版時整個換成機械解析，就是因為人工判讀的結果沒辦法重現。這次從第一行程式碼就把規則寫死：距最近一次活動七天內是綠、八到二十一天是黃、超過二十一天或完全沒有活動記錄就是紅，暫緩的專案永遠灰色。
第三，零依賴。整個建置腳本只用 Node 內建模組，測試用 node:test，前端是純靜態的 ES module。這不是潔癖，是因為要散播給別人用的工具，不該逼人先裝一堆東西；而且 PaperBrain 本身就承諾零依賴，儀表板沒有理由破壞它。
四個資料來源各自能給什麼
我先派了一個 agent 去盤點，不是問有什麼資料，而是要它回報實際的數字與欄位。這一步很重要，因為儀表板的每個區塊都得建立在真的撈得到的欄位上，不能先畫好版面再去找資料湊。
盤點結果大致是這樣。Zotero 本機 API 開著，總共 1,540 筆 item，其中書目 159 筆（期刊文章佔 140）、獨立筆記 1,259 則、20 個 collection、59 個 tag；有 PDF 附件的書目只有 9.4%，有子筆記的 46.5%，DOI 覆蓋 124 筆。PaperBrain vault 有 6 張研究卡、30 個概念、1 份綜整，每張卡的 frontmatter 有 12 個固定欄位（citekey、year、status、reviewed、tags 等），概念檔裡有一段「出現在哪些卡」可以反推被引次數，而且 PaperBrain 的程式庫本來就有 loadVault 與 buildHealthReport 兩個函式可以直接 import。Obsidian 那邊比較薄，9 篇論文筆記、96 條 wiki、一份知識缺口清單。03_Research 目錄下則是各專案的工作區。
盤點完之後，我才知道兩件事：一是閱讀漏斗這個原本想做的圖不成立，因為有筆記不必有 PDF，概念數可以大於卡片數，這些階段彼此不隸屬，後面會再講；二是 Zotero 那 1,259 則獨立筆記全是歷史匯入，它們的規模會壓過其他三庫，要不要納入是要另外拍板的事。
架構只有一句話
本機跑一支建置腳本，讀四個來源，算出所有統計，用 schema 驗過之後寫成 research-data.json；一個靜態頁面 fetch 這份 JSON 渲染九個區塊；Cloudflare Pages Functions 的中介層在 /research/ 前面擋一道密碼閘；部署腳本先跑測試、驗 JSON、確認工作樹乾淨，再從 git archive 出來的乾淨目錄上傳，最後 curl 線上路徑確認。
值得說明的是唯一需要人維護的檔案：專案對照檔 research.md。每條研究線一段，寫 id、名稱、狀態（active 或 paused）、對應的 Zotero collection key、對應的硬碟目錄、對應的 PaperBrain tag、目標、下一步。建置腳本用它把四個來源的資料歸到六條研究線底下：collection 裡的書目、tag 命中的卡片、目錄裡檔案的修改時間，聯集起來就是這條線的活動日期，燈號與三十天動工進度條都從這裡算。「下一步」是整份檔案裡唯一由人寫的語意欄位，其他全是機械計算。
四個問題，九個區塊
我在動手前問自己這個儀表板要回答什麼，答案是四個問題，優先序如下：研究進度指揮塔、主題地圖與知識網絡、閱讀與產出節奏、文獻庫健康。九個區塊就是照這個順序排的。
今日研究燈號放最上面：推進中、放緩、卡住、暫緩四個大數字，旁邊是機械彙整的注意事項。注意事項的規則有五條：PaperBrain 收件匣有 stub 滯留超過七天、有卡片沒審完、健檢有 error、專案停滯超過十四天、某條線的 collection 近三十天收了新書目但一張卡都沒有。最後那條上線第一天就跳出來提醒我：社群媒體行銷成效那條線收了 68 篇，尚未餵腦。
研究專案卡片牆是主體。每張卡有燈號、書目數、卡片數、筆記數、停滯天數、三十天動工進度條、下一步一行；點開右側抽屜看該線的最新書目、關聯卡片與最近活動。這裡有一個我刻意寫在區塊副標上的提醒：燈號依最近活動日推算，是活動的代理指標，不是進度本身。檔案的修改時間只能證明檔案被動過，證明不了研究有推進；批次整理一次目錄就能讓紅燈變綠。這種限制與其藏起來，不如寫在使用者眼前。
▲ 上線第一天的今日研究燈號與研究專案卡片牆：每張卡有燈號、書目／卡片／筆記數、停滯天數與三十天動工進度條，副標明寫燈號只是活動代理指標
四庫 KPI 與閱讀階段覆蓋接在下面。原本這一段叫閱讀漏斗，設計審查時 Codex 指出它在數學上不是漏斗，百分比會超過一百，我就把它改成「階段覆蓋」，只對書目總數算比例，概念與綜整兩格不算百分比。
主題地圖有五張卡：collection 樹（父夾顯示含子夾去重合計，這樣才和專案統計的口徑一致）、概念被引 Top 15、tag 雲（字級隨數量放大，自動 tag 用虛線淡色）、出版年分布與期刊 Top 8，還有一張卡片與概念的二分連結圖，左邊六張卡右邊三十個概念，滑鼠移過去高亮相鄰的邊。這張圖是這一輪我最喜歡的東西，因為它讓我第一次看見自己的閱讀在概念層是怎麼連的。
▲ 主題地圖：collection 樹的父夾顯示含子夾去重合計，概念被引數來自 PaperBrain 概念檔的「出現在哪些卡」段
▲ 卡片與概念的二分連結圖，滑鼠移過任一節點會高亮相鄰的邊；這是整套儀表板裡我最喜歡的一張
閱讀與產出節奏，是近十二週的四色堆疊柱加上本週、上週、三十天的小表；文獻庫健康把 PaperBrain 健檢的輸出原樣呈現，Zotero 覆蓋率畫成六條進度條，Obsidian 若沒接到就明白寫「未接入」而不是填零；最近入庫列出 Zotero 最近十筆與 PaperBrain 最近六張卡；最後是 MD、CSV、PDF 三個匯出鈕。
▲ 閱讀與產出節奏（上）與文獻庫健康（下）：Zotero 有 PDF 的書目只有一成出頭，這種洞放在同一頁上就藏不住
開發流程：AI 寫、AI 審、驗收不自驗
接下來的這部分，也許是對想開發自用工具的朋友最有價值的地方。整個專案從動念到上線大約一天，我自己沒有寫任何一行程式碼，但也不是胡亂丟一個構想讓 AI 自由發揮。
簡單來說，流程長這樣。先是 brainstorming：AI 派兩個 agent 分別去調查 Pulse HQ 的設計系統與四個資料來源的實際欄位，回來後一次問齊四個決策（核心問題、部署位置、這輪做到哪、獨立筆記要不要算），我勾完它才提設計方案。設計定案後它寫 spec，再從 spec 展開成八個任務的實作計畫，每個任務都附完整程式碼與測試案例。
計畫寫完，先過兩道審查。一道是工程審查，抓到七項，其中最重要的一項是 vista-lab 這個站的中介層對副檔名做白名單，任何 .json 都會被公開供應，而計畫原本把 Zotero 的測試 fixture 寫成 .json 檔，上線就等於把假資料公開，於是全部改成 .mjs 模組。另一道是 Codex 的獨立第二意見，二十點，我收了十七點：分頁邏輯在 header 缺失時會靜默只抓一頁、漏斗語意不成立、總燈號忽略健檢錯誤、注意事項沒有上限會被淹沒、Obsidian 缺席時填零會偽裝成零產出、寫檔不是原子操作等等。拒掉的三點裡最大的一點是它建議先做最小版本再擴充，但四大區塊是我自己拍板全做的，這不是它的判斷範圍。
接著才開工。八個任務逐一派給新開的 agent 實作，每個做完再派另一個沒看過實作過程的 agent 審查，審不過就退回原實作者修，修完再派範圍內的重審。八個任務裡有兩個走了一輪修正：一個是 PaperBrain 的錯誤物件被 String() 之後變成 [object Object]，操作者看不到任何有用資訊；另一個是注意事項的上限差一，規則說十二條含收尾行，實作做成十二條加一行收尾。全部完成後再派一個更強的模型做整分支審查，它又抓到五項，包括我在中介層註解裡宣稱的一條防線其實被舊 cookie 的續期邏輯繞過、部署腳本的 200 檢查是套套邏輯（未登入本來就回 200 的登入頁，閘門被拆掉也會過）、測試把部署綁死在另一個 repo 的絕對路徑上。一波修完，合併到 main 才部署。
上線後我沒有讓做的那些 agent 自己驗，而是另派一個完全不知道實作細節的 agent，給它一份找出問題的清單：匿名讀資料檔要拿到登入頁不是 JSON、fixture 路徑要 404、登入後九個區塊要有內容、375 像素寬不能橫向捲動。十九項它抓到一項真的失敗：手機寬度整頁橫捲。原因很諷刺，是最終審查那波修正裡為了讓圖表在手機上保持可讀而加的最小寬度，把 CSS grid 的卡片撐開了。修好、重新部署、再驗一次才算完。
我把這套流程，叫做「驗收要換問題意識」。做事的人不驗自己的活只是最低要求；驗收的方式如果和生產的方式同一種思路，兩邊會一起瞎。所以審查要看不到實作者的推理過程，驗收要拿「找問題」的清單而不是「確認沒問題」的清單，而且驗收的預期本身也可能錯：那次驗收裡另一項標 FAIL 的「Pulse 首頁看不到研究連結」，其實是驗收腳本忘了 Pulse 首頁自己也有密碼閘。
踩到的坑，照時間順序
白名單陷阱。中介層對副檔名做預設拒絕是好事，但白名單裡有 json，且不擋 scripts 目錄，所以 repo 裡任何一個 .json 都會變成公開網址。這一條在工程審查抓到，如果漏了，測試 fixture 會跟著上線。
Number(null) 等於 0。分頁抓 Zotero 時用 Total-Results 這個 header 判斷要抓幾頁，原本的寫法在 header 缺失時會算出 0，於是第一頁抓完就靜默停止，資料少了一大截也不會報錯。Codex 抓到，改成只接受純數字字串。
bash 變數緊接全形字。部署腳本的 echo 訊息把變數 $needle 直接接在全形右引號前面，bash 把那個引號一起吃進變數名，跑到驗證步驟才炸。這是我記憶裡早就記過的坑，這次還是踩了一次。
375 像素的 grid。為了讓 SVG 圖表在手機上不要縮成五像素的字，給它一個最小寬度讓外層容器橫捲；但容器是 CSS grid 的子項，預設 min-width 是 auto，SVG 一撐開，整個 grid 欄位跟著變寬，頁面就橫捲了。補一行 min-width: 0 解決。
以及最後那個小的：節奏圖在手機上初始看起來是空的，因為資料集中在最近幾週，也就是圖的最右邊，而容器預設捲在最左。加一行讓它載入後捲到最右。
上線第一天，資料告訴我什麼
三條線推進中、零條放緩、一條卡住、兩條暫緩。卡住的是 jres 的 AI 寫作鷹架，三十天沒動，這條我心裡有數但沒有數字之前不會正視。社群媒體行銷成效那條線收了 68 篇書目卻零張卡，因為 PaperBrain 現有卡片的 tag 沒有一張命中我在對照檔寫的 tag，這提醒我要嘛改 tag 要嘛開始餵腦。Zotero 有 PDF 的書目只有 17 篇，有子筆記的 74 篇，DOI 覆蓋七成多；1,259 則獨立筆記全在十二週之前，是歷史匯入。這些數字都不新，但把它們放在同一頁上，第一次看見自己研究工作的形狀。
你可以怎麼做
如果你想照著這樣的思緒開發自己的系統，以下這三件事最重要。
第一，先盤點再設計。派一個 agent 把你每個工具裡實際有多少筆、有哪些欄位、哪個 API 開著查清楚回報數字，儀表板的每個區塊都只建在撈得到的欄位上。如果你的文獻還沒有系統地收進 Zotero，可以先讀〈找文獻為什麼該用 AI Agent，而不是把 ChatGPT 當圖書館〉，把檢索與驗證的底盤先打好，儀表板才有東西可算。
第二，把人工判斷收斂到一個檔案。我這裡是 research.md，你可以是任何格式，重點是每條研究線的歸屬規則寫在一處，燈號與統計全部由程式從這裡算，這樣資料錯了你知道去哪裡改，而且不會被 AI 每天判出不同答案。
第三，讓寫的和審的分開，讓驗收的什麼都沒看過。這是整個流程裡最省時間的部分，不是最花時間的。一天裡真正的人工介入只有幾次：勾選核心問題與部署位置、對設計說開工、看最終審查的裁決、看驗收報告。其他都是 agent 之間在推。
儀表板本身的原始碼、規格與計畫都在我的 repo 裡，PaperBrain 是 Apache 2.0 授權。這篇文章講的是基本的做法，你無需複製我的區塊；你的四個來源可能是別的四個工具，但快照、機械算、沿用既有設計、AI 寫 AI 審人拍板這四條，換到任何自用工具上都成立。研究工具的挑選可以參考本站的全球資源庫，想看我怎麼把 AI 帶進提問與文獻階段，〈別再叫 AI 幫你整理論文主題〉是另一篇實作紀錄。如果你也做了自己的研究儀表板，或者卡在某個環節，歡迎寫信告訴我。
如果你想更有系統地把 AI 帶進研究流程：從文獻搜尋與驗證，一路到閱讀、寫作與投稿，歡迎參加我的《AI 賦能學術研究與寫作實戰工作坊》，用半天時間把 AI Agent 變成你的研究副駕駛；還沒準備好報名的話，先從免費課程開始。