原則庫 Principles
這些是跨專案一再出現、可以直接打包帶走的工程準則。每一條後面都有真實的專案決策撐著，不是喊口號。
核心
想讓 AI 安全動系統，先把它能碰的開關收到最小。
想讓 AI 幫你操作系統，先把它能碰的開關縮到最少、而且每個動作都留下紀錄；這樣就算它（或人）做錯，傷害有限、也查得回來。
核心資料不先弄乾淨，AI 摘要再強也救不回來。
AI 摘要好不好，先看餵進去的資料乾不乾淨；資料一旦被弄亂、壓扁，後面再聰明的 AI 也救不回來。
核心與其強調能做多少，不如先確定哪一塊真的穩得住。
與其吹自己能做多少，不如老實圈出「我真的穩得住的那一塊」，在那塊裡做到漂亮；可信度比規格表更值錢。
核心要放手讓 AI 改資料，前提是改錯了能還原。
要讓 AI 真的動手改東西，先準備好「先試跑一次看結果（dry-run）、留操作紀錄、能備份、能一鍵還原」；能反悔，才敢放手讓它做。
核心可以讓 AI 幫忙判斷，但別讓它一個人下最後決定。
讓 AI（LLM，大型語言模型）幫你判斷可以，但要加護欄：輸出格式固定、結果存起來重用、再用規則核對一次、拿不準的交給人；別讓它一個人說了算。
核心把「為什麼這樣決定」寫下來，留給下一輪。
把「為什麼這樣決定」寫成紀錄留下來，下次自己或下一個 AI 接手時，能站在上次的結論上繼續，而不是重新踩一遍同樣的坑。
別把工具當孤島，當成同一條輸送帶來看。
別把每個小工具當成孤島；把「資料從哪來、經過誰、最後到哪」看成一條輸送帶（pipeline），才看得出中間哪一段沒人負責、哪一段在重複做。
先把領域裡最關鍵的定義講死，AI 才不會亂猜。
先把這個領域最關鍵的定義講死（例如某個角度、某個方向到底代表什麼），AI 才不會給出「聽起來合理、其實工程上是錯」的答案。
出問題時，先確認哪份資料才是對的，再決定修哪一層。
出 bug 時先找出「哪一份資料才是正確的那一份」（source of truth），再判斷錯在哪一層；在錯的地方修，只會生出新的 bug。
動手前先想清楚「完成後該是什麼樣子」，再倒推步驟。
動手前先把「做完長什麼樣、怎麼算驗收過」寫成清楚的規格（spec），再倒推要做哪些步驟；不然改到一半很容易走偏。
規則寫進設定檔，別寫死；重跑結果不變，就是最便宜的檢查。
把規則寫在設定檔、而不是寫死在程式裡（hard-code），之後好改也好維護；而且「同樣輸入再跑一次、結果幾乎不變」（idempotence）就是一個很便宜的正確性檢查。