程序员实测：AI写代码究竟靠不靠谱

程序员眼中的AI编程靠谱吗？真实体验

前几天有个朋友跟我抱怨，说他们组来了个新人，第一天就靠 Cursor 生了三百行代码，还自信满满地提了合并请求。

前几天有个朋友跟我抱怨，说他们组来了个新人，第一天就靠 Cursor 生了三百行代码，还自信满满地提了合并请求。代码跑通没报错，逻辑也看着顺，可 senior 工程师在 code review 时盯着看了十分钟，发现有个边界条件处理错了，那个 bug 只有在高并发下才会触发，平时测试根本发现不了。实习生自己也没意识到问题，因为他压根没搞懂那块业务逻辑。

这事儿让我明白，关于“AI写代码靠不靠谱”，业内一直有争议。有人觉得 AI 让效率翻倍，有人觉得是定时炸弹。其实两边都对，只是描述的是同一头大象的不同部位。

要想看清 AI 写代码这事儿，得把它拆开来看。

先说 AI 真正厉害的地方。问问重度用 GitHub Copilot 或 Cursor 的工程师，他们都会承认，写样板代码（boilerplate）的速度快了一倍不止。一个 REST API 的增删改查，一个标准的数据库连接池初始化，一段正则表达式，一个记不住参数顺序的标准库调用，AI 在这些地方表现得很稳。这类代码特点是模式固定，上下文需求低，错了也容易改。程序员原本花在查文档、复制粘贴、处理语法细节上的时间，AI 直接压缩了，这是实实在在的效率提升。

GitHub 官方做过调研，用 Copilot 的开发者完成特定任务速度显著提升，满意度也高。数据虽有自证之嫌，但看各大技术论坛反馈，大方向一致，没人说 AI 写 CRUD 帮了倒忙。

但问题在于，代码库里不光有 CRUD。

任务复杂度一上来，AI 表现就开始飘忽。我说的复杂不是算法难，而是业务逻辑复杂。比如给一个跑了五年的金融系统加功能，你得懂那些奇怪的设计决策为啥存在，得知道多余的校验是为了应对监管，得清楚改动会不会影响下游三个系统。这些 AI 不知道。它只能看到你喂给它的上下文窗口，那些散落在会议纪要和口口相传里的隐性业务知识，根本不在窗口里。

这时候 AI 生成的代码，表面语法正确、逻辑流畅，其实是在对着残缺的需求做猜测。那种猜对表面逻辑但错边界条件的代码，比直接报错的代码危险，因为它会悄悄过测试，在生产环境埋雷。

还有一个少被正面讨论的问题：AI 会让人变懒。

这话听着扎心，但我是认真的。习惯了 AI 补全，肌肉记忆会退化，更糟的是，对代码的理解从“知道为啥这么写”退化成“AI 给的，跑着就行”。这个认知退化很隐蔽，短期效率高，长期在丢“代码直觉”。

老工程师厉害不只是写快，是看一眼就知道哪不对，那种直觉是写错、调试、重构磨出来的。如果大量编码被 AI 代劳，这个磨炼过程就跳过了。对初级工程师尤其危险，能用 AI 辅助学习，不能替代学习。

说到底，AI 写代码靠不靠谱，看使用者水平。

这话不是废话。高级工程师用 AI，能精确描述问题，判断输出合理，识别隐藏错误，做有意义改造。他是放大能力。初级工程师用 AI，不确定需求边界，没经验验证，容易被“看起来对”的代码糊弄。他是掩盖能力缺口。

业内有个非正式说法叫“AI 让强者更强，让弱者更脆”。Anthropic、OpenAI、Google 的模型在进化，代码能力变强，但本质是放大镜。判断力越强，放大效果越好；判断力越弱，放大混乱。

回到那个实习生故事。

那个 bug 虽然发现，系统没出事，但让我觉得，AI 写代码不该用“靠不靠谱”二元框架判断。更准的问法是：什么场景、什么水平的人、做什么任务，靠谱程度才具体。

•工具无对错，使用方式分高下。那些把 AI 当提效神器的，无一例外是先变强再用 AI 加速。顺序反了。

下次开 Cursor 或 Copilot，不妨在 AI 补全前，先想清楚要什么。那个想清楚的过程，才是你真正不可替代的地方。

下次开 Cursor 或 Copilot，不妨在 AI 补全前，先想清楚要什么。那个想清楚的过程，才是你真正不可替代的地方。