PS: 我原本打算在 2025 年初寫下這篇文章，但工具演化得太快，每隔幾周就有新的正規化、新的驚喜，直到最近，輪廓終於清晰，我才敢動筆。
2025 年註定不只是一個 “Agent 元年”，而是一個體系化躍遷的起點。在幾個月過去，這個判斷被不斷印證，也不斷被現實加速：
-
Cursor 和 Windsurf 正在從 AI Editor 升級成真正的 AI IDE，但是在編譯器加入這場遊戲之後，我們或許不需要傳統的 IDE。 -
Claude Code 用模型能力重塑任務執行流程，讓我們看到了：只靠模型的強大推理能力，如何讓 AI 編碼代理更智慧。 -
Augment 強大的閉環驗證能力，展現了他們對於軟體工程的思考。
工具不再是工具，它們正成為開發流程的策劃者與執行者。協作不是人與人，而是人與 Agent 們，還有 Agent 與 Agents。整個體系正在不斷迭代， 然而我們所見證的：它並不是簡單的提效，而是“放大” —— 即原來做得差的，現在會更差， ⚠️ AI 程式碼的副作用，比你想的要嚴重得多。
PS：在這篇文章裡，我將使用“AI 代理”來指代 AI 智慧體，因為代理更能體現它們的協作與執行能力。
1. 百花齊放的 AI 編碼代理，再次爆發
在過去的半年裡，我使用程式碼補全的頻率顯著降低。原因很簡單：AI 智慧體/代理的能力已遠遠超越了傳統的程式碼補全。不只是能補程式碼，它們還能理解需求、預測操作， 並自動完成一系列開發任務——從生成程式碼、編寫測試、執行構建，到校驗結果、出錯自動重試，全流程都能覆蓋。我只需清晰描述目標 （太難了），AI 就能高效執行。
與此同時，AI 程式設計的競爭格局也發生了根本性的變化。如今，頂尖模型已經成為所有工具供應商都能接入的通用“智慧引擎”，智慧本身不再是差異化優勢的來源。 真正的競爭，轉向了圍繞大模型打造怎樣的工作流、使用者體驗與生態系統整合——誰能用這些能力構建出最具價值的開發平臺，誰就能勝出。
這也解釋了為什麼市場上湧現出如此多的參與者：
- AI 程式設計外掛/編輯器
：如 Cursor、Windsurf、Augment、AutoDev、JetBrains Junie 等； - 軟體開發平臺
：如 GitHub Copilot（Web 版）、Atlassian Rovo Dev、Sourcegraph AMPCode 等； - 模型廠商
：如 Gemini CLI、Claude Code、OpenAI Codex 等。
背後的推動力主要來自兩個方向：一是基模型在理解、推理、上下文保持方面能力的躍遷；二是 Agentic 能力的成熟。這些進展降低了對自研或微調模型的依賴， 使得向量化模型、FastApply、NES 預測等架構成為可選項，而非剛需。
2. “計劃先行，程式碼後行”：AI 程式碼正在變得有章可循
正確使用 AI Agent 的方式應該是：
- 規劃與腳手架搭建。整個過程始於高層次的戰略規劃，通常在一個 Markdown 檔案中進行。由 AI 協助建立一份開發路線圖，將宏大的目標分解為更小的、可執行的任務，或者 mermaid 圖來視覺化整個開發流程。
- 詳盡的任務定義。對於每一個子任務，應該編寫一份極其詳盡、自包含的提示（prompt），精確地定義 AI 需要完成的工作、遵循的約束和預期的輸出。
- 受控的執行過程。開發者會一次只將一個任務指令交給 AI，並明確要求其在“完成後回報”，而不是讓其連續不斷地工作。
- 人在環路中的審查。AI 完成任務後，開發者會仔細審查生成的程式碼。如果發現問題（例如，AI 未能複用一個已存在的工具函式），開發者會進行迭代修正，直到程式碼質量達標，然後再進行下一個任務。
而由於程式設計可靠的提示詞過程太複雜，我們通常不願意這麼做，進而導致 AI Agent 程式設計生成的質量參差不齊。大力飛磚，還是比較好玩的。
因此 AI Agent 程式設計在過去幾個月裡經歷了一個顯著的轉變：從“程式碼直接生成”到“計劃先行，程式碼後行”，這種轉變不僅提升了程式碼質量，還讓過程透明， 進而讓結果更加可控。我們可以看到越來越多的 AI 程式設計代理開始採用這種方法：
-
Claude Code 即時更新任務：透過 TodoRead,TodoWrite工具來即時更新任務列表，確保開發過程中的每個步驟都被記錄和跟蹤。 -
Windsurf 即時更新任務：透過 update_plan在過程中動態更新任務計劃，確保開發者可以隨時檢視當前進度和待辦事項。
即由 AI 輔助人去生成初步 Task，然後人去審查，直到程式碼質量達標。
3. 自動驗證的強化：從測試到上下文引擎
在我們先前的《AI 編碼 2.0 分析、思考與實踐:從 Cursor Composer 到 AutoDev Sketch》裡， 我們介紹了看到的 AI 程式設計工具 2.0 的核心特點：
AI 程式設計工具正在從程式碼補全、程式碼預測，到更加智慧、更耗費 token 的 AI 自動化編碼與驗證，以及正在發展中的非同步 AI 編碼。
基於這些特點，我們認為 AI 程式設計工具 2.0 的核心應該是：
- Agent 驅動。依賴於基礎模型的強大推理能力，結合在程式設計工具中提供更快、更好的獲取上下文，可以讓 AI 程式設計工具更好地理解開發者的意圖，並編寫出更加符合開發者預期的程式碼。
- 開發者體驗優先。結合開發者日常活動，更好的滿足開發者的心流，諸如編輯預測、自動測試等;諸如 Cursor 結合開發者活動提供了大量機制來降低心智成本，以及應對失敗和重試等。
- 自動化校驗。即自動化校驗 AI 生成程式碼的質量、業務邏輯正確性、修復幻覺導致的問題，諸如 patch等，從而在機制上減少幻覺帶來的影響；諸如 Cursor 整合大量實用的 Lint、Terminal 等工具，提供自動化檢驗手段。
在過去的幾個月裡，我們看到 AI 程式設計工具 2.0 的自動化校驗能力得到了顯著提升，特別是 Claude 與 Augment 在這方面展現了非常強大的能力。自動驗證 不再只是單元測試，而是類似人類的程式碼校驗技巧：
-
連續試多種驗證方式 -
多輪自動測試和驗證 -
排除無關錯誤的自動校驗：建立更輕量級的測試指令碼
透過大量的自動化校驗，可以降低人來審查程式碼的負擔，進而讓 AI Agent 程式設計更像是一個“閉環”的過程。
4. 非同步 AI 編碼：從前臺到後臺的轉變
AI 程式設計的另一個重要趨勢是非同步化，諸如：Augment Remote Agent、Cursor Backend Agent。過去，AI 程式設計主要依賴於前臺的互動式體驗， 即開發者在 IDE 中直接與 AI 互動，即時生成程式碼和驗證結果。而現在，AI 程式設計正在向後臺非同步執行轉變，這種轉變帶來了更高的效率和更低的心智負擔。 你只需要 review AI 給你的 PR 即可，
儘管 AI 程式設計的非同步化仍處於早期階段，但它已經展現出巨大的潛力，你可以將
-
需求交給模型分析，在後臺生成 Plan、程式碼，甚至是自動化測試指令碼。 -
開發任務交給 AI Agent，AI Agent 會在後臺處理，並在完成後透過 PR 或通知的方式告知你。
當然了，AI 編碼並非單一技術的突破，而是三大關鍵技術支柱——遠端開發基礎設施（VSCode Server 等、程式碼庫整合）、 上下文引擎和模型上下文協議——協同演進的產物。
PS：隨著，AI 程式設計工具在工程化落地的增強，在未來，我們可能要面臨的問題，沒有足夠的 backlog 能給 AI 在後臺進行程式設計，
5. 從單兵作戰到 AI 代理團隊協作
當前，AI 已經以“單兵作戰”的形式滲透到 SDLC 的各個環節 —— 從市場研究（如 Google DeepResearch、Perplexity AI）、需求分析（如 Atlassian Intelligence）、 UI設計（如 v0.dev）、程式碼生成（如 Cursor、Augment）、程式碼審查（如 CodeRabbit）， 到測試（如 BrowserStack AI）和運維（如 Datadog）， 這些獨立的AI工具正在為各自的領域帶來顯著但孤立的效率提升。
-
市場調研：OpenAI/Google DeepResearch 等 -
UI 原型階段：UX Pilot、v0.dev (by Vercel) 等 -
需求階段：結合 Atlassian Jira、Confluence 等 -
程式碼生成：Claude Code、Cursor、Windsurf、Augment、AutoDev、GitHub Copilot 等 -
程式碼質量：CodeRabbit、Qodo Merge、CodeAnt.ai、Greptile 等 -
質量環節：Functionize、Testsigma、Appvance 等 -
運維：Datadog/NewRelic 等
同樣的，我們也可以看到越來越多的整合性方案：
- GitHub Copilot。Web 版本、CLI 版本、IDE 外掛等，提供了從程式碼生成到版本控制的“全流程支援”。
- Atlassian Rovo。是一個旨在將其整個產品套件（Jira、Confluence、Bitbucket）深度嵌入專業化 AI 智慧體（“AI 隊友”）的平臺。 其的核心戰略是利用其“團隊協作圖譜”（Teamwork Graph）來連線跨團隊、跨專案和跨知識庫的資料，透過 Rovo Studio，企業可以構建自己的定製化智慧體；Rovo Dev CLI 則將這種整合的體驗帶入了開發者最熟悉的終端環境。
在進入下半場之後，顯然我們會看到類似於這樣一個場景：你輸入一個想法，就可以自動上線。只需要藉助於通用的 AI Agent（如 Manus）、或者 Agentic 瀏覽器（如 Fellou）將這些工具整合起來，形成一個完整的開發閉環。
6. MCP 架起協作之橋，構建企業級智慧研發平臺基石
由於新一代的模型與 AI Agent 在現在已經充分展現了他的能力，對於企業來說，如何將這些能力整合起來，形成一個完整的開發閉環，是一個重要的挑戰。 而 MCP(Model Context Protocol，模型上下文協議) 作為 AI Agent 的外掛，可以讓 AI Agent 可以無縫地呼叫一系列專業工具、上下文來完成特定任務：
- 專案管理：透過連線 Asana、Atlassian (Jira) 或 Linear，智慧體可以直接建立任務、更新專案狀態、分析團隊進度。
- 基礎設施與運維：整合 Cloudflare 或 Sentry，使其能夠管理雲部署、查詢即時日誌、分析應用錯誤。
- 支付與金融：接入 PayPal、Plaid 或 Square，智慧體可以處理交易、分析財務資料、管理客戶支付資訊。
- 企業自動化：透過 Zapier 或 Workato，智慧體能夠連線數千個企業應用，執行傳送郵件、更新 CRM、安排會議等複雜工作流。
簡單來說，MCP 可以讓你的 AI Agent 更容易獲得模型所需要的相關、“高質量”上下文，以讓生成的程式碼更符合預期。因此，在引入了 AI Agent 程式設計之後， 建立起組織級的 MCP 能力是至關重要的。
PS：當前，就算不討論組織級 AI Agent 的能力建議，以 IDE + AI Agent 也需要 MCP 市場 + MCP 閘道器能力。當前由於 MCP 協議沒有鑑權相關的能力， 因此這個能力就需要由企業自身去想辦法。
7. AI 重構像賭命，沒有架構一切歸零
我使用 Augment 和 Cursor 等 AI 智慧體開發了多個原型應用，它們的確能極大提升開發效率，但也暴露出一個嚴重問題：
僅憑一個模糊的想法或“氛圍”，就讓 AI 生成大量的程式碼，而完全沒有一個連貫的、經過深思熟慮的架構計劃 。這種做法產出的系統，初看可能功能完備， 但其內部結構卻是一片混亂，充滿了義大利麵條式的程式碼和緊耦合的模組，幾乎無法維護。
在經典的軟體開發工程裡，我們一直強調的是：持續最佳化和演進系統架構，而重構則是實現這一目標的核心手段。然而，在 AI 驅動的開發流程中，這一原則卻很難實現，原因如下：
- 初始設計的固化：開發者通常會用一個相對簡單、高層次的提示來啟動一個專案。AI 基於這個初始提示生成了應用的第一個版本。
- 缺乏深層理解：AI 在生成初始架構時，缺乏對系統未來演進方向、非功能性需求（如可擴充套件性、安全性）以及複雜業務約束的深層理解。它選擇的往往是統計上最可能、而非架構上最優的方案。
- 重構的阻力：當人類開發者在後期試圖對這個由 AI 生成的架構進行重構時，會遇到巨大的阻力。如果開發者試圖讓 AI 輔助重構，AI 可能會將這些架構層面的改動誤解為“錯誤”，並試圖將其“修復”回最初那個有缺陷的設計。因為它不理解重構背後的戰略意圖。
- 人工重構的風險：如果開發者選擇手動重構，同樣困難重重。因為他們缺乏 AI 做出初始“決策”時的上下文，不清楚某些看似奇怪的設計背後是否有其隱含的（儘管可能是錯誤的）邏輯。這使得任何大規模的改動都充滿了風險。
即重構和演進式架構不靠譜，而 AI 生成的程式碼往往是義大利麵條式的架構，導致重構變得非常困難。那麼，是不是傳統的架構方式又需要回歸呢？
8. 10 倍速度，還是 10 倍技術債？
來自 GitClear 釋出的《2024 年 AI Copilot 程式碼質量研究》顯示：在 2024 年期間，包含五行以上重複鄰近程式碼的程式碼塊出現頻率增加了 8 倍，程式碼重複的普遍程度比兩年前高出 10 倍。而結合我使用 AI Agent 程式設計的經驗來看，我覺得這個數量級還可以翻倍。其原因是 AI 工具的另一個危險特性是它會不加分辨地放大輸入給它的任何模式——無論是好的還是壞的。
正如我司 Thoughtworks 的專家所指出的，AI 會 “不加選擇地放大”：如果你在犯錯，它會幫助你更快、更大規模地犯錯。 也因此極大地拉大了高質量程式碼庫與低質量程式碼庫之間的開發速度差距。
這種放大效應在“氛圍程式設計”（Vibe Coding）這一現象中體現得淋漓盡致。開發者，尤其是經驗不足的開發者，可能會陷入一種工作模式：僅僅依賴 AI 的快速響應來生成程式碼，而缺乏深入的思考和嚴謹的規劃。AI 程式設計助手恰恰為這種反模式提供了便利，加速了缺乏結構和紀律的程式碼的產出， 最終導致了難以收拾的混亂局面。
如果你在犯錯，它會幫助你更快、更大規模地犯錯。
如何構建更好的程式碼質量門禁，成為我們的新挑戰，
總結：從工具到流程，重構我們的開發正規化
AI 智慧體所承諾的“10 倍生產力”是真實存在的，但它附帶著以技術債形式出現的高額且不斷複利的“隱藏利息”。如果放任不管，這筆債務將最終壓垮整個工程組織。在 2025 年及以後能夠取得成功的領導者，將是那些能夠清醒地認識到這一悖論，並主動構建相應的文化、流程和分層工具鏈來馴服這頭智慧體“野獸”的人。 只有這樣，才能將其原始的、強大的力量，轉化為可持續的、架構優良的商業價值。