設計定了、計畫拆了，終於要開始寫 code 了。但「寫 code」這件事在有 AI 工具的情況下，跟以前的做法有很大的不同。這一篇講的是我怎麼選技術、怎麼用語意工具來導覽和編輯程式碼，以及按照計畫逐步推進的實際體驗。
技術選型：為什麼是這些
在 spec 階段就已經決定了技術棧，但這裡簡單說明選擇的理由：
Next.js App Router：Server Components 讓資料載入更乾淨，不用在 client 和 server 之間搬來搬去。App Router 的巢狀佈局也很適合這個網站的結構（公開頁面和管理後台共用外層，但內層完全不同）。
Prisma ORM：型別安全的資料庫操作，schema 即文件。migration 管理也比手寫 SQL 可靠。
三語系 i18n：用 translation group 模式——每筆內容都有一個 translationGroupId，同一組的 zh-TW、en、ja 記錄透過這個 ID 關聯。這比把翻譯塞在 JSON 欄位裡更靈活，也更容易查詢。
pCloud 圖片存儲：把圖片從資料庫搬到外部儲存，避免 DB 體積膨脹。pCloud 的 API 夠簡單，upload 後拿到 URL 就可以用了。
Serena MCP：看懂程式碼再動手
這個專案最讓我驚豔的工具之一是 Serena MCP。它是一個語意化的程式碼導覽工具，跟一般的文字搜尋不一樣——它理解程式碼的結構。
比方說你想知道「Article model 被哪些地方引用了」，用 grep 搜字串可能會搜到一堆不相關的結果。但 Serena 的 find_referencing_symbols 可以精準告訴你哪些函式、哪些元件實際用到了這個 model。
我最常用的幾個功能：
get_symbols_overview：看一個檔案裡有哪些 function、class、interface，不用讀完整個檔案就能掌握結構
find_symbol：用 name path 找到特定的函式或型別定義，比方說 ArticleEditor/handleSave
replace_symbol_body：精準替換某個函式的實作，不會動到檔案裡的其他部分
insert_after_symbol：在某個函式後面插入新的程式碼，保持檔案結構的完整性
這些操作的共同點是：它們都是以「程式碼的語意單元」為操作對象，而不是以「文字行數」為單位。這讓修改程式碼的精確度高很多，也大幅降低了改 A 壞 B 的風險。
execute-plan：照清單推進
有了 plan 之後，實作階段用的是 execute-plan skill。它的運作方式很直接——讀取 plan 文件裡的任務清單，一個一個執行，做完一個打勾一個。
每個任務通常包含：
要建立或修改的檔案路徑
具體的程式碼內容
完成後要跑的測試或驗證命令
這個流程的好處是它保持了節奏感。不會陷入「這個做完接下來做什麼」的迷茫，因為 plan 裡都寫好了。每完成一個任務就 commit 一次，git log 回頭看會是一條清楚的進度線。
pCloud 遷移：一個實戰範例
舉一個具體的實作經驗。原本圖片是存在資料庫裡的（以 base64 的形式），但隨著攝影作品越來越多，DB 的大小開始成為問題。
這件事在 plan 裡被拆成了幾個步驟：
建立 pCloud API client
修改上傳 action，改為上傳到 pCloud 後存 URL
寫一個一次性的 migration script，把現有的圖片搬到 pCloud
移除舊的 Image model 和相關的 API route
每一步都是獨立可驗證的。做完 pCloud client 可以單獨測試上傳功能，不用等整個遷移做完。這種拆法讓大型重構變得不那麼可怕。
寫 code 的方式變了
回頭看，有了這些工具之後，寫 code 的方式確實不一樣了。以前是打開檔案從頭讀到尾，改完之後祈禱沒壞掉。現在是先用 Serena 理解結構、用 plan 確認方向、用精準的語意操作做修改，改完之後有明確的驗證步驟。
不是說工具替你寫了所有 code——技術決策和設計判斷還是你自己的事。但它們確實讓「把想法變成 code」這個過程變得更有條理、更可預測。
下一篇會講那些讓開發過程更順暢的輔助工具——RTK 怎麼幫你省 token、context7 怎麼讓你查到最新的文件、自動翻譯系統又是怎麼運作的。