管理层眼里的AI vs 我们眼里的AI
管理层眼里的AI vs 我们眼里的AI
序
这篇文章憋了很久了,直到看到一个视频焕然：
越用AI越累？跟踪16名程序员后，揭开可怕的“生产力幻觉”！你以为AI让你效率翻倍，其实你变慢了19%！
想说的话太多了，不知道从哪开始。
事情的起因是这样的——某天开周会，领导突然很兴奋地说：
"我看了一个视频，说AI现在能自动写代码了，以后我们团队效率能提升10倍！大家赶紧学起来！"
然后PPT里放了一张图，上面写着"AI赋能"、"降本增效"、"智能升级"三个大字。
我当时坐在下面，表情大概是那种你看着一道明显做错了但不知道该不该指出来的数学题的感觉。
AI提效10倍？你说的哪个AI？提的是谁的效？提的是什么效？
这些问题的答案，他不知道。但他也不需要知道，因为他有抖音。
营销号是怎么吹的
先说说那些AI营销号都在吹什么。
打开短视频平台，搜"AI编程"，你能看到以下经典话术：
"AI将取代80%的程序员！"
"不会用AI的程序员将被淘汰！"
"一个人+AI = 一个开发团队！"
"AI写代码比我写的好100倍！"
"未来只需要产品经理，不需要程序员了！"
每条视频点赞过万，评论区全是"太对了"、"赶紧学"、"焦虑了"。
但如果你真的写代码，你就知道这些话有多离谱。
AI能取代80%的程序员？ 那请问Bug谁来修？线上出了故障谁去排查？数据库慢查询谁去优化？AI能帮你定位一个因为时区问题导致凌晨三点系统崩溃的Bug吗？
一个人等于一个开发团队？ 理论上可以。但前提是这个人既懂数据库又懂前端又懂运维又懂业务。AI能帮你写代码，但不能帮你理解为什么客户一定要在那个奇葩的日期格式里显示农历。
AI写代码比人好100倍？ AI写的代码，跑是能跑。但你敢让AI写一个涉及资金交易的支付模块吗？你敢让AI写一个涉及用户隐私的数据导出接口吗？出了线上事故，你去找AI追责？
这些营销号最擅长的事情就是把AI的能力无限放大，把AI的局限只字不提。
因为他们不是做技术的，他们是做流量的。
老板是怎么想的
营销号吹完了，信息传递到老板那里，就变成了另一种东西。
营销号说的:
"AI能提升开发效率"
老板听到的:
"AI能让开发团队少招一半人"
营销号说的:
"AI能自动生成代码"
老板听到的:
"以后不需要高级工程师了，招实习生+AI就行了"
营销号说的:
"AI是未来趋势"
老板听到的:
"赶紧搞AI，别的公司都在搞，不搞就落后了"
于是就出现了一系列骚操作。
骚操作一：全员学AI，KPI里加一条
突然有一天通知：从下季度开始，所有人的KPI里加一条"AI工具使用率"，每个人每周必须用AI工具完成多少工作量。
不是，你先告诉我"AI工具使用率"怎么量化？
是看我在ChatGPT上问了多少问题？还是看我用Copilot补全了多少行代码？还是看我在Claude Code里跑了多少条命令？
我一天用AI问了10个问题，9个是"怎么写正则表达式匹配邮箱"，1个是"这道LeetCode用动态规划怎么做"。请问这算不算AI提效？算的话提了多少效？
把AI当KPI，就像把"百度搜索次数"当KPI一样荒谬。
工具是拿来用的，不是拿来凑指标的。
骚操作二：AI项目一拥而上
领导在某个AI大会上被灌了一通迷魂汤，回来就要搞"AI智能化转型"。
然后一个月内同时启动了三四个AI项目：
- AI智能客服（没人评估过现有客服系统的接口能不能对接）
- AI代码审查（没人想过代码安全性和模型合规性的问题）
- AI需求分析（没人知道大模型对业务需求的理解准确率有多低）
每个项目都要在一季度内出成果。
结果？ 三个月后，每个项目都产出了一个Demo。Demo很酷，PPT很漂亮，汇报很成功。
然后？没有然后了。
没有一个项目真正落地。因为Demo和生产的距离，比PPT和代码的距离还远。
骚操作三：降本增效——主要是降本
"AI赋能，降本增效"——这句话里，重点永远在"降本"，不在"增效"。
领导算了一笔账：
一个高级工程师: 月薪3万
一个AI工具订阅: 每月200块
结论: 裁掉高级工程师，买AI工具，省下29800！
这个逻辑的漏洞大得能开卡车。
AI工具省的是重复性编码的时间，不是思考、设计、决策的时间。
一个高级工程师的价值不在于他手打代码有多快，而在于他知道该写什么代码、不该写什么代码。
这种判断力，AI目前给不了。
骚操作四：不懂技术的人指挥技术选型
最让人无语的场景：一个连API和ABI都分不清的管理层，在技术选型会上拍板决定用哪个AI框架。
"我听说LangChain很好，我们用LangChain吧。"
——大哥，我们是Java技术栈，LangChain是Python的。
"那用Java版的LangChain4j。"
——你确定？我们的项目用的是Spring Boot 3.4，LangChain4j的某些版本和Spring Boot有冲突。
"版本问题你们开发自己解决嘛，不要纠结这些细节。"
……好的，你开心就好。
技术选型是一件非常严肃的事情。它需要考虑现有技术栈的兼容性、团队的技术能力、社区活跃度、文档完善度、长期维护成本。这些都不是看两篇公众号文章就能判断的。
我们一线开发眼里的AI
吐槽完了，说说我们一线开发的真实感受。
AI到底提效了多少
以我自己为例，我每天的工作大致分为几类：
| 工作内容 | 占比 | AI提效幅度 | 备注 |
|---|---|---|---|
| 写CRUD代码 | 20% | 70-80% | AI写增删改查确实快 |
| 调试Bug | 20% | 30-40% | 能帮忙分析报错，但定位还是靠人 |
| 系统设计 | 15% | 10-20% | 能给参考方案，但决策靠自己 |
| 代码Review | 10% | 40-50% | AI做初筛很好用 |
| 开会/沟通 | 15% | 0% | AI帮不了你和产品经理吵架 |
| 写文档 | 10% | 50-60% | AI生成草稿，人做修改 |
| 环境部署 | 10% | 20-30% | 能帮忙写脚本，但环境问题还是靠人 |
综合下来，AI整体提效大概在30-40%左右。
注意，这是在我已经熟练使用AI工具的前提下。而且这个提效主要体现在"写代码"这个环节上。如果算上沟通、开会、思考这些AI帮不上忙的部分，实际提效更低。
10倍？不存在的。1.5-2倍是比较合理的估计。
而且提效不是线性的。简单任务提效很多，复杂任务提效很少：
任务复杂度 vs AI提效:
────────────────────────────────────
简单CRUD: ████████████ 80%提效
中等需求: ████████ 50%提效
复杂Bug修复: ████ 20%提效
架构重构: ██ 10%提效
系统设计: █ 5%提效
────────────────────────────────────
越复杂的任务，AI能帮的越少。而越复杂的任务，往往才是最有价值的。
graph LR
A["简单CRUD<br/>AI提效 80%"] --> B["中等需求<br/>AI提效 50%"]
B --> C["复杂Bug修复<br/>AI提效 20%"]
C --> D["架构重构<br/>AI提效 10%"]
D --> E["系统设计<br/>AI提效 5%"]
style A fill:#4CAF50,color:#fff
style B fill:#8BC34A,color:#fff
style C fill:#FFC107,color:#333
style D fill:#FF9800,color:#fff
style E fill:#F44336,color:#fff
AI的优点（我们用着舒服的地方）
1. 写重复性代码
这是AI最擅长的。实体类、DTO转换、CRUD接口、MyBatis Mapper——这些模板化的代码，AI写得又快又准。
以前写一个增删改查模块要半天，现在10分钟搞定。
2. 解释报错
把一段报错日志丢给AI，它能快速告诉你可能的原因。比自己Google半天效率高多了。
特别是那些晦涩的异常栈，比如Netty的内存泄漏告警、Spring的Bean循环依赖，AI的解释比官方文档还清楚。
3. 快速原型
想验证一个技术方案可不可行，让AI先写个Demo跑一下。不行就换一个方案，试错成本极低。
4. 补全知识盲区
比如要写一个正则表达式、要处理一个时区转换、要解析一个复杂的JSON——这些"不需要记住但用到时要查"的知识，AI直接给你答案。
AI的缺点（营销号不会告诉你的）
1. 幻觉——AI会一本正经地胡说八道
这是最可怕的。AI不是"不知道然后告诉你不知道"，而是"不知道但编一个看起来很像对的答案"。
你: "这个接口为什么返回500？"
AI: "根据错误信息分析，这是因为Spring Boot的自动配置
和你手动配置的DataSource产生了冲突。建议在
application.yml中添加 spring.autoconfigure.exclude
= org.springframework.boot.autoconfigure.jdbc
.DataSourceAutoConfiguration"
你: "可是我的项目没有用DataSource啊？"
AI: "您说得对，让我重新分析。可能是..."
第一次回答的时候，语气笃定得像个十年经验的老工程师。但实际上它在胡扯。
如果你自己不懂，你根本分辨不出AI的回答是真是假。
这才是AI最大的风险。不是它不会，而是它不会的时候不会告诉你它不会。
2. 上下文丢失——聊多了就忘了前面的
AI的记忆是有长度限制的。当对话超过一定轮数后，它就开始忘记前面说过的话。
你花了一个小时教它项目的架构规范，到第十个问题的时候，它已经把你的规范忘得差不多了，又开始按它自己默认的方式写代码。
3. 安全风险——代码不能直接上生产
AI生成的代码，必须经过人工Review。不是因为它写得不好，而是因为你不知道它有没有在某个角落引入了安全漏洞。
SQL注入、XSS、敏感信息硬编码、不安全的反序列化——这些安全问题AI有时候会注意到，有时候完全忽略。
4. 无法理解业务
这是最根本的问题。AI理解的是代码，不是业务。
它不知道"这个字段在财务系统里代表金额，不能为负数"。 它不知道"这个接口是给第三方调用的，字段命名要和合同文档一致"。 它不知道"这个功能下个月要下线了，不要花太多时间优化"。
这些业务上下文，只有参与项目的人才知道。
5. 环境问题永远得自己搞
AI能帮你写代码，但帮不了你解决"为什么本地跑得好好的部署到服务器就报错"这种问题。
环境变量不对、端口被占用、DNS解析失败、证书过期、磁盘满了——这些运维层面的问题，AI只能给你建议，最终还得你自己上服务器排查。
真正该做的事
吐槽归吐槽，AI确实在改变开发方式。但正确的打开方式不是看营销号，而是：
对管理层
- 先了解再决策。不要看了两篇公众号文章就拍板技术方案。找一线开发聊聊，他们比你更清楚AI能做什么不能做什么。
- 给时间不给KPI。与其把AI使用率写进KPI，不如给团队时间探索AI工具。真正有效的使用方式，是开发者在工作中自然发现和沉淀的。
- 降本不是裁员。AI提效省下来的时间，应该用来做更有价值的事——重构技术债、优化性能、完善监控。而不是把人裁了。
- 少开点AI大会。那些卖课的、卖工具的、卖焦虑的大会，真的没什么用。不如让团队做一次内部技术分享，比什么大会都实在。
对一线开发
- 学AI不是为了不被淘汰，是为了让自己更值钱。AI是工具，用好了是加分项，不用是减分项。
- 警惕AI的输出。永远不要盲目信任AI生成的代码。Review、测试、验证，一个都不能少。
- 关注核心竞争力。写代码越来越不值钱了，系统设计、问题排查、业务理解这些能力越来越值钱。把AI省下来的时间花在这些地方。
- 保持独立思考。AI给的方案不一定是最优解。它给出的往往是"最常见的做法"，但不一定是"最适合你项目的做法"。
最后
说一千道一万，AI就是一个工具。
锤子很厉害，但你不能指望锤子帮你设计一栋楼。
AI很厉害，但你不能指望AI帮你理解一个几十人开发了两年的项目为什么在这里用了策略模式而不是if-else。
工具在进化，但使用工具的人才是核心。
那些营销号不会告诉你的是：真正让AI发挥价值的，不是AI本身，而是懂技术、懂业务、懂架构的人在正确的地方使用AI。
AI不是魔法棒，是放大镜。它能放大你的能力，但前提是——你得先有能力。
否则AI只会放大你的错误。
让那些不懂技术但热衷AI的管理层看到这篇文章的话，可能会不太高兴。
但说实话，该说的总得有人说。