Day 1 那張時間分配表，我說文獻佔 35%、資料佔 25%、格式佔 20%、行政佔 20%，真正只有我能做的不到 15%。三十天後，我想用同一張表問自己：這套工具箱，到底吃掉了那 85% 裡的多少。

答案不是一個漂亮的百分比，是一份老實的清單——包含做出來的東西，也包含沒做出來的東西。

工具總目錄
Day 工具／內容 輸出
3 CLAUDE.md 交班單 專案根目錄的規則檔
4 資料夾結構（raw/clean 分離） 專案骨架
7 PubMed MCP + 檢索策略／紀錄 literature/search-log.md
8 摘要卡 skill literature/cards/.md
9 文獻比較矩陣 skill literature/matrix.md
10 引用查證 skill literature/cite-check.md
11 APA 校對 skill draft/references.apa.md
14 資料清理腳本 data/clean/02_cleaned.csv
15 SPSS 匯出 skill data/clean/03_for_spss.sav
16 表一自動生成 skill draft/table1.docx
17 圖表工具（色盲安全＋灰階核對） output/fig.png
21 AI 語氣檢查 skill analysis/tone-report.md
22 口試模擬器 analysis/mock-defense-log.md
23 委員意見對照表 committee/response-table.docx
24 進度紀錄 skill progress-log.md
25 流水線執行器 analysis/run_pipeline.py
26 打包分享骨架 .mcp.json ＋ 規則檔範本
十七個項目，十五個是真的可以重複執行的工具，兩個是制度性的東西（交班單、資料夾結構）。

還沒補上的洞
這份清單裡有缺口，三十天的路線圖裡，Day 5、6、13、20 從來沒有真正寫出來過：

Day 5：skill 這個概念本身，從 Day 8 開始每天都在用，但它是什麼、怎麼設計，沒有獨立講過。
Day 6：Day 6 到 Day 10 反覆提到的「被捏造的引用」那個起源故事，沒有寫過完整版本。
Day 13：Day 14 開頭說「昨天把 Google 表單原始檔改好」，那個「昨天」具體怎麼做的，沒寫過。
Day 20：文獻回顧段落草稿怎麼從摘要卡跟矩陣生成出來，Day 21 直接假設它已經存在，但生成的過程沒寫過。
Day 25 串流水線的時候，第一次正式承認了後兩個洞。今天把四個洞一起攤開寫，是因為完賽總結如果假裝三十篇都完整，那就是這整個系列最反對的那件事——看起來沒問題，不代表真的沒問題。這份總結如果不誠實列出缺口，就是在示範「看起來做完了」跟「真的做完了」中間的落差，而那正是這三十天想提醒讀者的核心。

省下的時間，老實算一次
第二週（Day 12）算過一次：建工具花十五小時，省下十四小時，小虧。第三週（Day 19）四個工具，省下的時間比花費的時間更明顯一些，因為第二週建立的規則檔習慣，讓第三週寫規格檔的速度快了不少。

這個趨勢本身，比任何單一數字更值得記下來：工具箱的報酬不是線性的，是累積的。 第一週幾乎全部在投入，沒有回收；到了第三、四週，前面建立的習慣——先寫規則檔、讓工具只做可驗證的部分、每一步都核對——已經變成不用重新思考的反射動作，新工具的建置成本因此一直在下降。如果只看第二週那張表，會覺得這整件事划不來；要看到第四週，才會看懂為什麼值得。

三條紅線，有沒有被打破過
Day 1 畫了三條線：不讓 AI 寫論文內容、不生成沒查證過的引用、研究資料不離開電腦。三十天過去，老實檢查一次。

不讓 AI 寫論文內容——守住了，但 Day 20 那個洞剛好就卡在這條線最模糊的地方：生成文獻回顧草稿，跟「AI 寫論文內容」的邊界到底在哪裡，這個洞還沒補上，可能不是巧合，是這條線最難寫清楚的地方剛好被我迴避掉了。

不生成沒查證過的引用——這條線有具體的工具守著（Day 10），是三條線裡執行得最確實的一條，因為它可以被驗證，符合整個系列反覆出現的判準：規則越可驗證，越容易真正做到。

研究資料不離開電腦——Day 27 才真正把這條線的機制講清楚，而且發現 Day 1 的講法本身不夠精確。這條線不是「守住了沒有」的問題，是「我到今天才真正理解它在防什麼」。

三條線裡最晚被真正理解的一條，反而是當初寫得最斬釘截鐵的那條。這個落差本身就是這三十天最真實的收穫。

如果你只能做一件事
三十篇裡，如果要我選一個今天就能做、最快看到效果的起點，還是 Day 1 那三行 CLAUDE.md。所有後面的工具，不管多複雜，核心都只是「把一條規則寫清楚，讓它每次都照做」，CLAUDE.md 是這個原則最小的示範。

這個資料夾是什麼

（填寫：你的研究主題、設計類型）

絕對不要

• 不生成沒有提供來源的參考文獻
• 不要動 data/raw/
  不到十行，三十天後回頭看，後面建的每一個規則檔，骨架都是這兩行的放大版。

要不要開源
Day 26 留下的問題，今天給一個暫時的答案：先不公開到陌生人能直接取用的地方，但會把骨架版本整理好，放在實驗室內部共用。理由很簡單——這套工具箱裡的每一條規則，都是從我自己的錯誤裡長出來的，拿掉錯誤發生的脈絡，規則會變成一堆沒有來源的斷言，別人照抄了規則，卻沒有機會理解「為什麼是這樣」。這整個系列存在的意義，一直是把脈絡寫下來，不只是把規則寫下來。公開分享如果只給規則、不給脈絡，就違背了這三十天想做的事。

給三十天後的自己
三十天前，我在改參考文獻，改到第二十筆發現前十筆用了另一套規則，那四個小時裡跟研究有關的時間是零。今天，literature/cite-check.md、analysis/cleaning-log.md、progress-log.md 這些檔案，都是那個晚上留下的後遺症，也是它的解答。

工具箱沒有讓我變成更好的研究者，它只是把那些不需要我變成更好的研究者、也能做對的事情，從我手上拿走。剩下的，讀完文獻決定怎麼用它、看到統計結果決定它代表什麼、判斷一段話的語氣配不配得上手上的證據——這些事三十天前是我在做，三十天後還是我在做，沒有變。

這大概就是這三十天最想說的一句話：工具會壞，壞的地方要自己知道；但工具解決不了的那部分，從頭到尾都還是我自己的事，而且會一直是。

謝謝看完這三十篇的人。如果有任何一篇的某個坑，剛好幫你省下一次踩雷，這系列就值得了。