# Claude Fable 5 最後時光(?) - 這幾天我用 Fable 5 做了些什麼
https://ijuhsu.com/posts/personal-wiki-harness · 2026-07-11
Category: ai · Tags: claude-code, obsidian, tools, workflow, llm-wiki
---
這是這篇文章的 side project 成品——one prompt，單一 HTML 檔，Obsidian 直接開。Inspired by @runghuang_z
在 Fable 5 變相(?) 免費的這一週，我花了一些時間把它用得乾乾淨淨:P
今天分享一些我覺得非常有趣的 Prompt 給大家參考。
對我來說，在這幾天 Fable 5 大放送的時代，我更新了我的網站、增進了我的個人知識庫，最後也做了個小小的 side project :P
最重要的核心 - 告訴 Fable 5 未來的任務都會交給 Sonnet 等較低階模型，需要建好上端的方向及設定，而低階模型可以協助執行。
> **什麼是 harness？**
直譯是「馬具、韁繩」。在 AI 圈指的是圍繞著模型建立的框架，包含規範文件、權限設定、自動檢查腳本等。
想像模型是隻聰明的馬，但如果沒有好的韁繩和馬具，你可能沒有辦法輕易駕馭；如果把韁繩拉好了，無論是聰明馬或普通馬，都能走得很順暢哦！
本文所有的 prompt 都是我這陣子實際用過的，再請 Fable 5 校正成更通用的版本。你也可以試試看！
## 方向一：Make My Websites Great Again (?)
如果你有既有的 App 或網站的話，可以趁這時候建好你的規範並做全面性的檢查。
雖然我有不少小 App，但主要核心是現在的[《許 i 啾不認真》](https://ijuhsu.com)以及[《LinguaPass》](https://linguapasstw.com)，我就把主軸放在這裡：
我都習慣先開 Plan Mode，請 Fable 5 計畫後交由 Sonnet 執行。
分享幾個 Prompt 給大家：
1. **安全性檢查與網站最佳化**——重新做好安全性檢查及網站的最佳化
```text
請對這個網站做一次上線前／已上線的全面檢查，重點是安全性：
1. 掃描 OWASP 常見漏洞（XSS、injection、header 設定、暴露的 API key 或環境變數）
2. 檢查第三方整合的安全邊界（留言系統、金流／贊助連結、外部 script）
3. 檢查 robots.txt、CSP、CORS、rate limiting 等設定是否合理
4. 順便盤點效能與 SEO 的明顯問題
輸出格式：依嚴重程度分級（P0 必修／P1 建議／P2 可忽略），每項附具體的修法與檔案位置。
最後把所有修正寫成一份 Plan 文件（含前後對照碼），我會交給較低階的模型執行。
```
最後一句是關鍵——檢查交給高階模型，執行交棒給 Sonnet。
2. **效能 harness**——進入「[PageSpeed Insights](https://pagespeed.web.dev)」檢查我的網站，把拖慢網頁速度的元兇們設好 harness，確保這兩個網站及未來我建的網站不會遇到問題。先把 PageSpeed 報告整份貼給它，然後：
```text
（附上 PageSpeed Insights 完整報告）
請根據這份報告全盤評估我的網站效能：
1. 先記錄目前的分數與各項指標（LCP／FCP／CLS），當作 baseline
2. 依「實測影響大小」排序修復項目，不要照報告順序修
3. 如果某個修法會犧牲 UX 或既有功能，先告訴我 trade-off，我們要找到好功能 vs. 好瀏覽速度的平衡，而不是無腦衝分數
4. 修完後重測，把前後分數對照記錄下來
最後把這次的診斷流程、修復 checklist、誤判排除清單（例如已被 route-splitting 處理的重型庫不要動、<50KB 的小項目不要動）、以及不能碰的安全邊界（auth／金流），整理成一個「全域 web-perf skill」，讓我未來任何專案都能直接觸發，不用重踩一次坑。
```
最後那段就是 harness 思維：**修好一次不算贏，把經驗變成可重複觸發的 skill 才算**。
3. **Design harness**——把和 Claude Design 共建好的 Design System 建成更完整的 harness
```text
（附上 Design System 匯出檔或設計規格）
這是我用 Claude Design 建好的 Design System，請幫我把它變成這個專案的 design harness：
1. 把色彩、字體、間距、圓角、陰影整理成 design tokens（CSS 變數或 Tailwind config）
2. 在 CLAUDE.md 寫下設計硬規則：新元件必須使用 tokens、禁止 hardcode 色碼、哪些元件必須複用既有的
3. 列出目前程式碼中違反這套 DS 的地方，依影響排序
目標：未來任何模型幫我加新頁面時，照著規則走就不會跑出設計之外。
```
（我本來想用 claude_design MCP 直接 import，裝不起來，最後直接把 Design System 匯出成 zip 丟給它XD 條條大路通羅馬）
## 方向二：建立個人知識庫（適用於尚未建立的）
許多人拿 Fable 做人生導師、問了很多問題；我會建議既然都做了，不如一起建好你的知識庫吧！
什麼是「個人知識庫（LLM Wiki）」呢？最近相當紅的這個概念，是發源自 [Karpathy 的 LLM wiki](https://x.com/karpathy/status/2039805659525644595)（他後來也發了[完整的 gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)）；
不過我沒有像他那麼博學多聞有那麼多知識系統，我比較想要建立知識庫來－記錄我的人生軌跡、信念、抉擇、健康狀況，然後給我人生（無論職涯、健康甚至人生藍圖）不同的建議。
因為我已建好我的知識庫，所以我大致時間都放在方向三；
但如果你還沒有建的話我很推薦你先建立起屬於你自己的知識庫哦，尤其你若已經把 Fable 5 當人生導師的話！
首先，先用以下的 prompt 來建立你的個人知識庫架構（這是我根據自己踩過的坑整理出來的版本——重點是「給 AI 讀寫的結構」，不是給人看的漂亮筆記）：
```text
我想建立一個「個人知識庫」，概念參考 Andrej Karpathy 的 LLM wiki（https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f）：用 markdown 存放在 git repo，讓 AI（包括未來較低階的模型）可以查詢和寫入。但方向不同——他記研究主題，我要記錄我的人生軌跡、信念、決策、健康狀況，讓 AI 能給我人生各面向的建議。
請幫我建立以下架構：
1. 依人生領域分資料夾（domain），例如：career／family／finance／health／travel／lifestyle／reading，每個 domain 一個資料夾
2. 兩層導覽：根目錄 wiki/index.md 放「Domain 導覽表」；每個 domain 有自己的 index.md 列出該領域所有頁面和一句話簡介。AI 查資料時：先讀根 index → 再讀 domain index → 最後只讀目標頁面，不用全文搜尋
3. 統一的 frontmatter schema（寫成 system/schema.md）：每頁都要有 source（資料來源）、source_date、compiled（最後編譯日）、domain 欄位
4. 每個 domain 加一個 log.md 記錄該領域的更新歷史
5. 根目錄放一個 inbox.md 當碎片收件匣——先記再說，之後再分類
6. 寫一份 system/editor.md：AI 編輯這個 wiki 時的規則（例如：只記事實不記推測、日期用 YYYY-MM-DD、不把觀察升級成行動承諾）
建好架構後，開始訪談我來填入第一批內容：先從我最常需要 AI 幫忙的領域開始，一次問一批、編號、每批不超過 5 題。
```
其實大致這樣，你的個人知識庫的核心就建好了，未來就可以慢慢擴充！
## 方向三：Make My Wiki Great Again (?)
我的個人知識庫其實已經有點太大了，而且記久了就容易變成資料堆：
頁面過期沒人管、連結壞了不知道、想查東西要靠全文搜尋碰運氣 ;_;
所以這次使用 Fable 5，把我的個人知識庫升級成更有系統的知識庫：
有 lint（自動檢查）、有路由表（一張告訴 AI「這類資訊該去哪找、該寫進哪頁」的對照表）、有自動提醒。
核心想法：**wiki 不只是給人看的，也是給 AI 讀寫的**。
如果結構夠明確，連便宜的小模型都能查對地方、寫對地方，那這個系統才算穩。
### A. 弱模型最佳化：讓 Haiku、Sonnet 也不會迷路
第一步是把「靠模型聰明」改成「靠結構明確」 ;)
- 每個 domain（career / family / work / travel）建 `index.md`，當作該領域的入口
- 建 `system/schema.md` 統一所有頁面的 frontmatter 格式
- GitHub Actions 加防幻覺 guardrail、明確列出 `allowedTools`
- `line-wiki-write.md` 從「讓模型自己判斷」改成**確定性路由表**——查表就知道該寫到哪，Haiku 也不會寫錯地方
這也是感謝網路上的[大神開頭](https://www.threads.com/@gyozalab/post/DaS69OPFJxy)，讓我有機會可以把它最佳化：
```text
如果我這輩子只能用一次 Fable，如何最大限度地優化 Harness？
```
然後給它明確的前提與目標（最佳化版）：
```text
請研究目前這個知識庫的架構，告訴我還可以怎麼最佳化。
重要前提：未來我無法使用像你這麼高階的模型，只會用 Haiku／Sonnet 等較低階的模型來執行日常查詢和寫入。所以最佳化方向是「靠結構明確，不靠模型聰明」：
1. 導覽：低階模型能不能在 3 步內找到任何一頁？（根 index → domain index → 目標頁）
2. 寫入：低階模型知道新資訊該寫到哪一頁嗎？需不需要一張確定性的路由表？
3. 格式：每頁的 frontmatter 和條目格式是否統一到「照抄範例就不會錯」？
4. 防呆：哪些地方低階模型容易幻覺或寫錯？可以加什麼機械式的 guardrail？
每個建議附「為什麼低階模型需要這個」的理由，並依影響排序。
```
改完之後記得驗收——實際開幾個 Haiku session 測它會不會迷路：
```text
請根據 wiki/ 資料夾的知識庫回答以下問題。查詢方式：先讀 wiki/index.md 的 Domain 導覽表，再讀對應 domain 的 index.md，最後只讀目標頁面。
問題：我的博士學歷和畢業年份？
```
實測結果：Haiku 照「根 index → domain index → 目標頁」三步就答對了，Sonnet 更是完全沒問題——結構建好之後，日常查詢真的不需要高階模型。
### B. 決策與健康系統
wiki 不只存資料，也開始存「規則」，尤其是有些文件沒有太時常更新會讓個人知識庫越來越過時；
因此這次也建立了幾個重要的內容：
- `wiki/career/life-design.md`：人生設計文件——裁決規則、什麼該說好／說不、五年三路線
- `life-check` skill：決策檢查三模式
- `health-check` skill：接 Garmin 查睡眠 / HRV
- `system/playbook.md`：週／月／季操作手冊
人生設計文件的 prompt 是我從網路上看到後改寫的（原版是給沒有知識庫的人用的訪談流程；我因為 wiki 都建好了，最後加了一句讓它直接吃現有資料）：
```text
你是我的人生設計顧問。目標：產出一份「我的人生設計文件」，
以後我做重大決定前，會把它貼給 AI 一起檢查。
規則：
1. 先訪談，問過去不問想像：我做過最滿意／最後悔的決定、重複發生的困境、錢和時間實際花在哪（不是我希望花在哪）。一次一批、編號、最多兩輪。
2. 我說的和做的衝突時，以做的為準，衝突本身寫進文件。
3. 文件格式：
- 我的優先順序（用我的話寫，含決定的規則：當家庭和工作打架先保哪個、為什麼）
- 說好／說不的條件（各附一個我人生中的真實正例反例）
- 什麼狀態下禁止做重大決定（深夜／剛被拒絕／剛看到別人成功…），改成先做什麼
- 未來五年 2-3 條可能路線，每條的檢查點（何時、看到什麼訊號就該調整）
- 使用說明：遇到什麼決定查哪段
4. 不要心靈雞湯。每條具體到「照著做就能做」。證據不足的判斷標「猜測」。
（但你已有我很多資料，先依目前有的資料判定，不夠隨時問我）
```
文件產出後，再一段把它變成可以留給低階模型的資產（最佳化版，一次講完）：
```text
接下來請把它變成低階模型也能用的資產：
1. 把這套「決策檢查」寫成一個 skill：任何模型照步驟走就能執行，不需要自己判斷流程。至少要有三種模式——check（我遇到決定時拿文件來檢查）、update（做完決定後回寫結果）、review（定期檢查文件本身有沒有過時）
2. 建一份 system/playbook.md 操作手冊：我每週／每月／每季各該做什麼（例如週日清 inbox、每月更新財務、每季 review 人生設計文件），每項附觸發方式
```
實際長這樣——觸發 life-check 後它會先問你想跑哪種模式：
check / update / review 三模式，直接說模式名稱就能觸發
選 check 之後，以「要不要買 PS5」為例XDDD
它直接對照人生設計文件的 §3，問你「現在是衝動還是考慮過了？」，不給你心靈雞湯（為我的錢包感謝你）
### C. Harness 強化：機械式 lint
因為人會忘記維護，而 AI 模型雖然是建置的核心，但若沒有像 Fable 5 這樣好的模型也常會遇到問題，所以交給腳本（寫死的檢查程式，不靠 AI 判斷）來處理：
- `scripts/lint_wiki.py`：機械式 lint——檢查 frontmatter、過期資料、孤兒頁、壞連結
- `wiki-lint` command：兩階段 lint（先跑腳本抓機械問題，再讓模型做語義檢查）
- `settings.json` 縮窄 git 權限（禁 push / reset / clean）——AI 可以寫，但不能做破壞性操作
- `worklog` skill 加上 gn 時提醒 push
（lint 是「自動程式碼／格式檢查工具」的統稱——就像文書軟體的拼字檢查，但是檢查 wiki 頁面的健康度）
這一段其實沒有「請幫我建 lint」這種 prompt——它是一次**harness 漏洞掃描**的產物。我請 Fable 5 回頭看我自己的使用習慣：
一跑完就看到 30 個問題：P0 有矛盾未更新、健康數據 135 天沒收集、財務頁面 4 頁過期——都是我完全不知道的
```text
請觀察我過去幾個月在這個專案的使用習慣（可看 git log、現有的 skill 和設定檔），考量到我不是程式設計師，幫我做一次 harness 漏洞掃描：
1. 已知漏洞：目前的設定裡有哪些安全或品質風險？（例如 AI 有沒有不該有的權限——push／reset／刪檔）
2. 未知缺口：哪些檢查是「應該要有而我沒設計」的？優先考慮不用 AI、用腳本就能跑的機械式檢查（frontmatter 完整性、過期資料、壞連結、孤兒頁）
3. Token 節省：以我的使用習慣，哪些地方在浪費 token？（重複讀大檔、不必要的全文搜尋、該交給腳本的事叫模型做）
每項附具體做法，能寫成腳本或設定的直接寫，依影響排序。
```
lint script、git 權限縮窄、push 提醒，都是它從這句自己盤點出來的。
另外還有一個我覺得很關鍵的問題——弱模型不知道「什麼該進 wiki」：
```text
我常遇到換成低階模型後，它不知道什麼內容該寫進知識庫、什麼不該；聊完天我說「記到 wiki」它也不知道要記哪段。
請幫我建一份「wiki-worthiness checklist」寫進 harness：明確定義怎樣的內容值得寫入（新事實、決定、偏好、修正過去的記錄），怎樣的不值得（閒聊、暫時性任務、可以從程式碼推導的東西），並給每類一個判斷範例。目標是任何模型照 checklist 判斷都會得到一樣的結果。
說實在 wiki 是給 AI 看的——所以該由你來定義 AI 需要什麼。
```
### D. 自動提醒：讓系統主動找你
我是個超級仰賴 Google Calendar 的人XD 但像這種系統性的內容如果有 AI 可以幫忙提醒也會很方便。
所以我也做了這些：
- `calendar-sync` / `health-sync` skill：行事曆與健康資料同步進 wiki
- `staleness_check.py`：掛在 SessionStart hook，每次開 session 自動掃過期頁面 + 行前提醒
- 補齊 `admin-calendar.md`、`relationships.md`、`learning.md` 等頁面
從「我要記得去查」變成「一開工它就告訴我」，完美適合我這個健忘的懶人XD
這段的 prompt 也很日常，就是把痛點直接說出來讓它設計方案：
```text
我的知識庫裡有幾類資料需要定期更新（例如行事曆、健康數據、財務快照），但我一定會忘記。請幫我設計提醒與同步機制：
1. 每類資料寫一個 sync skill：一句話觸發就能把外部資料源同步進對應頁面
2. 過期偵測：寫一個腳本檢查各頁面的最後更新日，超過該類資料的合理週期（行事曆 7 天、健康 30 天、財務 30 天）就標記過期
3. 把過期偵測掛在 SessionStart hook 上——不要掛在特定指令上，因為我不會記得叫它。我每次打開 session，過期的東西要自己跳出來提醒我
設計原則：我就是健忘的懶人:P 所有「要記得做」的事都要變成「它自己來找我」。
```
它本來建議掛在我的 good-morning／good-night skill 上，我說「但我好像很少在這裡叫 gm/gn」——於是改成 SessionStart hook。
**跟 AI 討論方案的時候，誠實說出自己的真實習慣很重要**，不然設計出來的流程只會是理想中的你在用XD
希望上述這些內容對大家的個人知識庫有幫助！
---
## 方向四：好玩的 one-shot：Travel Atlas
那天在 Threads 看到這位[強者 runghuang](https://www.threads.com/@runghuang_z/post/DahwBFkkSQ0)做的，覺得太帥了吧！
他有提到這是讓 Claude 做成 HTML 互動式儀表板，但 prompt 來來回回修了很多次、沒有公開。
因為我的個人知識庫也有很多旅行的資料，就想試試 Fable 5 能不能一次做出來——所以先用 Gemini 請它幫我寫好 prompt 後再餵給 Fable 5。
> **順便分享**：Chrome 內建的 Gemini 實在太好用了——不只能回答目前頁面的問題，連 YouTube 影片摘要都做得到！這一開始的 prompt 就是由 Gemini 幫我寫的！
左：Threads 上那篇讓我心動的原文；右：直接叫 Chrome Gemini 根據那篇幫我寫 prompt
鏘鏘！這是成品！
67 趟、21 國、13 年，全部在一個 HTML 檔裡，Obsidian 直接開
雖然沒有那位大神做得好看（因為我加入了自己的 DS 反而沒有那麼美了Q_Q）但我覺得很夠用了！
用**一個 prompt**，讓 Claude 把 `travel-history.md` 編成互動 3D 地球儀——globe.gl + Chart.js + Tailwind，單一 HTML 檔，放在 Obsidian vault 裡直接開。
完整 prompt 如下。我實際上是分兩段做的（先做出骨架，再花了一小時跟它來回調光點、色系、運鏡XD），這裡幫大家把兩段合併成一個 one-shot 版本，直接貼就能少走我踩過的彎路：
```text
請幫我寫一個單一檔案的 HTML/JS/CSS 程式碼，做為我內嵌在 Obsidian 的「個人旅遊足跡儀表板（Travel Atlas）」。
### 1. 視覺風格與佈局
- **風格**：現代高質感、奶油白/大地色系，搭配細緻的陰影與圓角。
- **佈局**：
- **左側欄**：個人大頭貼、核心數據統計（Trips、Countries、Years）、地區分佈比例（圓環圖或圓餅圖）、歷年足跡長條圖。
- **中央主區塊**：一個高質感的 3D 互動式地球儀（可滑動旋轉、放大縮小、點擊標記），使用衛星雲圖材質，右下角加拉近／拉遠按鈕，不要自動旋轉（或極慢速）。
- **右側欄**：所有旅遊行程的清單卡片，包含國旗、行程名稱、日期、區域標籤，並有搜尋與分類切換鈕（All, East Asia, SE Asia, Europe...）。
### 2. 使用的技術與套件（請直接從 CDN 引入）
- **UI 樣式**：Tailwind CSS
- **3D 地球儀**：globe.gl（非常適合處理地理標記與點擊事件）。
- **圖表**：Chart.js（用於製作左側的圓環圖與長條圖）。
- **圖示**：Font Awesome 或 Lucide Icons。
### 3. 資料結構（請在 JS 中先寫一組 Mock Data 供測試）
每個旅遊紀錄（Trip Object）必須包含：
- id, tripName (例如: "FR-BE-NL Dec 2025")
- date (例如: "2025-12-15 ~ 2025-12-23")
- region (例如: "Europe")
- tags (如: "france", "belgium")
- coordinates (經緯度，例如巴黎: [48.8566, 2.3522])
- imageUrl (預留一個隨機圖片網址，如 Unsplash 巴黎鐵塔圖)
### 4. 地球儀標記：發光座標點（使用 htmlElementsData）
- **不要**使用預設的 pointsData，請改用 htmlElementsData 來生成標記，這樣才能用 CSS 完全控制樣式。
- **光點樣式**：
- 水藍色/青色（例如 #38bdf8 或 #2dd4bf），所有光點同色即可、不需依區域分色（在地球上分色反而看不出來）。
- 微小的正圓形（border-radius: 50%）。
- **發光效果**：用 CSS box-shadow 疊多層陰影，營造強烈的「外發光（Glow）」質感——不要做成向外快速暈染的波紋（會像地震圖）。
- **動態效果**：寫一個 CSS @keyframes「呼吸燈（Pulse）」動畫，輕微的放大縮小與透明度漸變。
### 5. 精緻的彈出資訊卡（Popup Card）
- 點擊任一光點時，在該座標上方彈出 HTML 資訊卡（其他開啟的卡片自動關閉）。
- **毛玻璃/奶油白（Glassmorphism）**風格：背景微透明、精緻圓角（rounded-xl）、柔和下陰影。
- 頂部放該地點縮圖（object-cover 填滿上半部圓角）；下半部排版：國旗 Emoji、地點名稱、日期與備註，字體小巧精緻。
- 右上角有小小的「x」關閉鈕，點地圖空白處也能關閉。
### 6. 互動功能需求
- **攝影機運鏡（Camera Fly-to）**：點擊光點或右側行程卡片時，觸發 globe.pointOfView()，讓地球平滑優雅地旋轉並 Zoom in 到該經緯度。
- **分類篩選**：點擊區域按鈕（例如 Europe），右側清單自動過濾，地球上也只顯示該區域的點。
- **年度篩選**：點選左側長條圖的年份，可以 filter 右側行程與地球上的地點。
- **搜尋**：搜尋欄支援行程名稱與國家。
請提供完整、無刪減且可直接執行的單一 HTML 程式碼。
```
因為我的旅遊資料本來就都在 wiki 裡，Fable 直接跳過 Mock Data 那步，把 `travel-history.md` 真實資料編進去了——這就是知識庫建好的好處 :P
如果你有用 Obsidian 的話，我用的是 **HTML Docs** 外掛，就可以直接在裡面開好 html 檔，也可以直接連到既有的頁面哦！
---
## 心得
Fable 5 實在是太好玩啦，這幾天真的把 Token 用爆了XD
我是 Claude Pro 方案而已所以現在爆 token 的機會變得超多，像在寫這篇的時候是我又在等 limit refresh 了哈哈哈。
不過在網路上也看到一句說得很對的話－「Fable 5 不會是最強的模型，在一生中你還會看到更多更強的模型出現。」所以沒有跟上這一波也不用太 FOMO。
這是一些有趣的小試驗，但在 AI 時代，各個模型會越來越厲害，所以可以記住這樣的概念：
> **用高階模型建好 harness 與計畫，再交給一般或低階模型執行。**
這次文章其實都是建立在這樣的基礎下來做的，所以無論你是使用 Fable 5、GPT 5.6 抑或是未來其他更厲害的模型，也都可以套用本次的文章來幫你完善你的內容哦！
希望這次的文章對大家有幫助！
你還有什麼有趣的 Fable 5 用法呢？歡迎留言跟我分享 :D