掩耳盗铃也改变不了 AI 写代码比你又快又好的事实
2026 年年初，互联网上的程序员们还在争论要不要在工作流中引入 AI。到了年末，我想已经很难找到完全没有用过 AI 的程序员了，甚至大部分程序员应该都已经在完全依靠 AI 写代码了。
但我依然看到不少人觉得，AI 也就只能写写简单的代码，真正复杂的项目还得靠人。至于自己被 AI 替代？那更是天方夜谭。
在我看来，这只是无知带来的、作为人的傲慢。掩耳盗铃也改变不了 AI 写的代码比你写得又快又好的事实。
AI 写的代码不可靠吗？
有人可能会 argue：AI 写的代码无法确保正确性，万一上线出了问题，人也无法及时处理。
这个担忧我能理解。但你自己写的代码就能确保正确性吗？人类程序员写的代码，难道就不会有 bug，不会因为遗漏某个边界条件而在上线后出问题吗？我们做测试、做 code review，本来就是因为写代码的人也会犯错。
我觉得，很多人对 AI 的要求很奇怪：让它写一次代码，只要发现一个问题，就认定「AI 写的东西不可靠」；换成人类同事写的代码，发现问题却很自然地会提意见、要求修改，再继续测试。
这让我想到自动驾驶。如果有一天，自动驾驶汽车在相同条件下的事故率已经明显低于人类司机，那它即使偶尔还是会出事故，也应该逐渐取代人类驾驶。我们总不能因为看到一则自动驾驶事故的新闻，就要求它永远不能上路，却对每天发生的人为交通事故习以为常吧？评价 AI 写的代码也是一样：要看它在实际工作中犯错的情况，以及发现和修复问题的能力，而不是抓住它犯过的一次错，就断定人写的一定更可靠。
想象一下，你的团队来了一位计算机专业基础非常扎实、但对你们的项目一无所知的实习生。第一天，你会把一个需求扔给他，然后指望他什么都不问就写出完全符合团队规范的代码吗？你大概会先给他介绍项目，告诉他业务规则和代码习惯，review 他的实现，在他理解错的时候指出来。随着他越来越熟悉项目，他能独立完成的事情也会越来越多。
对待你的 AI 工作伙伴，你也可以用同样的态度。况且现在顶尖 AI 的能力，早已远不止一个初出茅庐的实习生。
比如你要实现一个订单处理功能，可以先让 AI 读相关代码和文档，把它对现有业务规则的理解讲出来，再开始动手。功能写完后，你不放心它是否考虑周全，就继续追问：用户连续点击两次怎么办？请求超时之后重试，会不会造成重复处理？操作失败后，数据会不会留在错误的状态？
然后让它根据这些要求独立编写并运行测试，解释每个测试用例的预期和结果，也说清楚还有哪些情况没有覆盖。如果测试发现了问题，再让它分析原因、修改代码并重新验证。这样来回几轮，原本只是「正常流程能跑」的功能，就有机会把你在意的异常情况也照顾到。
测试也不是写出来、跑绿了就万事大吉。你可以继续问它：这些测试有没有遗漏？测试本身是否和实现犯了同样的错误？让它再从另一个角度 review 一遍，或者根据需求独立检查测试。你对结果不放心，就把不放心的地方说清楚，让它继续验证。
如果你觉得它考虑得不够全面，或者代码写得不够好（当然，大多数情况下可能是你写得不如它好），也完全可以把发现的问题和自己的要求告诉它，让它继续修改。现在的 AI 完全能够理解这些要求。
我从 AI 身上得到的，远不只是写代码的速度
以我自己的体验来说，我现在甚至不需要使用最顶尖的模型。即便抛开 AI 实现新功能的速度，它帮我优化项目性能、发现 bug、增强测试覆盖、考虑到我之前完全没想到的 edge case，还会告诉我一些之前完全不懂的业务知识。这些收获已经远大于它犯错带来的问题。
做过实际项目的人应该都知道，很多问题并不是你坐在那里想一想就能发现的。一个功能的正常流程可能早就跑通了，但某个异常分支没人走过；一段代码平时看不出问题，数据量上来之后才暴露性能瓶颈；有些业务规则你以为自己已经理解了，直到有人问你「那这种情况呢」，才发现原来还有遗漏。
过去这些事情也可以靠人慢慢检查，只是人的时间和精力都有限。现在你可以让 AI 一遍遍地检查，可以要求它从性能、边界条件或者测试覆盖的角度重新看一遍。它不会因为「这段代码上周不是已经看过了吗」而不耐烦，也不会因为你改了需求就跟你抱怨。
当然，AI 确实不是万能的。它偶尔会犯错，偶尔也会「降智」，你也确实能发现它实现中的问题。但如果你是一位有耐心、真正做过产业项目的工程师，你也应该有耐心告诉它问题在哪里，以及你希望它怎么改。
不放心，就给它划清要求
如果你不放心它写代码的方式，可以要求它按照你原来的方式写，把项目的代码风格和约定告诉它。如果你不放心让它直接写生产业务代码，可以先让它独立写测试、review 代码，看它能发现什么。
如果你担心 AI 每次生成的结果不够稳定，也可以换一种方式：让 AI 写一个能生成稳定结果的确定性工具。比如同一批结构固定的数据需要反复转换，与其每次都让 AI 重新生成一遍，不如让它写好转换程序，再用测试验证这个程序。之后每次输入相同的数据，就由程序按同样的规则处理。
这些要求并不需要什么神秘的提示词。你平时怎么跟同事解释工作目标、约定验收标准，就可以怎么告诉 AI。它没理解，继续解释；它做错了，指出来让它改。相信我，现在顶尖的 AI 模型已经可以不知疲倦地发现比人工程序员更多的业务代码问题。
面试还在考手写算法？
当 AI 已经能够参与实际项目的开发，我再看一些公司的招聘要求，就觉得有些脱节了。它们还在强调程序员的「独立代码能力」。面试的时候照旧问八股文，甚至要求候选人现场手写算法题，而这些算法题可能连面试官自己在实际工作中都用不到。
想象一下，一个程序员白天在项目里跟 AI 协作，设计方案、实现功能、review 代码、修复问题；晚上准备跳槽，却要关掉所有工具，坐在那里默写一道工作中从来没遇到过的题。写不出来，就被认定为基础不扎实。
我觉得挺可笑的。当 AI 已经可以帮你完成绝大部分代码工作的时候，招聘还在考察脱离工具独立写代码的能力，就好比你要招一个司机，却先要求他证明自己能不能把汽车发动机拆开再装回去。
当然，我不是说计算机基础不重要。恰恰相反，基础越扎实，你越能理解 AI 给出的方案，越知道应该追问什么。只是背了多少八股、能不能在面试官的注视下手写出一道算法题，跟一个人能不能利用 AI 解决实际问题，恐怕已经越来越不是一回事了。要判断一个程序员能不能做好工作，也该看看他如何理解需求、提出要求、检查结果，以及处理真正的业务问题。
程序员应该做什么
说到用 AI 解决实际问题，不同的人使用同样的 AI，产出的质量可能有很大差异，因为每个人的核心能力圈不一样。面对同一个任务，有人满足于功能跑通了，有人会继续追问异常处理、性能和维护成本。两个人给 AI 的要求不同，最后得到的结果自然也不一样。
但我认为，同一个人使用 AI，一定比他不使用 AI 时产出的质量更好、速度更快。AI 是你能力的放大器，也是你能力的扩展器。你熟悉的领域，它能帮你做得更深入；你不熟悉的领域，它也能帮你打开思路，让你有机会接触到原本能力范围之外的东西。
目前的 AI 基本上还需要人来指挥干活，但我认为需要的人一定会越来越少。程序员也必须转变自己的角色，把自己放在规则制定者的位置上，去思考更抽象的工程问题：项目的代码结构和运行架构应该怎么设计？需求变化的时候，现有的设计能不能快速响应？团队里的工作怎么分配、怎么协作，才能让人和 AI 都发挥出更大的效率？
再往前走一步，还可以思考产品和业务特性应该怎么定义。毕竟，当实现一个想法所需要的时间越来越短，你要解决什么问题、为什么要解决这个问题，也就越来越需要先想清楚。