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