很多人讨论 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

典型代码可能是：

async function callPaymentService(orderId: string) {
  try {
    const result = await paymentService.pay(orderId, {
      timeout: 3000
    });

    return result;
  } catch (error) {
    logger.error("Payment service failed", {
      orderId,
      error
    });

    await markOrderAsPaymentPending(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 抽象：

type AIFailureType =
  | "intent_misread"
  | "context_missing"
  | "context_pollution"
  | "scope_creep"
  | "invalid_patch"
  | "test_failure"
  | "semantic_drift"
  | "tool_error"
  | "verification_failed";

interface AIFailure {
  taskId: string;
  type: AIFailureType;
  severity: "low" | "medium" | "high" | "critical";
  detectedAt: string;
  description: string;
  affectedSteps: string[];
  recoverable: boolean;
}

interface RecoveryPlan {
  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，但漏了关键词。

可以自动检测。

function checkRequiredKeywords(content: string, keywords: string[]) {
  return keywords.every(keyword => content.includes(keyword));
}

2. 边界检测

主要用于 Codex。

比如：

是否修改 forbidden files；
是否新增依赖；
是否超过最大修改文件数；
是否修改数据库迁移；
是否触碰 auth/payment 模块；

可以设计：

interface ScopeCheckResult {
  ok: boolean;
  violations: string[];
}

function checkScope(
  changedFiles: string[],
  forbiddenPatterns: string[]
): ScopeCheckResult {
  const violations = changedFiles.filter(file =>
    forbiddenPatterns.some(pattern => file.includes(pattern))
  );

  return {
    ok: violations.length === 0,
    violations
  };
}

3. 测试检测

Codex 修改代码后，必须跑测试。

类型检查失败
单元测试失败
lint 失败
集成测试失败

这些都是显式失败。

4. 语义检测

最难的是语义检测。

比如文章是否跑题，方案是否空泛，代码是否符合业务意图。

这类检测需要人工 review 或模型辅助 review。

可以设计语义检查清单：

是否回答原始问题？
是否保留用户指定角度？
是否存在明显重复？
是否引入未经验证的结论？
是否遗漏关键约束？

语义检测不能完全自动化，但必须制度化。

八、失败分类：不要把所有 AI 失败都归为“不靠谱”

很多人用 AI 出错后，会直接说：

AI 不靠谱。
Codex 改得不行。
ChatGPT 写得太空。

这不是工程思维。

工程思维要分类。

比如 ChatGPT 写得不好，可能是：

目标不清楚；
上下文不足；
角度重复；
输出格式没约束；
模型没有被要求自检；

Codex 改错代码，可能是：

没有加载相关文件；
没有给 forbidden scope；
任务过大；
测试不足；
历史业务规则缺失；

不同失败，需要不同恢复策略。

可以建立映射：

const recoveryStrategyMap: Record<AIFailureType, 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 执行前，尤其需要代码快照。

interface TaskSnapshot {
  taskId: string;
  goal: string;
  contextHash: string;
  constraints: string[];
  filesBefore: {
    path: string;
    hash: string;
  }[];
  createdAt: string;
}

执行后记录：

interface TaskResult {
  taskId: string;
  filesAfter: {
    path: string;
    hash: string;
  }[];
  changedFiles: string[];
  verificationStatus: "passed" | "failed" | "partial";
}

有了快照，才能回答：

AI 改了什么？
能不能回到修改前？
哪些文件被影响？
失败是否可局部撤销？

没有 Snapshot，Codex 修改失败后，恢复成本会很高。

十、回滚策略：AI 修改必须可撤销

Codex 参与真实项目时，所有写操作都应该可撤销。

回滚策略可以分级：

Level 1：丢弃当前输出
Level 2：撤销某个文件修改
Level 3：回滚整个 patch
Level 4：恢复到任务前快照
Level 5：停止 AI 工作流，进入人工处理

可以抽象为：

interface RollbackStrategy {
  level: 1 | 2 | 3 | 4 | 5;
  description: string;
  trigger: string[];
}

例如：

const rollbackStrategies: RollbackStrategy[] = [
  {
    level: 2,
    description: "撤销单个文件修改",
    trigger: ["单个文件测试失败", "单个文件超出范围"]
  },
  {
    level: 3,
    description: "回滚整个 Codex patch",
    trigger: ["多个测试失败", "修改范围失控"]
  },
  {
    level: 5,
    description: "停止 AI 工作流，进入人工处理",
    trigger: ["触碰支付模块", "修改数据库迁移", "安全检查失败"]
  }
];

AI 生成结果越快，越需要回滚策略。

否则错误也会传播得更快。

十一、Fallback Path：AI 不行时应该怎么降级

成熟系统不应该只有一条路径。

如果 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 必须包含失败反馈。

可以定义：

interface RetryRequest {
  originalTaskId: string;
  failureReasons: string[];
  revisedConstraints: string[];
  retryMode: "regenerate" | "analyze_only" | "minimal_patch" | "split_task";
}

这才是工程化重试。

十三、失败复盘：让 AI 工作流变得更稳定

失败恢复不只是把当前任务救回来，还要改进未来任务。

每次失败都应该沉淀为经验。

例如：

失败：Codex 增加筛选时漏掉导出逻辑。
沉淀规则：订单筛选条件变更时，必须检查导出功能。

或者：

失败：ChatGPT 写 CSDN 文章时变成普通体验文。
沉淀规则：CSDN 技术文章必须包含工程结构、程序示例、技术判断。

可以设计失败复盘结构：

interface FailurePostmortem {
  failureId: string;
  taskType: string;
  rootCause: string;
  preventionRule: string;
  workflowUpdate: string;
  testUpdate?: string;
}

示例：

const postmortem: 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 场景更复杂，必须管理状态。

例如一个长任务至少要记录：

当前目标
已完成阶段
已确认决策
被否定方案
当前上下文
风险清单
下一步计划

如果失败，就可以回到最近状态。

interface ProTaskState {
  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 真正纳入长期生产系统。

因为实验工具只需要成功案例。
工程基础设施必须能处理失败。