现在人人都能用 AI 写代码，反而证明了为什么有些人不该写代码

很多人觉得有了 Cursor 或者 Windsurf 之后，只要能写 Prompt 就能替代开发，但实际跑项目的结果往往是：代码量暴增，但系统复杂度失控，最后没人敢动那个屎山。Paul Ford 在 2026 年 9 月的一篇观点里点出了一个很残酷的真相：AI 让人们能够极其高效地「糟糕地完成他人的工作」。

这意味着，如果你不具备软件架构的直觉，AI 给你生成的 500 行代码可能在运行瞬间没问题，但它在内存管理、并发处理或可维护性上留下的坑，需要一个资深开发者花三天时间去排查。这种「伪效率」正是目前很多 AI 驱动项目最终崩盘的核心原因。

我最近在尝试用 AI 快速搭建一个多模块的内部管理系统，过程中深刻体会到了这种「能写代码」与「能做软件」的区别。

一、AI 编码在实际项目中的失效路径

在项目初期，我用 AI 快速生成了 12 个 API 接口和 5 个前端页面，耗时不到 2 小时。当时感觉效率起飞，但到了第三天，我发现一个简单的状态同步逻辑需要修改，结果导致 AI 之前生成的 3 个模块全部崩溃。

• 问题点： AI 倾向于给出一个「当前上下文最正确」的局部方案，而忽视了全局的依赖关系。
• 后果： 随着代码量增加，AI 产生的幻觉开始在模块之间产生共振。比如它在 A 模块定义了一个全局变量，在 B 模块又定义了一个同名但逻辑略有不同的变量，这种 Bug 在 IDE 的静态检查中很难立刻发现，直到运行时抛出 TypeError 或逻辑错误。
• 成本： 修复一个 AI 引入的深层逻辑 Bug，耗时往往是生成该代码的 10 倍以上。

真正的软件开发不是把需求翻译成语法，而是处理权衡（Trade-off）。

• 架构决策： 什么时候该用 Redis 缓存，什么时候该直接读库？AI 可能会根据训练数据给你一个最流行的方案，但这不一定是最适合你当前 100 个并发量场景的方案。
• 协作成本： 正如 Paul Ford 所说，前沿软件需要人类协作。AI 无法参与团队的共识讨论，它不能告诉你「这个设计虽然优雅但团队其他成员看不懂」，它只会给你最「正确」的代码。
• 维护陷阱： 很多非专业开发者用 AI 拼凑出产品，在 1.0 版本运行良好。但当需要 2.0 迭代时，由于缺乏对底层逻辑的掌控，他们发现无法在不推翻重来的情况下增加新功能。

如果你想用 AI 提高生产力而不是制造垃圾代码，我建议尝试以下操作流程：

1. 强制模块化约束： 每次让 AI 写代码前，先定义严格的接口契约（Interface）。

// 先定义好这个，再让 AI 实现具体逻辑，防止它在实现过程中随意修改参数名
interface UserDataService {
  fetchUser(id: string): Promise<User>;
  updateUser(id: string, data: Partial<User>): Promise<void>;
}

2. 限制单次生成量： 严禁让 AI 一次性生成超过 50 行的复杂逻辑。如果它给的代码太长，要求它将其拆分为更小的私有函数，这样你在 Code Review 时能快速定位问题。
3. 手动验证临界值： AI 写的代码最容易在边界条件（Edge Cases）上翻车。拿到代码后，不要直接运行，先手动写三个测试用例（包含空值、极大值、异常类型），确认它能通过后再合并。

总结来说，AI 抹平了语法的门槛，但拉高了架构的门槛。如果你没有基础，AI 只是让你更快地制造出无法维护的软件。