去年年底，我们公司推了一个要求：研发团队全员使用AI辅助编程工具，工具费用公司报销，KPI维度加上"AI使用频次"。
我当时的第一反应是：这是不是有点形式主义？
三个月之后，我改变了看法——但改变的方向，和我预期的不一样。
推广前三周：声势很大
第一周开全员会，工具演示，各种demo跑一遍，大家看起来都挺激动。
"这个好，以后再也不用写重复代码了。"
"这个生成的测试代码比我写的还规范。"
实际上前两周，大家确实都在用，因为新鲜，因为KPI的要求，因为领导在看。
三个月后：分化开始出现
三个月之后，再看团队里的使用情况：
一批人用着用着，越来越依赖。
这些人AI用得很顺，产出速度明显快了。但一旦AI给出来的代码不对，他们有时候不知道为什么不对，只能继续让AI改。陷入"AI改 → 我不满意 →AI再改"的循环，比自己动手还慢。
有个同事做了一个表单校验功能，来回七八轮还没对，最后我过去看，是一个对Java Stream的理解问题，自己写三十行代码解决。但他不熟悉这块，不知道怎么给AI描述，也没有办法判断 AI给的方案哪里有问题。
一批人用着用着，用出了自己的节奏。
这些人主要把 AI用在"有明确答案"的事情上：查API用法、生成单测、补注释、整理文档草稿。
他们很少让AI写核心逻辑——因为核心逻辑往往和业务场景强绑定，AI不了解背景，生成出来的东西还要大改，不如自己写。
这批人的整体产出质量提升了，代码review的问题也少了。
一批人基本没变。
这部分人用了几周发现"我写得也不慢啊"，就没再深入用了。KPI有要求，他们就每天开着工具，问几个不重要的问题，完成指标。
有一件事出乎所有人意料
三个月后，有一次技术复盘，leader发现了一个现象：
junior的代码量增加了，但bug率没有明显下降，甚至有些指标略有上升。
分析之后大概有这样几个原因：
- 1. 代码量上来了，但自己没看懂就提交了——AI写的，能跑，看起来对，就合进去了
- 2. 边界条件、异常处理这些，AI不主动加，junior也不知道要问
- 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不了解你的业务背景
热门跟贴