The Great AI Coding Methodology Debate: Process vs Vibe

最近同幾個香港做 startup 嘅朋友傾偈，大家不約而同提到一個現象：AI 寫代碼嘅能力已經唔係問題，真正嘅問題係「點解佢寫出嚟嘅嘢同我想要嘅差咁遠？」。呢個觀察其實道出咗 2026 年 AI coding 領域最核心嘅矛盾——當模型已經足夠強，瓶頸轉移咗去人類表達意圖嘅能力。而家業界正正喺度爭緊一套標準，三個方法論各自代表一種哲學：LID 要用 spec 串連意圖、SWE-ATLAS 主張最少前期思考、ALDC 堅持合約驅動嘅 TDD 流程。呢場 debate 唔止係技術選擇，而係關於你點樣理解「工程」呢件事。

LID：規格書先於一切，意圖必須可追蹤

LID（Linked-Intent Development）嘅核心主張好簡單：code 唔再係 artifact of attention，意圖先係。佢嘅操作邏輯係建一條「意圖之箭」（arrow of intent）：從高層設計（HLD）一路到細節設計（LLD），再到可測試嘅規格（EARS specs），再到測試，最後先到代碼。每一層都用明確嘅 ID 互相引用，形成一條可以雙向追溯嘅鏈條。

呢個方法論最犀利嘅洞察係：AI coding agent 唔係寫 bug，而係寫「意圖差距」（intent gaps）。即係模型以為你想要嘅嘢同你真正想要嘅嘢之間嘅落差。LID 試圖解決呢個問題，就係透過將意圖表達得夠明確、夠結構化，令 agent 冇空間自己揣測。改咗個設計？改 HLD，然後一路 cascade 落去 LLD、spec、test、code——全部自動更新。

但 LID 嘅代價係 Discipline。你必須認真 review 每一份設計文件，唔可以跳過任何 phase 因為「我已經知道要做咩」。佢用最少嘅 tooling（兩個 plugin、幾個 markdown template），但要求最高嘅人類投入。如果你願意付出呢個時間成本，你得到嘅係一個 coherent、self-documenting 嘅 codebase——因為 documentation 本身就係 system，code 只係 implementation 嘅副產品。對於要做大型系統、需要長期維護嘅香港 SaaS 團隊，呢個方法論嘅投資回報率其實好高。

SWE-ATLAS：Wireframe 先行，最少前期判斷

SWE-ATLAS 嘅立場完全相反。佢話：Claude Code 已經有晒 plan mode、goal、auto mode、dynamic workflows——你唔需要再包一層 framework 去重新發明模型已經做緊嘅嘢。SWE-ATLAS 嘅做法係做「最少嘅前期思考」（minimum upfront thinking）真正 de-risk 建設，而唔係寫 constitution 或者 task ledger。

佢嘅核心工具係 /plan:create-phase：用 targeted Q&A 搵出會真正搞垮個 project 嘅 unknowns，然後將所有嘢——wireframe、data flow、clarifications、decision matrices——打包成一個 self-contained 嘅 HTML document。用 HTML 而唔係 Markdown，因為 HTML 係更豐富嘅 canvas：真正嘅表格、SVG diagram、甚至可以互動嘅 slider。而人哋真係會 click 一個 HTML link 去睇 plan，但唔會打開一份 100 行嘅 Markdown plan。

SWE-ATLAS 嘅另一個核心概念係 free-will：一個可以自主做決策嘅 agent，喺 medium-to-high-stakes 嘅 fork 上（揀 stack、設計 schema、deprecate 人哋依賴嘅賴嘅嘢），佢唔會即刻攞最 plausible 嘅答案，而係 hold 住幾個 alternatives，用 codebase 嘅 evidence 去 grounding，模擬 blast radius，甚至嘗試 refute 贏家先 committed，最後將決策記錄喺 docs/decision_logs/。

呢個方法論啱邊啲人？如果你係 indie developer 或者小型 startup，需要快速 validation，唔想喺 spec 上面花太多時間，SWE-ATLAS 嘅 approach 會覺得自然好多。佢唔係 anti-discipline，佢係問一個務實嘅問題：邊啲前期工作真正 de-risk 建設，邊啲只係 ceremony？答案係：wireframe 同 targeted Q&A，唔係 constitution 同 task ledger。

ALDC：合約先行，TDD 強制執行

ALDC（AL Development Collection）係三者中最 specific 嘅一個——佢係專門為 Microsoft Dynamics 365 Business Central 開發設計嘅框架。但佢嘅哲學好有普遍意義：合約驅動（contract-driven）開發。

ALDC 嘅做法係：每個 feature 都要先有一份 spec contract，包含三個維度：functional requirement（用戶需要咩）、technical design（點樣 fit 入 extension）、test criteria（點樣知道佢 work）。呢份合約係 single source of truth——唔喺合約入面嘅嘢，就唔會被 build 出嚟。

然後係 TDD orchestration：Conductor agent 協調三個 subagent——Planning（研究 context）、Implementation（先寫 test、再寫 code）、Review（對照 spec 同 architecture 去 review）。每個 phase 都有人類 gate——即係每個階段都要你 approve 先可以繼續。

ALDC 嘅另一個特色係 “Skills Evidencing”：每個 agent 都要 declare 自己 load 咗邊啲 skill、apply 咗邊啲 pattern。唔係「我覺得 OK」，而係有 evidence 嘅 review。佢仲有一個可選嘅 BCQuality 知識層，令 review 同 audit 可以 cite 真正嘅 Business Central knowledge，而唔係 agent 嘅 opinion。

對於做 enterprise software 嘅香港團隊——特別係做 ERP、CRM、或者任何需要 compliance 嘅系統——ALDC 嘅 approach 幾吸引。佢嘅 overhead 比 LID 輕，因為唔需要從 HLD 開始，但又比 SWE-ATLAS 多一層結構。關鍵係佢嘅合約思維：你寫清楚你要咩，agent 按照合約做，review 有 evidence——呢個 model 對於需要 audit trail 嘅企業客戶好重要。

你揀邊個？

三個方法論代表三種對「工程」嘅理解：LID 話意圖先於一切，需要完整嘅 spec chain；SWE-ATLAS 話做最少嘅前期判斷，用視覺化工具快速 validation；ALDC 話合約係 single source of truth，TDD 係强制執行嘅紀律。

實際上，呢三個唔係互斥嘅選擇。我自己嘅做法係 mix and match：用 SWE-ATLAS 嘅 wireframe 做快速 validation（特別係 UI-related 嘅嘢），用 LID 嘅 arrow of intent 思維去 maintain 大型 project 嘅 coherence（特別係多 agent 嘅場景），用 ALDC 嘅合約思維去 handle 需要 compliance 嘅 enterprise 任務。

對香港同繁體中文圈嘅開發者，我嘅建議係：唔好被任何一個方法論綁死。你嘅 project 嘅 size、你團隊嘅 maturity、你客戶對 audit trail 嘅要求，會決定你應該 borrow 邊啲 concepts。但有一個共同點係肯定嘅：當 AI 已經可以寫代碼，你嘅價值唔在於寫 code，而在於表達清楚你要咩、同埋驗證佢做咗你要求嘅嘢。呢個先係 2026 年 developer 嘅真正 skill set。