我用 AI 替换了副项目的后端——首先出现了什么问题

Source: Dev.to

实验概述

如果你最近上网超过五分钟，可能已经有人对你说过：

“兄弟，AI 现在可以写完整的后端了。”

我决定做一个小实验：能否用 AI 生成的代码和提示来替换我大部分副项目的后端逻辑？

简短答案： 可以。
结果： 糟糕透顶。

副项目

• 简单的后端（CRUD + 认证 + 通知）
• 没有什么花哨的，只是能跑起来的东西
• 技术栈：REST API、数据库、一些“自然成长”的业务规则

计划

1. 使用 AI 生成控制器、服务以及部分验证逻辑。
2. “以后再清理”（著名的最后一句话）。
3. 快速迭代，打破东西——最好不要在生产环境中。

假设

• AI 在写代码方面很强大。
• AI 在理解你的假设方面很糟糕。

示例

提示： “生成一个发送通知的端点。”
AI 响应： “好的，我会无限重试失败的通知。”

结果：无限重试，没有退避，没有限制，也没有断路器。AI 的假设是：

• 网络调用总会恢复。
• 外部系统都是友好的。
• 速率限制只是建议。

现实并非如此。

安全（悄悄地）

没有崩溃，这让情况更可怕。AI 乐于：

• 暴露内部 ID。
• 记录敏感负载。
• 跳过边缘情况的认证检查，因为“看起来多余”。

代码干净……看不见。

经验教训： 如果你没有明确说明“这涉及安全”，AI 会把它当成教程来处理。

业务逻辑细微差别

我让 AI “验证用户是否有资格执行某个操作”。

AI：

• 检查了基本条件。
• 错过了这些条件最初存在的原因。

人类会在丑陋的 if‑语句和模式中编码意图。这种差异比我预想的更重要。

转折

AI 擅长：

• 样板代码（DTOs、映射器）。
• 测试用例脚手架。
• 向我解释我自己的代码。

它并没有取代我。

建议

如果你想尝试（至少一次），请注意：

✅ 使用 AI 来

• 搭建骨架。
• 编写重复性逻辑。
• 编写测试。
• 编写文档。

🚫 不要盲目信任 AI 用于

• 认证。
• 重试机制。
• 与金钱相关的逻辑。
• 因特定历史事件而存在的边缘情况（例如，“这个边缘情况只因为 2021 年的某次事件而出现”）。

结论： AI 是个出色的实习生，而不是你的技术负责人。是我的过度自信把后端弄坏了，而不是 AI 本身。若有更好的提示和更多测试，结果可能会大不相同。