AI 工具對軟體開發的影響不是單純「變快」或「變危險」，而是取決於工程師怎麼拆任務、怎麼審查輸出、以及 AI 是否理解足夠的系統脈絡。這篇整理來自論文 The Impact of AI-Generated Solutions on Software Architecture and Productivity: Results from a Survey Study，我會保留論文中的調查重點，也補上自己讀完後對架構工作的觀察。
我會去讀這篇論文，是因為前陣子有一場 AI 寫程式的慘痛經驗。那次經驗讓我重新思考：AI 工具到底是在幫工程師加速，還是在不知不覺把技術債塞進系統裡？
AI 工具對軟體開發的最大影響是什麼？
AI 工具能顯著提升開發生產力，但提升幅度和任務規模高度相關。小型、明確、可驗證的任務最容易受益，大型修改與架構決策仍需要工程師主導。
論文提到，Stack Overflow 2024 年調查中，超過 76% 的開發者正在使用或計劃使用 AI 工具。這代表 AI 工具已經不是少數人的嘗鮮，而是軟體工程現場需要面對的主流工具。
真正麻煩的問題不在「要不要用 AI」，而在「用 AI 之後，速度和品質怎麼平衡」。如果團隊只看交付速度，卻沒有檢查可維護性、可擴展性、模組邊界與測試覆蓋，AI 生成的程式碼很可能把短期效率變成長期維護成本。
AI 工具真的能提升多少開發生產力？
論文調查顯示，AI 工具的生產力提升相當明顯。約 45% 受訪者回報高於 35% 的提升；若納入約 35% 的提升，比例達 79%。
這組數字讓我比較警覺的是：不用 AI 工具，可能真的會開始出現生產力落差。尤其是資歷少於三年的初階工程師，論文中所有這類受訪者都表示 AI 工具提升了生產力，這暗示 AI 可能正在縮短部分經驗差距。
但這不代表 AI 能補足所有工程能力。AI 可以讓人更快生成第一版程式碼，也能更快理解陌生函式庫；可是一旦進入複雜系統、歷史包袱、跨模組修改，工程師的判斷力仍然是品質防線。
AI 工具在哪些開發階段最有幫助？
AI 工具最適合軟體專案早期實作、樣板程式碼、小型程式碼片段與概念支援工作。除錯、大型修改和跨模組整合的效益較不穩定。
論文把 AI 工具在不同軟體開發生命週期（Software Development Life Cycle，SDLC）任務中的效益拆得很清楚：
| SDLC 階段或任務 | 效益程度 | 論文中的觀察 |
|---|---|---|
| 早期實作 | 最高效益 | AI 在專案早期階段最能提升生產力，例如生成骨架程式碼或基本功能。 |
| 程式碼生成 | 高效益 | 最常見用途是生成小型程式碼片段與樣板程式碼。 |
| 概念與支援工作 | 高效益 | 工程師會用 AI 做架構概念討論、研究摘要、設計文件查找與腦力激盪。 |
| 複雜或大型任務 | 效益降低 | 專案越複雜，AI 工具的生產力效益越低；用單一提示解大型問題容易產生錯誤。 |
| 除錯與修改 | 中低效益 | 60% 受訪者認為人類修 bug 仍快於 AI；65% 受訪者認為用 AI 修改程式碼反而更耗時。 |
工程師最常使用 AI 處理的任務依序是：
- 生成小型程式碼片段：38 位參與者。
- 修改現有程式碼：26 位參與者。
- 修復錯誤：19 位參與者。
- 生成測試：17 位參與者。
除了直接寫程式，AI 工具在輔助任務也很有價值。像是快速整理研究論文、在內部設計文件中查資訊、作為技術顧問發想方案、提供函式庫使用範例，這些工作不一定會出現在 commit 裡，但會縮短工程師進入問題的時間。
AI 生成程式碼會傷害軟體架構嗎？
AI 生成程式碼不一定會傷害軟體架構，關鍵在任務大小與系統脈絡。小型獨立任務品質可接近人類；大型複雜任務較容易破壞內聚性與模組邊界。
論文對程式碼品質的觀察很值得架構師注意。當任務小、邊界清楚、可獨立驗證時，AI 生成的程式碼可以有不錯的維護性、性能與語法正確性，也不一定造成顯著的架構侵蝕。
風險通常出現在大型、複雜、需要理解既有系統脈絡的任務中。AI 工具缺少完整的 global context，容易把局部解法塞進不適合的位置，造成內聚性降低、模組責任變模糊、既有功能被破壞。
| 正面影響：小型、獨立任務 | 潛在風險：大型、複雜任務 |
|---|---|
| 程式碼品質可與人類相當，甚至更好。 | 程式碼分區與組織可能變差。 |
| 產出通常語法正確，性能沒有明顯額外開銷。 | 可維護性、可擴展性可能下降。 |
| 高內聚、低耦合的片段較容易由 AI 產生。 | 在大型程式庫中更容易破壞既有功能。 |
| 對架構侵蝕不一定顯著。 | 架構侵蝕主要體現在內聚性降低。 |
功能正確性也是限制。超過 65% 的參與者指出，AI 生成的程式碼很少在第一次嘗試就完全滿足功能需求。開發者通常需要反覆調整提示詞，才能接近可用結果。這也是我讀完最想畫線的一點：把 AI 產出直接當成正確答案，是非常危險的開發習慣。
工程師應該如何降低 AI 程式碼風險？
工程師降低 AI 程式碼風險的核心方法，是把大型問題拆成小型、明確、可測試的子任務。AI 負責局部實作，人負責架構拆解、審查、測試與整合。
我會把這個工作法整理成「拆解、委派、整合」循環：
| 階段 | 工程師要做的事 | AI 工具適合做的事 |
|---|---|---|
| 拆解 | 把大型問題切成邊界清楚的小任務，定義輸入、輸出、驗收條件。 | 協助列出可能的子任務、風險點與測試情境。 |
| 委派 | 針對單一子任務提供明確 prompt，不一次要求 AI 解完整系統。 | 生成程式碼片段、樣板、測試草稿或替代寫法。 |
| 整合 | 檢查命名、函式簽名、模組責任、測試與既有架構一致性。 | 協助解釋錯誤訊息、提出重構方向、補測試案例。 |
論文中的受訪者多數同意，把問題分解成小塊再請 AI 實作，是提高生產力的最佳方式。針對小型、集中的問題提問，可以降低 AI 猜測需求的機率，也能讓工程師更容易審查結果。
這裡的重點不是「prompt 寫漂亮」，而是工程師是否先想清楚問題邊界。超過 67% 的受訪者認為，程式碼規模越大，AI 越容易破壞現有功能；40% 的受訪者也觀察到，輸入程式碼規模越大，AI 處理時間會明顯增加。大任務拆小，不只是品質策略，也是效率策略。
AI 時代的軟體工程師角色會怎麼變？
AI 時代的工程師價值會從單純產出程式碼，轉向拆解複雜問題、設計架構邊界、驗證品質與整合方案。工程能力沒有消失，只是重心往更高層移動。
這篇論文讓我更確定一件事：AI 不會讓架構能力變得不重要，反而會讓架構能力更容易被看出差距。當程式碼生成成本下降，真正稀缺的是判斷哪些程式碼應該存在、放在哪裡、如何與既有系統一起演進。
我會把 AI 增強型工程師的工作分成兩面：
| 要善用 AI 的地方 | 要保留人工判斷的地方 |
|---|---|
| 早期實作、骨架程式、樣板程式碼。 | 系統架構設計、模組邊界、核心資料流。 |
| 研究摘要、文件查找、函式庫範例。 | 功能正確性、資安風險、商業邏輯。 |
| 小型程式碼片段與測試草稿。 | 測試品質、邊界案例、整合策略。 |
| 腦力激盪與替代方案比較。 | 最終取捨、維護成本、技術債控制。 |
論文也提醒，AI 生成測試可能流於表面，缺少對邊界條件和核心業務邏輯的深入驗證。我的實務感受也是如此：AI 很會補「看起來像測試」的東西，但測試真正有沒有抓住風險，還是要靠人理解需求和失敗模式。
這篇論文有哪些限制需要一起看？
這篇論文是問卷調查研究，適合觀察工程師使用 AI 工具的經驗與趨勢，但不能直接等同於所有團隊的客觀績效。閱讀時要保留樣本、情境與自陳資料限制。
論文價值在於整理開發者如何感受 AI 工具對生產力、程式碼品質與架構品質的影響。這類調查很適合用來形成警覺：哪些任務被認為有效、哪些任務容易出問題、工程師如何調整工作方式。
但問卷調查本身也有邊界。受訪者的生產力提升是回報結果，不一定等於每個團隊都能複製同樣幅度；不同語言、框架、程式碼規模、測試文化與工具成熟度，也會影響 AI 的實際效果。
所以我不會把這篇論文讀成「AI 一定提升 35% 以上效率」。比較穩的讀法是：AI 工具已經能在小型、明確任務上提供顯著助力，但大型系統中的品質責任仍然回到工程師身上。
延伸閱讀
如果想把這篇論文的觀察放回 AI 開發工具、Agent 和工程實務，可以接著看這幾篇站內文章：
- AI 原型程式開發工具怎麼選？v0、Bolt、Replit、21st.dev、shadcn/ui、Lovable 介紹
- Claude Code 終端操作技巧與 SDK 應用
- Claude Code MCP scope 如何選擇 Local、Project 與 User
- React、Prompting、Reasoning、Acting：生成式 AI 應用的核心能力
- AI 論文閱讀工具整理：ChatPDF、SciSpace、NotebookLM、Research Rabbit 怎麼選？
常見問題
AI 工具會讓軟體工程師失去價值嗎？
AI 工具不會讓軟體工程師失去價值，但會改變工程師價值的重心。當程式碼生成變快，工程師更需要負責問題拆解、架構判斷、品質驗證與整合。
AI 生成的程式碼可以直接放進正式產品嗎？
AI 生成的程式碼不建議未經審查就放進正式產品。論文中超過 65% 參與者指出，AI 生成程式碼很少第一次就完全滿足功能需求，因此仍需要 code review、測試與人工整合。
AI 最適合軟體開發的哪一個階段？
AI 最適合專案早期實作、小型程式碼片段、樣板程式碼與概念支援工作。當任務變成大型修改、跨模組重構或除錯，AI 的效益會下降，風險也會提高。
為什麼問題拆解對 AI 寫程式這麼重要？
問題拆解能把大型系統風險限制在小範圍內。AI 比較擅長處理邊界清楚、輸入輸出明確的任務；如果一次要求 AI 解完整系統，AI 容易忽略既有架構與隱含限制。
AI 生成測試可靠嗎？
AI 生成測試可以當作起點，但不能當作完整品質保證。AI 常能補出基本測試框架，卻可能漏掉邊界條件、商業規則與真正會造成事故的失敗情境。
這篇論文可以證明 AI 一定提升 35% 生產力嗎？
這篇論文不能證明所有團隊都一定提升 35% 生產力。論文整理的是問卷調查結果，適合觀察趨勢與受訪者經驗；實際成效仍取決於任務類型、程式碼規模、測試文化與工程師使用方式。
參考資料
- arXiv, The Impact of AI-Generated Solutions on Software Architecture and Productivity: Results from a Survey Study，存取日期：2026-08-28。
最後更新：2026-08-28
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2025-09-21