第三十天，襪哦襪哦哦哦
這是我第二次參賽，比起第一次都跑完了還沒搞清楚狀況，第二次參賽更像是一場冒險，啟程時我是愚者，旅途完成後，帶著所經所學的我，既感到滿足、又重新成為愚者。
我認為我在九月一號開賽時是「搞懂了」才來的，完全沒發現其實只是還沒踩到坑，或者說有踩到坑，但沒造成實際影響所以不在意。
儘管很自大地這樣覺得，還是非常保守地存了大約十五篇的存檔才開賽，這讓我即便重寫了好幾遍，系列的文章走向也改了兩三次，還是能以一個很舒適的姿態跑到最後一天，我的文章存量到今天才全部用完，三十天的長跑完全沒有「文章告急」的情況發生，對此我能挺起胸膛說「我真屌！」
所以文章存量！如果後續有人想參加 ITHOME 鐵人三十，這幾乎是最重要的事情。
不要跟我說我就屌，我就是可以每天都產出一篇文章，真的別鬧了，你不行。
用 AI 寫三百個字這種事情不用三十秒，這大家都知道，但是要寫一篇文情並茂、表達清晰、內容與技術相關又能為世界帶來實質影響的文章，你真的覺得每天能產出一篇嗎？
如果你要求夠高，提前把文章寫好做為存量我認為是必須的，這是老生常談了，我還年輕就不在這裡繼續嘮叨。
這篇主要內容是為我這三十天做一個完整的檢討，但我自己有 Bias，而且很遺憾的，這三十篇文章完全沒有吸引到讀者留言，所以我只有 AI 作為我嚴厲的導師，我們來看一下這段期間我到底幹了些什麼。
| 時間 | 事件 |
|---|---|
| 7/29–8/5 | 開專案，8/3 寫作策略轉向，8/5 封存舊方向整個重來 |
| 8/6–8/31 | 開賽前存了約 15 篇粗稿，第一到十八篇都是我在白板親手寫 |
| 9/5–9/10 | 第五、六篇拆分、編號整批遞補兩次；第七篇整篇重寫；第十六到十八篇因 Query 機制被推翻全部重寫 |
| 9/15–9/16 | Harness Engineering 大改，CLAUDE.md 254 行砍到 68 行 |
| 9/22–9/24 | 用「結構完整」評審標準回頭檢視，收尾方向改掉，示範庫改造成模板 |
| 9/24–9/29 | 第二十七到二十九篇改成 AI 先寫初稿、我修改；第二十九篇 9/29 23:12 定稿 |
所以可以說花了六十天完成三十篇文章，如果把時間拿去接案兼職能拿多少回來勒？
別想這麼多無聊的事情了，人生就像是我這三十天，總是以功利目的出發的話，總是會 miss 一些寶貴的經驗與智慧。
說是這樣說，但經驗與智慧又能值多少錢？這是下個階段的問題。
那麼，在這三十天我具體獲得了什麼呢？
真的成熟很多，CLAUDE.md 從 254 行降到現在的大小；規格拆成獨立的 spec；連結檢查改成腳本。
然後沒寫到的部分有：新增的待辦清單，有 SessionStart hook，還能同步到 Google 行事曆。第六篇雖然寫「Hooks 沒用過，歸類到不需要」，但它現在是每天開 session 第一個看到的東西。
我的知識庫在完賽後仍然繼續進化，越來越貼近我的生活與工作情境。
「LLM 在什麼情況下不可靠」，我在持續使用、並且持續質疑 AI 的過程中對這點深有感觸。
Skill 有寫、CLAUDE.md 有寫，跟「可靠執行」還差得很遠，什麼情況下 AI 會忘記、會變笨、會難用，然後最重要的：怎麼減少這種不可靠的情形，我認為這比我這三十天的任何實際產出都貴重，因為工具、產出可以讓 AI 做個七成八成，剩下的那兩三成必須有「理解」來彌補，而對於 AI 我可以說有一點自己的理解。
如果我當初不是參加鐵人賽而是去接案賺外快，我就失去這份理解，人類在犯錯中成長，參加鐵人賽本質可能是讓自己投身一個非常容易犯錯的情境，因為你要連續三十天產出優質文章，怎麼想都會出錯吧？
看看「一、實際發生了什麼」這節吧，我花了兩個月的時間寫三十篇文章，這讓我發現我有一個一直在拖累自己的特質：
「喜歡給自己畫餅」。
在每個專案開始的時候，我會先在心裡畫好「專案地圖」，每個步驟要做什麼都要計畫詳實，最好是連要寫什麼、什麼口氣都想好，這樣的專案推進方式屬於是給自己找罪受了。
真實的專案，或者說任何一件需要時間完成的任務，過程中一定是充滿調整、驗證、再執行，太詳實縝密的規劃方式在實際專案推進過程往往是另一種限制，這大大的拖累了我的專案進度，我花太多時間在規劃，兩個月的完成時間、反覆的推翻重規劃就是證據，檢討的時候對此深有感悟。
現在我知道自己最好的文章在哪種時候寫出來，是調整的時候，是犯錯的時候。
下次參加鐵人賽（如果還有下次的話），我應該會針對頻繁修改系列方向這點做調整，眼尖的讀者應該有發現，最後幾篇文章的 LLM Wiki 已經跟前二十篇是不一樣的東西，有很多修改我沒有完整寫在系列文章，因為修改本身就太花時間，寫得太詳盡又可能被推翻，所以後來是採取更多示範，而不是抓細節出來詳談。
當然也有一部份原因是我覺得寫太詳細的內容，會讓讀者有閱讀疲勞，講一點理論=>做一點實作，我覺得這樣比較好，但是頻繁修改的這個缺點應該還是多少會造成混淆，這是我這次鐵人賽參賽自己覺得最有問題的地方。
豪！那就這樣囉，這次鐵人賽是很不錯的經驗，感謝大家的觀看。
那我就下台一鞠躬。
啊
最後打個小廣告：我是一名五年以上經驗的軟體工程師，平常會在部落格寫一些技術跟應用相關的文章。如果你覺得這三十天的東西還有點意思，可以點開我的部落格，或是到 LinkedIn 找我聊聊。
一、知識庫為什麼會失敗（1–3）
二、動手蓋，並搞懂 AI 需要什麼（4–9）
4. 開工！建一個可能會被拆掉的知識庫
5. 知識庫可以解決使用 AI 時的上下文管理問題
6. 知識庫的 AI 協作內容該有什麼
7. 以為我懂 CLAUDE.md，直到官方說它只是一段訊息
8. 推坑：我用過最猛的筆記系統
9. 知識庫的兩個地基：Git 與建設歷程
三、資料怎麼進來（10–12）
10. 垃圾進、精緻的垃圾出——論採集（Ingest）
11. Ingest 實機示範：未消化、已消化、一大坨
12. 要不要乾脆抄我的？CLAUDE.md 拿出來對答案
四、蓋好之後，在裡面工作（13–15）
13. 知識庫蓋好之後，要怎麼在裡面工作？
14. 素材庫：讓創作輕而易舉一點
15. 跨裝置同步：像聊天一樣簡單
五、Query：查資料這件事比想像中難（16–19）
16. Claude 是怎麼查資料的？窺見 Harness 的冰山一角
17. Query 要怎麼設計
18. 花時間設計 Query，終究只是路邊一條！
19. 不用再複製貼上了，一鍵把網頁搬進 Obsidian
六、Lint 與 Harness Engineering：寫清楚不等於會被照做（20–23）
20. 定期 Lint 健康檢查？我不要
21. 跟著 Git commit 走——論 Lint 觸發時機與檢查邏輯
22. 鬼轉 Harness Engineering！
23. 七成是人家的！把 CLAUDE.md 砍到剩三成
七、公開站（24–25）
24. 偷偷停更的示範庫，和一個不會過時的公開站
25. 把 Obsidian 知識庫變成公開站：Quartz ＋ Netlify 部署實做
八、把模板交給你（26–30）
26. 系列收尾：弄了一個模板讓你開始自己的 LLM Wiki
27. 把 LLM Wiki 模板拿回家
28. 整包丟給 AI？這裡是現實世界
29. 把剩下的六支 skill 跑過一遍
30. （本篇）
note：
iThome鐵人賽
看影片追技術