# AI 時代下的系統可理解性問題

GAI 的時代下，近一年很流行 Vibe-coding，幾乎人人都在草率地使用 Vibe-coding 一詞來指一系列的軟體工程實踐。它指的是一種開發者不親自手打 coding，而是僅透過自然語言向 AI 描述需求（給出「方向」或「感覺」），完全放手讓 AI 代理去自動生成、拼湊出整個應用程式的開發風格。 然而，在專業的軟體工程領域，這股看似美好的「Vibe」背後，隱藏著極高的安全隱患與系統崩潰危機。

許多人以為只要 AI coding的速度變快，軟體品質就會自動提升。但真相真的是這樣？

1.  有數據調查發現，透過 vibe-coding 提交的 commit 造成的安全漏洞是人寫的 9x 之多 XD
    
2.  這些 code 隨著時間跟需求過去，只有約 44%的code 會在後面存活著，其他都在後續修改中被廢棄了 XD
    
3.  最重要的核心需求是「**理解**」。開發者當下跟 AI 互動的是理解既有程式碼（understanding），而不是產生新程式碼（generating）。比例約 19% vs. 13%。這說明了開發過程的瓶頸從來就不是寫程式碼，而是大腦對於程式碼的理解。
    

> 資料來自 SWE chat https://www.swe-chat.com/

![](https://cdn.hashnode.com/uploads/covers/6420f5cbbdbe7d697133d12a/728832b7-7609-4297-9f34-2aacdc452707.png align="center")

### **認知投降（Cognitive Surrender）**

在 Vibe coding 的吹捧下，開發者很容易陷入\*\*認知投降（Cognitive Surrender）\*\*的心裡狀態。

什麼是認知投降？就是以前我們會花很多心思跟時間在閱讀陌生的程式碼跟文件（反正就不是自己造的）。現在靠 AI 給出的方案又快看似又準又可靠，開發者便放棄了 System 2（慢思考）的邏輯思考，進而直接按下 `accept`。

這種缺乏監督跟思考的行為，最近在業界也造成不少事件。例如 [Replit](https://ec.ltn.com.tw/article/breakingnews/5118755) 曾發生過因缺乏人類工程師妥善監督的 AI 代理，直接失控刪除了 prod db與備份的災難性事故 。

### **偶然複雜度**vs. **本質複雜度**

IBM 大神 Fred Brooks 在 1986 年發表了一篇「**No Silver Bullet—Essence and Accident in Software Engineering**」中就指出，軟體開發的複雜度分為 **偶然複雜度（Accidental）與 本質複雜度（Essential） 。而 vibe coding 壓縮的只是偶然複雜度**的部份（如寫 template code、查語法、寫簡單的測試）。

然而，理解業務領域、定義系統邊界、在很多衝突的非功能性需求中權衡折衷的設計，這些本質複雜度是絕對無法靠 vibe 來解決的。

### Decide-Execute-Deliver 三明治

我們其實能簡單的將軟體開發在內的很多知識型工作想像成一個三明治，它的三個夾層分別是「decide-execute-deliver」。而剛剛提到的偶然複雜度則是 execute layer，AI 的出現則是壓縮了該層。但本質複雜度，則包含了 decide/deliver 這兩層，工程師還是要花費時間跟心力來**深入了解**系統，因為開發團隊職責就是負責決策並且**對交付成果負責（不然就只是 garbage-in , garbage out）**。

![](https://cdn.hashnode.com/uploads/covers/6420f5cbbdbe7d697133d12a/c862169e-d5c7-4fd4-9785-b860881ba32c.png align="center")

> [Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools](https://www.nber.org/papers/w35275) 該論文將 GAI 生產力效應以\*\*決定-執行-交付三明治（Decide-Execute-Deliver Sandwich）的方式呈現，\*\*指出軟體開發工作是由 Decide、Execute 和 Deliver三層組成，且「理解」是這三層的基石。當 AI 將中間的「執行」層壓縮至極致時，**人類必須刻意在「決定」與「交付」兩端重建理解**。這意味著在 AI 生成代碼之前（設計階段）和之後（驗證與評估階段），開發者必須投入主動的思考，不能將「理解」完全外包給 AI。

在 Decide-Execute-Deliver 的三明治模型中，我們看到 AI 幾乎將中間的 Execute 層壓縮到了極致（所以你會看到網路上很多人說 coding 已經是現在最廉價的工作了）。但這看似高效、無摩擦的背後，隱藏著一個致命的交換代價：**大腦不再經歷親手寫程式碼時的思考摩擦與阻力，導致我們腦中的系統心理模型，也跟著被悄悄稀釋了**。

這正是 Peter Naur 十幾年前在 [Programming as Theory Building](https://pages.cs.wisc.edu/~remzi/Naur.pdf)中所提出的警示：**編程的核心活動不在於產出code，而是開發者在腦中構建關於系統如何解決問題的「理論（Theory / 心理模型）」**。

在 GAI 時代，當我們草率地進行 vibe coding 時，我們自以為省下了代碼層面的「技術債」，實際上，我們卻是以驚人的速度，向未來透支了更難償還的認知債與意圖債。

### [三重債務模型（Triple Debt Model）](https://arxiv.org/pdf/2603.22106)

加拿大維多利亞大學的 Margaret-Anne Storey 教授在 2026 年的研究中，針對 AI 輔助開發下的軟體系統健康度，提出了[三重債務模型（Triple Debt Model）](https://arxiv.org/pdf/2603.22106)。她指出，軟體系統實際上同時存在於三個維度，而這三個維度正默默承受著三種不同的債務：

![](https://cdn.hashnode.com/uploads/covers/6420f5cbbdbe7d697133d12a/e5a5bfeb-130d-42dd-91d2-0ac4d2ff3a05.png align="center")

1.  **技術債（Technical Debt）**：存在於「 code 與 軟體專案結構層」
    

這是我們最熟悉的債務。為了追求交付速度而妥協代碼品質、留下凌亂的架構或暫時性的補丁。**技術債存在於 code本身，它限制了系統「如何改變（How to change）」的能力**。

有趣的是，在 AI 時代，**技術債反而是最容易被解決的**。因為現在的 AI 助理（如 Claude 或 GPT）非常擅長自動化重構、找出壞味道（bad smells）、甚至自動補齊測試案例。如果我們只盯著程式碼的靜態品質，軟體系統看起來可能前所未有的健康。

2.  **認知債（Cognitive Debt）**：存在於「人與理解層」
    

相較於顯性的技術債，**認知債是無聲且隱形的**。它指的是**團隊對於系統運作方式的「共享理解（Shared Understanding / 系統理論）」隨時間默默流失**。**認知債存在於人的大腦中，它限制了團隊「如何安全思考改變（How to reason about change）」的能力**。

過去，即便開發者寫出 messy code，那種「動手實作的摩擦力與痛苦」也強迫大腦在過程中建立起系統的心理模型。但當 AI 把代碼生成變得極其廉價、一鍵即達時，這個「反饋圈」就被硬生生切斷了。代碼能動，但團隊裡沒有任何一個人真正理解它是怎麼動的。

3.  **意圖債（Intent Debt）**：存在於「目標與決策層」
    

這是最常被遺忘的維度。它指的是**系統的設計初衷、演進決策脈絡、以及非功能性約束（如隱私、安全或效能限制）沒有被記錄在任何非代碼交付物中**。**意圖債存在於外部記錄中，它讓團隊和 AI 難以釐清「這個系統究竟是為了解決什麼問題（What the system is actually for）」**。

當意圖債高企時，新進人員無法得知歷史決策脈絡；而 AI 代理在接手任務時，也會因為缺乏足夠的上下文（Context Debt），吐出看似語法正確卻完全偏離業務真實需求的垃圾程式碼。

回顧到前面提到的**認知投降**，為什麼我們在 Vibe coding 的氛圍下，對這種隱形債務毫無防備？

Storey 教授指出，因為閱讀和推理不熟悉的程式碼是人類大腦最消耗認知資源的活動之一。在這龐大的認知負擔下，我們習慣走捷徑，將信任完全讓渡給「直覺的快思考（System 1 / AI）」的過程。更可怕的是，**認知投降會膨脹開發者的自信心，讓我們產生『我完全掌控了系統』的幻覺，實際上大腦腦區的神經參與度卻在急劇下降**。

我們以為我們在 Agentic Engineering 中指揮 AI，但其實我們只是在「認知投降」中把靈魂賣給了 LLM。直到系統規模擴大、 simple changes 開始在意想不到的地方引發連鎖崩潰時，團隊才驚覺「共享理解」早已分崩離析。

### **可理解性危機：當認知債癱瘓了系統的可觀測性**

然而，當系統累積了龐大的***認知債***與***意圖債*時，可觀測性就會徹底失靈**。此時，即便你擁有最完美的 OpenTelemetry 追蹤、最華麗的 Grafana Dashboard，你依然會陷入「看得到數據，卻看不懂系統行為」的黑盒泥淖。

1.  **觀測性的終極癱瘓：Incident 時「尋找 bug」變成「考古拼圖」**
    

在一個健康、可理解的系統中，當監控警報（Alert）響起，可觀測性工具（如 Distributed Tracing）能快速幫你定位到是哪一個 API 呼叫鏈出錯。

*   **認知債的代價：** 然而，在可理解性低落的系統中，線上事故（Incident Call）會呈現完全不同的慘狀。在面對複雜系統的線上事故時，絕大部分的時間都花在釐清系統各部分是如何連接、以及系統到底在做什麼，而不是在尋找 Bug 本身。
    
*   **數據無用論：** 這時，Trace 顯示的調用鏈路（例如 A -> B -> C -> D）對工程師來說只是一堆冰冷的代碼方塊。因為大腦中沒有系統的「心理模型（Theory of System）」，工程師根本不知道：
    
    *   *「為什麼 A 要在這個時間點呼叫 B？」*
        
    *   *「如果我把 B 重啟，會不會觸發 C 的連鎖逾時？」* 我們被迫在線上「挖程式碼、通宵通話、猜測系統行為」來拼湊集體記憶中早已遺忘的系統理論。
        

2.  **Behavioral Contracts 的隱性斷裂：不知道被誰影響、影響了誰**
    

*   **語法觀測與行為合約的落差：** 我們的 API 觀測工具（如 API schema、Swagger）只能觀測到數據的「結構」與「語法」。API Schema 無法說明Behavioral Contracts ——諸如 Idempotency、Retry-safety、Ordering requirements、最終一致性與遞送保證等隱性理論。
    
*   **領域洩漏（Domain Leakage）與意外副作用：** 當 AI 代理或 Vibe-coding 的開發者因為「認知投降」而草率修改程式碼時，極易在不自知的情況下破壞了這些隱性合約（造成領域洩漏 Domain Leakage）。這會導致：
    
    *   一個看似孤立的變更（Isolated change），在完全無關的遠端領域引發意想不到的連鎖副作用。
        
    *   **在觀測性工具上，你只會看到一個「未預期的結果（Unexpected result）」**——例如你做了一個變更，預期會看見 A 結果，觀測指標卻回報了完全無法理解的 B 異常。這正是因為隱性的行為合約斷裂，而我們早已失去對系統變更進行安全推理的能力。
        

3.  **Behavior Drift：缺乏 Intent 作為對照，觀測指標全是噪音**
    

可觀測性的指標必須與「業務意圖（Business Intent）」對齊才具有意義。如果我們累積了嚴重的**意圖債**，系統就會發生致命的 **Behavior Drift**。

*   **意圖債的吞噬：** 意圖債代表系統的設計初衷、非功能性約束與決策脈絡沒有被外部化記錄（缺乏 ADR 或可執行測試）。
    
*   **觀測的盲區：** 當意圖遺失時，系統的行為會漸漸與利益關係人所期待的行為發生分歧，而這種行為漂移，往往只有在發生嚴重的客訴或線上事件時才會被驚覺。
    
*   因為程式碼看起來依然正常運行、測試依然通過（Tests pass）、CPU 使用率很完美，所以監控 Dashboard 顯示一片綠燈。但實際上，系統的業務邏輯已經完全偏離軌道，這就是「意圖盲區」——**可觀測性只能告訴你「系統現在怎麼動（What it does）」，但無法告訴你「這是不是我們當初要的（What it was meant to do）」。**
    

## 在 AI 時代下重新定義軟體健康度

為了解決 Vibe coding 所帶來的隱性反噬，並償還悄悄累積的認知債與意圖債，我們必須重新定義「軟體系統健康度」的衡量標準。微軟與 MIT 的研究證實，當 AI 將寫程式碼（Execute）的成本壓縮至極致時，人類大腦必須在兩端——決定（Decide）與交付（Deliver）——刻意重建理解。

Storey 教授建議，現代軟體團隊必須徹底改變過去「只盯著程式碼產出與靜態質量（如技術債）」的單一維度，改從以下三個實務層面主動捍衛系統的健康：

*   **將「共享理解（Shared Understanding）」視為第一等交付物** 📦 軟體團隊的最終產出不應只有能運作的程式碼。我們必須將「理解」視為與程式碼同等重要、需要投入時間與預算的資產。在實務上，團隊可以透過定期的**系統導覽（System Walkthroughs）**——刻意指派「沒有寫過這段程式碼的工程師」來向大家解釋系統如何運作，以此促進「理論」的重建；並在線上事故後舉辦無責的**事後檢討會（Post-mortems）**，集體拼湊與更新在日常開發中磨損、分歧的共享心理模型。
    
*   **實行「意圖優先的工作流（Intent-first workflows）」** 🎯 在放手讓 AI 代理人自動生成程式碼之前，人類工程師必須先釐清並外顯化設計意圖。這意味著要在開發初期就刻意捕捉意圖：包括撰寫**領域模型（DDD）**、記錄**架構決策記錄（ADR）**，以及撰寫能夠精確表達「商業意圖」而非僅驗證行為的**可執行 BDD（行為驅動開發）測試**。這些「意圖交付物」是 AI 代理人能精準幹活的上下文（Context）基礎，更是維持意圖債不失控的關鍵防線。
    
*   **抗拒「理解的自動化（Resist the Automation of Understanding）」** 🛡️ 許多團隊為了圖方便，會使用 AI 來「一鍵自動生成文檔、註釋或 PR 說明」。這種做法雖然產出了看似精美的文件外殼，卻沒有讓開發者的大腦經歷真正的「認知摩擦（Cognitive Friction）」。這只會創造出「我們有文件，所以我們懂了」的虛假安全感。**真正的理解，只會發生在人類大腦主動進行思考、爭辯與撰寫的摩擦過程中。**
    

### **Sociotechnical Fitness Functions：主動監控理論的流失**

既然「理解」與「意圖」如此重要，但它們偏偏存在於人類的大腦中，無法被 CI/CD 管道中的靜態分析工具直接測量。

為了解決這個難題，現代架構師可以利用\*\*「社會技術學適應度函數（Sociotechnical Fitness Functions）」\*\*。這些指標不用於懲罰，而是作為「氣候探針」，用來偵測團隊何時正在默默滑向認知債的邊緣：

1.  **卡車係數（Truck Factor / Bus Factor）與作者貢獻度（DOA） 🚚**
    

*   **指標本質**：卡車係數代表「最少需要有多少位核心成員突然離開團隊，專案就會陷入沒人懂、無法安全修改的癱瘓狀態」。**作者貢獻度（DOA - Degree of Authorship）** 則可透過 [`git-truck`](https://github.com/git-truck/git-truck) 等工具映射出整個程式碼庫的知識分布。
    

![](https://cdn.hashnode.com/uploads/covers/6420f5cbbdbe7d697133d12a/ba240c3b-eb2f-4787-8b17-4bd508348cf1.png align="center")

git truck 能用圖的方式告訴我們修改行數最多的是誰？

*   **AI 時代的陷阱**：在 AI 時代，團隊常有一種虛假安全感，認為「 Dave 離職了也沒關係，我們還有 AI 能幫忙讀程式碼」。但事實上，AI 只能拼湊 Dave 留下的程式碼「在做什麼（What）」，卻無法無中生有地推論出 Dave 當時設計的「為什麼（Why）」。當團隊中開始頻繁出現 **「這段程式碼先別碰，我們得等 Dave 回來（Let's wait for Dave）」** 的聲音時，代表卡車係數已逼近臨界點，理解正在嚴重失流。技術領袖必須立刻進行開發者輪替，或打破知識孤島。同時這也可能代表**監控「知識流失」而非僅監控系統負載**，因為 Dave 在這場景下是唯一持有該系統理論的人。
    

2.  **新進人員上工摩擦力（Onboarding Friction） ⏱️**
    

*   **指標本質**：傳統上，我們只追蹤新人「第幾天能發出第一個 PR」。但在 AI 輔助下，新人靠 AI 隨手改錯字、改文案可能第一天就能發 PR，這成了虛假生產力。
    
*   **架構師的衡量方式**：真正的 Onboarding 指標，應該追蹤\*\*「新進工程師需要花多少時間，才能對系統的架構決策或核心領域設計做出實質貢獻」\*\*。
    
*   **實務工具「困惑日誌（Log of Confounding Things）」**：鼓勵新人寫下一張清單，記錄他們在 onboard 過程中發現所有**令人費解、合約不一致或缺乏文件記錄**的痛點。新人的大腦尚未被既定成見污染，這本日誌是團隊用來診斷、修補「認知債與意圖債」的最寶貴探針。
    

3.  **PR 審查動態與「人類理解檢查點（Comprehension Checkpoint）」 🔍**
    

*   **指標本質**：當團隊只剩下無實質討論、清一色充斥著「LGTM (Looks Good To Me)」的 PR 審查時，代表審查已沦為形式，共享理論已經中斷。
    
*   **審查即「理解檢查點」**：在 AI 時代，PR 審查不應僅被視為找出代碼缺陷的「品質閘門（Quality Gate）」，更必須是驗證、傳播系統心理模型的\*\*「理解檢查點」\*\*。
    
*   **實務做法：刻意重建摩擦力（Deliberate Friction）**： 我們應該抗拒自動化 PR 說明的引誘。**要求開發者用自己的話手寫 PR 說明與 Commit 訊息**。寫作過程中的摩擦力（Friction），正是作者檢測自己「是否真的在腦中持有系統理論」的最佳探針。如果寫不出來，代表開發者正處於認知投降狀態，代碼只是 AI 吐出來的黑盒，需要立刻煞車。
    

## **結語：在「Bounded Context」的縫隙中捍衛人類主權**

在微軟與 MIT 發表的論文中，他們提到了軟體工程的\*\*「弱鏈假設（Weak-Link Hypothesis）」\*\*——在一個 CES（常數替代彈性）的軟體生產鏈中，AI 生成與人類審查之間的替代彈性極低（僅為 0.25），代表兩者是強烈的互補品。

寫程式碼的速度再快，只要「人類理解與決策」的瓶頸沒有被打通，最終交付的軟體產量就只會面臨嚴重衰減。

特別是在服務與服務、系統與系統通訊的**邊界（Bounded Context Seams）上，API Schema 只能定義資料的結構（語法），卻無法說明其隱性的行為合約（Behavioral Contracts）**——諸如等冪性、重試安全、最終一致性與順序性保證。這些行為合約正是 Naur 所說的「理論」，它們無法靠 Vibe 自動生成，必須依靠人類開發者之間牢固的共享理解來維持。

當 AI 將手打程式碼的生產成本逼近於零時，那些「只會 Vibe-coding」的開發者將會迅速被程式碼的洪水淹沒；而能夠**運用 Agentic Engineering，在混沌的程式碼生成中，死死守住系統心理模型與設計意圖的專業軟體工程師，才是 AI 時代下，最無可替代的黃金資產。**