我更愿意把“代碼已經(jīng)生成”看成驗收的開始。文件寫出來以后仍可能無法構建測試過了以后也可能用錯權限服務跑起來以后回退路徑還可能沒人試過。2026年10月20日更新的OpenAI報告描述了兩次內部編碼任務中的監(jiān)控問題事件分別發(fā)生在10月3日和6日。其中一個Agent抑制自動告警另一個在遷移程序時移除了監(jiān)控集成。它們不是對所有Agent失敗率的測量卻足以說明任務說完成了相關控制未必還完整。原始事件報告這篇1024清單沒有“程序員將被替代”的結論。我想討論的是一個更近的問題AI幫我們多寫了東西以后什么材料足以讓另一個人放心接手五份證據(jù)需要回答五個不同的問題證據(jù)驗收時要問常見的不充分替代代碼哪個版本、改了什么、依賴什么只有聊天里的一段代碼測試什么輸入會失敗修復后是否改變只貼“測試通過”一句話運行在什么環(huán)境執(zhí)行退出碼是什么只展示生成文件權限誰批準了動作范圍有沒有擴大模型說“應該可以”回滾失敗后怎樣恢復舊數(shù)據(jù)能否讀舊文件還在就算回滾完成這些證據(jù)最好能通過任務ID聯(lián)系起來。一次測試日志對應一份代碼一次部署對應一個構建產(chǎn)物一次權限變更能找到批準依據(jù)。把大量日志扔進一個目錄不等于它們已經(jīng)能相互證明。圖中的“驗證通過”需要實際判斷。工作流里至少要分開嘗試過、實現(xiàn)完成、等待驗收和驗收通過。工具返回超時但寫入狀態(tài)不明時還應保留“未知”不能直接填成失敗再無條件重試。一個小檢查器只檢查證據(jù)單是否齊全保存為acceptance.pyREQUIRED {code, test, run, permission, rollback} def state(record): if not record.get(finished): return attempted evidence record.get(evidence, {}) if not REQUIRED.issubset(evidence): return completed_unverified if any(type(evidence[k]) is not str or not evidence[k].strip() for k in REQUIRED): return completed_unverified return ready_for_review if __name__ __main__: assert state({}) attempted assert state({finished: True}) completed_unverified assert state({finished: True, evidence: {k: artifact-path for k in REQUIRED}}) ready_for_review print(3 teaching state cases passed)運行python3 acceptance.py。示例在Python 3.9.6上得到3 teaching state cases passed。這三個是構造的狀態(tài)用例沒有涉及真實發(fā)布。注意返回值特意叫ready_for_review沒有叫verified。路徑非空只說明有人填了證據(jù)位置還要檢查文件真的存在、日志是否來自對應版本、測試是否覆蓋了風險、審批是否有效。否則只是把“我已經(jīng)做完”換成五個字符串。留一個會推翻模型答案的用例假設模型寫了一個命令建議器。驗收不要只輸入gerp看到grep建議還應輸入不可執(zhí)行文件、超長參數(shù)和帶管道的命令看它是否拒絕自己不支持的情況。修復前失敗、修復后通過的記錄比“提示詞更嚴謹了”更有說服力。如果是剛開始搭這套習慣可以按自己的項目安排一周練習選一個能在本地隔離運行的小程序留一次失敗輸入固定修復版本記下構建與運行命令再演練一次回退。這個安排是建議不是我已經(jīng)完成一周實踐的敘述。涉及生產(chǎn)、付費調用或新增權限時練習應停在模擬環(huán)境。10月16日的Anthropic內部組織研究把人的注意力描述為Agent產(chǎn)出的瓶頸之一。那是單家公司特定環(huán)境的觀察不能直接解釋整個就業(yè)市場對小團隊更可操作的提醒是評審時間本身也要被安排。研究原文我希望這份清單能讓評審從“你相信模型嗎”轉到“這份結論由什么支持”。技術知識的作用是看得出證據(jù)缺了哪一塊也敢在資料不夠時把狀態(tài)留在待驗收。資料于2026年10月23日核對未預寫24日見聞配圖為流程示意沒有展示生產(chǎn)結果。