公司要求所有人用AI写代码，3个月后发生了什么

去年年底，我们公司推了一个要求：研发团队全员使用AI辅助编程工具，工具费用公司报销，KPI维度加上"AI使用频次"。

我当时的第一反应是：这是不是有点形式主义？

三个月之后，我改变了看法——但改变的方向，和我预期的不一样。

推广前三周：声势很大

第一周开全员会，工具演示，各种demo跑一遍，大家看起来都挺激动。

"这个好，以后再也不用写重复代码了。"

"这个生成的测试代码比我写的还规范。"

实际上前两周，大家确实都在用，因为新鲜，因为KPI的要求，因为领导在看。

三个月后：分化开始出现

三个月之后，再看团队里的使用情况：

一批人用着用着，越来越依赖。

这些人AI用得很顺，产出速度明显快了。但一旦AI给出来的代码不对，他们有时候不知道为什么不对，只能继续让AI改。陷入"AI改 → 我不满意 →AI再改"的循环，比自己动手还慢。

有个同事做了一个表单校验功能，来回七八轮还没对，最后我过去看，是一个对Java Stream的理解问题，自己写三十行代码解决。但他不熟悉这块，不知道怎么给AI描述，也没有办法判断 AI给的方案哪里有问题。

一批人用着用着，用出了自己的节奏。

这些人主要把 AI用在"有明确答案"的事情上：查API用法、生成单测、补注释、整理文档草稿。

他们很少让AI写核心逻辑——因为核心逻辑往往和业务场景强绑定，AI不了解背景，生成出来的东西还要大改，不如自己写。

这批人的整体产出质量提升了，代码review的问题也少了。

一批人基本没变。

这部分人用了几周发现"我写得也不慢啊"，就没再深入用了。KPI有要求，他们就每天开着工具，问几个不重要的问题，完成指标。

有一件事出乎所有人意料

三个月后，有一次技术复盘，leader发现了一个现象：

junior的代码量增加了，但bug率没有明显下降，甚至有些指标略有上升。

分析之后大概有这样几个原因：

1. 1. 代码量上来了，但自己没看懂就提交了——AI写的，能跑，看起来对，就合进去了
2. 2. 边界条件、异常处理这些，AI不主动加，junior也不知道要问
3. 3. 代码review能力没有随着代码量一起成长——因为核心逻辑是AI给的，自己没有深度参与

这个问题不是AI的问题，是 使用方式 的问题。

后来团队做了一个调整：对junior的要求是，AI生成的代码，必须能向reviewer解释每一段逻辑，不能说"AI给的，我觉得应该对"。

这一条规则落地之后，junior的代码质量明显回来了。

我对"全员AI化"的真实看法

AI工具本身是中性的。 它让强的人更强，让弱的人有时候更乱。

决定结果的不是"用没用"，而是"怎么用"。

有几个观察：

AI放大了认知差距，而不是缩小了。 你越理解一个技术领域，越能给AI写出准确的prompt，越能判断它给的方案对不对。反过来，越不熟悉，越难用好。

AI不能替代"问问题"的能力。 很多人用AI卡住，不是因为AI不够强，是因为不知道怎么把自己的问题描述清楚。这个能力本质上是技术理解力，AI没法帮你建立。

强制推广效果有限。 用AI最后真的有效率提升的，大多是主动探索的那批人，不是被要求用的人。

三个月，我自己的变化

三个月下来，我觉得AI改变了我的工作节奏：

• • 查技术问题不搜Google了，直接问AI，省了30%-40%的查资料时间
• • 写测试代码的心理负担小了，让AI搭架子，自己补逻辑
• • 会议纪要、技术文档初稿，先让AI出骨架再填内容

但没变的是：

• • 核心方案的设计，AI只是讨论对象，不是决策者
• • 代码review还是自己来，不信任"AI说没问题"

三个月，AI没有让整个团队"突然变强"，但它让那些原本就愿意琢磨的人，节奏快了一截。

工具是工具。会用的人，用一把锤子也能盖房子。不会用的人，给再好的工具也只是装装样子。

• • 不要只考核使用次数，要考核用后的产出质量
• • 对junior明确要求：能解释AI给的代码，不能盲目合入
• • 整理一份团队级prompt规范，减少"风格不统一"问题
• • 定期分享"AI踩了什么坑"，比"AI很厉害"更有价值
• • 核心业务逻辑review不能省，AI不了解你的业务背景