---
title: "3.6.4 兜底策略：当 AI 真的搞不定"
---


![03-technique_3.6-debugging-ai_3.6.4-fallback-strategies.png](/images/Basic/03-technique_3.6-debugging-ai_3.6.4-fallback-strategies.png)
# 3.6.4 兜底策略：当 AI 真的搞不定

## 经过本节学习，你将掌握

- 识别 AI 的能力边界
- 三种兜底方案及其适用场景
- 「混合开发」模式的操作方法
- 知道何时该寻求外部帮助

## 认识 AI 的能力边界

AI 很强大，但并非无所不能。了解它的边界，能帮你在关键时刻做出正确判断，避免在死胡同里浪费时间。

### AI 擅长的事

| 领域 | 具体任务 |
|-----|---------|
| **标准化代码** | 实现常见功能、转换数据格式、生成模板代码 |
| **文档和解释** | 解释代码逻辑、生成注释、编写文档 |
| **模式识别** | 识别代码问题、找到类似方案、重构建议 |
| **快速原型** | 生成 UI 组件、搭建项目骨架、实现 MVP |

### AI 不擅长的事

| 领域 | 原因 | 示例 |
|-----|------|------|
| **复杂环境配置** | 涉及本地路径、系统权限、网络配置等 AI 无法访问的信息 | Docker 网络配置、环境变量设置 |
| **需要实时验证的任务** | AI 无法真正运行代码验证结果 | 调试性能问题、排查内存泄漏 |
| **高度项目特定的逻辑** | 依赖大量项目上下文，超出对话窗口容量 | 复杂业务规则、遗留系统集成 |
| **安全敏感操作** | 涉及密钥、凭证等不应该暴露的信息 | 配置 API 密钥、处理用户密码 |
| **实时数据操作** | 无法访问真实数据库、外部 API | 数据库迁移、线上问题排查 |

### 识别「AI 做不到」的信号

- 🚨 你已经提供了所有能想到的上下文，AI 还是给不出正确答案
- 🚨 AI 反复给出「看起来对但实际不能用」的方案
- 🚨 问题涉及你无法通过文字描述的内容（如视觉效果、本地环境）
- 🚨 修改了 5 轮以上，问题还没解决

## 三种兜底方案

### 方案一：换一个 AI 工具

不同的 AI 模型有不同的训练数据和擅长领域。如果一个工具反复卡住，换一个试试往往有效。

**选择建议**：

| 任务类型 | 可尝试的替代方案 |
|---------|----------------|
| 前端/React 相关 | 不同的 AI 可能有不同的框架偏好 |
| 算法逻辑问题 | 尝试偏理论型的 AI 模型 |
| 代码解释和学习 | 选择擅长教学的 AI |
| 快速原型 | 选择代码生成速度快的工具 |

**操作要点**：
- 换工具时，重新整理一遍需求描述
- 不要把前一个 AI 的错误代码带过去（避免干扰）
- 只描述问题本身和期望结果

### 方案二：搜索引擎找现成方案

很多问题已经被其他人遇到并解决过了。用搜索引擎找现成方案，可能比让 AI 从头生成更可靠。

**高效搜索技巧**：

```
[错误信息关键词] site:stackoverflow.com
```

```
[技术栈] [功能描述] github
```

```
[库名] [具体问题] 官方文档
```

**示例**：
```
TypeError map undefined react site:stackoverflow.com
```

**然后让 AI 帮你理解和适配**：
```markdown
我在 Stack Overflow 上找到了这个解决方案：

[粘贴找到的代码]

请帮我：
1. 解释这段代码的原理
2. 根据我的项目情况（[描述你的技术栈]）进行适当修改
```

### 方案三：用 AI 理解概念，自己动手实现

当 AI 生成的代码不可靠时，可以退一步——让它帮你理解原理，然后你自己写代码。

**操作流程**：

1. **让 AI 解释原理**：
   ```markdown
   不要写代码。请解释 [概念/功能] 的工作原理，包括：
   - 核心思路是什么
   - 有哪些关键步骤
   - 有哪些常见的坑需要注意
   ```

2. **让 AI 提供伪代码**：
   ```markdown
   请用伪代码（不是真正的代码）描述实现步骤，
   让我理解整体逻辑。
   ```

3. **你自己编写代码**，遇到具体问题再问 AI

**这种方式的好处**：
- 避免 AI 幻觉导致的错误
- 你对代码有完整的理解
- 后续维护更容易

## 混合开发模式

「混合开发」是一种务实的策略：让 AI 做它擅长的部分，你来补充它做不好的部分。

### 模式一：AI 做骨架，你做细节

```markdown
请生成一个 [功能] 的代码框架，包括：
- 基本的文件结构
- 主要函数的签名（参数和返回值）
- 每个函数的功能注释

不需要实现具体逻辑，我自己来写。
```

**适用场景**：
- 你熟悉业务逻辑，但懒得搭架子
- AI 对细节理解可能出错，但骨架是通用的

### 模式二：AI 做初版，你来审查修改

**工作流**：
1. 让 AI 生成完整代码
2. 你来审查，标记有问题的地方
3. 对于简单问题，让 AI 修正
4. 对于复杂问题，你自己改

**审查要点清单**：
- [ ] 代码逻辑是否正确？
- [ ] 边界情况是否处理？
- [ ] 引用的库和 API 是否存在？
- [ ] 是否有安全隐患？
- [ ] 是否符合项目规范？

### 模式三：分工协作

把任务按特性分成两类：

| AI 负责 | 你负责 |
|--------|-------|
| 生成标准 CRUD 代码 | 复杂业务逻辑 |
| 编写单元测试模板 | 关键算法实现 |
| 生成 UI 组件骨架 | 交互细节和动画 |
| 编写文档注释 | 架构设计决策 |

## 何时寻求外部帮助

有些问题确实超出了「Vibe Coding + AI」能解决的范围。识别这些情况，及时寻求帮助，是更高效的选择。

### 应该寻求帮助的信号

- 问题涉及你完全不理解的领域（如安全、性能优化、DevOps）
- 卡住超过 2 小时，没有任何进展
- 问题可能影响到数据安全或系统稳定性
- 需要做出可能影响长远的架构决策

### 去哪里寻求帮助

| 渠道 | 适合的问题 |
|-----|-----------|
| Stack Overflow | 技术细节问题，已有成熟答案的问题 |
| GitHub Issues | 特定库或框架的问题 |
| 社区论坛/Discord | 需要讨论的开放性问题 |
| 付费咨询/顾问 | 复杂的架构问题、安全问题 |

### 如何有效地提问

无论是问 AI 还是问人，好的问题能大大提高获得帮助的概率：

```markdown
**我想做什么**：[一句话描述目标]

**我遇到的问题**：[具体问题描述]

**我已经尝试过**：
1. [尝试过的方法 1]
2. [尝试过的方法 2]

**相关代码/错误信息**：
[附上最小可复现的代码或完整错误信息]

**我的环境**：[技术栈版本等信息]
```

## 本节要点

✓ **认识边界**：环境配置、实时验证、项目特定逻辑、安全操作是 AI 的弱项

✓ **三种兜底**：换 AI 工具、搜索现成方案、用 AI 学原理后自己实现

✓ **混合开发**：AI 做骨架/初版，你来补充细节和审查

✓ **寻求帮助**：卡住超过 2 小时、涉及安全架构时，及时寻求外部帮助

预防胜于治疗。下一节我们来看如何从一开始就减少 AI「不听话」的概率。