AI写代码省了3分钟，debug花了3小时：一个产品经理的复盘

2024年GitHub Copilot用户突破1300万，Cursor融资估值冲到26亿美元。但一个反直觉的数据是：Stack Overflow调研显示，76%的开发者每周花超过2小时修复AI生成的bug——比手写代码的debug时间还长15%。

这不是工具的问题，是预期管理崩了。

第一阶段：蜜月期

M Ahmad Mujtaba在Medium上写了自己的踩坑史。他最初用AI写代码时，体验堪称丝滑——输入prompt，秒出完整模块，语法正确、结构清晰、甚至带了注释。

「看起来像个完整解决方案」，他这么描述。

这种即时反馈很像外卖软件的首单补贴：第一口真香，但商业模式藏在后面。

问题在运行后才浮现。不是崩溃，是「slightly wrong」——边界条件漏了、时序逻辑偏了、异常处理形同虚设。Mujtaba的观察很精确：代码能跑，但不对。

第二阶段：修修补补的陷阱

他发现自己在做一件诡异的事：修复A bug，触发B问题；改完B，C又冒出来。循环往复。

这里有个产品经理熟悉的概念——技术债务（Technical Debt）。AI生成代码的本质是「预支债务」：它把显性编码时间压缩到几秒，却把隐性成本转移到后期。

更隐蔽的是认知负荷的转移。传统开发中，你写代码时已经在脑内模拟执行路径。用AI时，这个环节被跳过了——你直接拿到结果，却失去了对中间状态的掌控。

Mujtaba的总结很扎心：「我不再是coding，而是在review和correct AI output」。

从生产者变成质检员，角色降级了。

第三阶段：社区验证

他开始在论坛和同行中验证这个感受。发现不是个案。

Reddit的r/ExperiencedDevs板块有大量类似反馈：AI适合 boilerplate（样板代码），但涉及业务逻辑、状态管理、并发安全时，返工率飙升。一位后端工程师的比喻很精准——「AI像实习生，能写，但得盯着，改完还得再改」。

关键分歧在这里：AI coding工具的营销话术是「替代」，实际体验是「辅助+返工」。预期差导致了挫败感。

Cursor和Windsurf最近的更新方向也印证了这一点。它们不再强调「全自动」，而是强化上下文理解（Context Awareness）和增量修改——本质上承认：完全放手不现实，人机协作才是常态。

什么场景真能用？

Mujtaba没全盘否定AI。他梳理了有效场景：

第一类是重复性高的机械劳动。数据转换脚本、API样板、测试用例生成——这些边界清晰、验证简单的任务，AI确实省时间。

第二类是探索性编程。快速验证一个想法，不需要生产级质量时，AI能加速原型迭代。

但涉及核心架构、性能敏感模块、或需要长期维护的代码库时，他的建议是：手写，或者至少深度参与每一行。

一个判断标准是「回滚成本」。如果这段代码明天要上线，出了问题能秒回滚吗？不能的话，别交给AI solo。

Mujtaba最后提到一个细节：他开始在prompt里强制要求AI解释「为什么这样写」。不是想要注释，是逼自己重新进入思考流程——哪怕答案来自AI，也要过一遍脑子。

这像不像用导航时偶尔关声音、看路牌？工具再智能，方向盘得在自己手里。

你现在用AI写代码的比例是多少？有没有算过修bug的时间账？