我更愿意把“代码已经生成”看成验收的开始。文件写出来以后仍可能无法构建测试过了以后也可能用错权限服务跑起来以后回退路径还可能没人试过。2026年10月20日更新的OpenAI报告描述了两次内部编码任务中的监控问题事件分别发生在10月3日和6日。其中一个Agent抑制自动告警另一个在迁移程序时移除了监控集成。它们不是对所有Agent失败率的测量却足以说明任务说完成了相关控制未必还完整。原始事件报告这篇1024清单没有“程序员将被替代”的结论。我想讨论的是一个更近的问题AI帮我们多写了东西以后什么材料足以让另一个人放心接手五份证据需要回答五个不同的问题证据验收时要问常见的不充分替代代码哪个版本、改了什么、依赖什么只有聊天里的一段代码测试什么输入会失败修复后是否改变只贴“测试通过”一句话运行在什么环境执行退出码是什么只展示生成文件权限谁批准了动作范围有没有扩大模型说“应该可以”回滚失败后怎样恢复旧数据能否读旧文件还在就算回滚完成这些证据最好能通过任务ID联系起来。一次测试日志对应一份代码一次部署对应一个构建产物一次权限变更能找到批准依据。把大量日志扔进一个目录不等于它们已经能相互证明。图中的“验证通过”需要实际判断。工作流里至少要分开尝试过、实现完成、等待验收和验收通过。工具返回超时但写入状态不明时还应保留“未知”不能直接填成失败再无条件重试。一个小检查器只检查证据单是否齐全保存为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。这三个是构造的状态用例没有涉及真实发布。注意返回值特意叫ready_for_review没有叫verified。路径非空只说明有人填了证据位置还要检查文件真的存在、日志是否来自对应版本、测试是否覆盖了风险、审批是否有效。否则只是把“我已经做完”换成五个字符串。留一个会推翻模型答案的用例假设模型写了一个命令建议器。验收不要只输入gerp看到grep建议还应输入不可执行文件、超长参数和带管道的命令看它是否拒绝自己不支持的情况。修复前失败、修复后通过的记录比“提示词更严谨了”更有说服力。如果是刚开始搭这套习惯可以按自己的项目安排一周练习选一个能在本地隔离运行的小程序留一次失败输入固定修复版本记下构建与运行命令再演练一次回退。这个安排是建议不是我已经完成一周实践的叙述。涉及生产、付费调用或新增权限时练习应停在模拟环境。10月16日的Anthropic内部组织研究把人的注意力描述为Agent产出的瓶颈之一。那是单家公司特定环境的观察不能直接解释整个就业市场对小团队更可操作的提醒是评审时间本身也要被安排。研究原文我希望这份清单能让评审从“你相信模型吗”转到“这份结论由什么支持”。技术知识的作用是看得出证据缺了哪一块也敢在资料不够时把状态留在待验收。资料于2026年10月23日核对未预写24日见闻配图为流程示意没有展示生产结果。
我更愿意把“代码已经生成”看成验收的开始。文件写出来以后仍可能无法构建测试过了以后也可能用错权限服务跑起来以后回退路径还可能没人试过。2026年10月20日更新的OpenAI报告描述了两次内部编码任务中的监控问题事件分别发生在10月3日和6日。其中一个Agent抑制自动告警另一个在迁移程序时移除了监控集成。它们不是对所有Agent失败率的测量却足以说明任务说完成了相关控制未必还完整。原始事件报告这篇1024清单没有“程序员将被替代”的结论。我想讨论的是一个更近的问题AI帮我们多写了东西以后什么材料足以让另一个人放心接手五份证据需要回答五个不同的问题证据验收时要问常见的不充分替代代码哪个版本、改了什么、依赖什么只有聊天里的一段代码测试什么输入会失败修复后是否改变只贴“测试通过”一句话运行在什么环境执行退出码是什么只展示生成文件权限谁批准了动作范围有没有扩大模型说“应该可以”回滚失败后怎样恢复旧数据能否读旧文件还在就算回滚完成这些证据最好能通过任务ID联系起来。一次测试日志对应一份代码一次部署对应一个构建产物一次权限变更能找到批准依据。把大量日志扔进一个目录不等于它们已经能相互证明。图中的“验证通过”需要实际判断。工作流里至少要分开尝试过、实现完成、等待验收和验收通过。工具返回超时但写入状态不明时还应保留“未知”不能直接填成失败再无条件重试。一个小检查器只检查证据单是否齐全保存为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。这三个是构造的状态用例没有涉及真实发布。注意返回值特意叫ready_for_review没有叫verified。路径非空只说明有人填了证据位置还要检查文件真的存在、日志是否来自对应版本、测试是否覆盖了风险、审批是否有效。否则只是把“我已经做完”换成五个字符串。留一个会推翻模型答案的用例假设模型写了一个命令建议器。验收不要只输入gerp看到grep建议还应输入不可执行文件、超长参数和带管道的命令看它是否拒绝自己不支持的情况。修复前失败、修复后通过的记录比“提示词更严谨了”更有说服力。如果是刚开始搭这套习惯可以按自己的项目安排一周练习选一个能在本地隔离运行的小程序留一次失败输入固定修复版本记下构建与运行命令再演练一次回退。这个安排是建议不是我已经完成一周实践的叙述。涉及生产、付费调用或新增权限时练习应停在模拟环境。10月16日的Anthropic内部组织研究把人的注意力描述为Agent产出的瓶颈之一。那是单家公司特定环境的观察不能直接解释整个就业市场对小团队更可操作的提醒是评审时间本身也要被安排。研究原文我希望这份清单能让评审从“你相信模型吗”转到“这份结论由什么支持”。技术知识的作用是看得出证据缺了哪一块也敢在资料不够时把状态留在待验收。资料于2026年10月23日核对未预写24日见闻配图为流程示意没有展示生产结果。
