· React / Tanstack Query
原型能跑，不代表數字是對的：把 vibe coding 原型重構成 React 的紀錄
把一份約 9800 行的 HTML/JS 原型移植成 React + TanStack Query + Zustand，過程中最大的收穫不是架構，而是找出原型裡那些「不會報錯、只會悄悄算錯」的地方。
最近的文章
從實作問題出發，記下解法和取捨。
- · Software Engineering / Engineering Ownership
AI Agent 可以幫你寫 Code，但它不會替你承擔 Ownership
AI Agent 降低了實作門檻，但工程判斷與產品責任不會消失。Code 可以由 AI 產生，最後決定 Commit、Review 與 Merge 的仍然是工程師。
- · Cache / App Router
Next.js + TanStack Query 的 Cache 到底在快取什麼？一次搞懂三層快取
深入解析 Next.js 16 與 TanStack Query v5 的三層快取機制，搞懂 Query Cache、use cache 與 App Router Client Cache 的差異、生命週期與適用情境。
- · Tanstack Query / Zustand
當 Zustand 開始長得像半套 TanStack Query：一次 Legacy Server State 重構
當既有 Zustand store 開始同時負責 API cache、request dedupe、expiration、error handling 與 rendering state，同步問題也跟著出現。這篇記錄一次真實的 Legacy 重構：從找出 Server State 的責任邊界，到遷移至 TanStack Query，並改善資料一致性、錯誤恢復與 query identity。
寫程式時，我在意的事
一個元件，先做好一件事
當畫面、資料取得和副作用開始纏在一起，我會先拆清楚責任，再決定元件怎麼切。
先釐清狀態放在哪裡
伺服器資料和畫面狀態分開處理。用 TanStack Query 管資料與快取，讓 Zustand 留給需要共用的 UI 狀態。
把重複檢查交給工具
把型別檢查、lint 和測試放進 CI，讓每次修改都能重跑，也讓 Review 留時間討論設計與取捨。
處理過的問題
這些是我在實作中遇過，也持續整理成筆記的題目。
- 狀態重構 — 拆開既有專案的資料取得、快取與 UI 狀態，讓資料流更容易追蹤。
- 測試與 CI — 用 Vitest、Playwright 和 CI，補上容易被人工檢查漏掉的流程。
- 內容網站 — 處理 metadata、sitemap、圖片與快取更新，在 SEO 和載入速度之間做取捨。
- 權限邊界 — 透過 CSP、Route Handler 驗證與 DAL 分層，讓敏感邏輯留在伺服器。
