AI 程式設計的底層原則：壞程式碼在 AI 時代更為致命

原始來源與檔名：20260512_2026-05-12T093156+0800-AI 编程的底层原则.md

來源：[[@SaitoWu]] / X — 2026-05-09 原始檔名：2026-05-12T093156+0800-AI 编程的底层原则.md

NAPKIN | 餐巾紙

餐巾紙公式

Bad Code in AI Era = Exponential Entropy (AI amplifies mess). Vibe Coding / Specs-to-code = Divesting from Design. AI Workflow = Grill Me (Shared Blueprint) + Ubiquitous Language + TDD (Fast Feedback) + Deep Modules.

Matt Pocock 在他的演講中打破了「AI 時代隨便寫 Code 就好」的迷思。他指出，盲目依賴「寫規格讓 AI 產 Code (Specs-to-code)」本質上是一種放棄設計的 “Vibe Coding”。在爛代碼庫中，AI 只會在混亂上堆疊混亂。真正的軟體工程原則（如領域驅動設計的通用語言、TDD 測試驅動開發、以及 Ousterhout 提出的「深模組 Deep Modules」）在 AI 時代比過去 20 年更值錢。工程師的職責不再是敲鍵盤，而是「守住設計邊界」。

一句話

別以為有了 AI 就可以亂寫程式。在架構混亂的專案裡，AI 只會加速系統的崩潰。你必須用「Grill Me」技巧讓 AI 瘋狂追問你以對齊概念；用「通用語言」統一你們的對話詞彙；用 TDD (測試驅動) 限制 AI 一次不要寫太多；並且將系統重構成「介面極簡、內部複雜」的深模組 (Deep Modules)。AI 只是前線步兵，你必須是運籌帷幄的戰略指揮官，你的老派軟體工程基礎知識，現在是稀缺資源。

餐巾紙草圖

[ Shallow vs. Deep Modules in AI Coding ]

SHALLOW MODULES (Bad for AI)
[ Complex Interface ] -> [ Little functionality ]
* AI gets lost in a maze of details. It breaks things easily.

DEEP MODULES (Ideal for AI)
[ Simple Interface ] -> [ Massive, hidden functionality ]
* AI treats it as a black box. It modifies internals safely without breaking the whole system.

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

• 破除迷思: Code 變便宜了？錯。壞程式碼在 AI 時代最貴。在缺乏設計的架構下，AI 會引發「熵 (Entropy) 爆炸」。
• 解決方案一：對齊設計藍圖 (Grill Me):
  • AI 寫錯是因為沒有 Shared Design Concept。
  • 使用 Grill Me 提示詞，讓 AI 放棄直接寫 Code，先問你 40 個問題，直到理清需求樹的所有分支。
• 解決方案二：統一領域詞彙 (Ubiquitous Language):
  • 借鑒 DDD。讓 AI 掃描代碼庫，提取術語表 (Markdown 表格)。
  • 避免你說「用戶」，AI 改「帳戶」的悲劇，大幅縮短 AI 的思考與廢話。
• 解決方案三：控制反饋速率 (TDD):
  • 速率限制就是反饋速率。AI 喜歡一次寫一大坨，然後除錯地獄。
  • 強制 TDD (先寫測試，再寫實作)，逼迫 AI 踩煞車，小步快跑。
• 解決方案四：重構成深模組 (Deep Modules):
  • 壞程式 = 很多淺模組 (功能少，介面複雜)。
  • 好程式 = 少量深模組 (功能多，介面極簡)。
  • AI 最喜歡深模組，因為它只需理解極簡的介面，就能大膽修改內部細節。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

1. AI 是放大器，不是重構器: Specs-to-code 模式的問題在於，每次只修改規格而不關注整體架構，會導致系統逐漸腐化。AI 不會主動做高階架構抽象，它只會「在現有的泥沼中，幫你蓋出更精緻的泥巴屋」。
2. 工程師角色的轉變: 你的大腦無法追上 AI 產出程式碼的速度。因此，你必須把模組當成「灰盒」。你的職責是定義介面、編寫邊界測試、維護領域語言，而將具體的 if/else 實作細節外包給 AI。

關鍵證據

• 引用了多本軟體工程聖經的核心概念：Frederick P. Brooks 的《The Design of Design》(概念對齊)、Kent Beck 的 TDD、John Ousterhout 的《A Philosophy of Software Design》(深模組)。這些幾十年前的智慧，在面對當前最先進的 LLM 時，依然是控制系統複雜度的唯一解法。

邊界條件

• 何時 Specs-to-code 是對的: 文章強烈批判 Specs-to-code，但這主要針對「複雜的大型系統」。對於從零開始的單頁應用、拋棄式腳本，Vibe Coding / Specs-to-code 依然是快速驗證想法的有效手段。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

• 知識連結: 呼應了《ADLC 開發方式》與《SDD Writing Specifications for AI BDD》。Grill Me 就是一種協作推導 Spec 的過程；TDD 則是與 BDD 緊密結合的實作手段。這些文章共同指向一個結論：AI 時代的開發，核心在於建立「嚴謹的合約 (Contracts)」。
• 深層洞見: “AI 沒理解你，是因為你們沒有共享藍圖… 把概念對齊。” 我們常常抱怨 AI 幻覺，但實際上是人類自己的意圖模糊不清。AI 只是一面鏡子，照出了我們在設計階段的偷懶。
• 行動呼籲: 立刻在你的專案中引入 Ubiquitous Language。讓 Claude Code 掃描你的專案，產出一份 GLOSSARY.md，定義什麼是 Account，什麼是 User，什麼是 Subscription。將這份文件加入你的系統提示詞或 AGENTS.md 中。這會是你提升 AI 程式碼精準度投資報酬率最高的一步。