写在前面： 如果你正打算把核心业务代码交给AI写，请先花5分钟读完这篇文章。我不是反AI，恰恰相反——我每天用AI写代码。但有些事情，只有亲身体验过残酷的教训后才会明白。
那个让我兴奋的夜晚
2026年4月的一个周末，我坐在书桌前，面前是一个我规划了两个月的项目——一个中小型企业用的客户管理系统。
传统的做法是：先画架构图，再写接口文档，然后一个模块一个模块手动实现。以我的经验，这至少要两到三周。
但那天晚上，我决定换个做法。
我把整个需求文档丢给了Claude Code，然后用Cursor打开了项目目录。我说："帮我把这个项目从零搭建起来。"
接下来的四个小时是我作为程序员生涯中最魔幻的经历。AI像疯了一样输出代码：路由文件、数据库模型、控制器、中间件、DTO、异常处理……一行接一行，一个文件接一个文件。我只需要在出错时把错误日志复制回去，AI会自动修复。
凌晨两点，当AI告诉我"项目初始化完成，可以尝试启动"时，我数了一下——1078行新代码。
我试着启动了项目。奇迹发生了——服务跑起来了！API能响应请求了！Swagger文档自动生成了！那种感觉太爽了。我甚至发了条朋友圈："AI单挑全栈，四小时干完两周的活。"
如果故事到这里结束，这会是一篇完美的AI赞歌。
但真正的故事，从第二天早上才开始。
噩梦从"看起来没问题"开始
第二天我醒来，心情很好。泡了杯咖啡，打开项目，准备做第一个真实业务场景的联调测试。
第一个接口：创建客户。请求发出去，返回200 OK，数据写入了数据库。完美。
第二个接口：查询客户列表。返回200，分页正常。好。
第三个接口：按条件搜索客户。我输入了"来自深圳的VIP客户"——结果返回了空的列表。数据库里有数据，但查询条件没命中。
我开始查代码。这是AI写的一个典型的查询拼接：
def search_customers(self, filters: dict) -> list:
query = self.session.query(Customer)
if 'city' in filters:
query = query.filter(Customer.city == filters['city'])
if 'level' in filters:
query = query.filter(Customer.level == filters['level'])
return query.all()
看起来完全正确，对吧？我当时也这么想。
花了半小时我才发现问题：AI把所有过滤条件都用and拼接了，但如果传了空字符串而不是None，条件判断的if 'city' in filters会返回True，然后执行Customer.city == ''，导致结果为空。
这个问题本身不难修。但让我感到不安的是：这段代码看起来完全正确，不仔细推敲根本发现不了问题。
那天我总共发现了17个小bug——大部分是边界条件没处理好、异常捕获缺失、或者SQL查询有微妙错误。每段代码单独看都挺合理，但组合在一起就像一座用纸牌搭的房子，看起来漂亮，一碰就倒。
看不见的债务：AI代码的隐藏成本
那1000行代码的第一周，我每天都在做同一件事：打开AI写的代码，盯着它看，然后默默地删除重写。
我记录了一组数字，完全真实：
- AI生成的代码：1078行
- 一周后保留的代码：约350行
- 重写/大幅度修改的代码：约700行
- 发现的逻辑Bug：23个
- 发现的安全隐患：4个（包括SQL注入风险、硬编码密钥、CSRF保护缺失、权限校验遗漏）
- 发现的性能问题：3个（N+1查询、缺少索引导致的全表扫描、未使用连接池）
保留率：32%。
也就是说，AI生成的代码中，将近七成需要我重写。
这还不是最要命的。最要命的是：我花了大量时间阅读和验证AI的代码，而这些时间原本可以用来写自己的代码。
表面上看，AI帮我写了1078行，节省了两周时间。但实际上，我花在验证、调试和重写上的时间加起来，比我自己从零写还要多。
这让我想到一个概念：AI代码的"认知负载"。读自己写的代码，你知道自己当时在想什么，逻辑意图是清晰的。但读AI写的代码，你首先要理解"AI当时在想什么"——而AI根本没有"在想"，它只是在做概率预测。你要为每一段看似合理的代码做逆向工程，确认它是不是真的合理。
这比读一个水平一般的同事写的代码还要累，因为AI永远不会告诉你"这块我不确定"。
什么代码AI写得好，什么代码AI写得烂
经过几个月的反复试验，我总结了一个比较实用的经验矩阵。先说AI确实擅长的：
AI写得好的：
1. 样板代码 — CRUD接口、数据传输对象、配置文件。这类代码有固定模式，AI几乎不会出错。
2. 单元测试 — 尤其是基于已有函数签名的测试代码。AI能快速生成完整的测试覆盖，虽然边界情况偶尔遗漏，但修正成本很低。
3. 正则表达式 — 这个出乎我意料，AI写正则比我强十倍。
4. Dockerfile和CI配置 — 只要能描述清楚需求，AI能生成可用的配置。
5. 代码注释和文档 — 虽然可能有些啰嗦，但比程序员自己写文档积极多了。
AI写得差的（需要重点人工审查）：
1. 业务逻辑 — 特别是涉及"如果A发生但B没发生且C满足条件的话"这种多条件组合逻辑。AI容易遗漏分支。
2. 跨表事务处理 — AI经常忘记加事务，或者在事务中混入非事务操作。
3. 权限和认证逻辑 — 安全相关的代码AI写得最差，可能因为它训练数据中的安全示例不够多。
4. 状态机流转 — 涉及状态变更的代码，AI几乎必定遗漏状态转移的边界情况。
5. 与外部系统集成 — 调用第三方API时，AI经常假设"第三方一定正常工作"，缺乏错误处理和重试逻辑。
这个矩阵帮我节省了大量时间：遇到AI擅长的类型，我放心让它写；遇到AI不擅长的类型，我选择自己写或者写详细注释让AI填实现。
认知偏差：为什么你觉得AI写得好？
这个问题困扰了我很久。如果AI生成的代码问题这么多，为什么网上随处可见"AI帮我写完了整个项目"的帖子？
我自己的经历和后来的分析发现，这里面有几个认知偏差：
第一个是"幸存者偏差"。 那些用AI写个Demo、写个算法题、写个脚本就发帖说"AI替代程序员"的人，不会遇到后续维护阶段的那些坑。他们的项目可能就在GitHub上吃灰，永远不会上线跑真实流量。
第二个是"即时满足偏差"。 AI在几分钟内输出几百行代码，这种视觉冲击力会让人高估代码的质量。就像第一次做菜的人看到自己炒出来一盘菜，觉得味道不错，但吃了几口才发现没放盐。
第三个是"复杂度逐步增加"的幻觉。 AI生成"Hello World"级别的代码确实很完美，但随着功能增加、需求细化，代码复杂度非线性增长。AI在前20%的代码上表现良好，但后面的80%才是真正的挑战。
现在我是怎么用AI写代码的
经历了那次"1000行惨案"之后，我的工作流完全变了。如果你也在用AI写代码，这几个原则可能对你有用：
原则一：分段交付，逐段验证
以前：把整个需求给AI → AI生成全部代码 → 最终发现大量问题。
现在：把需求拆成2-4小时能完成的小块 → 让AI写一块 → 立即审查和测试 → 确认没问题后再写下一块。
这个改变让问题发现时间从"一周后"缩短到"半小时内"，单个问题的修复成本降低了一个数量级。
原则二：AI写草稿，人写终稿
我现在把AI定位为"极其高效的初稿生成器"。AI写完代码后，我会做三件事：
- 通读一遍：不逐行看，而是看整体结构是否存在明显的设计缺陷。
- 写测试用例：针对边界条件和异常路径写测试，用测试来暴露问题。
- 压力重构：在真正理解了AI的代码意图之后，按自己的风格重写核心逻辑。
听起来工作量不小，但实际上比从零写要快，因为AI至少给了我一个"可讨论的起点"，而不是一张白纸。
原则三：不信任任何AI生成的安全代码
这是最硬的一条。任何涉及权限验证、数据加密、用户认证的代码，我不看AI写的，我直接自己写。安全领域的代码不能用概率思维。
原则四：用AI补全，不用AI创作
我现在用得最多的功能不是"帮我写个函数"，而是代码补全：我写函数签名和核心逻辑的骨架，让AI帮我填充细节、写注释、生成类型标注。
这种方式保留了"我对代码的完全控制"，同时利用了AI最擅长的部分——填充模式化内容。
回头看：AI编程的真实价值在哪？
写了这么多"踩坑"，我想最后客观地聊聊AI编程的真正价值。
即使在经历了那痛苦的一周后，我仍然认为AI编程是自Stack Overflow以来对程序员最有帮助的工具。只是它的价值不在"帮我写代码"，而在以下几个方面：
第一，降低启动门槛。 面对一个新的框架或语言，AI可以瞬间生成一个可运行的项目骨架。这让我能更快地进入"修改而非创建"的状态。
第二，加速学习。 让AI解释一段看不懂的代码，或者让它用不同方式实现同一个功能，这种方式比读文档高效得多。
第三，处理不想做的事。 写单元测试、写文档、写配置文件——这些是正确但无聊的工作。AI很擅长做这些，而且做错了也无伤大雅。
第四，作为思维碰撞的伙伴。 有时候我卡在某个设计问题上，会让AI提供三种不同的实现方案。即使它的方案都不能直接用，但看到不同的思路往往会启发我找到更好的方案。
结语
我仍然每天用AI写代码。
但我不再相信"AI能替代程序员"这种说法了。至少在今天，AI更像是一个极其好用但需要严格监督的实习生——它能快速完成大量工作，但你得为它的每一个输出负责。
那个写了1000行代码的夜晚确实很爽。但真正让我进步的，不是AI写了多少行代码，而是我在修复那1000行代码时学到的东西：什么时候信任AI，什么时候不信任，以及如何从AI的输出中找到真正的价值。
这可能就是2026年一个普通程序员应该有的自我修养。
如果你也有类似的经历，欢迎在评论区分享你的AI编程踩坑故事。
💬 评论
0