AI Coding 給我的不是效率，是重構自由
整理版優先睇
AI Coding 的核心價值不在於提升開發速度，而是賦予開發者「推倒重來」的重構自由。
這篇文章由一位資深開發者分享其從 2018 年低代碼平台開發到 2026 年 AI Coding 實戰的心路歷程。作者想解決的核心問題是：當現有框架（如 Next.js）成為開發瓶頸、系統架構變成沉沒成本時，開發者往往因為重構代價過高而選擇與技術債妥協。
作者透過一個實際的 AI 項目，展示瞭如何在兩天內利用 AI 重寫 170 個文件，將臃腫的第三方框架與不可控的 Agent Runtime 替換為自研的輕量化底座。整體結論指出，AI 徹底改變了軟件開發的成本結構，讓「持續重建」取代「維護歷史」成為可能，開發者不再需要為了穩定而忍受糟糕的架構。
這是一篇深度技術反思與實戰指南，分辨了傳統開發與 AI 輔助開發在決策邏輯上的本質差異，強調 AI 釋放的是開發者的判斷力而非單純的雙手。
- 重構決策轉變：過去重構是高風險決策，現在 AI 讓大規模代碼變更（如 2 天修改 170 個文件）成為低成本的常規操作。
- 框架主客易位：當 Next.js 等框架的約定限制了創新（如動態頁面生成），應果斷利用 AI 自研 Mini 框架，將系統從黑盒變回全可控的白盒。
- Agent 架構優化：放棄通用的 Claude Code Runtime，改為自研輕量級 Agent Coordinator，實現 Skill 數據庫化與熱更新，提升資源可預測性。
- 文檔驅動開發：在 AI 動工前先要求其生成設計文檔作為「合同」，防止 AI 過度設計，確保生成代碼符合預期接口。
- 拆解與約束技巧：重構應按依賴鏈（Auth -> 首頁 -> 核心）逐步遷移，並使用「反面約束」限制 AI 的發揮邊界，一次只處理一個模塊。
AI 大規模重構五步法
1. 畫邊界（定義刪減/保留/新建）；2. 搭骨架（拆解 Prompt 逐步實現路由與 SSR）；3. 遷業務（按依賴鏈搬家）；4. 換引擎（自研輕量 Agent）；5. 穩定化（補齊 Loading、部署腳本與文檔）。
重構判斷標準
滿足以下 3 條中的 2 條即應動手：1. 框架限制設計；2. 新需求需改核心結構；3. 已有更簡單的方案。
從「忍受技術債」到「兩天重建系統」
過去開發者常陷入理想與現實的拉鋸：明知地基偏了，卻因樓裡住人（業務在跑）而不敢動彈。作者在 2026 年的項目中遇到了 Next.js 框架限制動態渲染的問題，這次他選擇不再打補丁，而是利用 AI 在兩天內完成了一次徹底的重建。
AI 重構實戰：如何讓 AI 靠譜地幹活
AI 雖然強大，但它不知道代碼「為什麼」長這樣。重構的第一步必須由人來畫定邊界，明確哪些要刪、哪些要留。在執行階段，則需要將任務極度拆解。
不要說「幫我重構整個項目」，要拆成「實現路由掃描器」、「實現 URL 匹配」、「實現 SSR 入口」等具體環節。
另一個關鍵技巧是「文檔驅動」。在寫代碼前，先讓 AI 生成設計文檔（如文件路由、SSR 注水方案）。這份文檔就是你與 AI 的合同，能有效抑制 AI 隨意發揮導致的過度設計。
自研 Agent 引擎：從航母到快艇
作者反思了過度依賴通用 Agent Runtime 的弊端。Claude Code 雖然強大，但行為不可預測且資源消耗大。針對特定業務場景，自研輕量級編排層反而更穩定。
❌ "舊的報表生成是用 SDK 調 Python 實現的，幫我改成直調 API"
✅ "這是舊的 SKILL.md：[貼完整內容]
這是舊的 Python 腳本：[貼完整內容]
幫我合併成一個 TypeScript 函數，用 Claude API 流式調用"核心認知：軟件開發正從「維護」轉向「重建」
AI Coding 帶來的最大改變不是效率，而是「架構不再是沉沒成本」。當重構的代價降低到可以忽略不計時，代碼就不再是歷史包袱，而是可以隨時替換的資產。
2018年，我當時做緊低代碼流程引擎（BPM）。
嗰段時間有個症狀：每兩星期，我就想重構一次核心引擎。
唔係因為寫錯咗，而係因為我又諗到一個更合理嘅設計。
你明唔明嗰種感覺？就好似你起咗半棟樓，突然發現個地基偏咗3度。理論上應該推倒重來，但實際上——棟樓已經住咗人。
結果好現實：成個團隊被折騰得好痛苦，系統長期唔穩定，項目亦都行唔到去理想狀態。
嗰幾年我開始懷疑一件事：係咪我呢個人有問題？
係咪我太理想主義？係咪我應該學識「忍」？學識同唔完美嘅架構共存？
後來我確實學識咗。我學識咗打補丁（patching），學識咗喺錯嘅地基上面繼續起樓，學識咗同技術債和平共處。
但講真，嗰啲唔係成長，係妥協。
轉機發生喺今年
我做緊一個 AI Coding 項目。一開始用 Next.js 做底座，前期都算順利。
直到有一日，我需要做動態頁面生成——LLM 生成嘅 code 要可以即時編譯、即時渲染。
Next.js 話：唔得。
唔係技術上做唔到，係框架嘅「約定」將條路封死咗。SSR 行為唔透明，build 流程係黑盒，middleware 執行次序估唔到。我想做嘅每一件事，都要先搞清楚 Next.js 內部係點樣設計。
講白啲：框架由「幫你做嘢嘅工具」變咗做「你要服侍嘅老細」。
呢個時候得返兩條路：
喺舊框架入面打補丁，繼續忍 推倒重來
2018年嘅我會揀1，嗰陣年少無知嘅我只係敢重構核心，唔敢重構成個系統。
2026年嘅我揀咗2。
因為今次，我有 AI。
兩日，170個檔案，一次真正嘅重建
呢句唔係口號。我將個過程拆開嚟講。
Day 1：搭骨架
我冇去「擴展 Next.js」。我直接重新寫咗一套類似 Next.js 嘅 Mini Next.js。
技術選型：React + Vite + Express，另外加一個自研嘅 framework/ 目錄，入面有路由、SSR、client-side hydration、runtime 編譯呢四大模塊。
骨架驗證標準好簡單，只要呢3件事成立就得：
一個頁面可以做到 SSR 渲染 動態路由 [param]行得通Nested layout 可以運作
做到呢3點，底座就 OK 喇。剩低嘅都係喺穩陣嘅地基上面起樓。
Day 1 完嗰陣嘅心態係：有啲興奮，但唔敢開心得太早。始終骨架行得通同業務行得通係兩回事。
Day 2：搬業務 + 換引擎
業務遷移我冇一嘢搬晒，而係跟住 dependency chain 一個個搬：
認證流程（auth）→ 首頁 → workspace（動態路由）→ 報表編輯（最複雜的頁面）
每搬完一個頁面，我會停低行一次，確認冇爆。呢個節奏好重要——你唔可以儲埋到最後先驗證，如果唔係出咗事你根本唔知係邊一步搞成咁。
之後我做咗一件更關鍵嘅事：將 Claude Agent SDK 同 Claude Code 呢成套 AI Agent Runtime 全部剷走。
舊架構係咁嘅：
用戶請求 → Claude Code（Agent Runtime）→ SDK Tool Use → 調 Python 腳本 → 結果返回 SDK → 生成報表
問題喺邊？Claude Code 作為底座，食 resource 食到好似飲水咁，而且行為預計唔到——你叫佢生成一個 report，佢可能幫你重構咗三個 file 先。呢個唔係 Agent，呢個係一個好有主見嘅實習生。
新架構：
用戶請求 → 自研 Agent Coordinator → 意圖識別 → 加載 Skill → 注入 Prompt → 流式調 Claude API → 直接生成
講白啲：由「將成個 Claude Code 當成 runtime」變成「自己寫一個夠用嘅 Agent，LLM 負責決策同最終生成」。
本質變化係：由「依賴外部 Agent Runtime」變成「自研輕量 Agent + Prompt 編排」。自己協調 LLM 嘅 call，完成 report 智能生成，再集成動態頁面渲染同業務邏輯。安全、可控、resource 消耗可以預計。加或者改 Skill 唔使改 code 部署，直接 database 操作就得，仲可以熱更新（hot update）。
Day 2 完嗰陣嘅心態係：一種好奇怪嘅平靜。唔係嗰種"終於搞掂晒"嘅鬆一口氣，而係——"原來真係可以咁做"。
真實數據
framework/最關鍵嘅一個變化：系統由"黑盒"變到"完全可控"。
以前遇到 build 嘢有問題要翻查 Next.js source code 嚟估估下，而家直接改自己嘅 page-runtime.ts。SSR 行為、routing 匹配、middleware 執行——每一行 code 都係我寫嘅（好啦，係 AI 幫我寫嘅），每一行都睇得明。
方法論：點樣用 AI 做一次靠譜嘅重構
淨係講故仔冇用，我將呢次實戰提煉成一套可以重複使用嘅方法。
第一步：畫邊界（你嚟做，唔係 AI）
重構之前先填咗呢張表先：
| 要刪的 | |
| 要留的 | |
| 風險點 |
呢一步一定要你自己做。AI 唔知你個系統邊度痛、邊度要換、邊度仲可以撐多陣。佢只係知啲 code 長咩樣，唔知啲 code 點解會寫成咁。
判斷標準：滿足以下 3 條入面嘅 2 條，就係時候郁手喇——框架開始限制你嘅設計；新需求需要改核心結構；你已經有更簡單嘅方案。
第二步：搭骨架（AI 執行，你驗證）
呢一步嘅關鍵係Prompt 拆解。唔好話"幫我重構晒成個 project"，要咁樣拆：
第1輪："實現一個文件路由掃描器，掃描 app/ 目錄，
支持 page.tsx/layout.tsx/[param] 動態路由，輸出路由樹"
第2輪："基於路由樹，實現 URL 匹配，靜態路由優先於動態路由"
第3輪："實現 SSR 入口，用 renderToString 渲染匹配到的頁面"
第4輪："實現客戶端入口，用 hydrateRoot 接管 DOM"
一次只係做一個 module。AI 處理單一明確任務嘅表現，遠遠好過模糊嘅大任務。
仲有一個反直覺嘅技巧：用"反面管束"比"正面描述"更有效。例如話畀 AI 聽"唔好用第三方 routing library"、"唔好 support catch-all routing"、"唔好做排序優化，保持簡單"。AI 天生傾向過度設計，你一定要明確話畀佢知條界喺邊。
第三步：遷業務（逐步搬屋）
次序：auth → 首頁 → 動態頁面 → 核心模塊。
一個關鍵經驗：畀 AI 睇舊 code，而唔係描述舊邏輯。
❌ "舊的報表生成是用 SDK 調 Python 實現的，幫我改成直調 API"
✅ "這是舊的 SKILL.md：[貼完整內容]
這是舊的 Python 腳本：[貼完整內容]
幫我合併成一個 TypeScript 函數，用 Claude API 流式調用"
AI 可以喺舊 code 入面提取出你可能唔記得提嘅 edge cases。你口頭描述嘅邏輯，永遠都唔夠原始代碼咁完整。
第四步：換引擎（核心重寫）
呢一步嘅本質原則係：唔好"搵替代嘅 Runtime"，而係"自己造一個夠用嘅 Agent"。
我冇去搵"另一個 Agent 框架"，而係問自己：如果由零開始，我需要嘅 AI 編排層到底有幾複雜？答案係——其實冇咁複雜。
Skill 存落數據庫，Coordinator 做意圖識別，Prompt 做編排，API 做生成。唔需要 SDK，唔需要 Claude Code 當 Runtime，唔需要 Python Runner，亦都唔需要文件系統上面嘅 Skill 目錄。一個自研嘅輕量 Agent，夠用半年，夠搞掂報表智能生成、動態頁面渲染、業務邏輯集成呢三件事就得。
點解唔繼續用 Claude Code 做底座？兩個字：可控。Claude Code 嘅設計目標係通用型 AI Agent，功能強大但係消耗資源多，行為鏈路長而且好難預測。我哋嘅場景好明確——生成報表、渲染頁面、執行業務邏輯。用一個通用 Agent Runtime 嚟做專用嘅嘢，就好似揸架航空母艦去釣魚咁。
流式輸出自己寫返出嚟，比起依賴 SDK 更加可控。Token 用量追蹤、調用日誌、異常兜底呢啲運維能力都應該自己做——將核心能力交畀人哋嘅 Runtime，即係將命運交畀人哋嘅版本發佈節奏。
第五步：穩定化（唔好唔記得補返啲窿窿罅罅）
重構完唔代表完咗。我重構完之後又再提交咗 8 個 commit 嚟收尾：
fix page runtime miss loading hint — 補 loading 狀態
fix build mode problem — 修構建問題
fix access host problem — 修訪問控制
add deploy.sh — 補部署腳本
update docs — 補文檔
起碼留 20% 時間做呢件事。好多人重構完就覺得大功告成，結果上線之後各種細問題磨死人。
文檔驅動：一個被低估嘅實踐
今次重構入面，我喺寫 framework/ 代碼之前，先叫 AI 生成咗 7 份設計文檔：
由設計總覽、文件路由、嵌套佈局渲染、SPA 導航、SSR 注水，到 API 路由同埋術語表。
點解要咁做？
因為文檔係你同 AI 之間嘅「合約」。有咗文檔，AI 生成嘅代碼唔符合預期嗰陣，你可以明確指出「呢度同文檔唔一致」。冇文檔嘅話，AI 就會「自由發揮」——而 AI 嘅「自由發揮」通常就代表過度設計。
講白啲：叫 AI 先寫計劃書，你審批通過咗先至動工。先對齊接口，再寫實現。
核心認知：AI Coding 改變嘅唔係速度
如果你只係記住一句話：
AI Coding 唔係幫你優化舊系統，而係令你有能力放棄舊系統。
以前嘅軟件世界，重構 = 高風險決策。一上咗線就唔敢郁，架構變咗沉沒成本。你唔係唔想重構，係重構嘅代價太高——一個人要改 170 個文件，改到一半發現改唔返轉頭，嗰種絕望感我真係太熟喇。
而家唔同晒：
軟件開發正由「維護歷史」變成「持續重建」。
呢個唔係效率提升，而係自由度嘅躍遷。
返去 2018 年
嗰陣時嘅我一直想重構，但係做唔到。唔係能力唔夠，係當時嘅生產力唔容許。
一個人改 170 個文件？改完仲要保證所有功能正常？改到一半團隊其他人啲 code 仲喺舊架構上面堆上去？
係冇可能嘅。
所以我學識咗妥協。我話畀自己聽呢啲叫「工程素養」，叫「務實」。
但係而家轉頭睇返，嗰啲只不過係因為工具唔夠好。
2026 年，我用 2 日就完成咗一次真正意義上嘅系統重建。170 個文件，刪走咗三個核心依賴，起咗一整套自研框架。系統由黑盒變返白盒，由被框架牽住走，變成我話事。
好多人唔係能力唔夠，只係當年嘅生產力唔容許佢哋去做啱嘅事。
如果你都試過嗰種「我知道點樣做會更好，但就係郁唔到」嘅無力感——AI 正在釋放緊你。
唔係釋放你對手，係釋放你嘅判斷力。
呢個係「AI Coding 實戰」系列文章。
2018年，我在做低代碼流程引擎（BPM）。
那段時間有個症狀：每兩週，我就想重構一次核心引擎。
不是因為寫錯了。是因為我又想到了一個更合理的設計。
你知道那種感覺嗎？就像你蓋了半棟樓，突然意識到地基偏了3度。理論上應該推倒重來，但實際上——樓裏已經住了人。
結果很現實：團隊被折騰得很痛苦，系統長期不穩定，項目也沒走到理想狀態。
那幾年我開始懷疑一件事：是不是我這個人有問題？
是不是我太理想主義了？是不是我應該學會"忍"？學會跟不完美的架構共存？
後來我確實學會了。我學會了打補丁，學會了在錯誤的地基上繼續蓋樓，學會了跟技術債和平共處。
但說實話，那不是成長。那是妥協。
轉折發生在今年
我在做一個 AI Coding 項目。一開始用 Next.js 做底座，前期還算順利。
直到有一天，我需要做動態頁面生成——LLM 生成的代碼要能實時編譯、實時渲染。
Next.js 說：不行。
不是技術上做不到，是框架的"約定"把路堵死了。SSR 行為不透明，構建流程是黑盒，中間件執行順序猜不準。我想做的每一件事，都要先搞明白 Next.js 內部是怎麼設計的。
說人話：框架從"幫你幹活的工具"變成了"你得伺候的老闆"。
這時候只有兩條路：
在舊框架裏打補丁，繼續忍 推翻重來
2018年的我會選1，那時年少無知的我也只敢重構核心，不敢重構整個系統。
2026年的我選了2。
因為這次，我有AI。
兩天，170個文件，一次真正的重建
這不是一句口號。我把過程拆開來講。
Day 1：搭骨架
我沒有"擴展 Next.js"。我直接重新寫了一套類似Next.js的 Mini Next.js。
技術選型：React + Vite + Express，外加一個自研的 framework/ 目錄，包含路由、SSR、客戶端注水（Hydration）、運行時編譯四大模塊。
骨架驗證標準很簡單，只要3件事成立：
一個頁面能 SSR 渲染 動態路由 [param]能跑通嵌套 layout 能工作
做到這3點，底座就OK了。剩下的都是在穩固地基上蓋樓。
Day 1 結束時的心態是：有點興奮，但不敢高興太早。畢竟骨架能跑和業務能跑是兩回事。
Day 2：遷業務 + 換引擎
業務遷移我沒有一口氣全搬，而是按依賴鏈逐個遷：
認證流程（auth）→ 首頁 → workspace（動態路由）→ 報表編輯（最複雜的頁面）
每遷完一個頁面，我會停下來跑一遍，確認沒炸。這個節奏很重要——你不能攢到最後再驗證，那樣出了問題根本不知道是哪一步搞的。
然後我做了一件更關鍵的事：把 Claude Agent SDK 和 Claude Code 這整套 AI Agent Runtime 全部幹掉。
舊架構是這樣的：
用戶請求 → Claude Code（Agent Runtime）→ SDK Tool Use → 調 Python 腳本 → 結果返回 SDK → 生成報表
問題是什麼？Claude Code 作為底座，吃資源像喝水，而且行為不可預測——你讓它生成一個報表，它可能先幫你重構了三個文件。這不是 Agent，這是一個有主見的實習生。
新架構：
用戶請求 → 自研 Agent Coordinator → 意圖識別 → 加載 Skill → 注入 Prompt → 流式調 Claude API → 直接生成
說人話：從"把整個 Claude Code 當運行時"變成"自己寫一個夠用的 Agent，LLM 負責決策和最終生成"。
本質變化是：從"依賴外部 Agent Runtime"到"自研輕量 Agent + Prompt 編排"。自己協調 LLM 的調用，完成報表智能生成，再集成動態頁面渲染和業務邏輯。安全、可控、資源消耗可預測。新增或修改 Skill 不用改代碼部署，直接數據庫操作就行，還能熱更新。
Day 2 結束時的心態是：一種奇怪的平靜。不是那種"終於搞完了"的如釋重負，而是——"原來真的可以"。
真實數據
framework/ | |
最關鍵的一個變化：系統從"黑盒"變成了"全可控"。
之前遇到構建問題要翻 Next.js 源碼猜，現在直接改自己的 page-runtime.ts。SSR 行為、路由匹配、中間件執行——每一行代碼都是我寫的（好吧，是 AI 幫我寫的），每一行都能看懂。
方法論：怎麼用 AI 做一次靠譜的重構
光講故事沒用，我把這次實戰提煉成了一套可複用的方法。
第一步：畫邊界（你來做，不是 AI）
重構前先填這張表：
| 要刪的 | |
| 要留的 | |
| 要新建的 | |
| 風險點 |
這一步必須你自己做。AI 不知道你的系統哪裏痛、哪裏該換、哪裏還能再撐一撐。它只知道代碼長什麼樣，不知道代碼為什麼長這樣。
判斷標準：滿足以下3條中的2條，就該動手了——框架開始限制你的設計；新需求需要改核心結構；你已經有更簡單的方案。
第二步：搭骨架（AI 執行，你驗證）
這一步的關鍵是Prompt 拆解。不要說"幫我重構整個項目"，要這樣拆：
第1輪："實現一個文件路由掃描器，掃描 app/ 目錄，
支持 page.tsx/layout.tsx/[param] 動態路由，輸出路由樹"
第2輪："基於路由樹，實現 URL 匹配，靜態路由優先於動態路由"
第3輪："實現 SSR 入口，用 renderToString 渲染匹配到的頁面"
第4輪："實現客戶端入口，用 hydrateRoot 接管 DOM"
一次只做一個模塊。AI 在單一明確任務上的表現，遠好於模糊的大任務。
還有一個反直覺的技巧：用"反面約束"比"正面描述"更有效。比如告訴 AI"不要用第三方路由庫"、"不要支持 catch-all 路由"、"不要做排序優化，保持簡單"。AI 天然傾向過度設計，你得明確告訴它邊界在哪。
第三步：遷業務（逐步搬家）
順序：auth → 首頁 → 動態頁面 → 核心模塊。
一個關鍵經驗：給 AI 看舊代碼，而不是描述舊邏輯。
❌ "舊的報表生成是用 SDK 調 Python 實現的，幫我改成直調 API"
✅ "這是舊的 SKILL.md：[貼完整內容]
這是舊的 Python 腳本：[貼完整內容]
幫我合併成一個 TypeScript 函數，用 Claude API 流式調用"
AI 能從舊代碼中提取出你可能忘了提的邊界情況。你口頭描述的邏輯，永遠不如原始代碼完整。
第四步：換引擎（核心重寫）
這一步的本質原則是：不要"找替代 Runtime"，而是"自己造一個夠用的 Agent"。
我沒有去找"另一個 Agent 框架"，而是問自己：如果從零開始，我需要的 AI 編排層到底有多複雜？答案是——沒那麼複雜。
Skill 存數據庫，Coordinator 做意圖識別，Prompt 做編排，API 做生成。不需要 SDK，不需要 Claude Code 當 Runtime，不需要 Python Runner，不需要文件系統上的 Skill 目錄。一個自研的輕量 Agent，夠用半年，夠完成報表智能生成、動態頁面渲染、業務邏輯集成這三件事就行。
為什麼不繼續用 Claude Code 當底座？兩個字：可控。Claude Code 設計目標是通用型 AI Agent，功能強大但資源消耗大，行為鏈路長且不可預測。我們的場景是明確的——生成報表、渲染頁面、執行業務邏輯。用一個通用 Agent Runtime 來幹專用的事，就像開航母去釣魚。
流式輸出自己實現比依賴 SDK 更可控。Token 用量追蹤、調用日誌、異常兜底這些運維能力也該自己做——把核心能力交給別人的 Runtime，就是把命運交給別人的版本發佈節奏。
第五步：穩定化（別忘了補牆）
重構完不是結束。我重構後又提交了8個 commit 做收尾：
fix page runtime miss loading hint — 補 loading 狀態
fix build mode problem — 修構建問題
fix access host problem — 修訪問控制
add deploy.sh — 補部署腳本
update docs — 補文檔
至少留 20% 的時間做這件事。很多人重構完就覺得大功告成，結果線上各種小問題磨死人。
文檔驅動：一個被低估的實踐
這次重構中，我在寫 framework/ 代碼之前，先讓 AI 生成了7份設計文檔：
從設計總覽、文件路由、嵌套佈局渲染、SPA 導航、SSR 注水，到 API 路由和術語表。
為什麼要這麼做？
因為文檔是你跟 AI 之間的"合同"。有了文檔，AI 生成的代碼不符合預期時，你可以明確指出"這裏跟文檔不一致"。沒有文檔，AI 就會"自由發揮"——而 AI 的"自由發揮"通常意味着過度設計。
說人話：讓 AI 先寫計劃書，你審批通過了再動工。先對齊接口，再寫實現。
核心認知：AI Coding 改變的不是速度
如果你只記住一句話：
AI Coding 不是幫你優化舊系統，而是讓你有能力放棄舊系統。
過去的軟件世界，重構 = 高風險決策。一旦上線就不敢動，架構變成沉沒成本。你不是不想重構，是重構的代價太高——一個人要改170個文件，改到一半發現改不回去了，那種絕望感我太熟悉了。
現在不一樣了：
軟件開發正在從"維護歷史"變成"持續重建"。
這不是效率提升。這是自由度的躍遷。
回到2018年
那時候的我一直想重構，但做不到。不是能力不夠，是當時的生產力不允許。
一個人改170個文件？改完還要保證所有功能正常？改到一半團隊其他人的代碼還在往舊架構上堆？
不可能的。
所以我學會了妥協。我告訴自己這叫"工程素養"，叫"務實"。
但現在回頭看，那只是因為工具不夠好。
2026年，我用2天完成了一次真正意義上的系統重建。170個文件，刪掉了三個核心依賴，新建了一整套自研框架。系統從黑盒變成白盒，從被框架牽着走變成我說了算。
很多人不是能力不夠，只是當年的生產力不允許他們做對的事。
如果你也有過那種"我知道怎麼做更好，但就是改不動"的無力感——AI 正在釋放你。
不是釋放你的雙手，是釋放你的判斷力。
這是「AI Coding 實戰」系列文章。