先說(shuō)結(jié)論吧AI寫代碼這事不能一句“靠譜”或“不靠譜”就蓋棺定論。我在這半年里幾乎每天都在真實(shí)項(xiàng)目里用AI輔助開發(fā)從最初覺得它只是個(gè)“高級(jí)補(bǔ)全插件”到后來(lái)摸索出一套能上生產(chǎn)環(huán)境的人機(jī)協(xié)作方式中間的落差和收獲都很大。這篇文章不聊那些Demo級(jí)別的演示效果就實(shí)打?qū)嵵v講在真實(shí)項(xiàng)目里AI寫代碼的能力邊界、翻車現(xiàn)場(chǎng)以及我現(xiàn)在到底是怎么用它把效率提上去的。如果你正糾結(jié)要不要把AI引入自己的開發(fā)流程或者試過(guò)幾次覺得“也就那樣”這篇文章應(yīng)該能給你一些實(shí)際參考。這半年我?guī)У氖且粋€(gè)中型的跨平臺(tái)管理系統(tǒng)后端API加前端頁(yè)面加起來(lái)幾十個(gè)模塊。一開始我的目標(biāo)也很簡(jiǎn)單把那些“寫起來(lái)沒意思、但又躲不掉”的重復(fù)性代碼比如表單頁(yè)面、列表頁(yè)、基礎(chǔ)CRUD接口盡量甩給AI。半年下來(lái)我積累了不少使用心得也踩了不少坑下面一個(gè)一個(gè)說(shuō)。1. 半年試用開局前我先搞清楚了AI寫代碼的三種能力層次很多人對(duì)AI寫代碼的期待是“一句話生成一個(gè)完整項(xiàng)目”這個(gè)期望從根上就錯(cuò)了。我在實(shí)際使用中把AI編碼助手的能力分為三個(gè)層次不同層次的表現(xiàn)天差地別。1.1 三個(gè)層次補(bǔ)全、生成、重構(gòu)第一層是行內(nèi)補(bǔ)全。你在寫代碼的時(shí)候它根據(jù)上下文幫你續(xù)寫下一行或下一小段。這一層AI的表現(xiàn)是最穩(wěn)定的類似輸入法聯(lián)想只不過(guò)聯(lián)想的是代碼。比如我寫一個(gè)函數(shù)它能把函數(shù)體的前半部分直接補(bǔ)齊。這一層的價(jià)值在于減少擊鍵次數(shù)節(jié)省手打時(shí)間。但它的能力僅限于“局部”它并不知道整個(gè)項(xiàng)目要干什么。第二層是代碼生成。你給它一段自然語(yǔ)言描述或者一個(gè)函數(shù)注釋它能生成一個(gè)完整的函數(shù)、一個(gè)類甚至一個(gè)完整的文件。這一層是大部分人說(shuō)的“AI寫代碼”。真實(shí)表現(xiàn)是對(duì)于模式固定的代碼比如根據(jù)數(shù)據(jù)庫(kù)表結(jié)構(gòu)生成對(duì)應(yīng)的增刪改查接口、生成一個(gè)表單頁(yè)面的前端代碼它做得又快又好。對(duì)于需要復(fù)雜業(yè)務(wù)判斷的代碼它生成的東西只能算“初稿”甚至有時(shí)方向就是錯(cuò)的。第三層是跨文件修改與重構(gòu)。你讓它理解項(xiàng)目現(xiàn)有代碼然后修改多個(gè)文件里的調(diào)用點(diǎn)、調(diào)整模塊間的關(guān)系。這一層目前最不成熟。AI看似理解了項(xiàng)目結(jié)構(gòu)實(shí)際上它只是把代碼庫(kù)作為上下文塞給了語(yǔ)言模型它對(duì)“項(xiàng)目為什么這么設(shè)計(jì)”完全沒有概念。我一想到這個(gè)層次就想起那個(gè)翻車案例——AI自信地把一個(gè)接口方法名改成了“看起來(lái)更合理”的名字結(jié)果項(xiàng)目里根本沒有這個(gè)方法導(dǎo)致整個(gè)模塊編譯失敗。這個(gè)我后面會(huì)詳說(shuō)。1.2 我對(duì)AI寫代碼的初始預(yù)期管理在真正上手前我給自己定了三條預(yù)期這半年證明這三條預(yù)期幫了大忙第一AI是用來(lái)“減少工作量”的不是用來(lái)“替代思考”的。架構(gòu)設(shè)計(jì)、模塊劃分、接口定義這些腦力活還得自己來(lái)。第二AI生成的代碼默認(rèn)視為“第三方貢獻(xiàn)的代碼”必須經(jīng)過(guò)和同事提交的代碼一樣的評(píng)審和測(cè)試流程不能因?yàn)閬?lái)自AI就放松審查。第三AI不是免費(fèi)的效率提升。你需要在“寫清楚需求”這件事上多花時(shí)間否則后續(xù)返工的時(shí)間遠(yuǎn)超你省下的時(shí)間。這三條預(yù)期可能看起來(lái)太保守但正是這套保守的預(yù)期讓我在后來(lái)的實(shí)踐中既沒踩毀滅性的坑也逐步建立了一套穩(wěn)定的使用流程。2. 真實(shí)項(xiàng)目半年效率實(shí)測(cè)哪些代碼AI真的靠譜如果只用一個(gè)維度評(píng)價(jià)AI寫代碼我覺得是“任務(wù)的模式化程度”。模式越固定AI越靠譜越需要隱性知識(shí)和項(xiàng)目全局理解AI越容易翻車。2.1 高頻低難度任務(wù)AI的絕對(duì)舒適區(qū)先說(shuō)AI表現(xiàn)最好的場(chǎng)景。舉一個(gè)很典型的例子我們的后臺(tái)管理項(xiàng)目里有十幾個(gè)基礎(chǔ)配置頁(yè)面每個(gè)頁(yè)面都是“表格搜索欄新增/編輯彈窗刪除確認(rèn)”邏輯大同小異。這類代碼的特點(diǎn)是結(jié)構(gòu)極其固定唯一的區(qū)別是字段名和校驗(yàn)規(guī)則。我用AI生成了其中一個(gè)完整的列表頁(yè)包括數(shù)據(jù)請(qǐng)求、表格列配置、分頁(yè)、搜索、彈窗表單和提交邏輯。一次性生成后我只改了大約20%的代碼主要是字段的中文標(biāo)簽和一些特殊的校驗(yàn)規(guī)則。說(shuō)實(shí)話完成質(zhì)量出乎我意料。同樣的頁(yè)面我之前手寫大概要2到3個(gè)小時(shí)用AI輔助后40分鐘就搞定包含修改和自測(cè)時(shí)間。效率提升是實(shí)打?qū)嵉?倍左右。我把這半年在真實(shí)項(xiàng)目里AI處理不同任務(wù)的表現(xiàn)整理成了表格方便大家直觀對(duì)比任務(wù)類型難度AI表現(xiàn)需要人工修改的工作量綜合評(píng)價(jià)表單頁(yè)面、列表頁(yè)低一次性生成可用10%-20%強(qiáng)烈推薦基礎(chǔ)CRUD接口低結(jié)構(gòu)完整邏輯正確5%-15%強(qiáng)烈推薦工具函數(shù)、日期處理中大部分邏輯正確20%-40%可推薦中復(fù)雜度業(yè)務(wù)接口中表面正確邊界條件需補(bǔ)40%-60%謹(jǐn)慎使用跨模塊數(shù)據(jù)流轉(zhuǎn)高經(jīng)?！白砸詾檎_”60%-100%不建議依賴系統(tǒng)架構(gòu)設(shè)計(jì)高只能提供參考幾乎全部重寫不建議使用2.2 中復(fù)雜度任務(wù)AI的及格線附近再往上一個(gè)臺(tái)階是中等復(fù)雜度的業(yè)務(wù)邏輯。比如一個(gè)訂單狀態(tài)流轉(zhuǎn)的功能一個(gè)帶有多種優(yōu)惠組合計(jì)算的價(jià)格服務(wù)。這類任務(wù)模式化程度中等但隱含著不少業(yè)務(wù)規(guī)則。我用AI寫過(guò)一個(gè)帶庫(kù)存扣減的訂單創(chuàng)建接口。AI確實(shí)生成了一個(gè)完整的接口參數(shù)校驗(yàn)、事務(wù)注解、庫(kù)存扣減邏輯都有模有樣。但仔細(xì)看發(fā)現(xiàn)幾個(gè)關(guān)鍵問(wèn)題一是沒處理庫(kù)存不足時(shí)的回滾細(xì)節(jié)二是并發(fā)扣減的場(chǎng)景完全沒考慮三是返回值沒有包含業(yè)務(wù)需要的訂單號(hào)。你說(shuō)它完全不能用吧基本骨架確實(shí)省了我不少時(shí)間但你說(shuō)它能直接用吧我改了將近一半的代碼才敢提交。這個(gè)場(chǎng)景我的結(jié)論是AI能做一個(gè)“60分到70分”的初稿能夠幫你完成一部分體力勞動(dòng)但業(yè)務(wù)中的關(guān)鍵邏輯必須自己盯死。2.3 高復(fù)雜度任務(wù)AI的門檻至于跨模塊的數(shù)據(jù)流轉(zhuǎn)、全局狀態(tài)管理、并發(fā)控制、性能優(yōu)化這類任務(wù)我現(xiàn)在的態(tài)度是不讓AI直接生成最多讓它做做參考方案。有一次我嘗試讓AI重構(gòu)一個(gè)多模塊共享的數(shù)據(jù)緩存模塊涉及三個(gè)服務(wù)的數(shù)據(jù)一致性問(wèn)題。AI生成的方案表面上看結(jié)構(gòu)很合理用了某種緩存更新策略代碼也寫得很工整。但我一檢查發(fā)現(xiàn)它根本沒有理解我們項(xiàng)目里一個(gè)關(guān)鍵的基礎(chǔ)約束——緩存更新必須依賴某個(gè)內(nèi)部消息通知而不能直接查庫(kù)判斷。結(jié)果它生成的代碼繞開了消息通知直接查庫(kù)刷新緩存雖然功能看起來(lái)沒問(wèn)題但實(shí)際上把整個(gè)模塊的架構(gòu)核心給破壞了。這類問(wèn)題的本質(zhì)是AI不懂項(xiàng)目的“活文檔”。代碼里那些沒有寫進(jìn)文檔、但所有團(tuán)隊(duì)成員都知道的隱性約定AI完全不清楚。這種“語(yǔ)義級(jí)理解”的缺失決定了高復(fù)雜度任務(wù)里AI只能是參考者不能是執(zhí)行者。3. 半年里踩過(guò)的坑AI寫代碼典型翻車現(xiàn)場(chǎng)實(shí)錄我得坦白講上半年使用AI的過(guò)程中翻車次數(shù)不算少。有些坑回頭想想覺得好笑但在當(dāng)時(shí)確實(shí)讓人抓狂。我把幾個(gè)最有代表性的記錄下來(lái)你可別在同樣地方摔倒。3.1 翻車一AI“自信”地維護(hù)了一個(gè)不存在的API這個(gè)是最典型的也是我第一次對(duì)AI產(chǎn)生了“原來(lái)你不懂我啊”的頓悟。當(dāng)時(shí)我讓AI幫我重構(gòu)某個(gè)訂單模塊的接口調(diào)用為了讓重構(gòu)后的代碼風(fēng)格更統(tǒng)一我讓它把所有的遠(yuǎn)程調(diào)用方法名統(tǒng)一為另一種命名規(guī)范。AI照做了修改了七八個(gè)文件。我一看代碼命名確實(shí)統(tǒng)一了當(dāng)時(shí)覺得很滿意。直到跑測(cè)試的時(shí)候才發(fā)現(xiàn)編譯直接失敗——因?yàn)锳I把某個(gè)底層SDK里的一個(gè)方法名改了但那個(gè)方法名根本不是我們能改的它是外部依賴庫(kù)定義的。AI為什么這么做因?yàn)樗皩W(xué)”過(guò)的代碼里類似的命名規(guī)范很常見它只是憑概率選了一個(gè)“看起來(lái)更合理”的名字但沒有真正去確認(rèn)這個(gè)名字在項(xiàng)目里是否真實(shí)存在。這個(gè)經(jīng)歷讓我明白AI修改代碼時(shí)完全沒有“驗(yàn)證”的概念。它只負(fù)責(zé)“改”不負(fù)責(zé)“對(duì)”。從那以后我要求所有AI修改過(guò)的代碼提交前必須自己過(guò)一遍所有涉及到的函數(shù)調(diào)用確認(rèn)沒有憑空捏造出來(lái)的新名字。3.2 翻車二AI在循環(huán)里埋了性能雷還有一個(gè)印象很深的案例我讓AI寫一個(gè)批量同步外部數(shù)據(jù)的任務(wù)它生成了一段很“標(biāo)準(zhǔn)”的循環(huán)代碼——遍歷所有待同步的記錄逐條調(diào)用外部接口獲取最新數(shù)據(jù)然后更新數(shù)據(jù)庫(kù)。功能上完全沒毛病測(cè)試也能通過(guò)。但上線跑了一天之后任務(wù)一直不完數(shù)據(jù)庫(kù)連接被大量占用其他模塊受影響。排查后發(fā)現(xiàn)AI的循環(huán)里沒有任何批量或并發(fā)控制的邏輯也沒有失敗重試和熔斷機(jī)制。外部接口響應(yīng)慢的時(shí)候循環(huán)就在那里一直傻等整個(gè)任務(wù)像老牛拉破車。這件事讓我意識(shí)到一個(gè)關(guān)鍵點(diǎn)AI只負(fù)責(zé)人工智能意義上的“功能正確”完全不負(fù)責(zé)性能、容錯(cuò)、健壯性這些工程屬性。你如果只讓它“完成功能”它保證不給你考慮生產(chǎn)環(huán)境下的實(shí)際情況。3.3 翻車三AI把重構(gòu)做成了“徹底的格式化”一次重構(gòu)經(jīng)歷更讓我哭笑不得。當(dāng)時(shí)我們有一個(gè)老模塊命名的風(fēng)格比較混亂同一種業(yè)務(wù)含義有時(shí)用幾種不同的英文單詞表達(dá)。我讓AI統(tǒng)一命名它很高效地把所有相關(guān)變量、函數(shù)名、文件的命名全部進(jìn)行了統(tǒng)一。但問(wèn)題來(lái)了有些命名雖然在風(fēng)格上不統(tǒng)一但是它們是有意為之——比如某些業(yè)務(wù)術(shù)語(yǔ)的別名在數(shù)據(jù)庫(kù)字段、外部接口文檔中已經(jīng)大量使用。AI不管這些它只做“字面級(jí)”的統(tǒng)一把所有看起來(lái)不一致的命名全部改了。結(jié)果就是雖然代碼內(nèi)部風(fēng)格統(tǒng)一了但和外部系統(tǒng)的對(duì)接全亂了數(shù)據(jù)庫(kù)映射的字段名也對(duì)不上了。我們花了兩天時(shí)間才把那些有業(yè)務(wù)含義的命名找回。從那以后凡是涉及全局重命名、跨系統(tǒng)接口對(duì)齊的重構(gòu)我再也不敢交給AI全自動(dòng)做了。4. 半年沉淀下來(lái)的AI寫代碼工作流踩了足夠的坑之后我逐漸摸索出一套穩(wěn)定且高效的使用流程。現(xiàn)在我在項(xiàng)目里用AI的方式和半年初期有了相當(dāng)大的變化。4.1 我的標(biāo)準(zhǔn)工作流分步驟、小步驗(yàn)證現(xiàn)在的AI使用流程分為五步每一步之間有明確的質(zhì)量檢查點(diǎn)第一步我負(fù)責(zé)架構(gòu)和接口設(shè)計(jì)。這步絕對(duì)不能交給AI。模塊應(yīng)該怎么劃分、接口該返回什么結(jié)構(gòu)、數(shù)據(jù)如何處理異常這些我想清楚了才往下走。我會(huì)把關(guān)鍵接口定義成函數(shù)簽名或接口文檔作為AI生成代碼的“規(guī)格說(shuō)明”。第二步寫清楚“給AI的規(guī)格說(shuō)明”。這個(gè)很重要。之前我隨便丟一句話“幫我寫個(gè)訂單列表接口”AI當(dāng)然只能寫個(gè)默認(rèn)模板出來(lái)?，F(xiàn)在我會(huì)寫清楚輸入?yún)?shù)、返回結(jié)構(gòu)、異常處理要求、逗號(hào)分隔、需要關(guān)聯(lián)查詢哪些字段、排序規(guī)則、分頁(yè)方式甚至說(shuō)明這個(gè)接口是給哪個(gè)頁(yè)面用的。有了這些約束AI生成的東西可用率高非常多。第三步讓AI生成實(shí)現(xiàn)。每個(gè)模塊或函數(shù)獨(dú)立生成不讓AI一次做太多東西。一次一個(gè)函數(shù)、一個(gè)接口、一個(gè)文件是合適的粒度。生成后立即檢查不積壓。第四步嚴(yán)格走“四道關(guān)”驗(yàn)收。AI生成的代碼必須過(guò)編譯關(guān)必須無(wú)警告通過(guò)、單測(cè)關(guān)補(bǔ)關(guān)鍵單測(cè)用例、人工Review關(guān)逐行讀一遍、邊界用例關(guān)考慮空值、異常、并發(fā)。這四道關(guān)做完AI代碼才允許提交。第五步小步提交快速反饋。每次讓AI生成的代碼量控制在一定范圍內(nèi)提交到分支后立刻跑完整測(cè)試。如果翻車影響范圍有限排查也快。4.2 給AI寫需求時(shí)的提示詞模板可直接抄半年實(shí)踐下來(lái)我總結(jié)了一套相對(duì)穩(wěn)定的提示詞模板。我不搞那些花哨的“角色扮演”就用最樸素的功能描述但信息要完整。核心模板如下任務(wù)實(shí)現(xiàn)[模塊名/函數(shù)名]的[具體功能描述]。 背景說(shuō)明 - 項(xiàng)目技術(shù)棧[語(yǔ)言/框架/版本] - 現(xiàn)有代碼風(fēng)格[如“所有接口返回Result對(duì)象”] - 關(guān)聯(lián)依賴[如“用戶信息通過(guò)某個(gè)工具類獲取”] 輸入?yún)?shù) - 參數(shù)1[名稱/類型/說(shuō)明] - 參數(shù)2[名稱/類型/說(shuō)明] 返回要求 - 成功返回[結(jié)構(gòu)說(shuō)明] - 失敗拋異常[什么情況下拋什么異常] 約束條件 - 性能要求[如“不允許N1查詢”] - 安全要求[如“所有輸入必須做SQL注入過(guò)濾”] - 邊界情況[如“空列表時(shí)返回空數(shù)組而不是null”] 請(qǐng)生成代碼并簡(jiǎn)要說(shuō)明實(shí)現(xiàn)思路。這個(gè)模板看起來(lái)樸實(shí)但每一項(xiàng)信息都直接影響AI生成代碼的質(zhì)量。其中“約束條件”這一項(xiàng)尤為重要它就是把前面說(shuō)的那些“項(xiàng)目隱性知識(shí)”顯性化給AI的通道。4.3 哪些代碼我絕對(duì)不讓AI碰半年用得越多我心里越有一張“禁區(qū)清單”。以下這些模塊無(wú)論AI表現(xiàn)得多么自信我都堅(jiān)決不讓它直接生成實(shí)現(xiàn)代碼支付、金額計(jì)算相關(guān)涉及精度、貨幣、對(duì)賬出錯(cuò)就是錢的問(wèn)題。AI對(duì)金融領(lǐng)域的舍入規(guī)則理解不靠譜。權(quán)限和認(rèn)證邏輯越權(quán)漏洞是最常見的安全風(fēng)險(xiǎn)AI生成的代碼在權(quán)限校驗(yàn)上經(jīng)?！安畈欢嘞壬边@是絕對(duì)不可以的。數(shù)據(jù)遷移腳本涉及歷史數(shù)據(jù)兼容需要理解現(xiàn)有數(shù)據(jù)的細(xì)節(jié)和臟數(shù)據(jù)形態(tài)AI沒有這個(gè)概念。與外部系統(tǒng)對(duì)接的解析邏輯外部接口的字段語(yǔ)義AI很容易憑經(jīng)驗(yàn)瞎猜一旦猜錯(cuò)數(shù)據(jù)全錯(cuò)。這些代碼我堅(jiān)持自己寫或者至少自己設(shè)計(jì)核心邏輯。AI可以幫忙補(bǔ)充文檔或生成輔助性的測(cè)試數(shù)據(jù)但核心實(shí)現(xiàn)絕不交出去。5. AI寫代碼的團(tuán)隊(duì)協(xié)作規(guī)范這套工作流如果只有一個(gè)人堅(jiān)持效率還是有限。我在團(tuán)隊(duì)里推廣了AI輔助開發(fā)的協(xié)作規(guī)范這里分享幾條落地后效果還不錯(cuò)的原則。5.1 代碼評(píng)審只嚴(yán)不松很多人有一個(gè)誤解AI生成的代碼質(zhì)量高那評(píng)審就可以放松一點(diǎn)我的答案恰恰相反——AI生成的代碼評(píng)審要更嚴(yán)格。原因很簡(jiǎn)單人寫的代碼如果某個(gè)地方邏輯怪那是這個(gè)人的問(wèn)題AI寫的代碼表面邏輯非常規(guī)整它很可能把“錯(cuò)誤”包裝得非?！罢_”反而更容易蒙混過(guò)關(guān)。所以在評(píng)審AI生成的代碼時(shí)我要求團(tuán)隊(duì)成員特別關(guān)注外部API的調(diào)用是否存在對(duì)應(yīng)翻車一循環(huán)里的性能開銷是否被忽略對(duì)應(yīng)翻車二命名統(tǒng)一是否跨出了合理邊界對(duì)應(yīng)翻車三5.2 面向AI的代碼設(shè)計(jì)模式我們內(nèi)部逐漸形成了一套“面向AI”的代碼組織習(xí)慣。嚴(yán)格來(lái)說(shuō)不是新的設(shè)計(jì)模式而是為了讓AI更好地理解上下文、生成更貼合的代碼函數(shù)體盡量短小長(zhǎng)函數(shù)AI續(xù)寫時(shí)容易“迷失方向”短函數(shù)則容易保持正確。命名保持明確變量名、函數(shù)名語(yǔ)義清楚AI推斷下一步邏輯的準(zhǔn)確率會(huì)顯著提高。關(guān)鍵決策留在注釋里重要的性能約束、異常處理原則寫在文件頭注釋或函數(shù)注釋里。這樣AI在生成后續(xù)代碼時(shí)會(huì)把注釋的約束考慮進(jìn)去。這些習(xí)慣在純?nèi)藢懙拇a中也是好習(xí)慣但有了AI協(xié)作后它們帶來(lái)的回報(bào)更直接。6. 半年之后的結(jié)論什么樣的人適合讓AI寫代碼半年實(shí)踐下來(lái)我對(duì)AI寫代碼這件事的判斷比較清晰了。它靠不靠譜更多取決于使用者的水平而不是AI本身的能力。6.1 AI寫代碼的效率規(guī)律我總結(jié)了影響AI寫代碼效率的幾個(gè)關(guān)鍵因素按重要性排序依次是因素影響權(quán)重任務(wù)模式化程度模式越固定AI表現(xiàn)越好最高上下文質(zhì)量提示詞、背景信息信息越完整輸出越準(zhǔn)確高使用者的代碼評(píng)審能力能不能看出AI埋的坑高項(xiàng)目的架構(gòu)清晰度架構(gòu)越清晰AI越不容易跑偏中團(tuán)隊(duì)的驗(yàn)收流程驗(yàn)證越嚴(yán)格越能抵消AI的錯(cuò)誤中從這個(gè)角度看并不是“會(huì)用AI的人”都能讓AI寫代碼而是“本來(lái)就會(huì)寫代碼的人”才能用好AI。AI是放大器你能力強(qiáng)它放大你的產(chǎn)出你能力弱它同樣放大你的錯(cuò)誤。6.2 我建議的引入路徑如果你看完這篇文章決定試著在真實(shí)項(xiàng)目里引入AI編程我建議你按下面的節(jié)奏來(lái)別一口吃成胖子第一周只做熟悉在非核心模塊里試用感受一下AI補(bǔ)全和生成的能力邊界別急著大規(guī)模鋪開。第二周開始建模板整理出適合你項(xiàng)目的提示詞模板把項(xiàng)目常用的接口風(fēng)格、異常處理方式、返回結(jié)構(gòu)寫進(jìn)模板。第三周建驗(yàn)收流程給AI生成的代碼建立一套強(qiáng)制檢查清單哪怕繁瑣也先跑起來(lái)。一個(gè)月后復(fù)盤統(tǒng)計(jì)一下哪些任務(wù)AI真正幫到了你哪些任務(wù)實(shí)際上增加了工作量比如生成后修改的時(shí)間比手寫還長(zhǎng)把這些任務(wù)從AI的工作范圍里剔除。三個(gè)月定邊界形成屬于自己的“AI任務(wù)白名單”和“AI禁區(qū)紅名單”之后嚴(yán)格按照這個(gè)邊界執(zhí)行。我個(gè)人在實(shí)際使用中最深的體會(huì)是AI寫代碼真正考驗(yàn)的不再是打字速度而是你把需求描述清楚的能力。以前你可以邊寫邊想“哦這里邏輯應(yīng)該這樣”現(xiàn)在你必須在讓AI動(dòng)手之前就想清楚所有邊界和異常路徑否則AI就會(huì)高高興興地把你的模糊需求實(shí)現(xiàn)成一堆看似正確但根本不能上線的代碼。這半年用得越多我反而越確認(rèn)一個(gè)判斷AI不會(huì)讓程序員失業(yè)但它會(huì)加速淘汰那些只會(huì)照著需求文檔敲代碼、從不停下來(lái)思考背后邏輯的人。反過(guò)來(lái)如果你愿意多花時(shí)間把需求背后的邏輯理順、把約束條件想透AI就是一雙無(wú)形的手讓你的產(chǎn)出效率比過(guò)去好上一大截。