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