Claude Fable 5 最後時光(?) - 這幾天我用 Fable 5 做了些什麼

Claude Fable 5 可以不用 API 計價，分享這一週時間，我如何用它建立 harness、打造連弱模型都能順跑的個人知識庫，和…一個 one-shot 做出來的 3D 地球儀 :P

2026/7/11 · 閱讀約 7 分鐘

Travel Atlas：67 趟旅程、21 國、13 年足跡的 3D 互動地球儀，一個 prompt 做出來的 — 這是這篇文章的 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 啾不認真》以及《LinguaPass》，我就把主軸放在這裡：
我都習慣先開 Plan Mode，請 Fable 5 計畫後交由 Sonnet 執行。

分享幾個 Prompt 給大家：

安全性檢查與網站最佳化——重新做好安全性檢查及網站的最佳化

請對這個網站做一次上線前／已上線的全面檢查，重點是安全性：

1. 掃描 OWASP 常見漏洞（XSS、injection、header 設定、暴露的 API key 或環境變數）
2. 檢查第三方整合的安全邊界（留言系統、金流／贊助連結、外部 script）
3. 檢查 robots.txt、CSP、CORS、rate limiting 等設定是否合理
4. 順便盤點效能與 SEO 的明顯問題

輸出格式：依嚴重程度分級（P0 必修／P1 建議／P2 可忽略），每項附具體的修法與檔案位置。
最後把所有修正寫成一份 Plan 文件（含前後對照碼），我會交給較低階的模型執行。

最後一句是關鍵——檢查交給高階模型，執行交棒給 Sonnet。

效能 harness——進入「PageSpeed Insights」檢查我的網站，把拖慢網頁速度的元兇們設好 harness，確保這兩個網站及未來我建的網站不會遇到問題。先把 PageSpeed 報告整份貼給它，然後：

（附上 PageSpeed Insights 完整報告）

請根據這份報告全盤評估我的網站效能：

1. 先記錄目前的分數與各項指標（LCP／FCP／CLS），當作 baseline
2. 依「實測影響大小」排序修復項目，不要照報告順序修
3. 如果某個修法會犧牲 UX 或既有功能，先告訴我 trade-off，我們要找到好功能 vs. 好瀏覽速度的平衡，而不是無腦衝分數
4. 修完後重測，把前後分數對照記錄下來

最後把這次的診斷流程、修復 checklist、誤判排除清單（例如已被 route-splitting 處理的重型庫不要動、<50KB 的小項目不要動）、以及不能碰的安全邊界（auth／金流），整理成一個「全域 web-perf skill」，讓我未來任何專案都能直接觸發，不用重踩一次坑。

最後那段就是 harness 思維：修好一次不算贏，把經驗變成可重複觸發的 skill 才算。

Design harness——把和 Claude Design 共建好的 Design System 建成更完整的 harness

（附上 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（他後來也發了完整的 gist）；
不過我沒有像他那麼博學多聞有那麼多知識系統，我比較想要建立知識庫來－記錄我的人生軌跡、信念、抉擇、健康狀況，然後給我人生（無論職涯、健康甚至人生藍圖）不同的建議。

因為我已建好我的知識庫，所以我大致時間都放在方向三；
但如果你還沒有建的話我很推薦你先建立起屬於你自己的知識庫哦，尤其你若已經把 Fable 5 當人生導師的話！

首先，先用以下的 prompt 來建立你的個人知識庫架構（這是我根據自己踩過的坑整理出來的版本——重點是「給 AI 讀寫的結構」，不是給人看的漂亮筆記）：

我想建立一個「個人知識庫」，概念參考 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 也不會寫錯地方

這也是感謝網路上的大神開頭，讓我有機會可以把它最佳化：

如果我這輩子只能用一次 Fable，如何最大限度地優化 Harness？

然後給它明確的前提與目標（最佳化版）：

請研究目前這個知識庫的架構，告訴我還可以怎麼最佳化。

重要前提：未來我無法使用像你這麼高階的模型，只會用 Haiku／Sonnet 等較低階的模型來執行日常查詢和寫入。所以最佳化方向是「靠結構明確，不靠模型聰明」：

1. 導覽：低階模型能不能在 3 步內找到任何一頁？（根 index → domain index → 目標頁）
2. 寫入：低階模型知道新資訊該寫到哪一頁嗎？需不需要一張確定性的路由表？
3. 格式：每頁的 frontmatter 和條目格式是否統一到「照抄範例就不會錯」？
4. 防呆：哪些地方低階模型容易幻覺或寫錯？可以加什麼機械式的 guardrail？

每個建議附「為什麼低階模型需要這個」的理由，並依影響排序。

改完之後記得驗收——實際開幾個 Haiku session 測它會不會迷路：

請根據 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 都建好了，最後加了一句讓它直接吃現有資料）：

你是我的人生設計顧問。目標：產出一份「我的人生設計文件」，
以後我做重大決定前，會把它貼給 AI 一起檢查。

規則：
1. 先訪談，問過去不問想像：我做過最滿意／最後悔的決定、重複發生的困境、錢和時間實際花在哪（不是我希望花在哪）。一次一批、編號、最多兩輪。
2. 我說的和做的衝突時，以做的為準，衝突本身寫進文件。
3. 文件格式：
- 我的優先順序（用我的話寫，含決定的規則：當家庭和工作打架先保哪個、為什麼）
- 說好／說不的條件（各附一個我人生中的真實正例反例）
- 什麼狀態下禁止做重大決定（深夜／剛被拒絕／剛看到別人成功…），改成先做什麼
- 未來五年 2-3 條可能路線，每條的檢查點（何時、看到什麼訊號就該調整）
- 使用說明：遇到什麼決定查哪段
4. 不要心靈雞湯。每條具體到「照著做就能做」。證據不足的判斷標「猜測」。

（但你已有我很多資料，先依目前有的資料判定，不夠隨時問我）

文件產出後，再一段把它變成可以留給低階模型的資產（最佳化版，一次講完）：

接下來請把它變成低階模型也能用的資產：

1. 把這套「決策檢查」寫成一個 skill：任何模型照步驟走就能執行，不需要自己判斷流程。至少要有三種模式——check（我遇到決定時拿文件來檢查）、update（做完決定後回寫結果）、review（定期檢查文件本身有沒有過時）
2. 建一份 system/playbook.md 操作手冊：我每週／每月／每季各該做什麼（例如週日清 inbox、每月更新財務、每季 review 人生設計文件），每項附觸發方式

實際長這樣——觸發 life-check 後它會先問你想跑哪種模式：

life-check skill 的三種模式選單 — check / update / review 三模式，直接說模式名稱就能觸發

選 check 之後，以「要不要買 PS5」為例XDDD

life-check check 模式實例：PS5 購買決策 — 它直接對照人生設計文件的 §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 回頭看我自己的使用習慣：

lint_wiki.py 掃描輸出：30 個問題，含 P0/P2/P3 分級 — 一跑完就看到 30 個問題：P0 有矛盾未更新、健康數據 135 天沒收集、財務頁面 4 頁過期——都是我完全不知道的

請觀察我過去幾個月在這個專案的使用習慣（可看 git log、現有的 skill 和設定檔），考量到我不是程式設計師，幫我做一次 harness 漏洞掃描：

1. 已知漏洞：目前的設定裡有哪些安全或品質風險？（例如 AI 有沒有不該有的權限——push／reset／刪檔）
2. 未知缺口：哪些檢查是「應該要有而我沒設計」的？優先考慮不用 AI、用腳本就能跑的機械式檢查（frontmatter 完整性、過期資料、壞連結、孤兒頁）
3. Token 節省：以我的使用習慣，哪些地方在浪費 token？（重複讀大檔、不必要的全文搜尋、該交給腳本的事叫模型做）

每項附具體做法，能寫成腳本或設定的直接寫，依影響排序。

lint script、git 權限縮窄、push 提醒，都是它從這句自己盤點出來的。
另外還有一個我覺得很關鍵的問題——弱模型不知道「什麼該進 wiki」：

我常遇到換成低階模型後，它不知道什麼內容該寫進知識庫、什麼不該；聊完天我說「記到 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 也很日常，就是把痛點直接說出來讓它設計方案：

我的知識庫裡有幾類資料需要定期更新（例如行事曆、健康數據、財務快照），但我一定會忘記。請幫我設計提醒與同步機制：

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做的，覺得太帥了吧！
他有提到這是讓 Claude 做成 HTML 互動式儀表板，但 prompt 來來回回修了很多次、沒有公開。
因為我的個人知識庫也有很多旅行的資料，就想試試 Fable 5 能不能一次做出來——所以先用 Gemini 請它幫我寫好 prompt 後再餵給 Fable 5。

順便分享：Chrome 內建的 Gemini 實在太好用了——不只能回答目前頁面的問題，連 YouTube 影片摘要都做得到！這一開始的 prompt 就是由 Gemini 幫我寫的！

Threads 原文貼文 + Chrome Gemini 幫我寫 Travel Atlas prompt — 左：Threads 上那篇讓我心動的原文；右：直接叫 Chrome Gemini 根據那篇幫我寫 prompt

鏘鏘！這是成品！

Travel Atlas 成品：67 趟旅程、21 國、13 年足跡的 3D 互動地球儀 — 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 版本，直接貼就能少走我踩過的彎路：

請幫我寫一個單一檔案的 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

#claude-code #obsidian #tools #workflow #llm-wiki

留言

載入中…