這次參加鐵人賽，本來是想寫一個「教大家怎麼做」的系列文章，沒想到寫的過程中遇到這麼多問題。
每當我覺得這個版本很完整了、功能很好用了，過個幾天又發現更大的問題，不斷地修修補補，害我文章也重寫了好幾遍。
重寫到後來甚至給了自己「這系列不接受再次重寫」的規則，現在每次想重寫 AI 都會提醒我：「這個已經屬於重寫」並且要我停手。
從一開始的「教學文章」寫到後面慢慢地變成「過程分享」。那種方法論、手把手教學的味道也漸漸淡掉了，雖然直覺告訴我這樣沒關係。
但是讀者仍然需要一個參考，我覺得。
因為我猜讀者在看文章的時候，大部份都不是在找一個「導師」，更多的是想看看別人怎麼做，給自己一點啟發，畢竟不是大家都有時間低頭研究一件事的。
Query 規則有什麼隱藏雷點、CLAUDE.md 應該長什麼樣子什麼沙小的，下班後誰還管這麼多，把時間花在感興趣的事物上比較實在。
所以「提供參考」，成了現在我要做的事情，問題出在這個參考，我隨時會改動。
拿我自己的知識庫來說，第四篇〈開工！建一個可能會被拆掉的知識庫〉本來是想建一個「陪大家一起做」的知識庫。
記得寫到第八還是第九篇，我所有的改動都還會同步到這個示範知識庫。
然後我就停止更新它了。
因為沒必要啊，首先拿來示範的話資料量不足，測不出問題。
其次是我對知識庫做的改動已經多到同步到示範庫是一件很麻煩的事情。我的心力都放在真的在使用的知識庫了。
這讓我了解到，文章只是「快照」，是某段時期的截圖，會過時。
然後再回頭看以前寫的「過時文章」，看完讓我很不舒服，因為我感覺我好像在提供錯誤資訊誤導讀者，我不要這樣。
所以我要建一個 Wiki 公開站，裡面放真實資料、設定，過濾掉不能公開的內容（像是我啊罵內褲的顏色）後，提供給「想建個人知識庫」或是「想學 Harness Engineering」的人參考。
我加上「想學 Harness Engineering」是因為調校知識庫的過程中，我發現本質上我是在管理 AI 在一個專案下取用 Context 的方法與行為，這可以應用到一般的專案，尤其是大型程式專案，已經屬於 Harness Engineering 的範疇了。
所以就這樣，我現在要分享我怎麼做這個 Wiki 公開站，可以的話寫個兩篇左右。
拆解成正式需求：
顯性需求：給讀者一個「參考」。
隱性需求：第四篇建的示範庫，本來就是想解決這個問題，後來卻停更了——資料量不夠，測不出真實問題；而且知識庫的改動速度，已龐雜到沒有心力再手動同步一份副本。
真正的需求規格：讀者要的不是另開一份要我手動維護的教材，是一個活的、跟著 master 走的真實系統。
讀者對象也拆成兩種：
雙受眾設定。
成本限制：免費。
安全邊界：本人在用的 repo 本身要維持 private，不受影響。
資料外流風險：不想公開的內容不能外流——而且這個風險不只是資料夾層級（哪個資料夾能不能看），還包括內容層級（同一頁裡混雜可公開跟不可公開的內容）。
方案一：GitHub Pages 免費方案 → 否決。一開始是因為這要求整個 repo 公開，後來只是覺得這樣不夠酷。
方案二：Cloudflare Pages + Access → 技術上可行，免費層可以做到資料夾層級的權限管理（最多 50 人）。但最後否決，不是技術問題，是感覺很麻煩，沒時間弄 Cloudflare 了，都要重學。
方案三（最終選型）：Quartz v5（Obsidian template，吃 wikilink，跟我現有的 Markdown／wikilink 格式直接相容）當產生器，Netlify 免費層當部署平台（只公開 build 出的靜態網頁，原始檔案不外流），GitHub 開出獨立分支 public-site 隔離要公開的內容。
分支隔離：切一個 public-site 分支出來，雖然跟 master 共用 git history，但因為整個 repo 本身是 private，這不構成外流風險。
同步紀律：只用 git checkout <path> 逐頁複製，或 cherry-pick 特定 commit，絕對不對這個分支做整支 git merge——這個細節是 AI 叫我一定要補充的。
風險分兩種。
好抓的風險：資料夾層級的洩漏——哪個資料夾整個不能公開（自我內容、進行中專案等），白名單一次擋掉。
難抓的風險：同一頁常青主題內容裡，混雜著可以公開的方法論跟不能公開的個人細節。這種風險，路徑比對抓不到，得靠語意判斷。
這類風險最後逼出一條規則：機械不適用，語意判斷不可自動化——重要的判斷，不能單靠路徑或關鍵字這種淺層機制，一次性交給 AI 跑完就相信結果。
架構設計與風險評估這兩項是整個公開站最麻煩的地方，要定好規則，定好之後還要寫腳本，然後每次同步都要執行，把整個站架起來相比之下非常輕鬆。
下一篇實作。
iThome鐵人賽
看影片追技術