🔧 阿川の電商水電行

Shopify 顧問、維護與客製化

💡

小任務 / 單次支援方案

單次處理 Shopify 修正／微調

⭐️

維護方案

每月 Shopify 技術支援 + 小修改 + 諮詢

🚀

專案建置

Shopify 功能導入、培訓 + 分階段交付

👉 瞭解詳情 / 免費諮詢

小編精選 - 技術文章翻譯 · 03月19日

AI 正在造成一種新的技術負債 — 卻沒有人在討論它

六個月前，我的團隊正在慶祝。

第三季我們發布的功能數量超過了去年全年的總和。我們的開發速度突飛猛進。人工智慧工具徹底改變了我們的工作方式——以前需要一周才能完成的工作，現在一天就能搞定；以前需要一天才能完成的工作，現在一個小時就能搞定。

我們的首席技術長在 Slack 上向全公司發送了一條訊息： “這就是工程的未來。”

上個月，我們不得不停止所有功能開發三週。

並非因為安全漏洞，也並非因為伺服器宕機，而是因為我們的程式碼庫與人工智慧生成的程式碼交織得太深，以至於任何人——甚至包括編寫這些程式碼的人——都無法再自信地對其進行修改。

我們一路狂歡，最後陷入了危機。

最糟糕的是什麼？我早就預料到了。只是我當時不知道自己看到的是什麼。 🧵

先前無人提及的新型科技債務

技術債早已不是什麼新鮮事。每個開發者都深有體會──為了趕工而偷工減料，心裡想著以後再重構。程式碼今天能用，明天就交給別人了。

人工智慧技術債有所不同。它不是偷工減料的問題，而是進展過快導致完全迷失方向的問題。

目前程式碼庫中實際上累積了三種不同類型的 AI 技術債務——而且大多數團隊同時面臨這三種債務：

1. 認知債務－程式碼編寫速度超過理解速度

2. 債務核實－批准你尚未完全閱讀過的差異

3. 架構債務－人工智慧產生的可行解決方案違反了系統設計。

大多數關於人工智慧和技術債的文章都集中在程式碼品質上。但這其實是錯誤的層面。真正的危機發生在更高層級——開發人員的思維中，他們本應理解自己建構的系統。

當我明白髮生了什麼事的那一刻

讓我來跟你說說那一週發生的一切。

我們團隊新來了一位開發人員——就叫他 Rahul 吧。他聰明、反應快，顯然很有天份。從入職第一天起，他就積極地使用 Cursor 和 Claude Code。

三週後，我請他向我詳細介紹他所建構的身份驗證流程。

他打開文件，開始解釋，講到令牌刷新邏輯部分時停了下來。

“其實，”他說， “我也不完全確定為什麼它的結構是這樣設計的。我測試的時候它執行正常。”

我當時並沒有生氣。我認出了那種感覺。這和我之前嘗試除錯自己用人工智慧生成的程式碼時的感覺一模一樣，感覺就像在讀別人的作品。

那次談話讓我陷入了一個全新的領域，徹底改變了我對人工智慧工具的看法。

解釋這場危機的數字

以下這些資料本應成為每個開發者社群的頭條新聞，但不知為何並非如此：

開發者對人工智慧編碼工具的信任度在18個月內從43%下降到29%，但使用率卻攀升至84%。

再讀一遍。開發者對人工智慧工具的信任度比以往任何時候都低，但他們使用人工智慧工具的頻率卻比以往任何時候都高。這種矛盾——使用你越來越不信任的工具——現在有了一個專門的名稱：認知債務。

情況變得更糟了。

由於人工智慧加速了編碼實踐，預計到 2026 年，75% 的技術領導者將面臨中度或嚴重的債務問題。

而最讓我感到難過的是：

一家API安全公司發現，在2024年12月至2025年6月期間，財富50強企業每月發現的安全漏洞數量增加了10倍，從每月1000個增加到超過10,000個。短短六個月內，這數字就成長了10倍。

短短六個月內，全球最大公司的安全漏洞數量增加了十倍。

這就是速度成為唯一衡量標準時會發生的情況。

我曾經是一名工匠

一位開發者以我一直在思考的方式捕捉了某些重要的東西：

“我以前是個工匠……現在感覺自己像宜家的工廠經理。”

那幅畫面一直縈繞在我心頭。不是因為它悲觀──而是因為它精準無誤。

IKEA的工廠經理並不了解每件家具的製作過程。他們只負責控制產量，留意明顯的缺陷，並信任這套系統。

這套方法適用於家具業，但不適用於處理用戶資料、處理付款或執行人們賴以生存的基礎設施的軟體系統。

軟體需要對軟體有足夠深入了解的人，才能分析出問題所在。工廠式的管理模式——高產量、淺層審查——最終只會製造出無人真正理解的系統。

而那些無人理解的系統，其故障方式也無人能預測或快速修復。

三種債務類型－簡明英語解釋

讓我來解釋一下目前程式碼庫中究竟累積了什麼。

1. 認知債務－隱形危機

瑪格麗特-安妮·斯托里對此描述得非常精闢：程式並非其原始碼。程式是一種理論——一種存在於開發者頭腦中的心智模型，它捕捉了軟體的功能、意圖如何轉化為實現，以及更改後會發生什麼。

AI 工具預設會將開發者從建立模式切換到審核模式。你不再解決問題，而是開始評估其他人提出的解決方案。

問題在於，審查人工智慧的輸出結果看似很有成效。你在閱讀程式碼，發現問題，進行修改。但你並沒有建構出能夠讓你獨立思考系統的心智模型。

一個學生團隊完美地詮釋了這一點——他們利用人工智慧快速建立軟體，並且已經可以正常運作。然而，到了第七週，當他們需要進行一個簡單的修改時，專案卻停滯不前。沒有人能夠解釋設計原理，也沒有人理解各個元件之間的互動方式。計畫原本的共同理論體系徹底瓦解了。

// This code works. Can you explain why in 30 seconds?
// If you generated it with AI and didn't stop to understand it — 
// you've accumulated cognitive debt.

const processPayment = async (userId, amount, currency) => {
  const [user, rateLimit, fraud] = await Promise.all([
    db.users.findById(userId),
    redis.get(`rate:${userId}`),
    fraudService.check(userId, amount)
  ]);

  if (!user || rateLimit > 10 || fraud.score > 0.7) {
    throw new PaymentError(user ? 'RATE_LIMITED' : 'USER_NOT_FOUND');
  }

  // Can you spot the bug? What happens if fraud.score is exactly 0.7?
  // What if rateLimit is null?
  // AI generated this. Did you understand it before you shipped it?
};

2. 驗證債務－虛假信心的陷阱

每次你點擊批准一個你尚未完全理解的差異時，你都是在透支未來。

與技術債（它會透過不斷累積的摩擦、緩慢的建構和錯綜複雜的依賴關係等問題顯現出來）不同，驗證債務會滋生虛假的自信。程式碼庫看起來很乾淨，測試也全部通過。

六個月後你發現你完全按照規格說明建造了東西——但完全沒有達到客戶的實際需求。

# The verification debt accumulates here:
# ✅ All tests passing
# ✅ No linting errors  
# ✅ Code review approved
# ✅ Deployed to production

# But nobody asked:
# ❌ Does this actually solve the user's problem?
# ❌ What happens in edge cases the AI didn't consider?
# ❌ Does this match our architecture patterns?
# ❌ Will the next developer understand this?

3. 建築債務－當模式被打破時

AI代理程式產生可執行程式碼的速度很快，但它們傾向於重複模式而不是抽像模式。最終，你會得到五個文件中同一邏輯的五個略有不同的實作。每個實作都能執行，但它們之間沒有任何共同的實用功能。

AI產生的程式碼傾向於處理理想情況。它能夠很好地處理訓練資料涵蓋的情況——標準輸入、預期狀態和常見錯誤程式碼。而對於邊緣情況、競態條件和特定基礎設施故障，則處理得不夠充分，甚至完全忽略。

當人工智慧代理需要某個功能時，它會直接呼叫對應的軟體包。它不會考慮現有程式碼庫是否已經滿足需求，依賴關係是否得到維護，或者軟體包的大小對於單一功能來說是否合理。

結果就是我所謂的「連貫的混亂」 ——程式碼單一來看是合理的，但整體上卻不連貫。

生產力悖論－為什麼更快不一定更快

這是領導階層最不願聽到的矛盾：

到 2026 年，人工智慧編碼工具將編寫 41% 的新商業程式碼。速度從未如此之快。

然而，Stack Overflow 的分析顯示，經驗豐富的開發人員在使用 AI 工具時，生產力下降了 19%。而且，大多數開發人員表示，他們花了更多時間除錯 AI 生成的程式碼，以及更多時間解決安全漏洞。

為什麼程式碼產生速度更快的工具反而會降低開發人員的工作效率？

因為寫程式碼從來都不是瓶頸。

理解程式碼是瓶頸。除錯程式碼是瓶頸。修改你沒寫過的程式碼——或者你寫過但不理解的程式碼——是瓶頸。

人工智慧讓快的部分更快，讓慢的部分更慢。

那些衡量人工智慧採用率和功能迭代速度的團隊，其實是在優化錯誤的指標。他們忽略了技術債的累積。那些在缺乏有效治理的情況下倉促投入人工智慧輔助開發的公司，將在2026-2027年面臨危機等級的債務危機。

當沒人理解程式碼時，究竟會發生什麼事？

我想具體說明這在實踐中會是什麼樣子。

情境一：為期三週的凍結

那正是我們當時的情況。在六個月的AI輔助高速發展之後，我們完全停工了三週，因為我們需要先弄清楚我們已經建造了什麼，才能安全地進行更改。

考慮凍結因素後的淨速度：與傳統開發方式相比，幾乎沒有成長。

場景二：初級開發人員的陷阱

54%的工程主管計劃因為人工智慧而減少初級開發人員的招募。但人工智慧產生的技術債需要人類判斷來修復——而這正是初級開發人員透過多年犯錯和學習才能培養的判斷力。

透過裁減初級職位，企業正在創造一個未來，在這個未來中，它們將缺乏足夠的人力資源來解決當前產生的債務。

2027 年需要的工程師——那些擁有 2-4 年除錯經驗的工程師——將不復存在，因為他們沒有被錄用。

情境三：安全定時炸彈

一家安全公司發現，與人工編寫的程式碼相比，人工智慧輔助開發的程式碼安全問題發生率高出2.74倍。這種安全隱患不會自行顯現，而是潛伏在生產環境中，伺機而動。

如何實際解決這個問題—實際操作

經過三週痛苦的除錯和重構，我的團隊做出了以下更改：

1. 引入「凌晨兩點你能除錯好它嗎？」規則

在任何人工智慧產生的程式碼合併之前，作者必須能夠回答以下問題：

“如果凌晨 2 點生產環境中出現故障並通知你，你能在不再次查看的情況下進行除錯嗎？”

如果答案是否定的──程式碼只有在作者理解之後才會合併。

這條規則在我們第一週就發現的問題比之前所有程式碼審查流程加起來還要多。

2. 將「生成環節」與「理解環節」分開

Monday: Use AI to generate the feature (fast)
Tuesday: Read every line without AI assistance (slow)
Wednesday: Refactor what you don't understand (medium)
Thursday: Test edge cases AI didn't consider (medium)
Friday: Merge

短期內速度較慢，但六個月後速度會顯著加快。

3. 追蹤認知債務－而不僅僅是程式碼質量

在衝刺回顧會議中加入以下問題：

每個團隊成員都能解釋一下我們在本次迭代中發布的核心系統嗎？
是否存在只有一個人能理解的模組？
我們是否發貨了任何我們無法在下週進行修改的產品？

這些不是感性的問題，而是風險評估。

4. 將人工智慧視為一位才華洋溢的初級開發人員

功能強大，速度極快，對不該自信的事情卻信心十足。處理任何複雜的事情都需要監督。

Junior developer rule:
✅ Use for boilerplate and scaffolding
✅ Use for well-understood patterns
✅ Use for test generation
⚠️ Review everything carefully
❌ Don't let them architect alone
❌ Don't merge code you can't explain
❌ Don't skip review because tests pass

對人工智慧也應適用同樣的規則，因為利害關係是一樣的。