五步起手式,每一步配一件刻意不做的事

Day11 [llm-wiki] 如果你要自己蓋一個:五步起手式、12 條習慣,和我繞過的遠路

Day10 結尾給了四句起步順序,今天把它展開成可以照做的版本。CLAUDE.md 201 行逐段盤完之後最反直覺的一筆是:行為準則只佔 14 行,路由與結構佔掉一半。skill 從 9 個開始,現在 15 個,中間有 10 個名字已經退場。這篇講五步起手式、每步配一個我實際付過的代價,12 條寫進 skill 才會生效的使用習慣,加上我實際的 routines(半年只有 42 個活躍天,斷過兩次一整個月)。文末附一段可以直接複製給 AI 的建置 prompt,它會先訪談你 12 個問題,再照你的答案長出你自己的骨架。

September 25, 2026 · 6 分鐘
Raw / Wiki / Schema 三層分工與各域檔案數

Day10 [llm-wiki] 756 個 markdown 怎麼被管住:三層架構、域優先、15 個 skill

前兩天都在講這個筆記庫的儲存層——搬家的決定,和雲端同步碟咬出來的三類症狀。今天正式介紹它本身。Karpathy 的 LLM Wiki 架構是 Raw / Wiki / Schema 三層分工,我加的是「域優先」——用生活域當頂層資料夾,讓查詢有路徑可循,LLM 每次只讀 2 到 4 個檔而不是掃全庫。這篇講五個取捨:為什麼不用 RAG、為什麼域優先、為什麼 raw 不到五個檔不准開 wiki、為什麼規範要用 hook 擋、以及 skill 怎麼從原子指令收斂成管線。附三個實際踩過的判斷錯誤。

September 24, 2026 · 3 分鐘
iCloud 咬人的三種方式對照表

Day9 [llm-wiki] iCloud 咬人的三種方式,和我為它長出的三層防線

Day8 只交代了搬家的決定,把事故本身整篇往後推。這篇補上:一個同時活在兩台機器上、又刻意不用版本控制的 vault,被 iCloud 咬出的三類症狀——檔案脫水成佔位檔、rename 被雲端還原、以及最危險的靜默衝突副本(本尊消失、副本才是新版)。還有我為它長出的三層防線:CLAUDE.md、PreToolUse hook、定期巡檢,各自攔在錯誤的不同時間點,也各自有攔不到的東西。

September 23, 2026 · 2 分鐘
iCloud、Obsidian Sync、git 三個方案對三個目標的達成狀況

Day8 [llm-wiki] 被 iCloud 卡了五個月,換到 Obsidian Sync 才發現它同步不了 .claude

放在 iCloud 的第二大腦 vault,五個月累積了檔案脫水、衝突副本、rename 被還原一整套症狀(細節明天單獨寫一篇)。搬到 Obsidian Sync 才發現它排除所有 dot 資料夾,.claude/ 的 15 個 skill 和 4 支 hook 一個都不同步。這篇記錄三個方案怎麼比、為什麼最後整個 vault 改用 git,以及三個坑:文件宣稱可攜但程式碼寫死、dispatcher 靜默不執行、我自己把路徑長度算錯。

September 22, 2026 · 5 分鐘
店家頁的統計摘要卡片,下方是常見風味 chips

Day7 [coffee-review] 測試全綠,功能卻永遠是空的:查詢沒 select 的欄位

店家頁的「常見風味」在線上永遠是空的,但負責統計的純函式有十幾條測試、全綠——問題不在算法,在查詢根本沒撈那兩個欄位。這篇記錄為什麼不直接把欄位加進去、假的 Supabase client 要假到什麼程度才抓得到這種 bug,順帶收掉草稿按「還原」就被清掉與全新安裝 SQL 缺欄位兩件,以及驗證修正時我怎麼用一行 git 把自己的修正刪掉。

September 21, 2026 · 5 分鐘
記錄列表上的沖煮與杯測兩種卡片

Day6 [coffee-review] 把「杯測」這個名字還給杯測:一場多杯的記錄類型

coffee-review 原本的「杯測」其實是自己沖一支豆,真正的杯測是一次擺 N 杯、每杯用編號識別。這篇記錄舊名字讓位、編號預設手動、未評分當成一級狀態這些產品取捨,為什麼資料分成兩張表而不是一個 jsonb 陣列,以及一組評分元件怎麼輪流裝 N 杯。

September 20, 2026 · 3 分鐘
統一後的店家選取器,本地找不到時列出 Google 地圖結果

Day5 [coffee-review] 品鑑表單上的「店家」:筆記搬進表單、搜尋合成一格

Coffee Review 品鑑表單最上面的「店家」有兩個問題:店家筆記只能從店家頁填,所以沒人填;選店家又拆成「選擇」和「新增」兩套,猜錯就撞 unique constraint。記錄把筆記搬進表單、把搜尋合成一個輸入框時的取捨(筆記要不要自己的儲存鍵、dirty 跟誰比、什麼時候才問 Google),以及 code review 才抓出來的三個坑:listener 疊兩層讓 chip 點了沒用、失敗 toast 被成功訊息蓋掉、把 LatLng 的方法拆下來呼叫讓從 Google 新增店家整條壞掉。

September 19, 2026 · 2 分鐘
兩個 Access application

Day4 [art-tracking] 掛上自己的網域,並用 Cloudflare Access 擋在登入後面

Art-Tracking 上線後的第一個問題:只有 workers.dev 網址、API 全 401。記錄把它掛上 art.kiwi-walk.com、用 Cloudflare Access 保護整站卻讓 agent 路徑 bypass 的取捨,Worker 端怎麼自己驗 JWT 做到 fail closed,以及靠 302 裡的 AUD 抓出 policy 設錯的過程。

September 18, 2026 · 5 分鐘
第一版與第二版的技術棧對照

Day3 [art-tracking] 技術選型:為什麼從 Vercel + Supabase 搬到 Cloudflare,而不是像 coffee-review 用 GitHub Pages + Supabase

Art-Tracking 第一版跑在 Vercel + Supabase 上,第二版(2026-09)整個搬到 Cloudflare Workers。這篇講為什麼不能像 coffee-review、commute 一樣用 GitHub Pages + Supabase,為什麼不留在 Vercel,以及 Hono、Drizzle、D1、R2、Vitest workers pool 這幾個選擇各自的理由與代價。

September 17, 2026 · 5 分鐘
展覽首頁

Day2 [art-tracking] 看展追蹤器要做什麼、不做什麼:規劃時的六個取捨

Art-Tracking 第二版動工前,先決定它是給誰用、抓什麼、狀態怎麼分、首頁要不要逼我表態、排序聽誰的、來源壞了怎麼辦。這篇記錄六個產品面的取捨與背後的理由,以及每一個取捨落到資料模型、ingest 合約與程式碼上長什麼樣。

September 16, 2026 · 5 分鐘