每個星期都有新模型、新參數、被棄用的功能，或突然出現的全新能力，令昨天的工作流程變得稍微過時。對一間同時開發多個產品的小公司而言，問題不是「是否使用 AI」，而是如何在工具不斷變化時仍然保持穩定交付。
我們的答案是把 AI 當成執行層，而不是記憶層。 長期上下文保存在 Obsidian 和專案文件中，Claude 與 Claude Code 讀取這些上下文，然後完成具體工作。
技術棧
Glia 的產品組合橫跨 Astro、React、React Native、Expo、Supabase、TypeScript 和 Tailwind。不同產品有不同需求，但我們盡量保持相同的設計語言、工程規律和驗證方式。
AI 工具在這裏不是裝飾。它們協助撰寫實作計劃、檢查程式碼、整理測試結果、產生報告，並在跨產品的上下文中保持一致。
上下文就是一切
每個 Glia 專案都有一組標準上下文文件：專案狀態、目前任務、決策紀錄、會話筆記及技術限制。代理開始工作前先讀取這些文件，結束工作後再把結果寫回。
這樣做的目的很簡單：如果上下文沒有被寫下來，下一次工作就不存在。AI 不能靠記憶可靠地接續專案，必須靠可讀、可審計的文件。
建置提示模式
我們把大型任務拆成清晰的建置提示：目標、檔案範圍、不可碰觸的邊界、驗證方式、輸出格式。這些提示不是為了微管理模型，而是為了讓它知道什麼才算完成。
一個好的提示會明確說明：哪些資料是事實、哪些地方仍被阻塞、哪些操作需要人工批准。這令 AI 更像可靠的工程同事，而不是一個需要不斷猜測意圖的文字框。
保持更新而不被淹沒
我們不追逐每一個新功能。相反，我們把變更分為三類：立即改善交付的功能、值得測試但不影響主流程的功能，以及暫時忽略的噪音。這讓團隊能受益於新工具，同時不把整個工作方式交給每週的產品公告。
我們做錯了什麼
早期最大的錯誤，是把太多上下文留在聊天紀錄裏。聊天很方便，但不穩定、難搜尋，也不適合作為專案真相來源。把上下文移回文件之後，AI 工作才真正變得可接續。