2025年2月，Andrej Karpathy提出"氛围编程"时明确划了边界：只适用于"用完即扔"的周末项目。但新手们正把它搬进生产环境——Stack Overflow数据显示，对人工智能准确性的信任度一年暴跌11个百分点，从40%跌至29%。
坑从哪来：一句话需求的三小时噩梦
我第一次用Cursor往真实项目里加功能，只敲了一行字："加个账单系统。"
两小时后，三个互相冲突的数据库表结构、两套不同的Webhook处理器，仪表盘对不上任何一端。我关掉提示框，打开记事本，亲手写下这套系统到底需要什么：哪些Stripe事件要监听、写进哪张表、路由怎么命名。
把这份笔记贴回去，二十分钟搞定。
问题不是提示词不够聪明，是太贵了——让AI在模糊需求里反复试错，比提前写清楚贵得多。
METR 2025年的随机对照试验印证了这个体感：经验丰富的开源开发者用AI工具处理真实GitHub issue，实际耗时反而增加19%，却自我感知提速20%。那19%的落差，就是"生成到一半才发现要澄清需求"的代价。
第一坑：把提示框当需求文档
新手的本能反应是直接开口："做个账单页面""加个用户邀请""重构这个模块"。输出看起来能用，直到你要扩展它。
解法：提示前先写一页规格说明书。输入什么、输出什么、错误状态、允许AI碰哪些文件路径。这不是官僚流程，是让AI第一次就做对的最低成本方式。
第二坑：编译通过就敢合并
CodeRabbit 2025年12月分析了470个真实GitHub PR：AI合写代码的正确性错误是人类独享PR的1.75倍，引入XSS漏洞的概率是2.74倍。这些bug不会出现在测试报告里，它们出现在客服工单和凌晨两点的告警电话。
AI代码的陷阱在于表面合规：编译通过、类型检查通过、明显测试绿。但错误藏在视线盲区——被静默吞掉的异常、错误的默认值、异步调用里的竞态条件、AI没考虑到的边界。
解法：接受前逐行阅读。如果你解释不清某行为什么存在，就不要让它进仓库。
第三坑：把AI当黑箱用
（原文未完整提供，此处基于已有信息继续）
第四坑：忽视长期维护成本
Karpathy的原话是"拥抱指数级效率，忘记代码存在"。但生产代码不能被忘记。周末项目的债务不会有人追讨，生产系统的债务会以技术债利息的形式复利增长。
当你用氛围编程堆出一个功能，却留下无法理解的抽象层和隐式依赖，六个月后的调试成本会吞噬当初节省的全部时间。
解法：每次提交前问自己——如果明天AI工具不能用，我能独立维护这段代码吗？
第五坑：混淆"能跑"与"该跑"
AI擅长生成看起来合理的代码，但不擅长判断业务逻辑是否合理。它不会告诉你"这个定价策略在欧盟违法"，也不会提醒你"这个用户流程违反了你们上周定的设计规范"。
解法：把AI输出当作草稿，不是终稿。业务规则的守门人必须是人。
核心判断：氛围编程的适用边界
这项技术的真正价值不在取代思考，而在压缩"从想法到可验证原型"的周期。把它用在探索阶段——验证需求是否存在、交互是否流畅、技术方案是否可行。
一旦进入维护周期，切换模式：规格先行、逐行审查、保留人类对业务规则的最终裁决权。生产环境的代码不是氛围，是契约。
热门跟贴