坑！
我在一次实际编程时，需要获取后台数据，来在前端显示一条曲线。AI 实现之后，曲线是显示出来了，但是效率低到令人发指。
在 Review 时我才发现，尽管我全栈的代码都放在同一个文件夹中， AI 也拥有所有的权限，但是它并没有在后端实现所需要的 API。
它复用了后端已经实现了的单个点数据的获取接口。
于是每当页面打开时，前端会做 150 次请求，获取这些点的数据，然后形成曲线！
这效率能高就出鬼了。
场景分析
我们在设计系统架构的时候，会把业务根据其计算量、数据来源、甚至包括公司的组织结构等因素，经过多方面的考虑，划分到不同的模块中。
最典型的就是计算或者数据拼接这类的逻辑，我们是可以前端请求原始数据然后做处理，也可以通过后端提供接口直接得到最终的结果，前端只负责显示。
这个选择并没有绝对的对错，而是根据具体情况来区分的。
计算量不大，数据来源不复杂，这种情况下由前端完成，可以省去后端的开发时间，也减少了服务器的压力。
但像一开始那种需求，就是典型的需要后端提供完整数据的场景。
为什么 AI 会“犯蠢”？
提前做好设计，划分模块，让 AI 在指定框架内工作，确实可以提高工作质量。但是这也出现了一个问题，就是AI会倾向于只在这个模块内改来改去。
如果是真人开发，遇到这种场景，一定是与后端开发协同，后端提供数据接口，前端直接拿来用。要是真的调用 150 次接口只为拼接出一条曲线，简直会让人笑掉大牙。
但是 AI 就做得非常心安理得，甚至它都不觉得这是个问题，连提醒都没有。
这并不是 AI 蠢。它会在我们允许它的工作范围内尽量完成任务，寻找一个“局部最优解”。当我们把它限制在一个模块中的时候，它就不会再从全局的角度考虑问题，也不会从系统架构层次寻找最优解。
它看到一个接口能用，可以实现功能，就拿来用了。至于会不会造成问题，性能上有没有影响，它都不关心。
如何避免？
也并不是说 AI 在 这种情况下一定会出现问题。如果能够实现多个 AI Agent 协同工作，每个负责一个模块，让它们之间有协商的功能，可能会好很多。
但是无论如何，我们在生成代码的时候，还是要尽量多想一些：
- 原则1：先设计，后实现。先让 AI 写出设计文档，我们审核，就可以避免这种情况。
- 原则2：在提示词中明确“优先使用批量接口”。例如：“如果需要获取多条数据，优先查找是否有批量查询的接口，如果没有，请先询问我是否可以新增。”
- 原则3：要求 AI 在生成代码前先做“性能评估”。例如：“在实现之前，预估一下这个方案会产生多少次网络请求，如果超过 X 次，请给出优化建议。”
- 原则4：把“架构原则”写进项目规则文件（如 .cursorrules）。例如：“When fetching list data for charts/tables, NEVER map over an array to call individual API endpoints. ALWAYS create a new bulk API route in the backend (e.g., WordPress REST API custom endpoint) if one does not exist.”。
你在 Vibe Coding 中踩过什么类似的“隐形坑”？欢迎分享和讨论。 关于 Vibe Coding 的更多内容，见我的置顶帖子。 欢迎转载。
