前言：為什麼要花 30 天講一套流程,而不是直接分享程式碼

決定寫這個系列時,心裡其實有點猶豫。市面上不缺「AI coding agent 怎麼用」的分享,但大多數示範停在「叫 AI 生成一段能動的程式碼」這個層次——這對日常開發任務或許夠了,但對一套已經運作多年、沒有安全網的系統來說完全不夠。真正困難的,從來不是 AI 會不會寫程式碼,而是怎麼設計一套流程,讓 AI 在你不確定它會不會亂改的情況下,還能安全地動手。這 30 天想記錄的,就是這套流程實際是怎麼一塊一塊拼起來的——不是一開始就有藍圖,而是每一塊都源自一次真實的踩坑。

第一部回顧：為什麼要有「流程」

第一部（Day 1-5）從「AI 重構 legacy 系統的真正難點在哪裡」開始，一路講到分支基準、覆蓋率門檻、PHP 版本相容性驗證——這幾天的核心,是先建立起系列會反覆回到的那句主題句：AI 給出的「已確認」結論，永遠只在它實際查過的範圍內成立。 現在回頭看，這句話撐住了後面 25 天幾乎每一篇的論點,從資料庫連線、DI 容器陷阱到日誌去重鍵,同一個模式一次又一次地以不同外殼出現。

第二部回顧：讓 AI 安全動手的核心機制

第二部（Day 6-15）走了最長，從乾淨基準比對、獨立 subagent 驗證迴圈、SQL 收斂進 Repository（原則到實戰兩篇）、外部 API 介面化、廠商 package 遷移與隔離、DI 容器兩個真實陷阱，一路到數值精度的 bcmath 規則。這幾天想傳達的核心想法是同一件事的不同樣貌：不是要求 AI 更謹慎、更聰明，而是把它需要承擔的風險範圍，收斂到一個可以被驗證的具體邊界。 覆蓋率門檻讓「這行能不能動」變成一個可以量化的問題；Repository 讓「這樣改安不安全」變成「呼叫一個已驗證過的介面」；獨立驗證迴圈讓「這個結果可不可信」變成一份客觀的差集報告。

第三部回顧：AI Agent 的長期記憶與團隊協作

第三部（Day 16-23）從 CLAUDE.md 跟 skill 的分工開始，講到 skill 怎麼從一次性經驗提煉出來、記憶系統的四種類型、feedback 記憶怎麼記住「為什麼」而不只是「使用者不喜歡什麼」、記憶會過期這件事、多 agent 協作的委派時機、AI code review 怎麼避免誤判，一路到怎麼把踩坑經驗回饋給工具本身。這幾天讓我更確定一件事：讓 AI 記住東西不是目的，讓 AI 記住「對的東西、在對的層級、標注清楚適用邊界」才是目的。 一份記憶如果沒有標注「為什麼」跟「什麼時候還適用」，跟沒有記憶其實沒有太大差別。

第四部回顧：實戰案例

第四部（Day 24-29）用了六個真實案例，把前面 23 天的原則放回真實情境裡檢驗：以為是非同步問題其實是資料庫唯一鍵設計、大表 DDL 差點拖垮整個資料庫實例、日誌去重分組鍵在正式環境資料才會踩到的坑、從 legacy 錯誤處理遷移到結構化 logger、長期遷移計畫的進度追蹤怎麼避免依賴過期清單、以及這套方法論本身的邊界在哪裡。這幾篇案例合起來想證明一件事：這一路講的原則不是憑空想像出來的方法論，是從真實犯過的錯裡一條一條長出來的。

如果重來一次，會怎麼設計

老實說，如果重來一次，有些地方我會更早做，而不是等到踩過坑才補上。

我會更早建立去識別化跟一致性的自動檢查機制，而不是靠人工複查。 這個系列在寫作過程中，靠人工複查漏掉過真實識別字串,直到寫了一支自動掃描 script 才第一時間就抓到——這跟整個系列的核心論點其實是同一件事：人工判斷「應該沒問題」的可信度，永遠比不上一個可以被重複執行、結果可驗證的檢查機制。 這條教訓應該更早套用在寫作這件事本身上，而不是只套用在程式碼重構上。

我會更早把「原則跟實作分層」講清楚。 這個系列用的技術細節是 PHP 生態的，但方法論本身跟語言無關——這件事一直到系列進行到一半才明確講出來，其實應該在 Day 1 就講得更清楚，讓讀者從一開始就知道怎麼把內容遷移到自己的語言環境。

誠實面對這套流程的侷限

這套流程不是萬能的。它降低了風險，但沒有消除風險——Day 29 已經講過這點。更誠實地說，這套流程本身也是一直在演化的東西，不是一開始就設計完整的。 很多規則是先踩了坑，被使用者當場糾正，才補進 skill 或記憶系統裡的；有些風險是明知道存在，但基於資源限制,決定先擱著、之後再處理的。如果有人期待這 30 天的內容是一套「照著做就萬無一失」的完美方法論，那是我沒有講清楚——它更接近一套「持續在修正自己盲點」的紀律，而不是一份終極答案。

給讀者的實用建議

如果你也在用 AI agent 處理手上的 legacy 系統，幾個立即可行的第一步：

• 先問一句「這個結論的查證範圍是什麼」——不管是 AI 給的，還是你自己給的。這是這整個系列成本最低、效益最高的一個習慣。
• 從一個小範圍的重構開始，先建立起覆蓋率門檻跟乾淨基準比對這兩個機制，不用一次把整套流程都搭起來，這兩個機制的投資報酬率最高。
• 把每一次被糾正的經驗都寫下來，不管是寫進記憶還是寫進 skill——這是這套方法論能持續進化的唯一原因。

結語

回到系列一開始那句話：AI 從來不是重構 legacy 系統的瓶頸，AI 會不會「亂改」才是。寫完這 30 天，我更確定這句話——但也更確定,「亂改」的解法不是讓 AI 變得更謹慎,而是設計一套讓「查證範圍」跟「自信範圍」保持一致的流程,不管動手的是 AI 還是人。

謝謝陪我走完這 30 天。這套流程還在持續演化，如果你在自己的專案裡也踩過類似的坑，歡迎跟我聊聊你的版本長什麼樣。