9.4 模型的能力边界

AI 做得好和做得差的领域

理解模型的能力边界，和知道怎么使用模型一样重要。毫无保留地信任 AI，和完全不相信 AI，都会让你无法充分发挥 Vibe Coding 的优势。

你需要对"AI 在什么场景下表现好、什么场景下容易出错"有一个清晰的认知。这种认知不是从评测报告里读来的——而是从你自己的实践中积累的。

以下是对 2025 年主流模型能力边界的总结。需要强调的是：这是一个快照，不是永久结论。 模型能力每个月都在进步，今天 AI 做不好的事情，下个模型版本可能就会改善。

AI 擅长的领域（高可靠）

模式匹配和模板生成。

这是 AI 最擅长的领域。它从大量训练数据中记住了各种"标准模式"——常见的 UI 组件（按钮、表单、导航栏）、标准的 CRUD 操作（增删改查）、通用算法（排序、搜索、数据处理）。在这些标准化的任务上，AI 的输出质量最高，几乎不需要修改。

典型例子：

• "用 Tailwind 写一个响应式的导航栏，左侧 Logo，右侧三个链接。"——AI 生成的代码几乎可以直接使用。
• "写一个 Python 函数，接收一个字符串列表，返回去重后的结果。"——AI 能给出多种实现并附带性能说明。
• "在 Express 中创建一个 GET /api/users 端点，返回数据库中所有用户。"——AI 能生成完整的路由、数据库查询和错误处理。

代码翻译和迁移。

将一段代码从一种语言翻译到另一种语言，或从一个框架迁移到另一个框架，AI 做得非常好。因为训练数据中有大量"同一功能、不同语言实现"的对应关系，AI 学会了"翻译"的能力。

典型例子：

• "把这段 Python 代码翻译成 JavaScript。"——AI 保留逻辑的同时完成语法转换。
• "把这个 React class 组件改写成函数式组件。"——AI 自动处理状态管理、生命周期方法等转换。
• "把这段 SQL 从 MySQL 语法改成 PostgreSQL 语法。"——AI 处理方言差异。

文档和注释生成。

AI 在生成自然语言文本方面天生擅长——因为它本身就是语言模型。为代码生成文档、注释、使用说明，AI 几乎不会出错。

典型例子：

• "给这个函数写 JSDoc 注释。"——AI 分析函数的输入输出和逻辑，生成高质量的文档。
• "为这个 API 端点写一段使用说明。"——AI 能根据代码逻辑推断出正确的用法。
• "把这个项目的 README 补充完整，包括安装步骤和 API 文档。"——AI 基于项目结构和代码分析，生成全面的文档。

标准化测试的编写。

单元测试是一种高度模式化的代码——结构固定（describe/it/expect）、逻辑简单（给定输入→验证输出）。AI 在这方面表现稳定。

典型例子：

• "为这个函数写完整的单元测试，覆盖正常路径和边界情况。"——AI 生成测试用例，包括 Mock 和断言。
• "为这个 React 组件写测试，验证它在不同 props 下的渲染结果。"——AI 理解组件的行为并生成对应的测试。

AI 表现中等的领域（需要人工审查）

复杂的状态管理。

当应用涉及大量交互状态时——多步骤表单、复杂的数据依赖、异步流程——AI 有时会搞混状态之间的关系。它可能在"通常情况下"正确，但在"边界条件下"遗漏了某个状态的更新。

为什么 AI 在这里表现中等？因为状态管理涉及"隐式的因果关系"——表单步骤 A 的状态影响步骤 B 的可用选项，用户的操作序列会影响最终结果的走向。这些因果关系在很多代码中不是显式写出来的，而是分散在各处的逻辑中。AI 可能忽略了某些分支路径的因果链。

实践建议：

• 让 AI 先生成状态转换的伪代码或逻辑流程图，你确认后再生成实现代码。
• 在提示词中明确列出所有涉及的状态和它们之间的依赖关系："有三个状态：step（当前步骤，1-3）、formData（表单数据对象）、errors（验证错误对象）。step 变化时需要重置 errors，但不清空 formData。"
• 生成代码后，手动走一遍"用户可能走的每一条路径"——特别是错误路径和异常路径。

创造性的架构设计。

当需求比较开放、有多种可行的实现方案时，AI 给出的方案虽然合理，但未必是最优的——因为 AI 倾向于选择"最普遍的"方案，而不是"最适合你这个场景的"方案。

举个例子：你问 AI "我的博客系统应该怎么存储文章？"——AI 可能建议用 PostgreSQL + 全文搜索。这个方案本身没有问题，但它没有考虑到你可能只有几十篇文章（SQLite 就够了），或者你的核心需求是"快速搜索"（可以考虑 Elasticsearch 或 Meilisearch），或者你只是需要基本的增删改查（文件系统 + 元数据就够了）。

AI 给出的方案是"对于大多数场景都合理的方案"——但"合理"不等于"适合你的场景"。

实践建议：

• 在需求描述中包含你的约束条件——"我只有 100 篇文章""我每月 1000 次访问""我需要支持全文搜索"。
• 让 AI 给出 2~3 个备选方案，并分析各自的优缺点，然后你来选择。
• 对于关键的架构决策，自己做功课或咨询其他资源——AI 的建议是"起点"不是"终点"。

长链路的调试。

AI 在分析单一函数或模块中的 Bug 时表现很好。但当 Bug 涉及多个文件、多个服务、多个网络调用时——前端代码→后端 API→数据库查询→缓存层——AI 的定位能力显著下降。

为什么？因为长链路调试需要"在多个文件中追踪数据流"——数据从 A 传到 B，经过转换后传到 C，然后 D 调用了某个接口返回了意外的结果。AI 需要同时在上下文中看到 A/B/C/D 四个文件的代码才能定位问题。但如果四个文件都贴进去，上下文窗口的占用很大，AI 可能顾此失彼。

实践建议：

• 先让 AI 分析最可疑的环节（通常是"数据第一次不符合预期的地方"），而不是让 AI 看所有文件。
• 采用"二分法"定位：先确定问题在前端还是后端？在 API 层还是数据库层？逐步缩小范围。
• 使用日志或调试输出帮助你定位——"在 X 函数的 Y 位置加一行 console.log，告诉我打印出的 Z 值是什么"。

AI 表现较弱的领域（需要特别注意）

涉及事实准确性和一致性的任务。

AI 有时候会"编造"——说它记得的东西，但其实它记错了。这种"幻觉"在以下场景中比较常见：

• 非常具体的数字（"React 18 中 useEffect 的 cleanup 函数在多少次渲染后被调用"）——AI 可能给出错误的数字。
• 偏门或过时的技术细节（"Python 2.7 中 dict 的 has_key 方法和 in 操作符的性能差异"）——AI 可能混淆不同版本的行为。
• 内部细节（某 API 的具体错误码、某算法的精确时间复杂度）——AI 可能给出"大概正确但不精确"的答案。

当答案涉及"具体的、可验证的事实"时，AI 仍然会出错。不是因为它"想"骗你——而是因为它在概率性地生成最可能的 Token，而不是在"查数据库"。

实践建议：

• 对于涉及具体数字、版本号、API 名称的答案，保持怀疑。
• 让 AI "引用官方文档"——AI 做不到真的引用，但这个要求会减少它编造的倾向。
• 关键的信息自己做一次验证——去官方文档或 Stack Overflow 确认。

对"新事物"的理解。

AI 的训练数据有一个截止日期。在这个日期之后发布的技术、框架、库——AI 不知道。

如果你问 AI "如何使用 React 19 的 Server Components"——如果 React 19 是在模型训练数据截止日期之后发布的，AI 会用 React 18 或之前的知识来"拼接"一个看起来合理的答案。这个答案可能在概念上正确，但在具体 API 和语法上完全错误。

类似的问题：新的语言特性（ES2025 的新语法）、新发布的库（2025 年新出的某个 NPM 包）、最近的 API 变更（某个云服务商更新的 API 签名）。

实践建议：

• 如果你问的是"新东西"，在提示词中明确指出版本号和时间——"请基于 2025 年的最新知识回答"。
• 要求 AI "不确定的地方请告诉我"而不是"假设你知道"。
• 对于新技术，优先查阅官方文档——AI 可以作为"概念理解"的辅助，但不能作为"准确实现"的参考。

需要外部实时信息的任务。

AI 在生成代码时不"知道"当前时间、不"知道"你电脑上的文件、不"知道"当前某个 API 的可用性。它只能基于它训练时的知识来回答。

所以以下任务 AI 做不好：

• "帮我看看我的代码里有个什么 Bug"——AI 看不到你的代码，除非你贴给它。
• "这个服务现在是不是挂了"——AI 不知道，除非你让它搜索。
• "今天的汇率是多少"——AI 不知道，除非你启用了它的搜索功能。
• "我电脑上是不是安装了 Node.js"——AI 不知道。

实践建议：

• 确保你给了 AI 需要的所有信息——不要假设 AI "知道你的情况"。
• 需要实时信息时，明确告诉 AI "请搜索"来获取最新信息（如果工具支持），或者你自己查完后告诉 AI。
• 对于"检查你的代码"这类任务，提供错误信息和上下文代码——不要只说"代码出错了"。

一个实用的"信任-调校"框架

理解了 AI 的强项和弱项后，你可以建立一个"信任-调校"的框架——对不同类型的问题，采取不同的信任度。

任务类型	信任度	策略
生成标准 UI 组件	★★★★★	可以直接使用，略读即可
生成 CRUD 接口	★★★★☆	检查关键路径，关注边界情况
编写单元测试	★★★★☆	检查测试用例是否覆盖了关键场景
翻译代码	★★★★☆	验证关键逻辑，关注语法差异
代码重构	★★★☆☆	审查整体结构，特别注意副作用
架构设计	★★☆☆☆	作为参考，自己做决策
复杂 Bug 定位	★★☆☆☆	用 AI 缩小范围，自己确认根因
安全敏感代码	★☆☆☆☆	必须严格审查，必要时手写
新技术的准确信息	★☆☆☆☆	仅作参考，以官方文档为准

这个框架不需要严格遵守——它是一个思维工具，帮你在不同的任务场景下建立"合理怀疑"的习惯。你对某个模型用得越久，越能根据自己的经验调整这个"信任度"表。

边界越清晰，Vibe 越流畅

最后，对能力边界的理解本身也会让你的 Vibe Coding 更流畅。

当你知道"这个问题的答案 AI 可能不行"时，你会提前调整你的提示词——提供更多上下文、要求 AI 明确标注不确定性、或者让 AI 只做"辅助"而不是"主力"。你不会在 AI 出错后感到挫败——因为你从一开始就没期待它 100% 正确。

相反，当你知道"这个问题 AI 很擅长"时，你可以放心地让 AI 去做，自己去做更有价值的事情。

边界意识的提升路径：

• 刚开始： 你不知道 AI 擅长什么、不擅长什么——一切靠猜测。AI 做对了你觉得"哇太厉害了"，做错了你觉得"唉还是不行"。
• 一段时间后： 你建立了初步的边界感——"这种标准组件 AI 肯定行""这种复杂的业务逻辑 AI 可能搞不定"。
• 熟练之后： 你能在发出一条提示词之前就预判 AI 的反应——"这个需求比较模糊，我先提供一个明确的示例"、"这个逻辑涉及太多分支，我先自己梳理好规则"。

有了这种边界感，Vibe Coding 就从"碰运气"变成了"可控的协作"。