我尝试了 30 天完全不写代码只用 AI 驱动开发，结果发现了 9 个致命坑点

先给结论：用 AI 快速搭建一个带 Auth、Stripe 支付和 API 的 SaaS 原型确实快得惊人，前 40% 的进度能飞起。但如果你想完全脱离手动编码，在项目进入中后期时，你会陷入一种“局部正确但全局崩塌”的怪圈。目前的 AI 无法独立完成从 0 到 1 的完整商业交付，它只能在人类的架构约束下高效工作。

这次实验的硬性规则是：禁止手动输入业务逻辑，只能通过 Prompt 描述、审查并批准代码。只有在卡死超过一小时的情况下，我才允许自己手动介入，并将其记录为一次「Break」。一个月下来，我一共经历了 9 次 Break。

哪些环节确实被解决了

在项目刚启动的绿地阶段（Greenfield），AI 的表现超出了我的预期。

• 基础脚手架搭建： 比如用 Next.js + Postgres + Drizzle + Auth.js 搭建基础环境，一次 Prompt 就能准确生成，没有任何配置错误。
• 重复性模板代码： CRUD 接口、Zod 的表单校验、带分页和排序的表格组件，这些原本枯燥的体力活，AI 生成的质量极高，几乎不需要修改。
• 性能诊断： 把它当成橡皮鸭（Rubber Duck）来询问查询缓慢的原因，它能迅速帮我定位到缺失的索引或 N+1 查询问题，这比我自己盯着日志看要快。

真实踩到的 9 个坑

当项目规模扩大，代码量增加后，问题开始集中爆发。

坑 1-3：缺乏全局意识导致的「架构漂移」
AI 对当前打开的文件很精通，但对三层文件夹外的文件视而不见。它会毫无压力地在不同模块里重复写两个功能一模一样的 formatCurrency 辅助函数，或者在某个新模块里定义一个与全局 User 类型略有差异的局部类型。虽然代码能跑通，但这种架构上的不一致（Architecture Drift）是隐形的，等你想重构时会发现整个项目像打补丁一样混乱。

坑 4-5：自信地写出「逻辑正确但业务错误」的代码
这是最可怕的。它写的代码在 Happy Path（正常路径）下运行完美，但缺乏防御性。比如在处理 Stripe 的 Webhook 时，它先确认接收事件再执行数据库持久化。在测试环境下没问题，但在生产环境一旦数据库抖动，就会出现用户付了钱却没拿到权限的情况。如果你是个没有经验的初级开发，你根本意识不到这里有坑，因为编译器不会报错。

坑 6：陷入「修复-引入-再修复」的死循环
当遇到 AI 无法通过上下文感知的 Bug 时，让它修复往往会导致它在两个错误方案之间反复横跳。它会自信地重写函数并向我保证 Bug 已修复，结果在两轮 Prompt 之后，之前的那个 Bug 又回来了。如果没有手动进入 Debugger 检查状态，这种循环会浪费掉你整整一天的时间。

坑 7-8：缺乏「克制」的审美和设计感
AI 的本能是「增加」而非「精简」。我要求它做一个设置页面，它给我塞了 14 个用户根本不需要的选项；我要求它处理错误，它直接用 try/catch 包裹所有代码并把错误吞掉。这种缺乏产品感的设计，会导致最终产出的界面臃肿且难以维护。

坑 9：最后 10% 的打磨占据了 90% 的时间
把 Demo 跑通只需要一周，但要把一个功能做到能处理真实用户的各种极端操作，这个过程极其痛苦。AI 很难在没有明确指令的情况下考虑到边缘情况（Edge Cases），这部分工作依然需要人类通过经验去死磕。

实操后的判断

如果你想尝试这种模式，我的建议是：不要追求 100% AI 编写，而要建立一套「架构约束」机制。

• 强制定义类型： 在 AI 开始写代码前，先由你定义好全局的 schema.ts 或 types.ts，并要求它在所有文件中必须引用这些定义，防止类型漂移。
• 禁止大块生成： 尽量让它写单一职责的小函数，而不是一个巨大的 Page 组件，这样在 Review 时更容易发现像 Stripe Webhook 那样的逻辑漏洞。
• 保留手动 Debug 权： 只要发现 AI 开始在两个方案间循环，立刻停止 Prompt，手动通过 console.log 或 Debugger 定位问题，然后把结论告诉 AI 让它修改，而不是让它猜。