1. 當(dāng)“碼農(nóng)”時(shí)代落幕這個(gè)議題為什么此刻被反復(fù)提起最近一段時(shí)間我身邊的氛圍變得有些微妙。以前大家在群里聊的是某個(gè)框架新版本、某個(gè)服務(wù)又超時(shí)了、誰的拉取請(qǐng)求又因?yàn)榇a風(fēng)格被駁回。現(xiàn)在大家聊得更多的反而是如果代碼主要由AI來寫那我每天打開電腦到底在干什么很多人聽說“工程師不再寫代碼”第一反應(yīng)是焦慮覺得是不是行業(yè)要完蛋了或者覺得這又是某種標(biāo)題黨式的夸張說法。但作為在這行摸爬滾打了十幾年的老開發(fā)我想說的是這個(gè)命題雖然帶著一點(diǎn)沖擊力但它指向的變化是真實(shí)存在且正在發(fā)生的。只不過它并不是“程序員失業(yè)”的前奏而更像是一次崗位內(nèi)涵的重新定義——我們過去習(xí)慣把“寫代碼”等同于“做開發(fā)”現(xiàn)在這個(gè)等式開始失效了。這也不是某個(gè)小圈子的自嗨。你去看各種招聘平臺(tái)上的崗位描述會(huì)發(fā)現(xiàn)“提示詞工程師”“AI協(xié)作開發(fā)”“模型微調(diào)與應(yīng)用工程師”這類職位開始出現(xiàn)而且薪資待遇并不低。再看企業(yè)內(nèi)部的組織架構(gòu)討論產(chǎn)品、測(cè)試、運(yùn)維、架構(gòu)這些角色之間的邊界正在被AI沖得七零八落。一個(gè)連數(shù)據(jù)庫都沒碰過的產(chǎn)品經(jīng)理現(xiàn)在可以借助AI工具直接拉取數(shù)據(jù)分析用戶行為一個(gè)干了五年的資深前端可能要被迫去學(xué)習(xí)怎么評(píng)估和校驗(yàn)AI生成的代碼質(zhì)量。這個(gè)議題的核心價(jià)值就在這里它不是預(yù)測(cè)未來而是幫我們看清正在發(fā)生的當(dāng)下——當(dāng)“編碼”這件事的門檻被AI大幅拉低之后工程師的核心競(jìng)爭(zhēng)力、工作流、以及一天24小時(shí)的時(shí)間分配究竟會(huì)變成什么樣這篇文章我打算拋開那些宏大的行業(yè)報(bào)告以一個(gè)親身經(jīng)歷者的視角拆解角色重構(gòu)后的真實(shí)工作日常。先說結(jié)論工程師并不是變得沒事干了恰恰相反我們要干的活變得更細(xì)、更雜、更需要判斷力。以前我們花80%的時(shí)間在“寫”上現(xiàn)在“寫”可能只占20%到30%剩下的時(shí)間全部轉(zhuǎn)移到了“想”“查”“辯”“驗(yàn)”這四個(gè)字上。接下來我會(huì)從底層邏輯、具體日程、能力模型、團(tuán)隊(duì)分工這四個(gè)維度把重構(gòu)后的工程師一天原原本本地?cái)傞_給你看。注意我聊的“不寫代碼”準(zhǔn)確說是“不親自敲擊每一行業(yè)代碼”而不是“不產(chǎn)出代碼”。AI負(fù)責(zé)把設(shè)計(jì)變成初稿工程師負(fù)責(zé)把初稿變成值得上線的東西干活的方式變了責(zé)任其實(shí)一點(diǎn)都沒變。2. 為什么AI替代的是“寫”而不是“思考”被忽略的工程師隱性工作要理解工程師不寫代碼之后一天在做什么首先得搞清楚一個(gè)關(guān)鍵問題在AI介入之前一個(gè)工程師的工作時(shí)間里到底有多少是“純粹寫代碼”2.1 一個(gè)接近真實(shí)的工時(shí)占比拆解我統(tǒng)計(jì)過自己過去的一些項(xiàng)目工時(shí)也參考過團(tuán)隊(duì)里不同級(jí)別開發(fā)者的日志。在一個(gè)標(biāo)準(zhǔn)迭代周期里一個(gè)后端開發(fā)者的時(shí)間消耗大致是這樣的工作項(xiàng)占工作日時(shí)間比例是否屬于“寫代碼”需求討論與澄清10%-15%否技術(shù)方案設(shè)計(jì)與評(píng)審10%-15%否編碼實(shí)現(xiàn)30%-40%是自測(cè)與問題排查15%-20%否但常被算進(jìn)“寫”的過程代碼評(píng)審看別人的代碼5%-10%否聯(lián)調(diào)與部署5%否文檔與復(fù)盤5%否也就是說哪怕在AI出現(xiàn)之前“寫代碼”這一動(dòng)作本身也只占了工程師不到一半的時(shí)間。剩下那50%以上的時(shí)間花在了搞清楚要做什么、怎么做、做完怎么確認(rèn)它是對(duì)的以及怎么和別人對(duì)齊預(yù)期這些事上。過去為什么我們覺得工程師一整天都在寫代碼因?yàn)槲覀兞?xí)慣把“坐在電腦前敲鍵盤”的時(shí)長(zhǎng)都算作寫代碼。但實(shí)際上對(duì)著需求文檔發(fā)呆的時(shí)候在腦子里跑流程的時(shí)候在幾個(gè)技術(shù)方案之間猶豫的時(shí)候那些時(shí)間并沒有產(chǎn)生任何代碼——那是在思考。2.2 AI把“表達(dá)”變便宜了但把“決策”變貴了理解了這個(gè)工時(shí)的基本盤再來看AI的影響就會(huì)非常清晰。AI擅長(zhǎng)的是什么呢是“從自然語言到代碼”的翻譯過程。你告訴它“幫我寫一個(gè)LRU緩存”它能給你一個(gè)非常完整的實(shí)現(xiàn)。這個(gè)能力替代掉的恰好是過去占30%到40%的“編碼實(shí)現(xiàn)”環(huán)節(jié)。模型的理解能力越強(qiáng)這個(gè)替代就越徹底。但AI不擅長(zhǎng)什么呢它不擅長(zhǎng)在沒有明確約束的情況下做選擇。你讓它寫一個(gè)緩存它默認(rèn)給你一個(gè)線程安全的實(shí)現(xiàn)但它不知道你面對(duì)的是讀多寫少的場(chǎng)景還是寫多讀少的場(chǎng)景不知道你的緩存鍵值平均大小是多少不知道你的部署環(huán)境里堆內(nèi)存上限是多少更不知道你下游服務(wù)的超時(shí)時(shí)間配的是幾秒。這些信息需要人來定義而且必須定義得足夠準(zhǔn)確否則AI給你的方案就是一個(gè)看起來正確、在錯(cuò)誤邊界上一碰就碎的漂亮花瓶。這就是我從“編碼者”變成“決策者”的第一個(gè)轉(zhuǎn)折點(diǎn)。以前我寫完一個(gè)函數(shù)心里很清楚它的邊界條件在哪因?yàn)槟切┻吔缡俏乙恍行袑懗鰜淼摹，F(xiàn)在AI三秒鐘生成了這個(gè)函數(shù)我需要在一分鐘之內(nèi)判斷出它在邊界上會(huì)不會(huì)崩。寫代碼的體力活被機(jī)器接走了但“判斷這段代碼該不該存在、存在的約束是什么、崩了之后怎么辦”的腦力活全落在了我頭上。所以在我看來“不寫代碼的工程師”并不是一個(gè)貶義詞它更接近“把時(shí)間從填空題轉(zhuǎn)向判斷題”的一個(gè)過程。過去我們花大量時(shí)間在“填空”把設(shè)計(jì)變成語法正確的代碼現(xiàn)在AI把填空做完了剩下的全部工作都是“判斷”——判斷需求是不是真的合理判斷設(shè)計(jì)是不是最優(yōu)判斷AI的答案是不是符合預(yù)期判斷上線后監(jiān)控指標(biāo)是不是正常。這一層想通了下面關(guān)于“一天在做什么”的描述才有意義。因?yàn)槟銜?huì)發(fā)現(xiàn)所謂角色的重構(gòu)本質(zhì)上是工作能量的重新分配從手部勞動(dòng)轉(zhuǎn)移到腦部勞動(dòng)從產(chǎn)出代碼轉(zhuǎn)移到產(chǎn)出決策。3. 重構(gòu)后的一天一個(gè)真實(shí)工作日的逐小時(shí)拆解這部分我寫得細(xì)一點(diǎn)把我在一個(gè)“AI重度參與”的項(xiàng)目里典型的一天還原出來。為了避免照搬教條我用的是“時(shí)間段內(nèi)容為什么這么干”的格式方便你對(duì)照自己的日常找差異。3.1 上午從需求澄清到任務(wù)分解9:00 - 12:00早上九點(diǎn)我沒有急著打開IDE。說實(shí)話過去我會(huì)因?yàn)樾睦锟倰煊浿蛱鞗]寫完的那個(gè)接口?，F(xiàn)在我的習(xí)慣是先花十五分鐘刷一下夜間監(jiān)控告警和AI生成的代碼提交記錄——不是看代碼本身而是看有沒有線上異常有沒有同事被AI生成的邏輯坑到。九點(diǎn)半是站會(huì)但這個(gè)站會(huì)的形態(tài)變了。以前每人說“我昨天寫了什么、今天打算寫什么”現(xiàn)在大家更多說的是“昨天驗(yàn)證了哪個(gè)模塊的AI輸出發(fā)現(xiàn)它在某個(gè)邊界上表現(xiàn)不對(duì)今天打算用什么方式引導(dǎo)它修正”。你看連匯報(bào)的語言都從“產(chǎn)出”變成了“評(píng)估”。站會(huì)之后是整個(gè)上午的重頭戲需求澄清和技術(shù)方案設(shè)計(jì)。舉個(gè)例子產(chǎn)品提了一個(gè)需求要把推薦列表的響應(yīng)時(shí)間從500ms壓到200ms。以前我會(huì)先回去看看代碼再想想方案?，F(xiàn)在我會(huì)拉一段之前的架構(gòu)文檔進(jìn)對(duì)話讓AI先幫我梳理出當(dāng)前響應(yīng)鏈路里的主要耗時(shí)點(diǎn)然后我會(huì)人工判斷它列出的這些點(diǎn)哪些是真實(shí)的、哪些是過時(shí)的、哪些是它腦補(bǔ)的。這個(gè)過程非常有意思。AI幫我把搜索范圍從整個(gè)代碼倉庫縮小到了幾個(gè)熱點(diǎn)路徑然后真正的判斷工作還是得我自己上這條鏈路里緩存命中率不高是因?yàn)殒I設(shè)計(jì)的問題還是過期策略的問題數(shù)據(jù)庫查詢慢是缺索引還是因?yàn)椴樵儣l件本身就不該這么寫AI能給出“可能存在問題的點(diǎn)”但“怎么改”以及“改了以后會(huì)不會(huì)引入其他問題”必須由我拍板。到十一點(diǎn)左右方案基本收斂了。我又做一件事把方案拆成可驗(yàn)證的任務(wù)清單。以前我會(huì)想“這個(gè)模塊我來寫那個(gè)函數(shù)我調(diào)整一下”現(xiàn)在我會(huì)想“這個(gè)任務(wù)適合讓AI做初稿那個(gè)任務(wù)約束條件太多AI容易跑偏要給出更精確的提示詞甚至拒絕讓它參與”。這其實(shí)就是新時(shí)代的“任務(wù)分解”只不過分解的對(duì)象不再是“代碼”而是“問題的邊界”。上午的最后一個(gè)小時(shí)通常會(huì)被評(píng)審會(huì)占掉。需要注意的是現(xiàn)在的評(píng)審會(huì)跟過去不太一樣。過去的代碼評(píng)審是看排版、看命名、看邏輯?，F(xiàn)在的評(píng)審是看AI給的方案有沒有把非功能需求考慮進(jìn)去有沒有處理異常與邊界以及有沒有引入不必要的復(fù)雜度。與其說是在審代碼不如說是在審AI的“思路”。3.2 下午人機(jī)協(xié)作編碼、驗(yàn)證與排障14:00 - 17:30下午進(jìn)入實(shí)操環(huán)節(jié)。確切地說是“人機(jī)協(xié)作實(shí)操”環(huán)節(jié)。一個(gè)后端模塊的實(shí)現(xiàn)大概分成三步走。第一步我把上午整理好的邊界約束、數(shù)據(jù)結(jié)構(gòu)定義、接口契約輸入給AI讓它生成初版代碼。第二步我打開AI生成的代碼不逐行精讀而是帶著幾個(gè)問題去“抽查”異常處理的覆蓋面夠不夠并發(fā)場(chǎng)景下的狀態(tài)是否正確有沒有引入不必要的依賴第三步我把代碼交給測(cè)試和Code Review但在此之前自己必須在腦子里把這個(gè)模塊的調(diào)用鏈跑通三遍。這里必須補(bǔ)充一個(gè)自己踩過多次的坑AI生成代碼的“表面可信度”非常高。它有完善的注釋有合理的命名有看起來滴水不漏的防御性判斷。但它最擅長(zhǎng)的也是最讓人頭疼的就是一本正經(jīng)地寫出一個(gè)在極端并發(fā)下會(huì)死鎖的方案。所以我的經(jīng)驗(yàn)是不寫代碼不等于不看代碼而是要用“設(shè)計(jì)者的視角”去看代碼而不是“抄寫員的視角”。驗(yàn)證環(huán)節(jié)現(xiàn)在的工作量反而比過去大了。以前寫完代碼跑通單測(cè)、冒煙一遍就敢提測(cè)。現(xiàn)在因?yàn)榇a是AI生成的我對(duì)它的信任度是打折扣的。我會(huì)刻意針對(duì)邊界情況補(bǔ)測(cè)試用例空值、超大值、并發(fā)沖突、依賴超時(shí)、網(wǎng)絡(luò)抖動(dòng)。這些東西AI在生成代碼時(shí)大概率不會(huì)主動(dòng)覆蓋但它們恰恰是線上事故的主要來源。三點(diǎn)以后是聯(lián)調(diào)與排障時(shí)間。我特別想聊聊“排障”這件事在新工作模式下的變化。以前遇到線上問題我得先自己翻日志、看監(jiān)控、推線索費(fèi)很大勁才能定位到具體代碼行?，F(xiàn)在工具鏈升級(jí)了我可以直接讓AI讀日志文件讓它幫我歸納異常模式甚至可以給它拋出問題“這個(gè)EOF異常為什么集中出現(xiàn)在節(jié)點(diǎn)A和節(jié)點(diǎn)B”讓它從日志里找共同點(diǎn)。但你猜怎么著AI能幫我縮小排查范圍到“節(jié)點(diǎn)A和節(jié)點(diǎn)B之間的心跳配置可能有問題”它甚至能給出可能的修復(fù)方向。但最終的決策——是調(diào)整超時(shí)參數(shù)還是改心跳機(jī)制還是干脆重啟大法——還是得由我這個(gè)工程師來判斷。為什么因?yàn)锳I只看到了日志而我看到了這個(gè)系統(tǒng)的歷史包袱這兩個(gè)節(jié)點(diǎn)的配置三年前是怎么演變的去年那場(chǎng)事故留下的潛在影響是什么。下午五點(diǎn)半之前我會(huì)做一件事把今天和AI協(xié)作過程中發(fā)現(xiàn)的“有意思的場(chǎng)景”沉淀下來。比如某個(gè)提示詞模板在什么情況下會(huì)失效某類問題需要給AI提供什么樣的示例才能得到可用答案。這些看起來像“使用心得”的東西實(shí)際上已經(jīng)成為我所在團(tuán)隊(duì)的新一代知識(shí)庫——它記錄的不再是代碼片段而是“如何與AI協(xié)作才能得到高質(zhì)量工程結(jié)果”的方法論。3.3 碎片時(shí)間的角色教練、評(píng)審與救火隊(duì)員除了這些整塊的時(shí)間還有不少碎片時(shí)間分散在一天里。現(xiàn)在這些碎片時(shí)間里做的事情跟AI出現(xiàn)以前也有很大區(qū)別。比如同事跑過來問“我這個(gè)接口的AI實(shí)現(xiàn)總是解析不了前端傳過來的復(fù)雜JSON結(jié)構(gòu)是提示詞的問題還是模型的問題”這時(shí)候我不是去幫TA寫代碼而是引導(dǎo)TA一步步拆解“復(fù)雜JSON結(jié)構(gòu)”到底復(fù)雜在哪——是嵌套太深還是字段名跟語義不匹配還是前端的序列化方式跟后端的反序列化約束本來就有偏差。再比如測(cè)試同事提了一個(gè)bug描述得模棱兩可。以前我可能會(huì)讓他先抓日志自己再慢慢看?，F(xiàn)在我會(huì)把這套流程做成一個(gè)標(biāo)準(zhǔn)操作先讓AI把測(cè)試日志里的關(guān)鍵節(jié)點(diǎn)做一個(gè)摘錄我根據(jù)摘錄結(jié)果判斷是功能邏輯還是環(huán)境問題然后精準(zhǔn)地通知對(duì)應(yīng)的同事。這種“引導(dǎo)”“判斷”“調(diào)度”的工作本質(zhì)上更接近教練和救火隊(duì)員的混合體。程序員這個(gè)詞越來越難準(zhǔn)確描述我的日常但“問題解決者”這個(gè)老掉牙的說法反而變得無比貼切——因?yàn)槲椰F(xiàn)在解決的問題從“怎么寫這段代碼”變成了“怎么讓代碼被正確且安全地生產(chǎn)出來”而后者的牽涉面顯然比前者大得多。4. 從編碼者到?jīng)Q策者能力模型正在發(fā)生六項(xiàng)位移上面聊的是“一天在做什么”接下來這部分想聊聊“憑什么能做這些”。角色重構(gòu)意味著對(duì)工程師的能力要求變了。用我自己的經(jīng)歷來看至少有以下六項(xiàng)能力出現(xiàn)了明顯的權(quán)重變化。4.1 從“精通API”到“精通語義”以前判斷一個(gè)工程師成長(zhǎng)得快不快經(jīng)常看他對(duì)框架API是否熟悉。誰能不看文檔寫出各種配置和復(fù)雜用法誰就是大神。現(xiàn)在這個(gè)能力的價(jià)值被AI大幅稀釋了——API細(xì)節(jié)類的問題AI知道得比任何人都全。真正拉開差距的是理解“業(yè)務(wù)語義”的能力。你知不知道這個(gè)接口的真正意圖你知不知道某個(gè)字段的歷史含義和下游依賴這些隱藏在代碼之外的背景知識(shí)是AI的視覺盲區(qū)也是工程師新的護(hù)城河。4.2 從“寫代碼”到“寫約束”AI要產(chǎn)出高可用代碼前提是你給它的約束足夠清晰。這里的約束包括技術(shù)棧版本、性能指標(biāo)、數(shù)據(jù)規(guī)模預(yù)期、并發(fā)模型、依賴邊界、錯(cuò)誤處理策略。我剛接觸AI輔助開發(fā)的時(shí)候提示詞寫得很隨意結(jié)果AI交回來的代碼離預(yù)期差得十萬八千里。后來我學(xué)乖了把它當(dāng)成一個(gè)剛?cè)肼毜某跫?jí)開發(fā)者不把需求細(xì)節(jié)說透它絕對(duì)會(huì)跑偏。這種“把模糊的意圖翻譯成可執(zhí)行約束”的能力恰恰是過去很多工程師最欠缺的。4.3 從“實(shí)現(xiàn)能力”到“驗(yàn)證能力”把代碼寫出來是水平把代碼驗(yàn)證到可上線是境界。在AI時(shí)代驗(yàn)證能力的權(quán)重被進(jìn)一步抬高了。因?yàn)锳I不會(huì)替你做質(zhì)量歸因它只負(fù)責(zé)產(chǎn)出不會(huì)幫你證明產(chǎn)出的對(duì)錯(cuò)。一個(gè)只會(huì)寫代碼不會(huì)驗(yàn)證的工程師面對(duì)AI產(chǎn)出的大量代碼會(huì)迅速招架不住——要么全盤接受然后上線事故頻發(fā)要么全盤否定然后回歸手寫效率不減反增。而一個(gè)擅長(zhǎng)驗(yàn)證的工程師懂得設(shè)計(jì)實(shí)驗(yàn)邊界、構(gòu)造有效用例、分析失敗樣本他知道怎樣用最小的成本獲取關(guān)于代碼正確性的最大信心。這套能力說到底不是AI教給我的而是在無數(shù)次線上故障和返工里磨出來的。4.4 從“單點(diǎn)深度”到“全棧廣度”這個(gè)變化可能有點(diǎn)反直覺但我個(gè)人感受非常明顯。過去我們講全棧是指你會(huì)前端也會(huì)后端現(xiàn)在講的“全?！笔侵改慵纫畼I(yè)務(wù)、又要懂?dāng)?shù)據(jù)、還要懂部署、還要懂一點(diǎn)模型調(diào)用的底層邏輯才能跟AI有質(zhì)量的對(duì)話。因?yàn)锳I生成一個(gè)功能模塊往往牽涉到從數(shù)據(jù)庫到網(wǎng)關(guān)的多個(gè)層次你需要判斷它在每個(gè)層次上是否合理。概念廣度的價(jià)值因此在提升。4.5 從“人跟人協(xié)作”到“人機(jī)人群協(xié)作”以前協(xié)作的對(duì)象主要是同事溝通的障礙主要是信息同步和理解偏差。現(xiàn)在協(xié)作鏈路上多了一個(gè)AI溝通就多了一層復(fù)雜度。我既要把需求翻譯給AI聽又要把AI的輸出翻譯給同事聽還要判斷哪些信息適合直接透?jìng)?、哪些信息需要我加工過濾。很多時(shí)候我在群里發(fā)一段帶解釋的代碼片段群里的人以為我在表現(xiàn)自己其實(shí)只有我知道那是我在幫AI做的“質(zhì)量背書”。4.6 從“執(zhí)行者”到“終極責(zé)任人”最后一項(xiàng)變化也是最沉重的一項(xiàng)變化責(zé)任不會(huì)因?yàn)锳I的介入而稀釋。我以前寫過一篇文章的大意是說無論代碼是手寫的還是AI寫的只要從你手里出去出了問題公司追責(zé)的時(shí)候從來不會(huì)聽“這段是AI生成的”這種解釋。因?yàn)樵诜珊蜕虡I(yè)意義上AI不是民事主體它是工具工具犯錯(cuò)等于使用者犯錯(cuò)。所以工程師的新角色里最重要、最不可推卸的外殼就是“終極責(zé)任人”。這六項(xiàng)能力位移放在一起可以看成是一個(gè)從“用手吃飯”到“用腦吃飯”的轉(zhuǎn)型過程。5. 團(tuán)隊(duì)運(yùn)作模式的連帶重構(gòu)人怎么分組、事怎么分、權(quán)怎么分個(gè)人角色變了團(tuán)隊(duì)的組織方式不可能還維持原樣。我在近兩年跟進(jìn)過幾個(gè)深度落地AI協(xié)作開發(fā)的團(tuán)隊(duì)觀察到了一些非常有意思的連帶變化。5.1 新的分工三角需求架構(gòu)師、驗(yàn)證工程師、工具鏈負(fù)責(zé)人過去一個(gè)開發(fā)小組里通常是大致平級(jí)的開發(fā)人員加一個(gè)組長(zhǎng)。現(xiàn)在慢慢地會(huì)裂變出新角色分工第一類人特別擅長(zhǎng)跟產(chǎn)品、運(yùn)營(yíng)打交道能把模糊的訴求翻譯成AI可執(zhí)行的詳細(xì)任務(wù)說明。我私下叫他“需求架構(gòu)師”因?yàn)樗龅牟皇切枨笳矶前研枨笳Z境補(bǔ)全到AI不需要再追問的程度。這類人往往邏輯感極強(qiáng)文檔功底好懂一點(diǎn)產(chǎn)品又懂一點(diǎn)技術(shù)。第二類人特別擅長(zhǎng)驗(yàn)證和排障。他們對(duì)AI生成的代碼不放心擅長(zhǎng)設(shè)計(jì)測(cè)試策略、做性能分析、處理線上疑難雜癥。這類人就是團(tuán)隊(duì)的“定海神針”因?yàn)锳I產(chǎn)生的工程質(zhì)量問題最終都要靠他們兜底。第三類人專注在工具鏈上。他們配置模型參數(shù)、設(shè)計(jì)提示詞庫、搭建AI產(chǎn)出質(zhì)量的自動(dòng)化評(píng)估流水線。以前這類工作在團(tuán)隊(duì)里是很邊緣的現(xiàn)在直接變成了提效的核心。當(dāng)然這三類人不是完全割裂的而是每個(gè)人有側(cè)重。但團(tuán)隊(duì)在招人和分配任務(wù)時(shí)會(huì)刻意按照這個(gè)維度去匹配因?yàn)楸取八腥耸裁炊紩?huì)一點(diǎn)”更容易產(chǎn)生協(xié)作效率。5.2 任務(wù)單元變小評(píng)審節(jié)奏變快以前一個(gè)功能模塊的開發(fā)周期能排到兩周因?yàn)閷懘a是需要時(shí)間的?，F(xiàn)在AI把初稿產(chǎn)出時(shí)間壓到了小時(shí)級(jí)別等下甚至是分鐘級(jí)別。這意味著任務(wù)單元不能再按“兩周一個(gè)模塊”這種方式劃分而是被切成了“半天一個(gè)可驗(yàn)證片段”。團(tuán)隊(duì)成員之間對(duì)齊的節(jié)奏也因此變快上午設(shè)計(jì)、下午產(chǎn)出、傍晚驗(yàn)證一天一個(gè)閉環(huán)。這里有一個(gè)非常微妙的問題任務(wù)切得太細(xì)溝通成本會(huì)暴漲任務(wù)切得太粗AI輸出質(zhì)量又容易失控。我見過做得好的團(tuán)隊(duì)他們的切割原則是每個(gè)任務(wù)單元必須滿足“可獨(dú)立驗(yàn)證”這個(gè)硬條件。只要任務(wù)有明確的驗(yàn)收標(biāo)準(zhǔn)切小一點(diǎn)問題不大如果驗(yàn)收標(biāo)準(zhǔn)都很模糊那不管切多細(xì)都是災(zāi)難。5.3 決策權(quán)的上移與下放AI介入之前技術(shù)決策權(quán)通常集中在架構(gòu)師或技術(shù)負(fù)責(zé)人手里因?yàn)樗麄兊慕?jīng)驗(yàn)最豐富。但現(xiàn)在有個(gè)有趣的現(xiàn)象一線工程師對(duì)AI的駕馭能力直接影響決策質(zhì)量于是決策權(quán)開始出現(xiàn)了雙向流動(dòng)。一邊是架構(gòu)層面的大決策變得更重了因?yàn)檫@些決策會(huì)直接成為AI生成代碼時(shí)的隱含約束一旦定錯(cuò)方向后面AI生成的所有代碼都會(huì)在錯(cuò)誤的地基上蓋樓。另一邊是執(zhí)行層面的小決策變得更靈活了因?yàn)锳I給了一線工程師快速驗(yàn)證自己想法的能力你不需要等架構(gòu)師批復(fù)就能先跑一個(gè)小試驗(yàn)。這種“大的更大小的更小”的決策權(quán)分布反而讓團(tuán)隊(duì)對(duì)“信息透明”的要求變高了。在我所在的項(xiàng)目里我們開始強(qiáng)制要求所有的AI協(xié)作過程和決策依據(jù)都要落到文檔里不是為了打卡而是為了確保團(tuán)隊(duì)在信息對(duì)稱的情況下做判斷。6. 我的實(shí)測(cè)建議給還在編碼一線的工程師的轉(zhuǎn)型方向聊到這里肯定有很多讀者會(huì)問既然角色變了那我該學(xué)點(diǎn)什么、做點(diǎn)什么才能不被動(dòng)以下是我自己實(shí)踐下來感覺比較靠譜的幾個(gè)方向也是我平時(shí)給團(tuán)隊(duì)里年輕人最常提的建議。6.1 把三分之一的手寫代碼時(shí)間空出來練習(xí)表達(dá)能力我這里說的“表達(dá)”不單是寫文章更關(guān)鍵的是把一段混亂的需求描述成AI能精確理解的規(guī)范語言。我建議你每天抽出一個(gè)小時(shí)不去寫業(yè)務(wù)代碼而是找一個(gè)你已經(jīng)會(huì)實(shí)現(xiàn)的模塊嘗試用自然語言約束條件把它描述清楚然后再看AI實(shí)現(xiàn)出來的跟你預(yù)期差多少。這個(gè)練習(xí)堅(jiān)持兩三個(gè)星期你對(duì)“邊界感知”的能力會(huì)上一個(gè)臺(tái)階。6.2 養(yǎng)成“驗(yàn)證優(yōu)先”的肌肉記憶很多工程師到手第一反應(yīng)是看“怎么實(shí)現(xiàn)”但我說現(xiàn)在的第一反應(yīng)應(yīng)該是“怎么驗(yàn)證”。當(dāng)你接一個(gè)任務(wù)時(shí)先不要想代碼長(zhǎng)什么樣先想清楚如果這段代碼是錯(cuò)的你用什么方法最快能發(fā)現(xiàn)是把測(cè)試用例先寫好是把監(jiān)控指標(biāo)先定義好還是把可觀測(cè)日志先埋好這套“驗(yàn)證優(yōu)先”的思考模式能讓你在面對(duì)AI生成的大量代碼時(shí)完全不慌因?yàn)槟闶掷镂罩话选霸嚱鹗薄?.3 保持親手折騰基礎(chǔ)設(shè)施的愛好不管AI把業(yè)務(wù)代碼生成得多么利索總會(huì)有一部分事是它做不利索的復(fù)雜的網(wǎng)絡(luò)策略、高可用的容災(zāi)方案、壓測(cè)和容量評(píng)估、灰度發(fā)布方案。這些領(lǐng)域邏輯鏈條長(zhǎng)、狀態(tài)空間大、受外部環(huán)境影響強(qiáng)AI常常給出一套“理論上正確但現(xiàn)實(shí)里根本沒法執(zhí)行”的方案。你在這些領(lǐng)域越有經(jīng)驗(yàn)越能成為團(tuán)隊(duì)里AI替代不了的人。6.4 學(xué)會(huì)給AI的產(chǎn)出建立“質(zhì)檢抽樣規(guī)則”我給團(tuán)隊(duì)定了條規(guī)矩AI生成的代碼不允許直接進(jìn)主干必須先過“50%抽查”這一關(guān)。什么叫抽查就是不看它寫得對(duì)不對(duì)而是刻意用幾個(gè)刁鉆場(chǎng)景去擊打它。你不需要檢查每一行代碼但你必須在關(guān)鍵邏輯交匯處親手埋幾個(gè)雷看它會(huì)不會(huì)炸。這個(gè)方法論很重要因?yàn)槟悴豢赡軐?duì)AI的所有產(chǎn)出都做全量審查但你也絕不能全盤接收抽樣質(zhì)檢是成本收益比最好的平衡點(diǎn)。6.5 擁抱“寫文檔”這件反人性的事以前我們總覺得寫文檔是負(fù)擔(dān)但實(shí)際上在AI協(xié)作模式下文檔就是另一種形式的“代碼”。你寫下來的每一個(gè)決策緣由、每一個(gè)邊界條件、每一次踩坑記錄未來都能直接變成AI協(xié)作時(shí)的提示詞上下文?？梢哉f你不會(huì)寫文檔就相當(dāng)于你沒有辦法給團(tuán)隊(duì)里的AI“對(duì)齊上下文”那你協(xié)作效率的瓶頸就卡在這了。為了改變這個(gè)認(rèn)知我自己現(xiàn)在把文檔草稿也丟給AI潤(rùn)色然后自己校對(duì)一遍把它變成既準(zhǔn)確、又具備結(jié)構(gòu)化信息的好文檔。7. 寫在最后角色重構(gòu)是一場(chǎng)卸甲而不是卸責(zé)最后我想再圍繞開頭那個(gè)問題多說兩句自己的體會(huì)。過去很長(zhǎng)一段時(shí)間我們都把“寫代碼”當(dāng)成工程師的身份標(biāo)識(shí)。別人問你是做什么的你說你是程序員對(duì)方腦海里浮現(xiàn)的畫面就是你對(duì)著屏幕噼里啪啦敲鍵盤?，F(xiàn)在這個(gè)畫面開始褪色一個(gè)未來的工程師日?？赡芨褚粋€(gè)坐在指揮室里盯著屏幕的調(diào)度員——AI是執(zhí)行者需求是戰(zhàn)場(chǎng)工程師做的是判斷、決策、兜底。但請(qǐng)務(wù)必放心判斷、決策、兜底這些事永遠(yuǎn)比執(zhí)行更值錢也永遠(yuǎn)比執(zhí)行更需要經(jīng)驗(yàn)與智慧。所以角色的重構(gòu)并沒有把程序員從臺(tái)前趕到幕后而是把過去那些附加在我們身上、可被工具替代的技能負(fù)擔(dān)卸了下來逼著我們走到臺(tái)前更核心的位置上。如果你現(xiàn)在還在一線寫業(yè)務(wù)代碼不需要因?yàn)椤癆I寫得比我快”而自我懷疑。你要看到的是那些你寫代碼時(shí)腦子里形成的整體思維、邊界意識(shí)、權(quán)衡取舍才是在AI時(shí)代真正值錢的東西。代碼是產(chǎn)品但你腦中的那套關(guān)于如何生產(chǎn)靠譜產(chǎn)品的方法論才是你自己真正的“產(chǎn)品”。這個(gè)過程不會(huì)一帆風(fēng)順我至今仍在試錯(cuò)中也會(huì)因?yàn)锳I在某些簡(jiǎn)單任務(wù)上的蠢笨而血壓飆升。但整體方向是清楚的與其擔(dān)心被替代不如抓住被重構(gòu)的機(jī)會(huì)去學(xué)著做那些代碼之外、但比代碼更重要的決策。相信我當(dāng)你不依賴寫代碼也能交付時(shí)你才是真的在這行站住了腳。