夜雨聆风凌晨三点，我又在删AI写的代码。
这是我本月第三次把Cursor生成的三百行代码整块注释掉。事情的开端很美好——上周我只用了两小时就让那个用户管理模块跑了起来，AI像变魔术一样把"做一个后台"这个模糊需求变成了能点击的界面。我当时还在团队群里发："这效率，我们要 revolutionize 行业了。"
然后噩梦开始了。
客户说："加个权限分级吧。" 我让AI改。它改了。然后登录功能崩了。我让它修登录，结果注册又出bug。修到第三轮时，AI开始把之前的修复逻辑覆盖掉，陷入一种诡异的循环——就像参考资料里那个数学建模比赛的团队，AI在代码里藏了个"删除数据库"的隐患，差点让数据付之一炬。
这不是我一个人的遭遇。中科院深圳先进院的研究团队最近测了个数据：当用户用模糊或前后矛盾的自然语言描述需求时，AI会进入"盲执行"（Blind Execution）状态——不问、不确认、闭眼干活，交出来的代码看着像那么回事，但根本不是你要的。更可怕的是，当你试图用敏捷开发的方式，基于AI搓出来的MVP不断迭代加功能时，出错概率会指数级上升。
因为我们搞错了一件事：AI编程最快的场景是0到1，但最危险的场景是1到N。
一、MVP陷阱：从"氛围编程"到"代码屎山"
现在流行一个词叫"Vibe Coding"（氛围编程），意思是跟着感觉走，让AI写代码就像 DJ 打碟一样随性。确实，在空白项目上，AI强得离谱。没有历史包袱，没有复杂的业务嵌套，AI能在白纸上画出漂亮的图案。就像那个搞数学建模的朋友说的，AI十分钟生成的框架确实能跑，看起来"堪比高级工程师"。
但问题是，MVP不是"小一点的正式产品"，而应该是"能用的实验品"。
很多团队把AI生成的Demo当成了产品地基。有个做SaaS的产品经理跟我吐槽（这是参考资料里那个真实案例）：他们让一个开发用AI写多租户系统的代码，单租户测试时顺得很，一上真实流量就崩，整个服务停了一上午。事后那个开发自己都说不清代码的核心逻辑是什么——他只是把需求"喂"给AI，代码能跑通，就提交了。
这就是AI编程的第一个陷阱：它极快地把你的MVP变成了一栋精装房，但地基是松软的。
当你想"敏捷"地加个功能，比如从单租户改成多租户，AI需要理解之前所有的上下文。但AI的上下文窗口是有限的，更重要的是，它对"之前为什么要这么写"的理解是模糊的。于是它开始瞎猜：可能把之前的补丁覆盖掉，可能在老代码上打新补丁，最后整出一个谁也看不懂的"意大利面条式"架构。
参考资料里那个研究团队发现，当需求变得模糊或矛盾时（比如"既要简洁又要功能齐全"），AI不会追问，而是直接闭眼执行。在敏捷开发里，需求本来就是渐明朗的，这正好撞上了AI的枪口。
二、为什么敏捷开发+AI=慢性自杀？
传统的敏捷开发建立在"人"的理解力上。程序员每次迭代都记得"三个月前为什么要把这个字段设为冗余"，记得"这个if-else是为了兼容某个特殊客户"。但AI没有这种记忆，或者说，它的记忆是碎片化的。
当你说"在这个基础上加个支付功能"，AI看到的只是当前文件的代码。它不理解整个系统的业务逻辑已经"充满了针对特定客户场景的特殊处理"（参考资料里描述的老系统现状）。于是它生成的支付代码可能是全新的逻辑，与之前的用户体系冲突；或者它为了"兼容"，把简单问题复杂化，生成一堆冗余的适配层。
更危险的是错误累积。
第一次迭代，AI有10%的概率出错。你手动修好了。第二次迭代，AI需要理解"原来的代码+第一次的修复"，出错概率变成15%。到第五次迭代，上下文已经复杂到AI开始" hallucinate "（幻觉）——它开始编造不存在的API，或者把之前的正确逻辑当成bug改掉。
这就像一个厨师，第一次做菜时你告诉他"不要辣"，第二次说"加点糖"，第三次说"用红烧的做法"。如果是一个人类厨师，他会整合这些需求。但AI可能会在做红烧的时候又加了糖又加了辣，最后问你："为什么这盘鱼香肉丝是甜的？"
三、瀑布式才是AI编程的正确姿势
听起来很反直觉，对吧？我们都被教育说"瀑布式过时了"，"要敏捷，要快速迭代"。但在AI编程的语境下，瀑布式（Waterfall）反而更安全。
瀑布式的核心是：需求分析→设计→编码→测试，阶段分明，一次性把话说清楚。这正好规避了AI的"盲执行"弱点。
中科院那个InteractWeb-Bench研究告诉我们，AI在面对"非专业用户、模糊需求"时表现最差。反过来，如果你能把需求拆解得足够清晰、完整、逻辑自洽——这正是瀑布式所要求的——AI就能发挥最大价值。
具体怎么做？
第一步：用人类做需求分析，不要用AI做探索。
在Vibe Coding里，我们常对着AI说："给我做个电商网站，要酷一点。"这是找死。你应该先自己画好流程图，明确数据库Schema，列出所有边界情况。把"做个后台"拆解成："用户表需要手机号、密码（加密存储）、创建时间；权限分三级；API需要支持每秒100并发..."
第二步：一次性生成，不要渐进增强。
与其让AI先写个基础版，然后不断"在此基础上加功能"，不如一次性把MVP的完整需求文档喂给AI，让它生成完整架构。这样AI能全局考虑，而不是在局部打补丁。参考资料里那个数学建模团队的建议是："关键算法部分手动编写，辅助代码用AI生成"——其实就是把确定性的部分一次定好，不确定的交给AI填充。
第三步：生成后冻结，手工集成。
AI生成代码后，把它当成"外援写的初稿"——你都需要逐行审查（参考资料里强调的"逐行审查"重点检查循环、条件判断），理解每一行逻辑，做好单元测试，然后冻结。接下来的迭代，如果是小改动，人工改；如果是大功能，回到第一步，重新写需求文档，让AI生成新的独立模块，而不是在旧代码上改。
四、实操指南：如何和AI"安全地"合作
说点具体的，如果你现在就要用AI写代码，怎么避免掉进MVP陷阱？
1. 把AI当临时工，不要当员工
临时工做外包项目，你会给他一份详细的需求文档（Spec），验收时严格检查，完成后交接。对AI也要这样。参考资料提到的"Spec Driven MVP"就是这个意思——用明确的规格说明书驱动，而不是模糊的"vibe"。
2. 建立"代码隔离区"
AI生成的代码先放在独立分支或模块，不要直接混入主代码库。跑通后，人工重构一遍，确保你理解每个逻辑，再合并。那个差点删数据库的案例告诉我们，AI可能生成"未关闭的数据库连接"或更危险的逻辑，必须审查。
3. 保留"人类可读性"
要求AI生成代码时必须加详细注释，变量命名要规范。不是为了别人，是为了三个月后你自己能看懂。更重要的是，每天花一小时手动写核心代码（参考资料的建议），保持对底层逻辑的肌肉记忆，避免"AI出错时全队傻眼"的绝境。
4. 识别"该停下来"的信号
如果出现以下情况，立刻停止让AI继续迭代：
- 同样的bug修了又出现
- AI开始修改它之前生成的、你确认过正确的代码
- 生成的代码里出现了项目里根本不存在的函数名（幻觉征兆）
这时候说明上下文已经混乱，你需要人工接管，或者回到需求阶段重新来。
写在最后
AI编程工具不是魔法棒，而是一把电锯。用它砍树快得惊人，但如果你想用它精雕细琢，还可能伤到自己。
那些真正用AI做出好产品的人，不是最会用提示词（Prompt）的人，而是最懂"什么时候该让AI停手"的人。他们把AI关在笼子里——笼子就是清晰的需求文档、瀑布式的阶段划分、严格的人工审查。
下次当你兴奋地看着AI在十分钟内生成一个MVP时，记得问自己：我是想快速验证一个想法，还是在用糖衣包裹一颗定时炸弹？
如果是后者，请回到白板前，把需求写清楚，让AI一次性把活干完，然后让它退下。剩下的路，你自己走。
毕竟，代码能自动生成，但技术债不会自动消失——它只会以AI的速度，积累得更快。
