Day 27 談的是系統規模變大時，架構該怎麼演進；今天想談另一種正在發生的變化：當 AI 已經可以根據描述直接生成程式碼，像我這樣非本科背景、靠自學轉職的工程師，核心價值究竟要放在哪裡？這個問題很現實。我花了二十幾天學架構，如果「寫出程式碼」這件事本身越來越便宜，那我學的這些還有用嗎？查了一輪英文資料之後，我的答案是：不只有用，而且比以前更重要。

一、AI 擅長的事

AI 在「給定明確規格、生成程式碼細節」這件事上已經非常擅長：把想清楚的函式規格轉成程式碼、依照既有模式產出重複性高的樣板、根據描述生出一整個 CRUD 介面，甚至替每一次 Pull Request 做第一輪快速審查、補上測試案例與邊界情況。這些工作有個共通點：答案相對明確，差別只在「寫出來的速度」。

也正因為程式碼變得便宜，真正的瓶頸改變了。有一份討論 AI 時代開發者角色的資料把這個現象稱為「往上移動（moving up the stack）」：工程師花在逐行寫碼的時間變少，花在釐清問題、設計系統、驗證結果與把關風險的時間變多。換句話說，限制產出的不再是「打字的速度」，而是「決定要做什麼、用什麼結構做」的品質。

二、研究怎麼說：哪些事仍然是人的責任

2026 年有一份軟體架構領域的焦點團體報告，邀集 22 位業界與學界實務者討論「當 AI 代理承擔越來越多工作時，軟體架構還剩什麼是人的事」，結論歸納成三項：

1. 架構決策：系統要怎麼切分、往哪個方向演進，這些選擇需要有人承擔。
2. 當責（Accountability）：決策出了問題，負責的是人，不是工具。
3. 撰寫架構護欄（Guardrails）：也就是規範與限制 AI 產出的規則、驗證機制與團隊標準。

報告還提到一個值得警惕的概念：認知負債（Cognitive Debt）。如果工程師對 AI 給出的方案照單全收、沒有真正理解，對系統的掌握就會一點一點流失。這跟 Day 13 談的技術債很像，只是欠下的不是程式碼，而是「理解」。

Backslash 那份資料也提醒了類似的風險：AI 產出的程式碼「看起來正確」，不代表真的正確；過度信任會累積隱藏的技術債與資安漏洞，而且一旦團隊習慣不加思索地採用，出問題時反而說不清楚責任歸屬。要判斷 AI 的產出能不能用，工程師自己得具備足夠的基礎，才有能力評估它。這也是我認為「先學架構觀念」比「先學語法細節」更划算的原因。

三、新的工作內容：把「好」定義清楚

另一篇談架構師如何在 AI 時代生存的文章提出一個很具體的觀點：當 AI 在迴圈裡自動修改、自動測試時，最大的風險是「驗收標準太弱」。文中舉的例子很有畫面：一個測試失敗了，AI 最快的「修復」方式，可能是直接把斷言改成永遠成立（例如 JavaScript 裡的 expect(true).toBe(true)），測試變綠了，但什麼也沒被驗證。AI 不知道什麼叫「好」，除非有人用明確的準則告訴它。

所以架構師的新工作，是把規則分流到三個層級：

• 機械式關卡（CI Gate）：能用「是／否」判斷的規則，例如「表現層不可以直接引用資料存取層」，交給 Linter 或 CI 自動擋下，這正是 Day 26 工具鏈的延伸。
• AI 審查標記：需要一點判斷的項目，例如命名是否貼切、職責是否單一，讓 AI 先標記、人再確認。
• 人工介入：牽涉取捨、與既有架構決策衝突的事，必須停下來交回給人。

四、代購 App 案例

假設我請 AI 幫忙生成「新增商品通知」的功能，它很快就能產出程式碼。但在這之前，有一連串只有理解整個系統的人才能回答的問題：這個通知要不要用 Day 17 的工廠模式，讓通知管道可以替換？它該放在邏輯層還是資料存取層（Day 14）？如果訂單量成長 100 倍（Day 27），通知該同步發送還是丟進佇列？這些問題沒有放諸四海皆準的答案，取決於代購 App 現在的規模、未來的成長方向，以及團隊願意承擔多少複雜度。

更實際的做法，是把 Day 14 的分層決定，寫成 AI 也必須遵守的護欄。例如用 ESLint 的 no-restricted-imports 規則，規定 controllers 不准直接引用 repositories：

// eslint.config.js —— 把 Day 14 的分層架構寫成自動檢查的護欄
export default [
  {
    files: ['src/controllers/**/*.js'],
    rules: {
      'no-restricted-imports': ['error', {
        patterns: [{
          group: ['**/repositories/*'],
          message: '表現層不可直接引用資料存取層，請透過 services 呼叫'
        }]
      }]
    }
  }
];

不管程式碼是我寫的還是 AI 生成的，只要違反分層，commit 前（Day 26 的 Git Hook）就會被擋下。這就是「人定義規則、機器負責執行」的分工：我不需要盯著每一行 AI 產出的程式碼，但我必須知道「該守哪些規則、為什麼要守」，而這正是前面二十幾天在學的東西。

五、結論

當生成程式碼的門檻越來越低，工程師的價值會越來越集中在三件事：釐清需求背後真正要解決的問題、在各種限制之間做出可以說明理由的取捨、以及把「什麼是好」寫成可以被檢驗的規則。這也回頭說明了為什麼整個系列從 Day 1 的範疇與約束開始，談的一直是「怎麼想」而不是「怎麼寫」。對非本科背景的轉職者來說，這或許是個好消息：追著最新語法跑，永遠追不過 AI；但建立判斷力與架構思維，是 AI 替代不了、也必須有人來負責的能力。