1024聊AI編程很容易把話題帶到“誰會(huì)被替代”。對(duì)正在交付軟件的人更有用的問題是哪些判斷必須有人負(fù)責(zé)哪些工作適合交給工具出了問題怎樣找到證據(jù)。把決定范圍留給具體的人Agent可以起草實(shí)現(xiàn)方案但本次是否允許改協(xié)議、是否接受兼容性破壞、是否能碰生產(chǎn)數(shù)據(jù)需要有明確的負(fù)責(zé)人。把“請(qǐng)自主完成”寫進(jìn)提示詞無法消除這些決定的后果。我會(huì)給任務(wù)保留三個(gè)短字段目標(biāo)行為、不可改變的約束、交還條件。例如“給超時(shí)錯(cuò)誤增加可識(shí)別分類不改變成功返回結(jié)構(gòu)發(fā)現(xiàn)調(diào)用方依賴字符串判斷時(shí)先停止”。這比“寫得專業(yè)一些”更容易執(zhí)行也方便審查。生成能力不等于證明能力代碼生成擅長填補(bǔ)局部實(shí)現(xiàn)卻可能同時(shí)生成一套與錯(cuò)誤實(shí)現(xiàn)相互配合的測試。復(fù)核時(shí)應(yīng)先從需求列出反例再看測試是否真的覆蓋而不是被整齊的綠色輸出說服。GitHub對(duì)云端coding agent的介紹包含運(yùn)行測試、提交修改和保留工作記錄。這些記錄讓復(fù)核更容易但審核人仍需要檢查環(huán)境、斷言和權(quán)限。一個(gè)成功退出的命令只證明那條命令在那個(gè)環(huán)境成功退出。最近Go團(tuán)隊(duì)開放了2026年開發(fā)者調(diào)查公告明確征集開發(fā)體驗(yàn)和工具使用反饋結(jié)果計(jì)劃在之后發(fā)布。這種把問題、樣本和結(jié)論分開的習(xí)慣也值得用在AI工具評(píng)價(jià)里使用感受可以先記整體收益要等證據(jù)積累。工程師的價(jià)值落在什么地方至少有四類判斷值得持續(xù)練習(xí)識(shí)別需求沖突設(shè)計(jì)失敗路徑判斷證據(jù)是否足夠把限制解釋給協(xié)作者。這些能力需要讀代碼也需要理解業(yè)務(wù)和運(yùn)行環(huán)境。它們不會(huì)因?yàn)樯伤俣茸兛炀妥詣?dòng)出現(xiàn)。可以從一個(gè)很小的練習(xí)開始下一次接受AI補(bǔ)丁時(shí)寫下一個(gè)最擔(dān)心的失敗場景、一條支持接受的證據(jù)以及一項(xiàng)尚未驗(yàn)證的邊界。如果三句都寫不出來補(bǔ)丁可能還沒有準(zhǔn)備好進(jìn)入主干。本文討論的是工作方法沒有聲稱完成某個(gè)倉庫的生產(chǎn)驗(yàn)收也沒有拿廠商發(fā)布推算個(gè)人效率。工具不斷更新負(fù)責(zé)判斷的人仍需要能夠解釋“為什么現(xiàn)在可以合并”。參考GitHubCopilot在GitHub上的工作方式Go官方2026年開發(fā)者調(diào)查公告