Best Practices

The Problem: AI Agents Forget, but the Task Doesn’t End 技術社群已經習慣「給人類看的 RFC」— Architecture Decision Records、incident postmortem、設計文件，模板都很成熟。但給 AI agent 之間用的非同步協作文件呢？少有公開討論。 最近處理一個跨三個 repo 的 schema migration：後端表結構改、前端 GraphQL 切換、行動端讀寫遷移，估計要 30+ 天，會跨越十多個獨立的 Claude session（不同時段、不同任務切片、不同筆電）。每次 session 結束、下一輪起來，前次的 context window 就消失了。問題不只是「上下文遺忘」，還包括： 上次 session 進度到哪？沒人記得。 之前否決過的方案？新 session 很容易「自信地重新提案」。 跨 repo 的「我改完了、等你那邊配合」訊息，怎麼跨越 session 邊界？ 某次踩的坑，下次會不會重蹈？ 我們最後長出一份 CUTOVER.md 放在獨立的 metadata repo，作為跨 session、跨 repo 的 out-of-band control plane。實戰一個月後，這份文件結晶出 8 個對 AI agent 特別有效的設計模式 — 它們幾乎都對應到分散式系統的經典概念。 The Architecture 每個 AI session 開場先 pull doc → 讀完上下文 → 完成任務 → push update。Doc 自己是獨立 repo，與三個 code repo 解耦，扮演純控制平面角色。 ...

引言:當業務主表需要翻轉 某個 SaaS 系統長期以「客戶資料表」為核心:所有訂單、文件、操作紀錄都用客戶 ID 當外鍵。但這個客戶表的資料來源是外部 POS 系統匯入,每天同步幾百筆,schema 由廠商定義。 業務發展後問題浮現:自己 SaaS 的會員表(users)才是真正的「人」 — 有登入、有偏好、有應用內行為。新功能(個人化推薦、訂閱管理、社交綁定)都需要以 users 為主軸。 於是有了一個經典的 schema migration 需求:主表翻轉(primary table pivot)。把業務邏輯的中心從 customers(外部 POS 匯入)轉到 users(SaaS 自家會員),但歷史資料、新進資料、系統相依、回滾風險全部都要顧到。 名詞解釋 開始拆解之前,定義幾個會反覆出現的詞: 詞 定義 主表翻轉(Primary table pivot) 業務主要 entity 從表 A 改成表 B Dual-write 寫入時同時寫舊欄位 + 新欄位,回滾安全 Partial cut-over 分階段切換,read 跟 write 不同步切 Hard cut-over(stop-the-world) 一次切完,downtime 短但 risk 大 Backfill 歷史資料補齊新欄位的 batch update Idempotent migration 重跑無副作用,cron / retry 安全 DISTINCT ON PostgreSQL 專屬去重 syntax,搭 ORDER BY 取每組第一筆 Pseudo entity 為了統一查詢介面而建的「假」實體 Link table ORM 多對多 join 表(user_id + entity_id) 為什麼選 dual-write 而非 stop-the-world 最直接的搬家方式是「stop-the-world cut-over」:選一個維護窗口,停寫入、跑 batch script、改完所有 reference、開機。但這個 SaaS 的條件不允許: ...

系列文章第 4 篇（完結篇）：整理所有實用技巧、最佳實踐和疑難排解方法，並提供 30 個立即可用的 Skill 靈感。 前言 歡迎來到「Claude Code Skills 完全指南」系列的最終篇！ 在前三篇文章中，我們從概念到實戰，從基礎到進階，全面探索了 Skills 系統。今天，讓我們將這些知識轉化為實用的指引和建議。 你將獲得： ✅ 完整的最佳實踐清單 ✅ 常見問題與解決方案 ✅ 除錯和優化技巧 ✅ 30 個實用 Skill 靈感 ✅ 可直接使用的完整模板 預計閱讀時間：15 分鐘 讓我們開始吧！ 最佳實踐指南 1. 命名規範 Skill 名稱 ✅ 好的命名： name: pdf-editor name: api-tester name: blog-writer name: code-reviewer ❌ 避免的命名： name: PDF Editor # 不要用空格和大寫 name: apiTester # 不要用駝峰式命名 name: Blog_Writer # 不要用底線 name: skill-1 # 不要用無意義的名稱 規則： ...