1. 從“補(bǔ)全代碼”到“接手任務(wù)”AI智能體到底在改變什么這兩年但凡寫過幾行代碼的人應(yīng)該都能感覺到一個(gè)明顯的變化AI在開發(fā)流程里的角色正在從“幫你補(bǔ)全下一行”變成“幫你把一整件事做完”。以前我們用代碼補(bǔ)全工具敲個(gè)函數(shù)名它給你提示參數(shù)后來有了對(duì)話式編程助手你把報(bào)錯(cuò)貼進(jìn)去它給你解釋原因、給出修改建議。而現(xiàn)在所謂的AI智能體AI Agent開始出現(xiàn)在真實(shí)項(xiàng)目里它不只是回答問題而是能自己拆任務(wù)、自己調(diào)工具、自己跑測(cè)試、自己根據(jù)結(jié)果調(diào)整下一步動(dòng)作。這個(gè)變化聽起來像是量變實(shí)際上是質(zhì)變。補(bǔ)全代碼解決的是“手速”問題對(duì)話助手解決的是“知識(shí)檢索”問題而智能體試圖解決的是“任務(wù)執(zhí)行”問題。一個(gè)典型的智能體工作流是這樣的你給它一個(gè)目標(biāo)比如“給這個(gè)模塊加上輸入校驗(yàn)并補(bǔ)充單元測(cè)試”它會(huì)先讀代碼庫、理解現(xiàn)有結(jié)構(gòu)、規(guī)劃出幾個(gè)步驟、然后依次執(zhí)行——寫代碼、運(yùn)行測(cè)試、發(fā)現(xiàn)失敗、定位原因、修改代碼、再跑測(cè)試直到通過或者卡住向你求助。整個(gè)過程里人從“操作者”變成了“監(jiān)督者”。但這里有個(gè)關(guān)鍵問題必須先說清楚能自主執(zhí)行任務(wù)不等于能自主編程。這兩件事之間隔著一條很深的溝。自主執(zhí)行是在既定框架、既定目標(biāo)、既定約束下完成動(dòng)作序列自主編程則要求它能自己定義問題、自己判斷目標(biāo)是否合理、自己決定架構(gòu)取舍、自己承擔(dān)技術(shù)債的后果。前者是“執(zhí)行力”的自動(dòng)化后者是“判斷力”的自動(dòng)化。目前市面上絕大多數(shù)號(hào)稱智能體的東西都還牢牢停留在前者。我之所以想認(rèn)真聊這個(gè)話題是因?yàn)楝F(xiàn)在圍繞AI編程的討論太容易走兩個(gè)極端。一邊是“程序員要失業(yè)了”的恐慌式敘事另一邊是“AI寫的代碼根本不能用”的輕視式否定。這兩種說法都偷懶。真實(shí)情況是智能體已經(jīng)在某些具體環(huán)節(jié)上強(qiáng)得超出很多人預(yù)期但在另一些環(huán)節(jié)上又笨得讓人哭笑不得。搞清楚它到底強(qiáng)在哪、弱在哪、邊界在哪比站隊(duì)有用得多。這篇文章我會(huì)從實(shí)際使用和工程落地的角度把AI智能體在軟件開發(fā)中的能力拆開來看。我會(huì)講清楚它的工作機(jī)理、當(dāng)前能穩(wěn)定做到什么、在哪些地方會(huì)翻車、以及從“輔助執(zhí)行”到“完全自主”之間還差哪些關(guān)鍵能力。不管你是剛?cè)胄械拈_發(fā)者還是帶團(tuán)隊(duì)的技術(shù)負(fù)責(zé)人或者只是對(duì)AI編程好奇的產(chǎn)品、測(cè)試同學(xué)都能從中拿到一些能直接用的判斷依據(jù)和實(shí)操參考。2. 智能體編程的工作機(jī)理它憑什么能“自己干活”2.1 一個(gè)智能體的最小閉環(huán)感知、規(guī)劃、行動(dòng)、反饋要理解智能體為什么比單純的代碼補(bǔ)全強(qiáng)得先看它的基本結(jié)構(gòu)。一個(gè)能干活兒的編程智能體核心是一個(gè)閉環(huán)而不是一次性的輸入輸出。這個(gè)閉環(huán)通常包含四個(gè)環(huán)節(jié)感知讀取當(dāng)前環(huán)境狀態(tài)。對(duì)編程任務(wù)來說就是讀代碼文件、讀報(bào)錯(cuò)信息、讀測(cè)試結(jié)果、讀依賴配置、讀版本歷史。規(guī)劃根據(jù)目標(biāo)和當(dāng)前狀態(tài)決定下一步做什么。是把大任務(wù)拆成小步驟還是先探索代碼庫再動(dòng)手。行動(dòng)調(diào)用工具執(zhí)行具體操作。寫文件、改文件、運(yùn)行命令、執(zhí)行測(cè)試、搜索文檔。反饋拿到行動(dòng)的結(jié)果判斷是否接近目標(biāo)然后回到感知環(huán)節(jié)進(jìn)入下一輪。這個(gè)循環(huán)聽起來簡單但它是智能體和普通對(duì)話助手的根本區(qū)別。普通助手是“你問一句它答一句”沒有持續(xù)的狀態(tài)跟蹤也沒有基于結(jié)果的自我修正。智能體則是在一個(gè)循環(huán)里不斷迭代直到任務(wù)完成或觸發(fā)終止條件。我打個(gè)生活化的比方。普通代碼助手像是一個(gè)坐在你旁邊、你問什么他答什么的技術(shù)顧問智能體則像是一個(gè)你派出去辦事的實(shí)習(xí)生你告訴他“把這份材料整理好交到某處”他會(huì)自己找路、自己問人、自己判斷材料齊不齊遇到搞不定的才回來找你。顧問給的是建議實(shí)習(xí)生給的是結(jié)果。這就是為什么智能體的出現(xiàn)讓很多人感到緊張——它開始“動(dòng)手”了。2.2 工具調(diào)用才是智能體的手腳光有循環(huán)還不夠智能體必須能操作真實(shí)環(huán)境這就靠工具調(diào)用Tool Use / Function Calling。一個(gè)編程智能體通常掛載的工具包括文件讀寫、終端命令執(zhí)行、代碼搜索、測(cè)試運(yùn)行器、版本控制操作、文檔檢索等。這些工具就是它的手腳沒有工具它只是個(gè)會(huì)聊天的腦子。這里有個(gè)容易被忽略的工程細(xì)節(jié)工具的設(shè)計(jì)質(zhì)量直接決定智能體的上限。工具給得太粗比如只給一個(gè)“執(zhí)行任意命令”的接口智能體容易亂來安全風(fēng)險(xiǎn)高工具給得太細(xì)比如每個(gè)操作都要拆成十幾個(gè)原子接口智能體的規(guī)劃負(fù)擔(dān)就會(huì)爆炸容易在中間步驟迷路。實(shí)際落地時(shí)比較穩(wěn)妥的做法是給一組語義清晰、邊界明確、冪等性盡量好的工具并且在工具層做權(quán)限和沙箱約束。提示如果你自己在搭智能體工具的數(shù)量不是越多越好。我見過一個(gè)項(xiàng)目給智能體掛了三十多個(gè)工具結(jié)果它在選擇工具上就消耗了大量推理預(yù)算還經(jīng)常選錯(cuò)。后來砍到八個(gè)核心工具任務(wù)成功率反而上去了。2.3 上下文管理智能體的“工作記憶”瓶頸智能體要連續(xù)工作就必須記住之前發(fā)生了什么。但大模型的上下文窗口是有限的任務(wù)一長歷史信息就會(huì)溢出。所以上下文管理成了智能體工程里最核心也最容易被低估的部分。常見的做法有這么幾種一是摘要壓縮把早期對(duì)話和操作壓縮成簡短摘要二是外部記憶把關(guān)鍵信息寫進(jìn)文件或向量庫需要時(shí)再檢索回來三是結(jié)構(gòu)化狀態(tài)用一份明確的任務(wù)清單和進(jìn)度表來跟蹤而不是靠原始對(duì)話歷史。實(shí)際項(xiàng)目里往往是幾種混用。我自己的體會(huì)是結(jié)構(gòu)化狀態(tài)最靠譜。讓智能體維護(hù)一份類似“任務(wù)清單”的東西每完成一步就更新狀態(tài)比讓它從一堆雜亂的歷史里自己回憶要穩(wěn)得多。這就像人干活兒列個(gè)清單比全靠腦子記要可靠。上下文管理做不好智能體就會(huì)出現(xiàn)“干著干著忘了目標(biāo)”“重復(fù)做已經(jīng)做過的事”“把之前的結(jié)論推翻”這類典型癥狀。2.4 規(guī)劃能力的層次從固定流程到動(dòng)態(tài)拆解智能體的規(guī)劃能力也分層次。最基礎(chǔ)的是固定流程就是預(yù)先寫死一套步驟智能體照著走本質(zhì)上是個(gè)自動(dòng)化腳本只是每步用模型來執(zhí)行。往上一層是模板化拆解給幾套常見任務(wù)模板智能體根據(jù)任務(wù)類型選一套再填充細(xì)節(jié)。最高層是動(dòng)態(tài)規(guī)劃智能體自己根據(jù)目標(biāo)現(xiàn)場拆解步驟邊做邊調(diào)整。目前真正穩(wěn)定可用的大多在前兩層。動(dòng)態(tài)規(guī)劃在簡單任務(wù)上表現(xiàn)不錯(cuò)但任務(wù)一復(fù)雜、依賴一多就容易規(guī)劃出看似合理實(shí)則跑不通的步驟。原因也不難理解規(guī)劃需要預(yù)判每一步的后果而軟件系統(tǒng)里的后果往往是非局部的——改一個(gè)函數(shù)可能影響十個(gè)調(diào)用方這種連鎖反應(yīng)很難在規(guī)劃階段全部預(yù)見到。3. 當(dāng)前智能體能穩(wěn)定做到什么別神化也別小看3.1 局部任務(wù)執(zhí)行它已經(jīng)相當(dāng)能打先說好消息。在邊界清晰、目標(biāo)明確、反饋及時(shí)的任務(wù)上智能體的表現(xiàn)已經(jīng)相當(dāng)可靠。什么叫邊界清晰就是任務(wù)范圍限定在一個(gè)或幾個(gè)文件內(nèi)依賴關(guān)系簡單有明確的成功判據(jù)。比如給指定函數(shù)補(bǔ)充參數(shù)校驗(yàn)和邊界處理根據(jù)現(xiàn)有代碼風(fēng)格補(bǔ)全一個(gè)CRUD接口修復(fù)一個(gè)已有明確報(bào)錯(cuò)信息的bug為某個(gè)模塊補(bǔ)充單元測(cè)試并跑到通過把一段重復(fù)代碼抽取成公共函數(shù)并替換所有調(diào)用點(diǎn)這些任務(wù)的共同點(diǎn)是有明確的輸入輸出、有可自動(dòng)驗(yàn)證的結(jié)果測(cè)試通過與否、影響范圍可控。在這類場景里智能體的“執(zhí)行—驗(yàn)證—修正”閉環(huán)能真正跑起來因?yàn)闇y(cè)試就是它的反饋信號(hào)它可以根據(jù)測(cè)試結(jié)果自我迭代。我實(shí)測(cè)下來在測(cè)試覆蓋良好的代碼庫里智能體修復(fù)簡單bug的成功率是相當(dāng)高的。關(guān)鍵在于“測(cè)試覆蓋良好”——如果測(cè)試本身不健全智能體就失去了判斷對(duì)錯(cuò)的依據(jù)很容易改出一個(gè)“看起來對(duì)但實(shí)際錯(cuò)”的版本。3.2 代碼理解與檢索比人快但不如人深智能體在代碼庫理解上的能力也值得說。給它一個(gè)中等規(guī)模的代碼庫它能快速回答“這個(gè)功能在哪里實(shí)現(xiàn)的”“這個(gè)函數(shù)被哪些地方調(diào)用”“這個(gè)配置項(xiàng)影響哪些模塊”這類問題。這種全局檢索和關(guān)聯(lián)的能力比人手動(dòng)翻代碼要快得多尤其在陌生代碼庫里能省下大量時(shí)間。但它的理解是模式匹配式的不是語義推理式的。它能找到“看起來相關(guān)”的代碼但不一定能理解“為什么這么設(shè)計(jì)”。比如一個(gè)看似冗余的判斷可能是為了繞開某個(gè)歷史遺留的邊界情況一個(gè)奇怪的命名可能對(duì)應(yīng)著某個(gè)業(yè)務(wù)上的特殊約定。這些隱含知識(shí)往往不在代碼里而在人的腦子里或早已丟失的文檔里。智能體讀不到這些就容易做出“技術(shù)上正確、業(yè)務(wù)上錯(cuò)誤”的修改。3.3 跨文件重構(gòu)能做但要盯緊跨文件重構(gòu)是智能體能力的一個(gè)分水嶺。簡單的重命名、移動(dòng)函數(shù)它做得不錯(cuò)。但涉及接口變更、依賴調(diào)整、調(diào)用鏈修改的復(fù)雜重構(gòu)就需要人盯著了。問題主要出在影響范圍判斷上。智能體改了一個(gè)函數(shù)的簽名它需要找出所有調(diào)用方并同步修改。在靜態(tài)類型語言里編譯器能幫它兜底在動(dòng)態(tài)語言里就得靠它自己搜索。搜索就可能漏——比如通過字符串拼接、反射、配置注入等方式間接調(diào)用的地方它未必找得到。這些漏網(wǎng)之魚在運(yùn)行時(shí)才會(huì)暴露而智能體的測(cè)試未必覆蓋到。所以我的經(jīng)驗(yàn)是讓智能體做重構(gòu)必須配合強(qiáng)類型檢查和完整的測(cè)試套件。類型檢查負(fù)責(zé)抓接口不一致測(cè)試負(fù)責(zé)抓行為不一致。兩者都健全時(shí)智能體的重構(gòu)才敢用缺一個(gè)就得人工復(fù)核每一處改動(dòng)。3.4 一個(gè)能力邊界速查表為了讓大家有個(gè)直觀判斷我把常見任務(wù)按智能體的可靠程度整理成表任務(wù)類型智能體可靠度關(guān)鍵前提人工介入程度補(bǔ)全函數(shù)/方法高上下文清晰抽查即可修復(fù)有明確報(bào)錯(cuò)的bug較高測(cè)試可復(fù)現(xiàn)復(fù)核修改點(diǎn)補(bǔ)充單元測(cè)試高接口穩(wěn)定抽查斷言合理性局部重構(gòu)單文件較高類型/測(cè)試健全復(fù)核跨文件重構(gòu)中強(qiáng)類型全測(cè)試逐處復(fù)核新功能從零實(shí)現(xiàn)中低需求明確深度參與架構(gòu)設(shè)計(jì)決策低無人來主導(dǎo)性能調(diào)優(yōu)低有基準(zhǔn)測(cè)試人來主導(dǎo)排查偶發(fā)疑難bug低無人來主導(dǎo)這張表不是絕對(duì)的會(huì)隨模型能力和工具鏈進(jìn)步而變化但它反映了一個(gè)基本規(guī)律任務(wù)越局部、反饋越及時(shí)、判據(jù)越客觀智能體越可靠任務(wù)越全局、反饋越滯后、判據(jù)越主觀智能體越吃力。4. 距離完全自主編程還差哪幾座山4.1 第一座山需求理解與問題定義完全自主編程的第一個(gè)前提是能自己搞清楚“要做什么”。這恰恰是當(dāng)前智能體最弱的一環(huán)。人類開發(fā)者接到一個(gè)模糊需求會(huì)去追問、去澄清、去結(jié)合業(yè)務(wù)背景推斷真實(shí)意圖。智能體面對(duì)模糊需求要么按字面理解做出一個(gè)“技術(shù)上沒錯(cuò)但完全不是想要的東西”要么反復(fù)追問把提問的人問煩。它缺乏的是對(duì)意圖的推斷能力和對(duì)業(yè)務(wù)語境的感知能力。更麻煩的是很多需求本身就是矛盾的、不完整的、會(huì)變的。人類開發(fā)者能在開發(fā)過程中不斷和需求方對(duì)齊動(dòng)態(tài)調(diào)整理解。智能體目前很難處理這種“邊做邊明確”的過程它更擅長處理已經(jīng)凍結(jié)的、明確的需求。4.2 第二座山架構(gòu)判斷與技術(shù)取舍寫代碼只是軟件開發(fā)的一部分甚至不是最難的部分。真正難的是架構(gòu)決策這個(gè)功能該放在哪一層用同步還是異步要不要引入新的依賴數(shù)據(jù)一致性怎么保證這些決策沒有標(biāo)準(zhǔn)答案取決于團(tuán)隊(duì)規(guī)模、業(yè)務(wù)階段、運(yùn)維能力、未來預(yù)期等一堆因素。智能體做架構(gòu)決策的問題在于它傾向于給出“教科書式”的方案——也就是網(wǎng)上最常見、最通用的那種。但真實(shí)項(xiàng)目里的好架構(gòu)往往是“在約束下妥協(xié)出來的”而不是“理論上最優(yōu)的”。一個(gè)在小團(tuán)隊(duì)里跑得很好的簡單方案可能比一個(gè)理論上更優(yōu)雅但運(yùn)維復(fù)雜的方案更合適。這種基于約束的取舍智能體目前做不好因?yàn)樗恢滥愕募s束是什么也很難權(quán)衡那些無法量化的因素。4.3 第三座山長程任務(wù)的狀態(tài)保持前面提過上下文管理的瓶頸放到“完全自主”的語境下這個(gè)問題會(huì)被放大。一個(gè)真實(shí)的開發(fā)任務(wù)可能持續(xù)幾天甚至幾周涉及幾十上百次修改、多次方向調(diào)整、若干次推翻重來。智能體要在這么長的周期里保持目標(biāo)一致、狀態(tài)連貫、不重復(fù)勞動(dòng)、不遺忘關(guān)鍵約束目前是做不到的。它更像是一個(gè)“短跑選手”在單次會(huì)話、單個(gè)任務(wù)里表現(xiàn)不錯(cuò)但缺乏“長跑”能力。要解決這個(gè)問題需要更成熟的外部記憶機(jī)制、更可靠的任務(wù)狀態(tài)管理、以及跨會(huì)話的目標(biāo)追蹤能力。這些方向都有研究但離工程上穩(wěn)定可用還有距離。4.4 第四座山對(duì)后果的負(fù)責(zé)能力這一條聽起來有點(diǎn)虛但很關(guān)鍵。人類開發(fā)者寫的代碼出了問題是要負(fù)責(zé)的——要排查、要修復(fù)、要承擔(dān)后果。這種“責(zé)任壓力”會(huì)反過來影響開發(fā)時(shí)的謹(jǐn)慎程度不確定的地方多測(cè)幾遍影響面大的改動(dòng)多找人review拿不準(zhǔn)的方案先做小范圍驗(yàn)證。智能體沒有這種壓力。它寫完代碼任務(wù)就算“完成”了至于這段代碼上線后會(huì)不會(huì)引發(fā)事故不在它的考量范圍內(nèi)。它不會(huì)因?yàn)椤斑@個(gè)改動(dòng)可能影響線上”而主動(dòng)多做一些驗(yàn)證。這種后果意識(shí)的缺失使得它在關(guān)鍵系統(tǒng)里的自主程度必須被嚴(yán)格限制。4.5 第五座山創(chuàng)造性問題的解決軟件開發(fā)里有一類問題靠的是靈光一現(xiàn)、跨領(lǐng)域類比、反常規(guī)思路。比如一個(gè)性能瓶頸常規(guī)優(yōu)化都試過了沒用最后可能是某個(gè)開發(fā)者突然想到“換個(gè)數(shù)據(jù)結(jié)構(gòu)”或者“把計(jì)算挪到另一個(gè)階段”才解決。這種創(chuàng)造性智能體目前展現(xiàn)得很有限。它擅長在已知方案空間里搜索和組合但不擅長跳出方案空間。5. 實(shí)操視角怎么把智能體用出最大價(jià)值5.1 任務(wù)拆分是使用智能體的第一技能想讓智能體干活兒干得好最關(guān)鍵的不是模型選得多強(qiáng)而是任務(wù)拆得好不好。同一個(gè)任務(wù)拆成“給這個(gè)模塊加輸入校驗(yàn)并補(bǔ)測(cè)試”和拆成“先讀這個(gè)模塊理解結(jié)構(gòu)再列出需要校驗(yàn)的輸入點(diǎn)再逐個(gè)實(shí)現(xiàn)最后補(bǔ)測(cè)試”效果差別巨大。拆分的核心原則是每一步都有明確的完成判據(jù)。判據(jù)越客觀比如測(cè)試通過、類型檢查通過智能體自我修正的能力就越強(qiáng)。反過來如果一步的完成標(biāo)準(zhǔn)是“代碼寫得好”那智能體就沒法判斷自己做完沒有容易陷入反復(fù)修改或者草草收?qǐng)?。我通常?huì)把一個(gè)中等任務(wù)拆成三到七步每步控制在智能體一次會(huì)話能完成的范圍內(nèi)。步驟之間盡量解耦這樣某一步失敗不會(huì)導(dǎo)致全盤重來。5.2 給足上下文但別給垃圾智能體的表現(xiàn)高度依賴上下文質(zhì)量。給它的信息要滿足兩個(gè)條件相關(guān)和精煉。相關(guān)是指只給它這個(gè)任務(wù)需要的信息別把整個(gè)代碼庫塞進(jìn)去精煉是指信息要結(jié)構(gòu)化別把一堆原始日志直接倒給它。實(shí)際操作中我習(xí)慣在任務(wù)開始前先讓智能體自己探索一遍相關(guān)代碼把關(guān)鍵文件、關(guān)鍵函數(shù)、關(guān)鍵約束整理成一份簡短的“任務(wù)上下文”然后再基于這份上下文開始干活。這樣比一上來就讓它改代碼要穩(wěn)因?yàn)樗冉⒘藢?duì)任務(wù)的理解。注意不要把敏感信息、密鑰、生產(chǎn)環(huán)境配置直接喂給智能體。工具層要做好隔離讓它只能訪問該訪問的東西。這不是不信任模型而是基本的工程安全習(xí)慣。5.3 驗(yàn)證環(huán)節(jié)必須自動(dòng)化智能體最大的價(jià)值在于“自我迭代”而自我迭代的前提是“能自動(dòng)判斷對(duì)錯(cuò)”。所以自動(dòng)化驗(yàn)證是使用智能體的基礎(chǔ)設(shè)施。具體來說單元測(cè)試要能一鍵跑結(jié)果要能結(jié)構(gòu)化輸出類型檢查、靜態(tài)檢查要能自動(dòng)執(zhí)行關(guān)鍵路徑最好有集成測(cè)試兜底代碼格式、lint規(guī)則要統(tǒng)一避免智能體產(chǎn)出風(fēng)格不一致的代碼沒有這套基礎(chǔ)設(shè)施智能體就只能靠人來判斷對(duì)錯(cuò)那它的迭代優(yōu)勢(shì)就沒了你還得花大量時(shí)間復(fù)核得不償失。5.4 人機(jī)分工的實(shí)操建議基于我的使用經(jīng)驗(yàn)比較合理的分工是這樣的人來定目標(biāo)和約束做什么、不做什么、邊界在哪、優(yōu)先級(jí)如何智能體來執(zhí)行和迭代在約束內(nèi)完成具體實(shí)現(xiàn)根據(jù)反饋?zhàn)晕倚拚藖戆殃P(guān)關(guān)鍵決策架構(gòu)選擇、接口設(shè)計(jì)、影響面大的改動(dòng)智能體來處理重復(fù)勞動(dòng)補(bǔ)測(cè)試、改格式、批量替換、寫文檔這個(gè)分工的核心邏輯是把判斷力留給人把執(zhí)行力交給智能體。判斷力是當(dāng)前智能體最缺的執(zhí)行力是它最擅長的。順著這個(gè)邏輯分工效率提升最明顯翻車概率最低。6. 常見問題與排查技巧實(shí)錄6.1 智能體“跑偏”了怎么辦最常見的癥狀是智能體干著干著做的事情和原目標(biāo)越來越遠(yuǎn)。比如讓它修一個(gè)bug它改著改著開始重構(gòu)整個(gè)模塊。這通常是因?yàn)樗谀骋徊接龅搅苏系K然后自己“重新規(guī)劃”了一個(gè)偏離原目標(biāo)的方向。排查思路先看它的任務(wù)狀態(tài)記錄找到它是在哪一步開始偏離的。然后檢查那一步的輸入——往往是那一步的上下文里混入了無關(guān)信息或者那一步的完成判據(jù)不清晰導(dǎo)致它自己腦補(bǔ)了一個(gè)新目標(biāo)。解決辦法把任務(wù)拆得更細(xì)每步的判據(jù)寫得更明確在系統(tǒng)提示里強(qiáng)調(diào)“不要做任務(wù)范圍之外的改動(dòng)”關(guān)鍵步驟之間加人工確認(rèn)點(diǎn)。6.2 智能體反復(fù)改同一個(gè)地方改不對(duì)這個(gè)癥狀說明它陷入了局部循環(huán)改一下、測(cè)試失敗、再改、還失敗來回折騰。原因通常是它沒有真正理解失敗的原因只是在盲目試錯(cuò)。這時(shí)候應(yīng)該打斷它讓它先停下來分析失敗原因把分析結(jié)果寫出來再?zèng)Q定怎么改。很多時(shí)候讓它“先解釋再動(dòng)手”比讓它“直接動(dòng)手”要有效。因?yàn)榻忉尩倪^程會(huì)強(qiáng)迫它做推理而不是碰運(yùn)氣。6.3 智能體說“完成了”但實(shí)際沒完成這是“完成判據(jù)不客觀”的典型后果。它覺得完成了是因?yàn)樗鼪]有可靠的驗(yàn)證手段只能憑感覺判斷。解決辦法就是前面說的把驗(yàn)證自動(dòng)化讓“完成”有客觀標(biāo)準(zhǔn)。測(cè)試通過就是通過沒通過就是沒通過不給它“感覺完成了”的空間。6.4 常見問題速查表癥狀可能原因處理辦法任務(wù)跑偏目標(biāo)不清晰/上下文污染拆細(xì)任務(wù)明確判據(jù)清理上下文反復(fù)改不對(duì)未理解失敗原因要求先分析再動(dòng)手假完成缺乏客觀驗(yàn)證補(bǔ)自動(dòng)化測(cè)試和檢查重復(fù)勞動(dòng)狀態(tài)管理失效引入結(jié)構(gòu)化任務(wù)清單改動(dòng)范圍失控約束不明確明確“只改什么”加確認(rèn)點(diǎn)上下文溢出任務(wù)過長分段處理外部記憶工具選錯(cuò)工具過多/描述不清精簡工具優(yōu)化描述6.5 幾個(gè)踩過的坑第一個(gè)坑是過度信任。早期我用智能體改一個(gè)核心模塊它改完測(cè)試也過了我就直接合并了。結(jié)果上線后發(fā)現(xiàn)一個(gè)邊界情況沒覆蓋到出了小事故。從那以后凡是核心路徑的改動(dòng)不管測(cè)試過沒過我都會(huì)人工復(fù)核一遍關(guān)鍵邏輯。第二個(gè)坑是上下文給太多。有次我把整個(gè)項(xiàng)目的文檔都塞給智能體想讓它“全面理解”結(jié)果它反而抓不住重點(diǎn)在無關(guān)信息里繞圈子。后來改成只給相關(guān)部分效果立刻好轉(zhuǎn)。第三個(gè)坑是任務(wù)太宏大。一開始我總想讓它一次完成一個(gè)大功能結(jié)果它規(guī)劃得亂七八糟。后來學(xué)會(huì)把它當(dāng)“只能干一件事”的執(zhí)行者一次只給一個(gè)明確的小任務(wù)完成一個(gè)再給下一個(gè)整體效率反而高得多。7. 完全自主編程還有多遠(yuǎn)一個(gè)務(wù)實(shí)的判斷如果非要給個(gè)時(shí)間判斷我的看法是在受限場景下的高度自主正在快速到來在開放場景下的完全自主還有相當(dāng)長的路。受限場景指的是代碼庫規(guī)范、測(cè)試健全、任務(wù)邊界清晰、有明確驗(yàn)證手段的環(huán)境。在這種環(huán)境里智能體已經(jīng)能承擔(dān)相當(dāng)比例的常規(guī)開發(fā)工作人只需要做目標(biāo)設(shè)定和關(guān)鍵把關(guān)。這個(gè)趨勢(shì)在未來一兩年會(huì)越來越明顯尤其在那些工程規(guī)范做得好的團(tuán)隊(duì)里。開放場景指的是需求模糊、架構(gòu)待定、約束復(fù)雜、后果重大的環(huán)境。在這種環(huán)境里完全自主編程需要的不僅是更強(qiáng)的模型還需要一整套關(guān)于意圖理解、約束建模、后果評(píng)估、創(chuàng)造性問題解決的突破。這些突破什么時(shí)候來很難預(yù)測(cè)但可以肯定的是它們不會(huì)因?yàn)槟Ｐ蛥?shù)變大就自動(dòng)出現(xiàn)。所以對(duì)開發(fā)者來說務(wù)實(shí)的姿態(tài)不是焦慮“會(huì)不會(huì)被取代”而是搞清楚“哪些事可以交給它、哪些事必須自己扛”。把執(zhí)行力外包出去把判斷力攥在手里這個(gè)組合在當(dāng)下就是最優(yōu)解。我自己用下來最大的感受是智能體沒有讓我變懶反而讓我更專注于那些真正需要人來做的事——想清楚要做什么、為什么做、做到什么程度算好。這些事它替不了也不該替。