面向六個月後的AICode，也許影響的不只是前端

在 2024 年底我還覺得 AI 取代程式設計師是遙不可及的事情，隨著在 AI Code 領域個人學習和團隊高密度的討論、實踐，個人的一些觀點發生了 180 度掉頭，AI 取代初級程式設計師的程式設計任務近在眼前，本文來分享一下讓我觀點發生變化的 AI 能力和對未來 AI Code 的理解。

"從長遠看，注意我說的“長遠”可能也就是 18~24 個月，而不是五六年，也許在初級層面的編碼工作上會出現“替代”現象，也可能比這更早。"Dario 在訪談中直言不諱地表示。這一時間線比大多數行業專家預期的要短得多，尤其是考慮到他所謂的“長遠”僅僅是一年半到兩年的時間。—— 2025.02 Anthropic 執行長 Dario Amodei

Agent VS Workflow

Manus 的爆火讓很多人忽然發現，已經有多個產品稱自己是 AI Agent，就像市場上很多食品都標榜“純天然”一樣，Agent 這個詞被過度使用。就像人有人質疑 Manus 一樣，有些所謂 Agent 只是預編排的 Workflow，因為在 Workflow 內可以呼叫大模型，看起來都很 AI，導致人們難以區分 Worklow 和 Agent。

兩者關鍵區別在於自主決策能力，簡單說 Workflow 就像是固定的生產線，每個步驟都是預先設計好的；而 Agent 則像是有自主思考能力的助手，透過感知-決策-執行的路徑，可以自己決定怎麼做、做多久。

歸根結底，真正的 Agent 有兩個關鍵特點：

1.能自己做決定：不需要人類告訴它每一步該做什麼？

2.會一直工作到完成任務：執行次數不是預先固定的，而是根據需要自動調整。

想象一下廚房裡的兩種場景：

Workflow：按照菜譜一步步做菜，第一步切菜，第二步放油，第三步炒菜，每一步都是預先定好的，按部就班地執行，過程中如果出現沒油了，可能炒菜就得中斷了。
Agent：你告訴一個會做飯的人“做一道可口的晚餐”，他會根據冰箱裡有什麼材料，自己決定做什麼菜，如何烹飪，需要走多少步驟才能完成，如果沒油了，Agent 會自己知道要去買油。

最適合 Agent 的任務特徵

在選擇使用 Agent 的場景時，來自 Anthropic 的 Barry 提出了一個非常實用的標準：

我認為代理最適合的場景是那些既複雜又有價值的任務，但失敗後的風險較低或監控成本不高的任務。這是代理應用的理想交叉點。

簡單來說最適合 Agent 的任務應該是：

足夠複雜：簡單任務用代理可能是“殺雞用牛刀”；
有一定價值：值得投入資源去自動化；
容錯性高：即使代理偶爾出錯，也不會造成嚴重後果，在人監督的情況下可以進一步降低風險。

舉個生活中的例子，你可能會讓 Agent 幫你篩選郵件或整理文件，因為即使它偶爾分類錯誤，後果也不嚴重。但你可能不會讓 Agent 直接操作你的銀行賬戶進行大額轉賬，因為錯誤成本太高。

以搜尋為例，這是一個非常有價值的任務，進行深入的迭代搜尋非常困難，但總是可以用一些精度換取召回率，然後獲得比需要更多的文件或資訊，然後過濾下來。這意味著 Agent 可以進行多輪、深入的資訊檢索，不斷調整搜尋策略，最終找到使用者真正需要的資訊，而不僅僅是關鍵詞匹配的結果。

所以我們在 Agent 搜尋方面看到了很多成功，比如 Perplexity 和 Alibaba.com 的 Accio，也許看到這裡大家已經注意到了，除了搜尋還有一個領域近乎完美契合這些特徵 —— Coding！

最近大家可能有些觀察，有了 Agent 模式， Cursor、Windsurf 越來越像了：

Cursor 的 Yolo 模式能自主判斷終端命令執行狀態，在編譯報錯後自動修正並重新執行。
Windsurf 的 AI Flows 可分解複雜任務為多步驟工作流，即時監測檔案變更並同步調整後續操作。

甚至位元組 3 月份力推的 Trae 在人機互動體驗上也如出一轍，重點從 MarsCode 時的 Tab 提示轉向了 Agent 模式，IDE 的智慧輔助已超越傳統補全，演變為環境感知型協作者，環境感知+自主決策將成為下一代 IDE 標配。

潮湧護城河

程式設計師的 Coding 時間甚至佔不到 50%，所有 AI 程式設計工具暫時還取代不了人類，先來捋一下程式設計師是怎麼寫程式碼的

1.參與需求評審、設計評審，明確程式設計目標。

2.利用自身知識做技術方案設計。

3.使用企業、社群方案完成程式碼框架。

4.完成程式碼實現，對程式進行完善。

a.透過報錯資訊對程式進行修改

b.上網查詢相關資訊

c.向身邊專家求助

5.對程式碼進行單元測試。

6.整合測試、冒煙、專案驗收。

有了對 Agent 瞭解之後，發現貌似程式設計師的不可取代性主要集中在需求理解，技術設計和程式碼框架對企業內部知識有依賴，AI 無法全面完成，其餘的工作 Agent 在程式設計師的監督下可以代勞。之前覺得 AI 程式設計無法取代自己的僥倖感，正是來自於 AI 擅長通用問題的解決，而兩個障礙讓 AI 沒法幫我寫程式碼

1.針對單檔案的 Tab 提醒，沒法結合專案最佳實踐，給我最優建議。

2.因為大量使用企業內部的程式碼規範、基礎元件、中介軟體、框架等，AI 不懂這些。

隨著最近三個月 AI 圈的不斷重新整理，發現事情並沒有那麼簡單。

Codebase Indexing 理解專案全文

Cursor 在誕生時就透過 Codebase Indexing 解決了第一個問題，把護城河填埋了一半。

當用 Cursor 開啟一個專案時，Cursor 會自動對程式碼庫進行掃描和索引。它會分析程式碼中的各種元素，如函式、類、變數等，並建立它們之間的關係。透過這種方式，AI 可以快速定位到相關的程式碼片段，瞭解程式碼的上下文和用途

上下文感知的程式碼片段關聯，如識別 getUserInfo() 在不同模組中的過載形態；
跨檔案語義追溯，如透過介面定義自動定位所有實現類；
增量更新機制，新增檔案在儲存後 30 秒內完成索引同步；

這樣，當開發者提出一個程式碼生成需求時，AI 可以根據索引資訊，參考專案中已有的程式碼模式和風格，生成更符合專案實際情況的程式碼

RAG + Function Call 讓模型更懂企業

模型不懂企業內部或專業領域知識以往多透過模型微調來解決，微調雖能針對性注入領域知識，但始終面臨幻覺、降智的頑疾，同時面臨“知識固化”困境——調整後的引數無法動態適應業務規則變化，且高頻次全量微調帶來的算力/預算消耗也是一個巨大的成本。

如果僅為了專業知識的拓展，相對而言 RAG 是個不錯的選擇，可以解決知識的即時性和成本問題，但會讓 AI 生成程式碼進入預定流程編排的 Workflow 模式，而且需要開發使用強啟用詞呼叫 RAG 後拼裝 Prompt，比如呼叫元件庫，使用 Button 元件改寫程式碼。雖然業界有 RAG “無感知智慧化”演進的實踐，例如微軟的 GraphRAG 透過知識圖譜實現多跳推理檢索，但考慮到技術難度和成本問題，應用並不廣泛。

Function Call 算是個救星，透過將自然語言指令轉化為結構化預定義 API 請求，執行具體操作或獲取即時資料。根據 OpenAI 最新指南，Function Call 的“資料獲取”模式本質上是一種 RAG 實現——在生成回答前，透過 Function Call 主動觸發知識庫檢索動態補充模型知識，大模型實現從被動應答向主動求知的認知躍遷。

Function calling example with get_weather function

from openai import OpenAIclient = OpenAI()tools = [{"type": "function","name": "get_weather","description": "Get current temperature for a given location.","parameters": {"type": "object","properties": {"location": {"type": "string","description": "City and country e.g. Bogotá, Colombia" } },"required": ["location" ],"additionalProperties": False }}]response = client.responses.create( model="gpt-4o",input=[{"role": "user", "content": "What is the weather like in Paris today?" }], tools=tools)print(response.output)

但 Function Call 每次呼叫需將 API 返回資料全量注入提示詞，導致上下文長度線性膨脹。同時 Function Call 的生態極其碎片化，不同模型廠商定義各自的函式呼叫格式（如 OpenAI 的 JSON 結構），導致跨平臺開發需重複適配，同時因為開發者需手動實現三階段流程（函式定義→模型適配→結果解析），每新增一個 API 需投入大概 20+ 小時開發。

然而這個複雜度也在 MCP 的衝擊下也開始鬆動起來。

MCP：大模型與企業知識的 USB-C

什麼是 MCP

The Model Context Protocol (MCP)lets you build servers that expose data and functionality to LLM applications in a secure, standardized way. Think of it like a web API, but specifically designed for LLM interactions.

簡單來講 MCP 是 Anthropic 提出的一個用於標準化應用程式如何向大語言模型提供上下文的開放協議，相當於模型與各種應用程式之間的 USB-C。

MCP 使用 C/S 模式，它們之間用一種標準的訊息格式（基於JSON-RPC）交流

MCP Client：嵌入在 AI 應用內（比如 Cursor），負責跟伺服器“聊天”，根據使用者自然語言，智慧發起 MCP 服務呼叫，獲取資料、資源或命令執行。
MCP Server 器：開發者提供的向模型暴露內部資料、資源、功能的服務。

Cursor 支援 MCP 的關鍵角色

Cursor、MCP Server 與模型之間的資料流程是一個標準化的協作體系，透過 MCP協議實現三者的高效互動。

Cursor 本身作為一個 MCP Client，負責發起請求、展示結果，並作為使用者與系統的互動入口。
開發者實現的 MCP Server 提供標準化介面，處理客戶端請求，對接本地或遠端資源（如GitHub API、本地檔案系統），並返回結構化資料。
模型接收 Cursor 傳遞的請求和上下文，生成決策（如是否需要呼叫工具）及自然語言響應。

MCP 資料流轉

階段一：初始化

1.Cursor 啟動時，初始化 MCP Client 並與專案或 IDE 全域性配置的 MCP Server 建立連線。

2.雙方進行功能協商，確定 Server 提供的可用資源/工具列表，為後續呼叫做好準備。

階段二：處理使用者請求

1.請求傳遞與工具選擇：使用者在 Cursor 透過自然語言輸入指令，Cursor 將請求傳送至 MCP Server，獲取當前可用的工具描述。Cursor 將工具列表與使用者指令拼接，傳送給模型。

2.模型決策與工具呼叫：模型解析請求，判斷需呼叫的工具，並生成結構化引數，Cursor 透過 MCP Server 執行工具呼叫。

階段三：資料互動與結果整合

1.資源訪問與執行：MCP Server 響應請求，結果透過 JSON-RPC 2.0 協議返回給 Cursor。

2.模型生成最終響應：Cursor 將 MCP Server 返回結果傳送給模型，模型整合上下文生成自然語言響應，最終結果透過 Cursor 介面展示給使用者。

因為有了模型決策呼叫哪個工具來解決使用者問題的步驟，因此如果模型判斷需要呼叫 MCP Server 的話會多一次模型的呼叫。

MCP 核心優勢

MCP 帶來了幾個核心優勢

協議標準化驅動生態統一： MCP透過統一的協議簡化了AI與外部工具的連線，開發者無需為每個工具單獨編寫介面程式碼，實現一次開發多工具複用

這裡有數千開源的 MCP Server 實現可以使用、借鑑，Cursor、Windsurf 等 IDE 均已支援：

https://glama.ai/mcp/tools

https://smithery.ai/

開發效率：MCP 官方提供了開發工具包 & 除錯工具，相對於相容各種 AI 模型的 Function Call，實現一個通用的 MCP Server 極其簡單。

demo MCP Server

from mcp.server.fastmcp import FastMCP# Create an MCP servermcp = FastMCP("Demo")# Add an addition tool@mcp.tool()defadd(a: int, b: int) -> int:"""Add two numbers"""return a + b# Add a dynamic greeting resource@mcp.resource("greeting://{name}")defget_greeting(name: str) -> str:"""Get a personalized greeting"""returnf"Hello, {name}!"

根治上下文爆炸：MCP 採用模組化上下文管理，將外部資料來源抽象為獨立模組，模型僅在需要時啟用指定模組，同時透過增量索引，MCP 僅同步變更資料，相比 Function Call 的全量注入模式，Token 消耗顯著降低。
動態發現與靈活性：MCP 支援動態發現可用工具，AI 可自動識別並呼叫新接入的資料來源或功能，無需提前配置。

MCP 透過協議層革新重構了 AI 與外部系統的協作正規化，其標準化、動態化、安全性的特徵，正在解決 Function Call 面臨的生態碎片化、上下文冗餘、許可權粗放等核心痛點。隨著 Anthropic 攜 Claude 之利的生態推進，MCP 有望成為下一代智慧系統的核心基礎設施。

Fuction Call 與 MCP

乍一看兩者非常相似，都在解決模型與外部工具互動問題，兩者的資料流程有很大區別

Function Call：使用者輸入 → 模型識別意圖 → 生成工具引數 → 執行外部函式 → 返回結果整合。
MCP：使用者輸入 → Client 向 MCP Server 請求可用工具列表 → 模型生成自然語言指令 → Client 解析指令並呼叫工具 → 返回結果 -> 模型根據結果更好的響應使用者輸入。

Function Call 依賴模型層面的支援，而 MCP 更像是模型的外掛，只要有 Client 負責提供可用服務列表並對模型發起詢問，任何模型都可以使用 MCP，no magic, just chat。

Function Call 是模型能力的延伸，而 MCP 是工具互動的基礎設施。兩者的差異本質上是“垂直最佳化”與“橫向通用”的技術路線之爭，未來或將共存互補。

六個月後的 AI Code 正規化

未來 AI 程式碼生成體系將形成 “規範驅動→知識沉澱→協議貫通→智慧執行” 的閉環架構，確保程式碼生成的高質量、可維護性和智慧化。

規範驅動體系，透過一系列技術規範和最佳實踐來確保架構合理，生成企業級高可用程式碼。
業務知識庫作為 AI 程式碼生成的核心認知模組，負責儲存和管理多模態知識，支援動態更新和智慧檢索。
MCP Server 作為系統的感官系統，負責與各類智慧 Agent 互動，獲取並處理開發過程中的各種資訊，確保系統的高效執行。
IDE 整合智慧編碼工作流和多智慧體協作機制，透過人機協同介面提升開發效率和程式碼質量。

在這種模式下前端普遍嘗試的 D2C 生成 UI 程式碼，可以進化到 UI + 資料繫結 + 互動邏輯我全都要。

順便便可以看一下目前根據 Figma 生成 HTML 程式碼有多簡單：

https://glama.ai/mcp/servers/kcftotr525

留給中國隊的時間已經不多了

Dario Amodei 認為，隨著模型不斷變強、變得足夠好，它們會在現實中“破圈”。有些更偏研究用途的模型，我們自己也在做，很快就會出來，再下一步是 Agent，可以去自主執行任務，這會是另一個層級。到那時候，我相信人們會在接下來的兩年中，比以前更深刻地理解到 AI 的風險和收益。我只是擔心，這種覺醒可能來得很突然。

⚠️ 雖然 AI Code 現階段對前端開發者衝擊最大，但可能幾個月後後端開發者會更猝不及防。