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