1. 三年前那個“玩具”到底能干什么2023年前后我第一次認真把AI編程工具拉進日常工作流。當時的心態(tài)很樸素讓它幫我補全幾行樣板代碼省得我翻文檔。那個階段的工具本質上是一個“高級自動補全器”——你寫個函數(shù)名它猜你想干什么然后吐出一段看起來像那么回事的代碼。你稍微較真一點它就開始胡編不存在的庫、拼錯的API、邏輯上自相矛盾的邊界條件全都能給你整出來。我印象特別深的一次是讓它寫一個讀取本地CSV并做簡單聚合的腳本。它給出的代碼里pandas的read_csv參數(shù)寫錯了groupby后面跟的聚合函數(shù)名也不對。我花了二十分鐘改它的“作品”最后發(fā)現(xiàn)還不如自己從頭寫快。那時候圈子里有個共識AI編程就是個玩具能幫你寫寫正則、生成點測試數(shù)據(jù)真到生產環(huán)境你還得自己兜底。但到了2026年情況完全變了?，F(xiàn)在我用AI編程工具處理一個中等復雜度的后端模塊從接口設計到數(shù)據(jù)庫查詢再到異常處理它能一次性給出接近可用的代碼我只需要做代碼審查和少量調整。這個變化不是線性的中間有幾個明顯的拐點。這篇文章我想把這三年我親身經歷的進化路徑拆開講清楚它到底從“玩具”變成了什么哪些能力是真正質變的哪些坑到現(xiàn)在還沒填上以及作為一個普通開發(fā)者你現(xiàn)在應該怎么用它才不會被它帶偏。如果你是從python安裝教程、requests爬蟲這類關鍵詞搜進來的新手也別急著劃走。我會用大量Python場景做例子因為Python生態(tài)是這波AI編程進化里受益最明顯的領域之一。你不需要有很深的編程基礎我會把每個階段的能力邊界和實操方法都講透。2. 第一階段的真實能力邊界為什么它連requests都寫不利索2.1 那個階段AI對“庫”的理解是碎片化的2023年的AI編程工具對第三方庫的掌握方式是“見過很多代碼片段但沒真正理解庫的設計邏輯”。這導致一個典型問題它能把requests的常見用法拼出來但一旦涉及稍微冷門的參數(shù)組合就開始露餡。比如你讓它寫一個帶重試機制的HTTP請求它大概率會給你這樣的代碼import requests response requests.get(url, retry3)requests根本沒有retry這個參數(shù)。正確的做法是用urllib3的Retry配合HTTPAdapter或者用tenacity這類重試庫。但那個階段的AI不知道這些它只是從訓練數(shù)據(jù)里“感覺”重試應該有個retry參數(shù)。更麻煩的是錯誤處理。你讓它寫一個爬蟲它給出的代碼往往沒有try-except或者except后面直接pass。你問它為什么它會說“這樣代碼更簡潔”。這不是簡潔這是不負責任。生產環(huán)境的爬蟲網(wǎng)絡抖動、目標站點限流、DNS解析失敗全是家常便飯。沒有健壯的錯誤處理腳本跑十分鐘就崩。2.2 “exceeded retry limit, last status: 429”這類報錯它當時根本看不懂熱詞里有個exceeded retry limit, last status: 429 too many requests這是爬蟲開發(fā)者最常遇到的報錯之一。429是HTTP狀態(tài)碼意思是請求太頻繁被限流了。2023年的AI工具看到這個報錯給出的建議往往是“增加重試次數(shù)”或者“加個sleep”。但真正的問題在于你沒有遵守目標站點的Retry-After響應頭也沒有做請求頻率控制。我當時的做法是手動寫一個令牌桶限流器配合指數(shù)退避重試。AI能幫我寫令牌桶的骨架但退避策略和Retry-After的解析它總是漏掉。你得自己補。那個階段AI是一個“能幫你寫30%代碼但剩下70%你得自己來”的工具。它省的是打字時間不是思考時間。2.3 新手最容易在這個階段被帶偏我見過不少剛學Python的人用AI生成一段爬蟲代碼跑通了就以為自己會了。結果目標站點一改結構或者一限流整個人就懵了。因為他們沒有理解requests的會話機制、沒有理解HTTP協(xié)議的狀態(tài)碼含義、沒有理解為什么需要設置User-Agent和Referer。AI在那個階段最大的危害是讓新手跳過了“理解問題”這一步直接拿到一個能跑的代碼。但這個代碼是脆弱的換個場景就廢。所以我一直建議用AI寫代碼可以但每一行你都要能解釋它為什么這么寫。解釋不了就去查文檔。查文檔的過程才是你真正學會的過程。3. 拐點出現(xiàn)在哪里從“補全”到“能讀懂整個項目”3.1 上下文窗口的擴大改變了游戲規(guī)則2024年到2025年AI編程工具最實質的進步不是模型變聰明了而是它能“看到”的東西變多了。早期工具只能看你當前打開的文件或者你手動粘貼進去的幾百行代碼。后來上下文窗口擴展到能吞下整個中小型項目情況就完全不同了。這意味著什么意味著AI可以理解你的項目結構、你的命名習慣、你用的框架版本、你已有的工具函數(shù)。它給出的代碼不再是“通用模板”而是“符合你這個項目風格的代碼”。這個變化聽起來不大但實際體驗是質的飛躍。舉個例子。我有個項目里封裝了一個http_client.py里面定義了帶重試和日志的get和post方法。早期AI會忽略這個文件直接給我寫裸的requests.get。后來它能讀到這個文件就會主動調用我封裝好的方法甚至提醒我“你這里可以用項目里的http_client.get它已經處理了重試”。這種“懂項目”的能力是它從玩具變成工具的關鍵一步。3.2 從“寫函數(shù)”到“改架構”的能力躍遷另一個拐點是AI開始能處理跨文件的修改。你告訴它“我要給所有API接口加上統(tǒng)一的鑒權頭”它能找到所有相關的路由文件逐個修改并且保持風格一致。這在早期是不可想象的——早期你讓它改三個文件它改完第一個就忘了第二個的上下文。我實測過一個場景一個Flask項目有十幾個藍圖每個藍圖里都有若干接口。我要求給所有接口加上一個裝飾器來做權限校驗。AI不僅找到了所有需要修改的地方還注意到有兩個接口是公開的主動問我“這兩個是否需要排除”。這種主動性和全局觀是2025年之后才穩(wěn)定出現(xiàn)的。但這里有個前提你的項目結構得清晰。如果你的代碼全堆在一個文件里或者命名亂七八糟AI也會跟著亂。所以我現(xiàn)在越來越覺得AI編程工具其實在倒逼開發(fā)者寫好代碼——結構清晰、命名規(guī)范、職責單一的項目AI的表現(xiàn)會好很多。3.3 調試能力從“猜”變成了“推理”早期AI幫你調試基本靠猜。你把報錯貼給它它給你幾個可能的原因讓你逐個試。現(xiàn)在它會真的去讀你的代碼追蹤變量在調用鏈里的變化然后指出“你這個變量在第37行被重新賦值了導致第52行拿到的是空值”。我遇到過一個典型的KeyErrorAI讀完相關代碼后告訴我字典在某個分支里沒有插入那個鍵因為那個分支的條件判斷寫反了。它甚至給出了修復后的條件表達式。這種推理能力已經接近一個初級程序員在code review時的水平了。不過要注意它的推理仍然可能出錯。尤其是涉及并發(fā)、異步、或者復雜狀態(tài)機的場景它偶爾會給出看似合理但實際有問題的分析。所以我的習慣是AI給的調試建議我會當作“假設”來驗證而不是“結論”來執(zhí)行。4. 現(xiàn)在的AI編程到底強在哪幾個我反復驗證過的場景4.1 數(shù)據(jù)處理管道從CSV到結構化數(shù)據(jù)的全流程這是我用得最多的場景。一個典型的任務讀取一個雜亂的CSV做清洗、類型轉換、聚合最后輸出結構化數(shù)據(jù)。早期AI寫的代碼類型轉換經常漏掉異常處理遇到臟數(shù)據(jù)就崩?，F(xiàn)在它會主動加try-except會處理NaN會提醒你“這一列有混合類型建議先統(tǒng)一”。我最近做的一個項目需要從多個來源拉數(shù)據(jù)合并后做去重和優(yōu)先級排序。AI給出的方案用了pandas的merge配合drop_duplicates還建議我用category類型來節(jié)省內存。這些細節(jié)說明它不只是“會寫代碼”而是“懂數(shù)據(jù)處理”。但有個坑它有時候會過度使用pandas。對于小數(shù)據(jù)量用原生Python的字典和列表可能更快更簡單。AI傾向于用“標準答案”但標準答案不一定是最優(yōu)解。你得根據(jù)實際數(shù)據(jù)量來判斷。4.2 爬蟲與反爬對抗它現(xiàn)在能理解“策略”了熱詞里有大量requests爬蟲、python爬蟲相關的內容。我實測下來現(xiàn)在的AI在爬蟲場景下的進步非常明顯。它不再只是給你一個requests.get而是會考慮請求頭偽裝User-Agent、Referer、Accept-Language請求頻率控制配合time.sleep或令牌桶會話保持requests.Session重試策略指數(shù)退避、Retry-After解析代理池的接入方式雖然我不建議新手一上來就搞代理池我讓它寫一個帶限流和重試的爬蟲框架它給出的代碼結構清晰甚至把限流器抽象成了一個獨立的類。這在兩年前是不可想象的。但反爬對抗的“灰色地帶”它仍然處理不好。比如目標站點用了JavaScript渲染AI會建議你用Selenium或Playwright但不會提醒你這些工具的資源消耗和穩(wěn)定性問題。熱詞里有個python上利用rapidocr太吃CPU這其實反映了同一個問題AI能給你方案但方案的性能代價它往往輕描淡寫。4.3 代碼重構它敢動你的老代碼了重構是AI編程里風險最高的操作之一。早期AI重構基本等于“重寫”它會把你原來的邏輯改得面目全非。現(xiàn)在它會保守很多保留你的函數(shù)簽名、保留你的錯誤處理邏輯、只改它確定可以優(yōu)化的部分。我有個跑了三年的老腳本里面有很多歷史遺留的if-else嵌套。我讓AI幫我重構它沒有直接重寫而是先給我列了一個“重構計劃”哪些分支可以合并、哪些條件可以提前返回、哪些變量可以提取。我確認后它才動手。重構完的代碼邏輯等價但可讀性好了很多。這個“先計劃后執(zhí)行”的模式是我現(xiàn)在用AI編程的標準流程。尤其是涉及生產代碼的修改我一定會讓它先輸出方案我審核后再讓它改。直接讓它改風險太大。5. 那些到現(xiàn)在還沒填上的坑5.1 它仍然會“自信地胡說八道”這個問題從第一天到現(xiàn)在本質上沒有完全解決。AI仍然會編造不存在的庫、不存在的參數(shù)、不存在的API。而且它編造的時候語氣非常自信新手很容易被騙。我最近遇到的一次它建議我用一個叫fastcache的庫來做緩存說“這是Python標準庫的一部分”。實際上Python標準庫里有functools.lru_cache但沒有fastcache。fastcache是一個第三方庫而且已經很久沒維護了。所以我的鐵律是AI提到的任何庫、任何API我都要去官方文檔確認一遍。這個習慣救了我很多次。5.2 性能優(yōu)化它給不出“實測數(shù)據(jù)”AI能告訴你“用生成器比用列表更省內存”但它給不出具體的數(shù)據(jù)。它不知道你的數(shù)據(jù)量有多大、你的內存限制是多少、你的CPU是什么型號。所以它的性能建議永遠是“理論上更好”而不是“實測下來快了多少”。我現(xiàn)在的做法是AI給優(yōu)化建議我自己寫benchmark跑一遍。有時候它建議的優(yōu)化在我的場景下反而更慢。比如它建議用numpy向量化替代循環(huán)但如果數(shù)據(jù)量很小numpy的初始化開銷反而讓整體更慢。5.3 涉及公司內部系統(tǒng)時它基本幫不上忙熱詞里有個python如何連接公司系統(tǒng)實現(xiàn)自動拉表這其實是個很典型的痛點。公司內部系統(tǒng)往往有私有的SDK、私有的認證方式、私有的數(shù)據(jù)格式。AI沒見過這些東西它只能給你一個“通用模板”然后你自己去填。我處理這類任務時會把內部系統(tǒng)的接口文檔脫敏后喂給AI讓它基于文檔寫代碼。這樣它的準確率會高很多。但即便如此涉及認證和權限的部分還是得我自己來。6. 我現(xiàn)在怎么用AI編程一套可復現(xiàn)的工作流6.1 先讓它“讀”再讓它“寫”這是我最重要的習慣。在讓AI寫任何代碼之前我會先讓它讀相關文件然后讓它用自己的話總結“這個模塊是干什么的、有哪些關鍵函數(shù)、數(shù)據(jù)怎么流動”。如果它的總結有偏差說明它沒理解對這時候讓它寫代碼肯定出問題。這個“讀-總結-確認”的流程花不了幾分鐘但能避免大量返工。尤其是接手老項目或者復雜模塊時這一步幾乎是必須的。6.2 小步提交每步驗證我不會讓AI一次性寫幾百行代碼。我會把任務拆成小步驟先寫數(shù)據(jù)讀取跑通再寫清洗邏輯跑通再寫輸出跑通。每一步都驗證確保前面的基礎是穩(wěn)的。這樣做的好處是出問題時容易定位。如果AI一次性寫了一大坨跑不通你根本不知道是哪里的問題。小步提交配合版本控制出問題直接回滾成本很低。6.3 讓它寫測試但不信它的測試AI寫測試用例的能力很強它能覆蓋很多邊界條件。但它的測試有一個致命問題它傾向于測試“自己寫的代碼”而不是“應該實現(xiàn)的功能”。也就是說如果它的代碼有bug它的測試可能剛好繞過那個bug。所以我的做法是讓AI寫測試但我自己會補充幾個“刁鉆”的用例。尤其是涉及邊界值、空輸入、異常輸入的場景我會手動加測試。AI的測試作為基礎覆蓋我的測試作為補充驗證。6.4 提示詞的關鍵給約束不給自由熱詞里有ai編程提示詞我在這方面踩過很多坑。早期我喜歡說“幫我寫一個爬蟲”結果它給我的代碼風格、用的庫、錯誤處理方式全看它心情。后來我學會了給約束指定Python版本比如python 3.8指定庫比如“用requests和beautifulsoup4不要用selenium”指定風格比如“函數(shù)要有類型注解錯誤處理用try-except日志用logging模塊”指定邊界比如“只處理前100條數(shù)據(jù)不要分頁”約束越具體它給的代碼越可用。這其實和帶新人的邏輯一樣你給的要求越模糊他越容易跑偏。7. 給不同階段開發(fā)者的實操建議7.1 如果你剛學Python別讓AI替你思考python安裝教程、python入門、python怎么安裝這些是熱詞里出現(xiàn)頻率最高的。我理解新手想快速跑通代碼的心情。但我的建議是安裝、環(huán)境配置、基礎語法這些一定要自己動手。AI可以幫你解釋報錯可以幫你寫示例代碼但不要讓它替你完成“理解”這一步。你至少要知道python環(huán)境變量配置是干什么的、vscode python環(huán)境配置里每個選項的含義。這些基礎打牢了后面用AI才有效率。我見過太多新手環(huán)境是AI配的代碼是AI寫的報錯是AI修的。結果換臺電腦連Python都裝不上。這不是在用AI這是被AI綁架。7.2 如果你有一兩年經驗把AI當“高級結對伙伴”這個階段的人最容易從AI編程里獲益。你已經有了基礎能判斷AI給的代碼靠不靠譜。你可以讓AI幫你處理那些“你會寫但不想寫”的代碼樣板代碼、測試用例、文檔字符串、數(shù)據(jù)轉換腳本。我的建議是把AI當成一個隨時在線的結對伙伴。你負責架構和關鍵邏輯它負責填充細節(jié)。你負責判斷對錯它負責提供選項。這種協(xié)作模式效率提升最明顯。7.3 如果你是資深開發(fā)者用AI來“對抗遺忘”資深開發(fā)者的問題不是不會寫而是“記不住那么多細節(jié)”。比如你很久沒寫pandas了突然要做一個數(shù)據(jù)聚合你可能記得大概思路但具體的API參數(shù)記不清了。這時候AI就是你的“外部記憶”。我現(xiàn)在的用法是讓AI給我一個“起點代碼”然后我基于自己的經驗去改。它給的可能不是最優(yōu)解但能幫我快速回憶起這個領域的常見做法。然后我用我的經驗去優(yōu)化它。這種“AI出草稿我來精修”的模式對資深開發(fā)者來說效率很高。8. 關于“超越中高級程序員”這個說法的冷靜判斷標題里說“超越中高級程序員”這個說法我持保留態(tài)度。AI在某些維度上確實超過了中高級程序員比如它知道的語言和庫比我多、它寫樣板代碼比我快、它不會因為加班而犯低級錯誤。但在另一些維度上它差得還很遠。它沒有“品味”。它不知道什么樣的代碼是“優(yōu)雅”的它只知道什么樣的代碼是“常見”的。它沒有“責任感”。它不會因為線上事故而失眠它只會給你下一個“可能可行”的方案。它沒有“領域知識”。它不懂你的業(yè)務、你的用戶、你的歷史包袱。所以我的判斷是AI編程工具現(xiàn)在是一個“能力很強的初級程序員”加上“知識面很廣的技術顧問”的結合體。它能大幅提升你的效率但它不能替代你的判斷。你仍然需要知道“什么是對的”才能用好它。這三年AI編程從玩具變成了工具從“幫你打字”變成了“幫你思考”。但最終做決定的還是你。工具越強使用工具的人的判斷力就越重要。這是我用了三年AI編程之后最深的體會。