去年刚用上Cursor的时候，真的有种”我要失业了”的感觉——写个CRUD几秒钟的事，爬虫一句话搞定，正则表达式都不用自己想了。当时还发朋友圈说”这玩意再进化两年程序员真没活路了”。结果用了一年多，现在的感受完全变了：简单的活确实香，复杂场景基本靠自己，调试的时候想砸键盘。这不是错觉，是AI编程工具的底层机制决定的。
先说结论：AI是”概率最优解生成器”，不是万能程序员。它的核心能力是根据训练数据和你给的上下文，生成一个统计意义上”最可能正确”的代码。注意这几个关键词——训练数据，是它见过的代码模式；上下文，是你在prompt里给它的信息；最可能正确，不是”一定正确”，是”在大多数情况下看起来对”。这就解释了为什么写CRUD、写爬虫、写工具脚本特别快，因为这些模式它见过几百万遍；复杂业务逻辑就拉胯，因为你公司的业务规则它从来没见过；调试的时候原地转圈，因为它不理解你的系统，只能靠猜。
上下文窗口的限制，比想象中严重得多。现在的大模型都在吹自己上下文窗口有多大——100K tokens、200K tokens、甚至号称百万tokens。但实际用起来，这个”大”是打引号的。一个正经的业务系统，几十个模块、上百个文件、几万行代码是常态，这还不算配置文件、数据库schema、部署脚本、历史commit这些。全部塞进prompt？不可能。所以你只能给它”部分信息”，然后指望它基于部分信息推断出完整逻辑，这本身就是个不靠谱的事。更反直觉的是，塞太多反而更差。之前看过一个研究说，给模型更多上下文，效果不一定更好，有时候反而更差，因为信息太多模型会”分心”，忽略真正关键的部分。我自己遇到过这个坑：有次我把整个模块的代码都贴进去让它帮忙改一个bug，结果它改了一堆不相关的地方，真正的问题没动。后来我只贴了出问题的那个函数加调用链，反而改对了。还有个问题是长距离上下文经常被忽略，即使上下文里明明有相关的API定义或者类似代码，模型也经常”看不到”——特别是距离当前位置比较远的信息。这就解释了为什么改一个数据结构，它能改掉眼前的文件，但漏掉其他地方用到这个结构的代码。
业务逻辑这块它是真的不懂。代码层面的东西AI确实见过很多，但业务逻辑？对不起，你公司的那些规则它从来没见过。举个例子，你做一个电商系统，有个促销规则：”会员满100减20，但不能和新人券叠加，除非是双11期间”。这种规则训练数据里有吗？不太可能有一模一样的。你能在prompt里完整描述吗？很难，因为还有各种边界情况。它能自己推断出来吗？不行，它又不知道你们公司的促销策略。结果就是它给你一个”看起来像促销逻辑”的代码，但漏掉了”双11例外”这条，上线后客服被投诉电话打爆，你花一晚上排查。更麻烦的是那些隐性知识——这个接口要兼容老版本APP、这个字段在某些情况下可能为null、这个服务在高峰期会被限流、这个表的某些字段有历史遗留问题不能动。这些东西不在代码里，在你脑子里，或者在团队的口口相传里，AI怎么可能知道？
技术债这个事也挺坑的。AI写代码快，这是真的，但快带来的问题是你没有真正理解这些代码。刚开始不觉得，反正能跑就行。但几个月后需要改需求、加功能、重构的时候，问题就来了：这段代码为什么要这么写？不知道，AI写的。这个设计模式适合这个场景吗？不确定，AI选的。改这里会影响哪些地方？得查，因为不是自己写的。去年有个研究我印象很深，叫METR，他们找了一批有经验的开发者，让他们在大型成熟项目里用AI工具写代码，结果发现实际效率反而慢了将近20%，尽管这些开发者自己觉得快了20%。为什么会这样？因为写代码的时间确实省了，但Review AI输出的时间增加了，修复隐性bug的时间增加了，理解AI代码逻辑的时间增加了，调试莫名其妙问题的时间增加了，把这些加起来，净效率反而下降了。
调试难是我觉得AI编程最坑的地方，没有之一。你让它写代码，它写了。不对，你让它改，它改了。还不对，你再让它改，它改回去了……我遇到过最离谱的一次：让它修一个bug，它改了A。不对，再改，它把A改回去然后改了B。再改，它把B改回去又改了A。循环了三次我才发现这货在原地转圈。为什么会这样？因为它没有真正的理解，它只是在根据你的描述生成”看起来最合理”的代码。你说”这样不对”，它就换一种”看起来合理”的方式。但如果正确答案它没见过，它就只能在错误的圈子里打转。更麻烦的是它生成的代码你也没完全看懂，你信任它没仔细review就上线，炸了。这时候debug，你既要理解业务逻辑，又要理解它写的代码逻辑，还要理解它为什么会写成这样——难度直接翻三倍。
讲两个我自己踩过的坑，都是真事。
第一个是数据格式改动炸了三个地方。项目是一个微服务系统，用户地址原来是简单字符串，后来要支持国际化，改成嵌套结构。我让AI帮忙改数据结构，顺带更新所有涉及address的地方。AI干得挺利索，改了schema定义、改了主API的序列化、改了数据库ORM映射，看着像那么回事。但它漏了三个地方：某个老接口里的address校验没更新、消息队列消费者里还在用老格式、有个定时任务在同步address格式对不上。结果测试环境过了——因为测试用例没覆盖这些边缘场景——生产环境一上线，三个地方同时报错。更坑的是调试：日志显示”address字段为空”，但代码里明明有赋值。我查了两小时才发现是消息队列那边在用老key取值，取到的是undefined。这种跨模块跨文件的bug，AI真的很难处理，因为它不知道这些模块之间的依赖关系。
第二个是debug原地转圈。项目是一个订单系统，高并发下偶尔出现”扣了库存但订单失败”的问题。我把日志、代码、报错信息都贴给AI，让它帮忙定位。它的第一个答案是锁竞争问题，建议改用分布式锁，改了，没用。第二个答案是事务隔离级别不对，建议改成SERIALIZABLE，改了，还是没用。第三个答案是可能是异步队列延迟，建议加重试机制，改了，问题依旧。然后我发现它开始循环了——第四个答案又回到”锁竞争问题”。最后我自己排查才发现：是某个分仓服务的启动脚本里，初始化库存的默认值设错了。这个脚本不在代码仓库的主目录里，AI根本没”看到”过它。
说点数据吧，证明这不是我一个人的感受。复杂任务成功率很低，SWE-EVO这个benchmark专门测”软件长期演化”场景——需要改多个文件、跑上千个测试用例、维护版本兼容性的那种，结果SOTA模型的成功率只有百分之二十出头，相比之下单个简单issue的解决率能到百分之六七十，差距巨大。前面提到的METR实验也很有意思，有经验的开发者用AI工具实际效率慢了将近两成，但这些开发者自己觉得快了两成，也就是说AI给了一种”虚假的效率提升感”。还有个调查说百分之九十多的开发者表示不完全信任AI生成的代码，但只有不到一半的人每次都会认真review，这意味着一半以上的人明知道可能有问题但还是直接用了，问题早晚会暴露只是时间问题。
为什么”刚开始特别厉害”的感觉这么强？这个错觉不是幻想，是有原因的。刚开始用的时候你让它写的都是CRUD、工具脚本、样板代码这种，这类任务AI见过无数遍，当然写得又快又好。写完能跑立刻有成就感，少量错误你自己能cover住感受不到痛苦。而且很多人以为AI”懂代码”就是”懂你的系统”，实际上它只懂训练数据里的模式加你在prompt里给的信息，你的系统架构、业务规则、团队约定它一概不知。等你真正让它处理复杂场景的时候，这个认知差距就暴露了。
踩了这么多坑之后我现在的用法是这样的：把它当高级代码补全用，写一半让它补全比让它从零写靠谱得多，因为你给了上文它顺着写不容易跑偏。任务拆细每步验证，不要让它一口气写整个功能，拆成一个个小函数每个函数单独让它写写完自己review加测试，这样出问题也容易定位。核心逻辑自己写它写工具代码，业务核心逻辑、涉及钱和安全的代码我自己写，那些”正则怎么写”、”这个API怎么调”、”数据格式转换”这种活让它干，这类任务它又快又准而且出了问题影响也有限。上下文要精不要多，不要把整个代码库丢给它，只给当前改动需要的文件加相关的接口定义加明确的业务规则，信息太多它会分心太少它会乱猜这个度需要自己摸索。Review一定要做，不管它写得多像那么回事都要过一遍，特别是边界情况有没有处理、异常逻辑对不对、有没有用到不该用的全局变量或者硬编码、安全相关的校验有没有。别指望它Debug，它写的bug十有八九还是得你自己debug，让它改来改去不如你直接看代码找问题快，把日志报错上下文给它它能给你一些思路但最终定位问题还是得靠你自己。
这些问题短期内能解决吗？说实话很难。上下文限制是架构问题，Transformer的注意力机制决定了上下文越长计算量越大，虽然各家都在扩容量但”能塞进去”和”能有效处理”是两回事。业务逻辑是知识问题，除非你能把所有业务规则结构化地喂给它比如用RAG，否则它永远只能靠猜，而业务规则这东西很多时候连你自己都说不清楚。技术债是人性问题，AI让写代码变得太容易人就会偷懒不去理解，这不是工具能解决的。但也不是完全没希望，多Agent协作、RAG增强、更好的IDE集成这些方向都在发展，只是短期内复杂场景下AI编程的痛点不会消失。
说到底，AI编程是个效率放大器——你本身会写代码它让你写得更快。但它不是能力放大器，你不会的它帮不了你，复杂的场景还是得靠你自己。”刚开始觉得厉害用久了不行”不是你的问题，是这个工具的设计和现实任务的gap。认清这个，调整预期，把它用在合适的地方，才是正确的打开方式。
有类似体验的可以评论区聊聊，或者你有什么好用的prompt技巧、避坑经验也欢迎分享。
