’
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
不要写代码。请解释 [概念/功能] 的工作原理，包括：
- 核心思路是什么
- 有哪些关键步骤
- 有哪些常见的坑需要注意让 AI 提供伪代码：markdown
请用伪代码（不是真正的代码）描述实现步骤，
让我理解整体逻辑。你自己编写代码，遇到具体问题再问 AI
这种方式的好处：
- 避免 AI 幻觉导致的错误
- 你对代码有完整的理解
- 后续维护更容易
混合开发模式
「混合开发」是一种务实的策略：让 AI 做它擅长的部分，你来补充它做不好的部分。
模式一：AI 做骨架，你做细节markdown
请生成一个 [功能] 的代码框架，包括：
- 基本的文件结构
- 主要函数的签名（参数和返回值）
- 每个函数的功能注释
不需要实现具体逻辑，我自己来写。适用场景：
- 你熟悉业务逻辑，但懒得搭架子
- AI 对细节理解可能出错，但骨架是通用的
模式二：AI 做初版，你来审查修改
工作流：
- 让 AI 生成完整代码
- 你来审查，标记有问题的地方
- 对于简单问题，让 AI 修正
- 对于复杂问题，你自己改
审查要点清单：
- 代码逻辑是否正确？
- 边界情况是否处理？
- 引用的库和 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「不听话」的概率。`