很多人讨论 ChatGPT、Codex、Pro、Plus 时容易把焦点放在“成功案例”上。ChatGPT 写出一篇文章。Codex 修复一个 bug。Plus 支撑日常工作。Pro 处理复杂任务。这些都是真实价值。但如果站在软件工程角度只讨论成功是不够的。真正成熟的工程系统从来不是假设一切都会成功而是默认任何环节都可能失败。数据库可能失败。网络可能失败。接口可能失败。服务可能失败。部署可能失败。人也可能判断失败。所以软件工程才需要异常处理、事务、回滚、重试、熔断、降级、日志、监控和恢复机制。ChatGPT 和 Codex 进入真实工作流后也必须面对同样的问题AI 失败了怎么办这就是 AI Failure Recovery。也就是 AI 失败恢复机制。ChatGPT 可能理解错目标。Codex 可能改错文件。Plus 日常任务可能输出空泛内容。Pro 复杂任务可能在多轮上下文中逐渐偏离方向。这些失败不是偶然而是 LLM-Native 系统必须长期面对的工程现实。所以未来真正成熟的 AI 工作流不是让 AI 永不失败而是让 AI 失败后可发现、可隔离、可回滚、可复盘、可改进。一、传统软件工程从来不相信“永远成功”传统软件系统的设计前提是失败必然发生。比如一次接口调用可能出现请求超时 返回 500 网络断开 参数错误 权限不足 数据库死锁 下游服务不可用所以工程系统会设计try/catch retry timeout fallback circuit breaker transaction rollback error logging alerting典型代码可能是asyncfunctioncallPaymentService(orderId:string){try{constresultawaitpaymentService.pay(orderId,{timeout:3000});returnresult;}catch(error){logger.error(Payment service failed,{orderId,error});awaitmarkOrderAsPaymentPending(orderId);return{status:pending,message:Payment is being processed};}}这里的关键不是业务逻辑而是工程思想不要假设外部系统永远成功 不要让局部失败拖垮整体系统 失败要被记录 状态要可恢复 用户体验要可降级AI 系统也一样。不能假设 ChatGPT 永远理解正确。不能假设 Codex 永远修改合理。不能假设 Pro 长任务永远保持方向。不能假设 Plus 日常输出永远可直接使用。成熟的 AI 工程系统必须把“失败”作为一等公民。二、AI 失败不是只有报错更多是“看起来成功”传统系统失败经常会直接报错。AI 系统更麻烦。因为很多 AI 失败看起来像成功。比如 ChatGPT 输出了一篇完整文章但角度重复、逻辑空泛、主题跑偏。比如 Codex 输出了一个 patch代码能编译但业务逻辑错了。比如模型给出一个排查路径语气非常肯定但根因其实不对。比如 Pro 级长任务连续推进了很多轮最后产出很完整但已经偏离最初目标。这种失败最危险。因为它不是显式失败而是隐性失败。可以把 AI 失败分成两类Hard Failure显式失败 Soft Failure隐性失败Hard Failure 比较容易发现模型拒绝输出 代码无法运行 测试失败 工具调用报错 上下文读取失败 JSON 格式错误Soft Failure 更难发现目标理解偏了 上下文用错了 推理前提错了 代码逻辑看似合理但业务错误 方案忽略关键风险 多轮对话逐渐漂移 输出内容完整但没有价值AI Failure Recovery 真正要解决的是 Soft Failure。因为它不会自动报警。它需要验证、审查和恢复机制。三、ChatGPT 的典型失败模式ChatGPT 更常见的失败不是语法错误而是认知错误。1. 意图误解用户说写得更高深一点。ChatGPT 可能理解成加更多抽象词 加更多复杂概念 写得更长但用户真正想要的可能是角度更技术 论点更深 结构更高级 更符合 CSDN 减少浅层体验描述这就是意图误解。2. 上下文遗忘在多轮对话中用户之前要求要有 ChatGPT、Codex、Pro、Plus。后面继续写时模型可能忘记这些关键词。这就是上下文遗忘。3. 主题漂移一开始写的是 AI Testability。写着写着变成普通 AI 效率文章。这就是主题漂移。4. 表达空泛文章看起来完整但大量句子是AI 正在改变未来。 效率会越来越重要。 人类要学会拥抱变化。这种内容没有技术密度。这是语义质量失败。5. 未验证推断ChatGPT 有时会把推测写成事实。比如未来所有代码库都会采用某种结构。这类判断如果没有限定条件就容易显得绝对。这也是一种失败。四、Codex 的典型失败模式Codex 的失败更接近工程风险。1. 改动范围失控用户只想改订单筛选Codex 顺手重构了订单模块。原目标增加一个筛选项 实际改动重构多个组件、修改多个接口、调整测试结构这就是 Scope Creep。2. 只修表面不修根因比如登录刷新后掉线Codex 只在前端加了一个判断但根因是 token refresh 流程有问题。这就是 shallow fix。3. 破坏历史兼容Codex 看到某段旧逻辑很奇怪把它删掉了。但这段逻辑是为了兼容旧订单、旧接口或旧客户。这就是 context loss。4. 测试被错误修改为了让测试通过Codex 修改了测试断言而不是修复业务逻辑。这是严重问题。5. 未触达相关模块修改了列表筛选却忘了导出逻辑。修改了前端参数却忘了后端 DTO。修改了类型定义却忘了接口 mock。这类失败在真实项目中很常见。Codex 的难点不是写代码而是在工程网络中保持一致性。五、Pro 级长任务的失败累积偏差Pro 级使用通常涉及更长上下文、更复杂任务和更多轮迭代。这种场景最容易出现累积偏差。一次小偏差不明显。多轮之后偏差会放大。比如写一组 CSDN 技术文章第 1 篇LLM-Native 架构 第 2 篇Tool Contract 第 3 篇AI Observability 第 4 篇AI Testability 第 5 篇AI Failure Recovery如果每一篇都没有记录已写角度就容易重复。再比如一个代码项目第一轮Codex 改筛选 第二轮Codex 补测试 第三轮Codex 优化结构 第四轮Codex 写文档 第五轮Codex 再次重构如果没有持续验证和回归测试第五轮可能破坏第一轮功能。这就是 Pro 级任务的风险上下文长 步骤多 状态复杂 目标容易漂移 错误容易累积 最终失败不容易定位所以 Pro 级任务更需要恢复机制而不是更少需要。六、AI Failure Recovery 的基本架构一个完整的 AI 失败恢复系统至少应该包含六层AI Failure Recovery ├── Failure Detection 失败检测 ├── Failure Classification 失败分类 ├── State Snapshot 状态快照 ├── Rollback Strategy 回滚策略 ├── Fallback Path 降级路径 └── Learning Loop 复盘更新可以用 TypeScript 抽象typeAIFailureType|intent_misread|context_missing|context_pollution|scope_creep|invalid_patch|test_failure|semantic_drift|tool_error|verification_failed;interfaceAIFailure{taskId:string;type:AIFailureType;severity:low|medium|high|critical;detectedAt:string;description:string;affectedSteps:string[];recoverable:boolean;}interfaceRecoveryPlan{failure:AIFailure;action:|retry_with_more_context|rollback_patch|fallback_to_manual_review|split_task|restore_previous_context|stop_execution;reason:string;}这套结构的关键是失败不能只是“感觉不对”。它必须被分类、记录、处理和复盘。七、失败检测如何知道 AI 已经失败AI 失败检测可以分成几类。1. 结构检测结构检测最简单。比如输出要求 Markdown但没有标题。要求 JSON但 JSON 不合法。要求包含 ChatGPT、Codex、Pro、Plus但漏了关键词。可以自动检测。functioncheckRequiredKeywords(content:string,keywords:string[]){returnkeywords.every(keywordcontent.includes(keyword));}2. 边界检测主要用于 Codex。比如是否修改 forbidden files 是否新增依赖 是否超过最大修改文件数 是否修改数据库迁移 是否触碰 auth/payment 模块可以设计interfaceScopeCheckResult{ok:boolean;violations:string[];}functioncheckScope(changedFiles:string[],forbiddenPatterns:string[]):ScopeCheckResult{constviolationschangedFiles.filter(fileforbiddenPatterns.some(patternfile.includes(pattern)));return{ok:violations.length0,violations};}3. 测试检测Codex 修改代码后必须跑测试。类型检查失败 单元测试失败 lint 失败 集成测试失败这些都是显式失败。4. 语义检测最难的是语义检测。比如文章是否跑题方案是否空泛代码是否符合业务意图。这类检测需要人工 review 或模型辅助 review。可以设计语义检查清单是否回答原始问题 是否保留用户指定角度 是否存在明显重复 是否引入未经验证的结论 是否遗漏关键约束语义检测不能完全自动化但必须制度化。八、失败分类不要把所有 AI 失败都归为“不靠谱”很多人用 AI 出错后会直接说AI 不靠谱。 Codex 改得不行。 ChatGPT 写得太空。这不是工程思维。工程思维要分类。比如 ChatGPT 写得不好可能是目标不清楚 上下文不足 角度重复 输出格式没约束 模型没有被要求自检Codex 改错代码可能是没有加载相关文件 没有给 forbidden scope 任务过大 测试不足 历史业务规则缺失不同失败需要不同恢复策略。可以建立映射constrecoveryStrategyMap:RecordAIFailureType,RecoveryPlan[action]{intent_misread:retry_with_more_context,context_missing:retry_with_more_context,context_pollution:restore_previous_context,scope_creep:rollback_patch,invalid_patch:rollback_patch,test_failure:fallback_to_manual_review,semantic_drift:split_task,tool_error:retry_with_more_context,verification_failed:fallback_to_manual_review};这就是 AI 失败恢复的基础。先分类再恢复。九、状态快照没有 Snapshot就没有可靠回滚传统系统要回滚必须有状态记录。数据库事务有 before/after。代码版本有 git commit。部署有 release version。配置有历史版本。AI 工作流也需要 Snapshot。一次 ChatGPT 或 Codex 任务开始前应该记录原始目标 当前上下文 已确认约束 任务计划 代码状态 文件版本 测试状态Codex 执行前尤其需要代码快照。interfaceTaskSnapshot{taskId:string;goal:string;contextHash:string;constraints:string[];filesBefore:{path:string;hash:string;}[];createdAt:string;}执行后记录interfaceTaskResult{taskId:string;filesAfter:{path:string;hash:string;}[];changedFiles:string[];verificationStatus:passed|failed|partial;}有了快照才能回答AI 改了什么 能不能回到修改前 哪些文件被影响 失败是否可局部撤销没有 SnapshotCodex 修改失败后恢复成本会很高。十、回滚策略AI 修改必须可撤销Codex 参与真实项目时所有写操作都应该可撤销。回滚策略可以分级Level 1丢弃当前输出 Level 2撤销某个文件修改 Level 3回滚整个 patch Level 4恢复到任务前快照 Level 5停止 AI 工作流进入人工处理可以抽象为interfaceRollbackStrategy{level:1|2|3|4|5;description:string;trigger:string[];}例如constrollbackStrategies:RollbackStrategy[][{level:2,description:撤销单个文件修改,trigger:[单个文件测试失败,单个文件超出范围]},{level:3,description:回滚整个 Codex patch,trigger:[多个测试失败,修改范围失控]},{level:5,description:停止 AI 工作流进入人工处理,trigger:[触碰支付模块,修改数据库迁移,安全检查失败]}];AI 生成结果越快越需要回滚策略。否则错误也会传播得更快。十一、Fallback PathAI 不行时应该怎么降级成熟系统不应该只有一条路径。如果 AI 失败应该有降级方案。比如 ChatGPT 写作失败自动生成失败 ↓ 改为只输出大纲 ↓ 人工选角度 ↓ 再生成局部段落比如 Codex 修改失败自动 patch 失败 ↓ 退回影响范围分析 ↓ 只输出修改建议 ↓ 人工手动改代码比如 Pro 长任务漂移继续生成失败 ↓ 回到最近一次确认的任务快照 ↓ 重新编译目标 ↓ 拆成更小任务Fallback 的核心是AI 不能完成完整任务时至少保留部分价值。不能因为 AI 改代码失败就完全没有产出。它仍然可以输出问题分析 影响范围 风险说明 测试建议 人工处理路径这就是降级。十二、Retry 不等于重复问一遍很多人发现 AI 输出不好会直接说重新写。 再来一版。 换个说法。这不是高质量 retry。真正的 AI Retry 应该带着失败原因重试。低质量 retry再写一篇。高质量 retry上一版失败原因 1. 太偏体验文 2. 缺少 CSDN 工程结构 3. 没有程序示例 4. 没有形成明确技术判断。 请基于这些失败原因重写。Codex 也一样。低质量 retry再修一下。高质量 retry上一版 patch 失败原因 1. 修改了无关文件 2. 没有同步测试 3. 导出逻辑未检查。 请回滚上一版改动只分析影响范围先不要生成 patch。Retry 必须包含失败反馈。可以定义interfaceRetryRequest{originalTaskId:string;failureReasons:string[];revisedConstraints:string[];retryMode:regenerate|analyze_only|minimal_patch|split_task;}这才是工程化重试。十三、失败复盘让 AI 工作流变得更稳定失败恢复不只是把当前任务救回来还要改进未来任务。每次失败都应该沉淀为经验。例如失败Codex 增加筛选时漏掉导出逻辑。 沉淀规则订单筛选条件变更时必须检查导出功能。或者失败ChatGPT 写 CSDN 文章时变成普通体验文。 沉淀规则CSDN 技术文章必须包含工程结构、程序示例、技术判断。可以设计失败复盘结构interfaceFailurePostmortem{failureId:string;taskType:string;rootCause:string;preventionRule:string;workflowUpdate:string;testUpdate?:string;}示例constpostmortem:FailurePostmortem{failureId:fail-001,taskType:codex_feature,rootCause:上下文中没有加载 orderExportService导致导出逻辑被遗漏,preventionRule:订单筛选相关任务必须加载导出服务文件,workflowUpdate:feature.workflow.json 增加 related export logic 检查,testUpdate:新增 orderExport filter sync regression test};这就是让 AI 工作流不断变稳的关键。十四、失败恢复会改变 Prompt 模板很多 Prompt 模板只描述成功路径。例如请你帮我生成一篇高质量文章。但成熟模板应该包含失败预案。比如如果你发现主题过大请先拆解不要直接写。 如果上下文不足请列出缺失信息。 如果存在多个角度请先给出方案比较。 如果某些判断只是推测请明确标注。Codex 模板也应该包含失败预案如果影响范围超过 5 个文件请停止并请求人工确认。 如果需要修改数据库结构请只输出分析不要生成 patch。 如果测试失败请不要修改测试绕过失败而是说明失败原因。 如果发现上下文不足请先列出需要读取的文件。这类模板不是为了让 AI 更啰嗦而是为了让 AI 在不确定时不要乱执行。十五、AI Failure Recovery 与 CI/CD 的关系未来 Codex 生成代码后失败恢复应该接入 CI/CD。流程可以是Codex 生成 patch ↓ 运行测试 ↓ 如果通过进入人工 review ↓ 如果失败自动标记 failure type ↓ 触发 rollback 或 retry ↓ 生成失败报告可以抽象AI Patch Pipeline ├── Generate Patch ├── Scope Check ├── Type Check ├── Unit Test ├── Integration Test ├── Failure Classification ├── Rollback / Retry └── Human Review这意味着 AI 生成的代码不能绕过工程体系。它必须进入现有质量链路。成熟团队不会因为代码是 Codex 写的就降低标准。相反AI 代码更需要严格测试和回滚机制。十六、Plus 场景的失败恢复轻量但不能没有Plus 日常场景也需要失败恢复只是可以轻量一点。例如写文章失败失败原因角度不够深。 恢复方式保留标题重写大纲。总结资料失败失败原因遗漏关键点。 恢复方式增加“必须覆盖的信息清单”后重试。代码解释失败失败原因解释太泛。 恢复方式要求逐行解释、列出输入输出和边界条件。Plus 的恢复机制可以简单指出失败原因 补充约束 缩小任务范围 重新生成 人工定稿但不能完全没有恢复意识。否则日常 AI 使用会变成不断生成、不断丢弃。十七、Pro 场景的失败恢复必须有状态管理Pro 场景更复杂必须管理状态。例如一个长任务至少要记录当前目标 已完成阶段 已确认决策 被否定方案 当前上下文 风险清单 下一步计划如果失败就可以回到最近状态。interfaceProTaskState{taskId:string;currentGoal:string;completedStages:string[];confirmedDecisions:string[];rejectedOptions:string[];activeContext:string[];knownRisks:string[];nextStep:string;}没有状态管理Pro 级长任务失败后只能从头来过。有状态管理失败可以局部恢复。这就是复杂 AI 工作流和普通聊天的区别。十八、未来程序员的新能力AI Failure Debugging过去程序员 debug 代码。未来程序员还要 debug AI failure。AI Failure Debugging 要问AI 是在哪一步失败的 是意图解析失败还是上下文失败 是工具调用失败还是验证失败 是 Codex 修改越界还是测试设计不足 是 ChatGPT 表达空泛还是任务目标不清这是一种新的工程能力。可以用一个排查树AI 输出不好 ├── 目标是否明确 ├── 上下文是否完整 ├── 约束是否清晰 ├── 任务是否过大 ├── 是否有验收标准 ├── 是否有验证过程 ├── 是否有人工反馈 └── 是否需要拆分任务这比简单说“AI 不好用”更有价值。CSDN 技术读者应该关注的正是这种工程化排错能力。十九、结语AI 成熟的标志不是不失败而是会恢复ChatGPT、Codex、Pro、Plus 的能力越强越不能只讨论成功。真正成熟的 AI 工程体系必须讨论失败。ChatGPT 会理解错。Codex 会改错。Plus 日常任务会输出空泛内容。Pro 长任务会出现目标漂移。这并不可怕。可怕的是失败不可见、不可回滚、不可复盘、不可改进。AI Failure Recovery 的目标不是让 AI 永不失败而是让失败可管理。失败可检测 失败可分类 失败可隔离 失败可回滚 失败可降级 失败可复盘 失败可转化为新规则。这才是 LLM-Native 软件工程真正成熟的标志。对 CSDN 技术读者来说真正值得关注的问题不是ChatGPT 能不能写 Codex 能不能改 Pro 强不强 Plus 够不够而是当它们失败时系统怎么处理 当 Codex 改错时如何回滚 当 ChatGPT 跑题时如何恢复 当 Pro 长任务漂移时如何回到正确状态 当 Plus 日常输出低质时如何建立轻量验收未来 AI 工程的竞争不只是生成能力竞争而是恢复能力竞争。谁能把失败管理好谁才能把 ChatGPT、Codex、Pro、Plus 真正纳入长期生产系统。因为实验工具只需要成功案例。工程基础设施必须能处理失败。