為什麼把複雜工作交給 AI 開發者卻總是會忘記：「約束衰退」的秘密

想像一下：今天早上你進辦公室，對新引進的超智慧 AI 新進員工下達指示：「幫我們公司網站做一個讓員工可以用的簡單意見箱留言板。」聰明的 AI 新員工只花了 10 分鐘，就迅速寫出完美運作的程式碼並展示在螢幕上。你對這驚人的速度感到讚嘆，順勢決定把真正的工作交給它：「做得太棒了！那麼這次請務必符合我們公司主資料庫的規則，套用最新的安全模式，並與現有的登入系統完美整合，再重新做一個。」

然而，令人驚訝的事情發生了。剛剛還像是天才開發者的 AI，突然寫出會破壞公司現有系統的荒唐程式碼，或是完全忘記你剛才提到的核心安全規則，開始不知所措。甚至有時候根本無法給出任何產出，畫面直接卡死。

這種令人鬱悶的情況並非單純的錯誤或暫時性的 Bug。最近人工智慧研究人員在後端開發（使用者看不見的伺服器與資料庫領域開發）環境中，觀察 ChatGPT 等 AI 程式碼代理（能自行規劃並撰寫程式碼的 AI 程式）時，發現了一個致命的弱點——這正是所謂的「約束衰退（Constraint Decay）」現象。在世人期待 AI 馬上就能 100% 取代人類開發者的熱潮中，這個現象為「目前 AI 真正的極限在哪裡」提供了明確的線索。

為什麼這很重要？（Why It Matters）

最近看科技新聞，每天都能看到 AI 徹底改變軟體開發版圖的報導。許多人常常感到不安：「是不是再過一兩年就不需要人類開發者了？」事實上，若是改變網站按鈕顏色或製作簡單畫面，AI 確實比人類更快且準確。

但是，要打造我們在日常生活中能安心使用的實際商用服務（Production）等級軟體，絕非只是在一張白紙上打出像樣的程式碼而已。簡單來說，這就像是建造一棟外表華麗的模型屋，與建造一棟讓人們能在裡面安全居住、使用水電的堅固真實公寓之間的差別。

真正的軟體必須安全地隔離並保管數百萬名使用者的資料，必須在不發生衝突的情況下與舊有的銀行系統通訊，還必須嚴格遵守既定的框架，以便日後其他同事修改程式碼。總而言之，必須像守護生命一樣，死守複雜且嚴格的規則與骨架。為了讓目前的 AI 成為能夠被完全信任、並將複雜業務託付給它的真正「同事開發者」，它絕對需要具備在如此嚴苛環境中不迷失方向的能力。這正是我們無法將公司核心業務系統完全交給 AI 的真正原因。

淺顯易懂的解釋（The Explainer）

科學家們針對「為什麼 AI 規則一多就會做出荒唐舉動」的原因進行了深入研究，並將此現象命名為「約束衰退（Constraint Decay）」。 [2605.06445] 約束衰退：LLM 代理在後端程式碼生成中的脆弱性

為什麼會發生這種現象呢？讓我們用簡單一點的方式來窺探 AI 模型的內部吧。AI 的神經網路層（Neural network layers，如同人類大腦神經細胞般連結的人工智慧資訊處理結構）就像是智慧型手機裡照片修圖 App 的濾鏡。如同原始照片依序經過亮度濾鏡、色彩濾鏡、降噪濾鏡後變成精美的成品一樣，你一句簡單的「幫我做一個留言板」輸入，也會經過數百個層級的轉換，最終變成程式碼。這時候，AI 會將程式碼拆解成名為「Token（人工智慧閱讀和書寫的極小資料單位）」的微小拼圖碎片來理解。這其實是一種機率計算的原理，它會從數十萬個拼圖碎片中，計算出下一個最自然出現的碎片，然後不斷拼湊起來。

然而，在這裡不斷追加「約束條件」代表什麼意思呢？這不再只是單純完成一幅美麗的圖畫而已，而是像是在上面疊加數十個諸如「紅色拼圖不能放在藍色拼圖旁邊」、「邊角拼圖的背面必須印有公司標誌」，或是「每 10 行必須加上黑色邊框」等嚴苛的指示。當指示一個接一個累積時，AI 的資訊處理能力就會超載，最終導致它慢慢將先前提到過的重要規則一個個忘記。

打個比方，想像一下你為了一隻剛在訓練所完成基礎教育的聰明小狗教導新把戲，而對牠進行微調（Fine-tuning，為了特定目的讓 AI 進行額外學習的工作）的情境。如果你對完成基礎訓練的小狗只下一個「坐下！」的指令，牠會非常聽話。在只執行單一任務的寬鬆條件（Loose specifications）下，牠能發揮卓越的能力。但是，如果一次加上多個條件：「坐下之後舉起右前腳，搖三次尾巴，然後只有在我拍兩下手的時候才能叫一聲」，結果會如何呢？再怎麼聰明的天才小狗也會陷入混亂、急得團團轉，最後甚至把第一個「坐下」的指令忘得一乾二淨，直接癱倒在地上。

AI 程式碼代理的大腦也是一模一樣的。在沒有太多規則需要遵守的自由環境中，它能出色地寫出程式碼。但是一旦被投入到需要嚴謹處理隱形伺服器與資料庫的後端開發時，情況就會急轉直下。決定什麼資料要以何種方式存放在哪裡的資料規則、作為整個系統骨架的架構模式（Architecture pattern，構成軟體骨架的標準設計方式）、以及物件關聯對映（ORM，連結程式語言與資料庫結構的翻譯技術）等沉重的「結構性約束條件」，會在整個作業過程中如影隨形。當這類嚴苛的需求不斷累積時，AI 的寫扣性能就會像掉下懸崖般直線墜落，並開始無視最初的指示。 [2605.06445v1] 約束衰退：LLM 代理的脆弱性 …

研究團隊特別像動手術般，仔細解剖了 AI 失敗的原因。結果發現，根本的錯誤種子主要來自於「資料層（Data-layer）」的缺陷，這是負責物理儲存與讀取資料、非常深層且重要的領域。 約束衰退：LLM 代理在後端程式碼中的脆弱性 … 在必須按部就班連續思考的複雜作業中，前一個步驟的小失誤會像滾雪球般，在下一個步驟演變成致命錯誤，最終導致整體規則崩潰。電腦專家將這種現象稱為「推理衰退（Reasoning decay，邏輯思考流程逐漸崩壞的現象）」。 為什麼 LLM 代理會失敗：認知衰退的四種機制與推理約束層 - DEV Community

目前情況（Where We Stand）

這項有趣且重要的研究是獲得歐盟（EU）資助的「AI4SWeng」專案的一環，由 Francesco Dente 與 Dario Satriani 兩位專家主導進行。 LLM 程式碼代理能否遵守嚴格的架構規則？在 …

為了客觀證明「AI 究竟能將多種嚴苛的結構性約束條件記住並遵守多久？」，他們打造了一個巨大的測試舞台。他們建構了多達 8 種不同的 Web 框架（Web framework，為了快速且安全地建置網站的標準建築工具套件）環境。接著讓 AI 執行 80 項從零開始、猶如白紙般編寫程式碼的全新生成任務（Greenfield generation），以及 20 項在現有程式碼上添加新功能的追加任務。 約束衰退：LLM 代理在後端程式碼中的脆弱性 … 用人類來比喻的話，就像是丟給你一套統一的建築法規，讓你在 8 種不同的環境下蓋 100 棟房子，然後拿著放大鏡檢視你遵守規定的徹底程度。

實驗的結論非常冷酷且明確。根據論文指出，這個結果也向一般使用者傳遞了明確的訊息。目前的 AI 程式碼代理「雖然是個可以將腦海中的想法快速呈現於螢幕上進行測試、在原型製作（Rapid prototyping）方面非常值得信賴的魔法工具；但要完全投入到將規則與骨架視為生命的商用服務等級後端開發（Production-grade backend development）中，它仍處於無法被信任與託付的狀態」。 約束衰退：LLM 代理在後端程式碼生成中的脆弱性

這裡有一個我們容易受騙的盲點。目前市面上許多「AI 程式碼效能評估測試」，只要 AI 寫出的程式碼在功能上「能運作」，就會被判定為正確答案。儘管它忽略了實際公司商用軟體所必備的複雜架構模式或嚴格安全規則等看不見的非功能性要素，人們還是會因為「AI 在程式測驗中拿了滿分」，而產生它已完美取代人類開發者的錯覺。 約束衰退：LLM 代理在後端程式碼中的脆弱性 …

甚至還存在著更詭異、更嚴重的錯誤形式。這是一種 AI 被約束條件折磨到受不了，不僅吐出荒唐的程式碼，最後乾脆自行閉嘴的症狀。研究團隊發現，當指示 AI 代理撰寫需要遵守龐大且複雜格式的文件時，它會在畫面上沒有任何錯誤警告的情況下，默默給出空白回應並停止運作，這被稱為「輸出停滯（Output stalling，因超載而無法給出結果並停止運作的錯誤）」。 當代理保持沉默：LLM 文件合成的輸出生成能力與格式成本分離 這完全就像是面對主管連番轟炸的複雜指示，大腦一片空白，最後乾脆放棄回答的人類一樣。

未來將會如何發展？（What’s Next）

那麼，AI 注定永遠無法進行規則錯綜複雜的後端軟體開發嗎？現在要我們放棄所有期望還為時過早。研究系統架構的專家們所做出的分析，正指向一個完全不同的正面解決方案。

有位敏銳的分析師點出，這種頻繁失敗的現象並不是 AI 本身「智力不足」。真正的問題在於驅使 AI 工作的「架構（系統運作結構）」設計不良。他強調：「失敗並非始於 AI 的大腦內部。真正的死因在於最初餵給 AI 什麼樣的資訊，以及 AI 產出的結果後續會經過什麼樣的過濾過程。」 LLM 可靠性悖論：代理沒有壞，壞的是你的架構 也就是說，這不是 AI 本身的故障，而是我們驅使 AI 的「工作方式」出了問題。

因此，未來的 AI 程式碼工具將擺脫單純增加大腦容量的粗暴方式。就像細心的人類開發者每寫一行程式碼就會隨時執行看看、確認是否符合規則一樣，未來的工具內部必定會搭載「獨立驗證層（Validation layer，扮演確認程式碼品質與是否遵守規則的監督者角色的系統）」，能在旁邊立即檢閱 AI 吐出的程式碼並揪出錯誤。在開發實務中，不再盲目相信 AI 的產出，而是必須經過額外的安全機制與解析器（Parser，讀取程式碼並分析是否符合語法的工具），這種雙重、三重的安全網機制已經成為主流趨勢。 為什麼 LLM 會停止計算：開源 LLM 中使用者回報失敗案例的實證研究

AI 記者的觀點（AI’s Take）

我們在日常生活中接觸到的 AI 寫扣工具不是魔法棒，而是性能優異的頂級「電動電鑽組」。在快速組裝一張 IKEA 書桌時，它能發揮出遠勝於滿頭大汗的人類的最高效率；但如果遞給它一張複雜的大型醫院建築設計圖，要它蓋一棟巨大的建築，它會連順序都搞不清楚，就在錯誤的柱子上打洞，釀成一場大災難。

雖然遺忘約束條件的「約束衰退」現象目前看似是 AI 的致命傷（阿基里斯腱），但這不過是技術成熟過程中必然經歷的陣痛。在不久的將來，AI 會進化成一邊自己寫扣，同時嚴格審查自己程式碼的成熟夥伴。

然而，在能自行完美控制錯誤的真正 AI 建築師出現之前，建立專案大骨架、不斷協調眾多約束條件，並引導至正確方向的「洞察力」，依然是我們人類開發者最可靠且最閃耀的武器。因為無論技術再怎麼進步得令人目眩神迷，指揮巨大齒輪精準咬合運作的角色，終究還是得由人類來擔綱。

參考資料

1. [2605.06445] 約束衰退：LLM 代理在後端程式碼生成中的脆弱性
2. 約束衰退：LLM 代理在後端程式碼生成中的脆弱性
3. [2605.06445v1] 約束衰退：LLM 代理的脆弱性 …
4. 約束衰退：LLM 代理在後端程式碼中的脆弱性 … (DeepPaper)
5. 為什麼 LLM 代理會失敗：認知衰退的四種機制與推理約束層 - DEV Community
6. LLM 程式碼代理能否遵守嚴格的架構規則？在 …
7. 約束衰退：LLM 代理在後端程式碼中的脆弱性 … (Eurecom)
8. 約束衰退：LLM 代理在後端程式碼中的脆弱性 … (CatalyzeX)
9. 當代理保持沉默：LLM 文件合成的輸出生成能力與格式成本分離
10. LLM 可靠性悖論：代理沒有壞，壞的是你的架構
11. 為什麼 LLM 會停止計算：開源 LLM 中使用者回報失敗案例的實證研究