過去我們評價(jià)一個(gè)AI編程工具最常問的是代碼寫得準(zhǔn)不準(zhǔn)能不能補(bǔ)全函數(shù)能不能修Bug能不能理解更多文件能不能一次生成更完整的代碼這種評價(jià)方式?jīng)]有錯(cuò)。因?yàn)樵缙贏I編程的核心任務(wù)本來就是Code Generation。開發(fā)者提出需求模型生成代碼然后人負(fù)責(zé)復(fù)制、運(yùn)行、測試、修改和提交。但真正長期使用ChatGPT、Codex這類工具以后會(huì)發(fā)現(xiàn)一個(gè)變化開發(fā)者交給AI的任務(wù)正在越來越少地停留在幫我寫一段代碼。而越來越接近幫我把這個(gè)問題解決掉。兩句話看起來差別不大背后的工程模式卻完全不同。因?yàn)椤皩懘a”只需要解決一個(gè)輸出問題。而“完成任務(wù)”意味著Agent必須經(jīng)歷理解目標(biāo) ↓ 讀取項(xiàng)目 ↓ 定位問題 ↓ 修改代碼 ↓ 運(yùn)行工具 ↓ 執(zhí)行測試 ↓ 檢查結(jié)果 ↓ 繼續(xù)修正 ↓ 判斷是否完成這意味著AI編程正在從生成代碼走向執(zhí)行任務(wù)。一、Code Generation時(shí)代AI只是開發(fā)流程中的一個(gè)環(huán)節(jié)最早的AI編程工作流非常簡單需求 ↓ AI生成代碼 ↓ 開發(fā)者復(fù)制 ↓ 運(yùn)行 ↓ 調(diào)試AI真正負(fù)責(zé)的只有中間一段Generate。其他環(huán)節(jié)仍然由人完成。所以這個(gè)階段最重要的指標(biāo)自然是代碼正確率補(bǔ)全速度首次生成質(zhì)量代碼風(fēng)格上下文長度。如果模型生成代碼質(zhì)量更高開發(fā)效率就會(huì)提高。整個(gè)邏輯很直接。但它有一個(gè)明顯限制AI并不知道自己生成的代碼最終有沒有真正解決問題。它可以輸出修改完成。但它可能沒有運(yùn)行測試。沒有Build。沒有檢查Diff。甚至沒有真正理解當(dāng)前項(xiàng)目環(huán)境。所以這個(gè)階段的“完成”更多只是Output Finished。而不是Task Finished。二、任務(wù)執(zhí)行最大的變化代碼從“結(jié)果”變成了“動(dòng)作”假設(shè)用戶現(xiàn)在提出修復(fù)登錄后偶發(fā)401的問題。如果只是代碼生成模型它可能直接輸出修改Token刷新邏輯……但一個(gè)真正承擔(dān)任務(wù)執(zhí)行的Agent首先應(yīng)該問401到底來自哪里于是流程變成復(fù)現(xiàn)問題 ↓ 讀取認(rèn)證代碼 ↓ 分析日志 ↓ 檢查Token ↓ 檢查Cookie ↓ 確定Root Cause ↓ 修改代碼 ↓ 運(yùn)行測試 ↓ 重新驗(yàn)證這時(shí)候代碼已經(jīng)不再是最終目標(biāo)。代碼只是Agent完成任務(wù)過程中采取的一種Action。所以可以把兩種模式簡單區(qū)分成過去 Goal Generate Code現(xiàn)在 Goal Change System State真正的目標(biāo)是登錄問題消失并且有證據(jù)證明它已經(jīng)消失。這就是任務(wù)執(zhí)行和代碼生成之間最重要的區(qū)別。三、AI一旦開始執(zhí)行工程問題就突然變多了代碼生成階段問題相對簡單。模型只需要考慮寫什么Agent真正執(zhí)行以后必須繼續(xù)回答在哪里執(zhí)行可以讀取什么可以修改什么可以運(yùn)行哪些命令能不能聯(lián)網(wǎng)哪些操作需要確認(rèn)修改之后怎么驗(yàn)證于是AI編程開始出現(xiàn)一整套過去很少討論的概念Workspace Permission Sandbox Tool Context Task Boundary Verification Evidence這也是為什么現(xiàn)在談Codex越來越難只討論模型寫代碼能力。因?yàn)橥粋€(gè)模型在兩個(gè)不同工程環(huán)境里的表現(xiàn)可能完全不同。一個(gè)環(huán)境目錄準(zhǔn)確項(xiàng)目規(guī)則清晰工具完整權(quán)限合理測試體系成熟。另一個(gè)環(huán)境Workspace巨大依賴損壞權(quán)限混亂任務(wù)沒有邊界沒有測試。最終使用體驗(yàn)可能完全不同。所以Agent時(shí)代真正重要的不只是Model Intelligence。還有Execution Environment。四、從Prompt Engineering到Task Engineering代碼生成時(shí)代大家最關(guān)心Prompt怎么寫比如給模型更多背景指定技術(shù)棧規(guī)定輸出格式補(bǔ)充示例。這些當(dāng)然仍然有價(jià)值。但任務(wù)越來越復(fù)雜以后僅僅優(yōu)化Prompt已經(jīng)不夠。假設(shè)你告訴Codex幫我把認(rèn)證系統(tǒng)優(yōu)化好。即使Prompt寫得很漂亮Agent仍然面臨大量未定義問題什么叫優(yōu)化允許修改哪些模塊能不能升級依賴數(shù)據(jù)庫能不能動(dòng)什么狀態(tài)算完成如果第一次修改失敗是繼續(xù)擴(kuò)大范圍還是停止所以Agent任務(wù)越來越需要定義Problem Scope Constraint Milestone Verification Done這其實(shí)已經(jīng)不是傳統(tǒng)Prompt Engineering。更接近Task Engineering。也就是不只是告訴Agent“做什么”還要設(shè)計(jì)整個(gè)任務(wù)應(yīng)該怎樣運(yùn)行。五、任務(wù)執(zhí)行必須有“狀態(tài)”不能只靠聊天記錄長任務(wù)里還有一個(gè)明顯問題Agent不只是需要記住需求。還需要知道現(xiàn)在做到哪里了。例如目標(biāo) 修復(fù)認(rèn)證問題 已確認(rèn) Token正常 已排除 數(shù)據(jù)庫問題 當(dāng)前Root Cause Cookie配置 已修改 auth/cookie.ts 當(dāng)前狀態(tài) 單元測試通過 集成測試未完成這些信息其實(shí)已經(jīng)形成Execution State。如果狀態(tài)只存在于幾十輪聊天記錄里任務(wù)越長越容易混亂。所以真正長期運(yùn)行的Agent越來越需要計(jì)劃Checkpoint狀態(tài)記錄決策記錄最終Evidence。這和傳統(tǒng)軟件系統(tǒng)非常相似。復(fù)雜工作不能只靠“我記得剛才做過什么。”必須把狀態(tài)顯式化。六、為什么Verification會(huì)成為Agent時(shí)代的核心能力代碼生成時(shí)代人通常會(huì)自然接過AI的代碼自己看一遍自己運(yùn)行自己測試。所以驗(yàn)證壓力主要在人。但Agent開始自主執(zhí)行以后如果每一個(gè)結(jié)果仍然需要開發(fā)者從頭檢查AI雖然寫得更快人的Review壓力卻可能越來越大。這時(shí)候一個(gè)真正成熟的Agent不能只輸出Done。還應(yīng)該能夠提供修改了哪些文件 為什么修改 運(yùn)行了什么測試 測試結(jié)果是什么 哪些內(nèi)容沒有驗(yàn)證 還存在什么風(fēng)險(xiǎn)也就是說Execution之后必須跟著Verification?？梢园淹暾鞒汤斫獬蒚ask ↓ Action ↓ Result ↓ Verification ↓ Evidence其中Evidence非常關(guān)鍵。因?yàn)锳gent真正進(jìn)入工程體系以后企業(yè)需要的不是“AI覺得自己完成了?！倍窍到y(tǒng)能夠證明任務(wù)達(dá)到了完成條件。七、多Agent進(jìn)一步把AI編程變成系統(tǒng)問題一個(gè)Agent的時(shí)候開發(fā)者還可以一直盯著。但如果同時(shí)運(yùn)行Agent A修Bug Agent B補(bǔ)測試 Agent C分析日志 Agent D處理另一個(gè)Issue問題馬上從單任務(wù)變成Coordination。需要解決誰負(fù)責(zé)什么哪些任務(wù)可以并行哪些必須串行是否共享Workspace結(jié)果怎么匯總沖突怎么處理哪個(gè)Agent擁有最終決策權(quán)。這時(shí)候“AI編程工具”的概念又繼續(xù)變化。它不再只是一個(gè)更強(qiáng)的Coding Assistant。而開始接近一個(gè)由多個(gè)執(zhí)行單元組成的工程系統(tǒng)。因此未來真正重要的能力可能不是一次開多少個(gè)Agent。而是這些Agent能不能在清楚的邊界內(nèi)形成穩(wěn)定協(xié)作。八、開發(fā)者的位置也在發(fā)生變化傳統(tǒng)開發(fā)者大量時(shí)間花在Read Write Run Debug TestAgent承擔(dān)更多執(zhí)行以后人不會(huì)消失。但人的工作重心會(huì)逐漸向上移動(dòng)Define Goal ↓ Set Boundary ↓ Review Decision ↓ Handle Exception ↓ Verify Result也就是說人正在從直接執(zhí)行者逐漸增加一個(gè)角色任務(wù)監(jiān)督者。這并不是簡單的“AI替人寫代碼”。真正發(fā)生的是人和機(jī)器之間的工作分工重新劃分。Agent負(fù)責(zé)越來越多How。人負(fù)責(zé)越來越多WhatWhyWhether。九、所以未來評價(jià)AI編程工具的標(biāo)準(zhǔn)也會(huì)變化過去評價(jià)模型寫代碼準(zhǔn)確率Benchmark上下文長度Token成本。這些不會(huì)消失。但Agent真正進(jìn)入工作流以后還需要增加新的指標(biāo)。例如Task Completion Rate任務(wù)最終有沒有真正完成Human Intervention Rate完成一個(gè)任務(wù)需要人介入多少次Recovery Rate遇到失敗以后能不能自行恢復(fù)Verification Quality結(jié)果有沒有可靠證據(jù)Scope Control任務(wù)執(zhí)行過程中有沒有不斷擴(kuò)大范圍Long-Horizon Stability執(zhí)行時(shí)間變長以后還能不能保持最初目標(biāo)這些指標(biāo)衡量的已經(jīng)不是模型單次輸出質(zhì)量。而是整個(gè)Agent系統(tǒng)的工作質(zhì)量。十、AI編程真正發(fā)生的是“抽象層級上移”回頭看整個(gè)變化會(huì)發(fā)現(xiàn)AI編程正在不斷提高自己的工作抽象層級。第一階段LineAI補(bǔ)全一行代碼。第二階段Function / FileAI生成完整模塊。第三階段TaskAI修復(fù)一個(gè)Bug或者實(shí)現(xiàn)一個(gè)Feature。第四階段GoalAgent圍繞一個(gè)目標(biāo)自己協(xié)調(diào)多個(gè)步驟甚至多個(gè)執(zhí)行單元。所以真正的發(fā)展路線可能不是模型一次寫更多代碼。而是人類逐漸把更高層級的目標(biāo)交給系統(tǒng)。十一、從“代碼工具”到“執(zhí)行系統(tǒng)”如果只看表面Codex仍然是AI編程工具。但從系統(tǒng)結(jié)構(gòu)來看它正在越來越接近Intent ↓ Agent ↓ Context ↓ Tools ↓ Environment ↓ Execution ↓ Verification ↓ Result這套結(jié)構(gòu)真正強(qiáng)調(diào)的是完整閉環(huán)。如果只有Intent ↓ Code仍然是生成工具。如果能夠完成Intent ↓ Verified Result它才開始接近執(zhí)行系統(tǒng)。這也是為什么最近AI編程領(lǐng)域越來越多地討論Context EngineeringTask EngineeringSkillsMCPSubagentsVerificationControl Plane。它們表面上是不同技術(shù)。本質(zhì)上都在解決同一個(gè)問題怎樣讓模型從“會(huì)生成”走向“能持續(xù)、可控地完成工作”。最后AI編程正在從代碼生成走向任務(wù)執(zhí)行并不是因?yàn)榇a突然不重要了。恰恰相反。代碼依然是軟件工程最核心的執(zhí)行媒介之一。真正變化的是代碼在整個(gè)AI工作流里的位置。過去Code Result現(xiàn)在越來越接近Code Action真正的結(jié)果是Task Completed Verified所以未來開發(fā)者真正需要掌握的也可能不再只是怎么讓AI生成更好的代碼。還包括怎樣定義目標(biāo)怎樣限制范圍怎樣組織Context怎樣設(shè)計(jì)工具怎樣拆分Agent怎樣建立驗(yàn)證怎樣讓失敗可以恢復(fù)。當(dāng)這些能力逐漸成熟以后AI編程就不再只是一個(gè)模型幫人寫代碼。而會(huì)越來越接近人定義目標(biāo)Agent系統(tǒng)負(fù)責(zé)把工程推進(jìn)到一個(gè)可以驗(yàn)證的完成狀態(tài)。這才是從Code Generation走向Task Execution真正意味著的變化。