團隊開始使用 AI coding 工具後，我常看到一個很自然、也很危險的動作：打開某個隱藏設定資料夾，看到裡面有設定檔、session、快取、資料庫、外掛紀錄，接著就把它當成「這個工具的標準專案結構」。
這個誤會很容易發生。資料夾確實看起來很像架構；檔名也都很技術。但對需要長期維護的工程團隊來說，看得到的檔案，不等於應該被管理的介面。
我後來會先把 AI coding 工具相關的檔案拆成四類：設定、指令、技能，以及執行期資料。這個分類比記住某個工具目前用了哪些資料夾更重要，因為工具會改版，資料夾會搬家，但責任邊界不應該跟著漂。
第一類：設定，是「這個工具怎麼運作」
設定檔處理的是模型、profile、權限預設、可信任專案、網路或工具行為等問題。它回答的是：這個 agent 在什麼條件下可以啟動？要讀哪一層設定？誰可以覆寫誰？
這一層最容易被低估的，其實是優先序。同一個行為可能同時受到命令列參數、專案設定、個人 profile、使用者全域設定和系統預設影響。如果團隊不知道最後是哪一層生效，就會出現很熟悉的場景：A 的電腦可以跑、B 的不行；本機測試正常、CI 卻用了另一個模型；安全限制明明寫了，卻被某個較近的設定檔蓋掉。
所以設定不該只是「把參數放對地方」。技術主管需要把它當成配置治理：哪些屬於個人偏好，哪些必須進版控，哪些只能由平台管理，哪些專案只有在被信任後才可以載入。設定層愈清楚，團隊愈不必靠口耳相傳猜環境。
第二類：指令，是「AI 在這裡該怎麼做事」
另一類常被混在設定裡的，是專案指令文件。它描述的不是模型溫度或 API 端點，而是工程脈絡：目錄怎麼分、哪些區域不能碰、測試要怎麼跑、資料庫 migration 有哪些規則、PR 前要做什麼檢查。
這類文件對人是 onboarding 文件，對 AI 則是持久的工作說明。它應該跟程式碼一起演進、可以逐層補充，也應該接受 code review。根目錄的規則講共通原則，子目錄再補上局部限制，通常比塞一份越寫越長的萬用指令可靠。
不過我不建議把它當成萬靈丹。指令文件不是把所有知識倒進去的地方，更不是把敏感資訊藏在 repo 裡的捷徑。它的價值在於提供穩定、可驗證的操作約束：先讀哪些文件、不要改哪些邊界、完成後如何驗收。講不清楚的規則，AI 讀再多也只是在猜。
第三類：技能，是可重用的方法，不是工具的私有雜物
當團隊把某個任務反覆做過幾次，例如釋出前檢查、資料修復、需求分析、測試診斷，真正值得沉澱的通常不是一段很長的聊天紀錄，而是一個 skill：觸發條件、必要前置、步驟、風險、失敗處理與驗證方式。
這裡的重點是把「怎麼做」和「工具把它放在哪裡」分開。不同 AI coding 平台對技能、命令、外掛的格式未必相容；即使檔案看起來很像，也不代表能直接搬過去用。前幾天能讀的格式，下一版可能就有新的作者入口或載入規則。
因此我會把技能內容視為團隊資產，把特定宿主的封裝視為 adapter。核心方法盡量用清楚文件、腳本與可測試輸出保存；需要接到特定工具時，再做薄薄一層轉接。這樣未來換工具，不會連整套作業方法一起被鎖死。
第四類：執行期資料，是證據，不是骨架
最常被誤當成專案結構的，是 session、cache、本機索引、SQLite、暫存下載、外掛狀態等執行期資料。它們很有用，因為除錯時能提供證據；但它們通常不是穩定 API，也不是應該手動建立、複製到每台電腦或放進 Git 的內容。
把這些資料當成骨架，會導致幾個後果：設定被快取覆蓋時找不到原因；團隊誤把本機對話或憑證狀態同步出去；升級後因內部格式變動而壞掉；更糟的是，大家以為備份了這個資料夾，就完成了可復原設計。
真正的可復原設計，應該備份可宣告的設定、版控中的指令與技能、必要的憑證管理流程，以及能重建執行環境的文件。執行期資料可以依風險決定是否保留為診斷證據，但不該默默變成唯一資料源。
從資料夾思維，轉成責任思維
我現在在導入 AI coding 工具時，會要求團隊先回答四個問題：
- 這份資料是在控制行為、描述工作方法，還是只是工具跑過後留下的痕跡？
- 它該不該進版控？如果要，誰 review、如何更新？
- 它是否包含個人偏好、專案規範或敏感狀態？三者能不能混在同一處？
- 工具明天換版或換宿主時，我們要移走的是檔案，還是可驗證的工作能力？
這幾個問題看起來樸素，卻能避開很多「照著網路上的目錄結構建一遍」的假安全感。AI coding 的工具層還在快速演化，今天的隱藏資料夾很可能只是實作細節，不是團隊契約。
身為技術主管，我不希望團隊對某一個 agent 形成信仰式依賴。我希望我們知道：設定在哪裡收斂、規則如何被閱讀、技能怎麼重用、狀態出了問題要如何重建與稽核。把這些邊界畫清楚後，工具可以替換，方法可以累積，工程治理才不會跟著某個資料夾一起消失。