AI 是乘数器不是替代品：资深工程师和初级开发用 AI 的差距在哪
AI 是乘数器不是替代品：资深工程师和初级开发用 AI 的差距在哪
你的 AI 产出总是差点意思？问题可能不在模型，在你自己。
dev.to 上有一篇文章火了，标题很直白——"资深软件工程师怎么用 AI"。评论区炸了，因为作者说了一个很多人不想听但确实是真的话：
AI 只能放大你已经拥有的能力。乘数器乘以零，还是零。
买了个 Claude Opus 订阅，就开始觉得自己马上要革新软件工程了。这就好比你刚拿到驾照，就觉得自己和 Lewis Hamilton 的差距只是人脉关系。
我读完了全文和 13 条评论，觉得这篇文章的核心洞察值得每个在用 AI 写代码的人认真看看。
本文提纲
- 同一个 AI，完全不同的提问方式
- 你无法要求你不知道存在的东西
- 像用初级开发者一样用 AI
- AI 不消除技能需求，它暴露技能缺失
- 资深工程师的上下文预算花在验证上
- 最危险的模式：让同一个系统既生成又打分
同一个 AI，完全不同的提问方式
作者举了一个很直接的例子。
初级开发者这样问 AI：
"像 Jeff Bezos 一样思考，给我做一个电商应用，用户可以下单、结账、付款。要安全、不能被黑、要快。"
AI 愉快地生成了 4000 行代码。初级开发者庆祝，LinkedIn 又多了一篇"我用一个周末做了 Amazon"的帖子。
资深工程师这样问：
"创建一个
confirmCheckout()函数，接收cartId和userId，验证购物车仍然属于该用户，从数据库重新计算总价，在事务内创建订单，为每个商品预留库存，事务成功后向 Kafka 发布order.created事件。"
区别在哪？
资深工程师不是因为告诉 AI "像 Amazon 的资深工程师一样思考"而更强。他们更强是因为他们知道什么东西存在。
你无法要求你不知道存在的东西
这是文章中最有洞察力的一句话。
没有人某天早上醒来说："你知道这个应用需要什么吗？分布式事件处理。"——如果他从来没听过分布式事件处理。
作者说他经常看到有人发 20 页的 prompt，企图改变整个行业，内容全是：
- 小心一点
- 仔细检查
- 想深一点
- 再想深一点
- 像资深工程师一样思考
- 像 Netflix 的首席工程师一样思考
- 像 Linus Torvalds 巅峰时期一样思考
到这个程度，你不是在用 AI，你是在祈祷。
真正的资深工程师不需要写 20 页 prompt。他们需要的是：知道问题是什么，知道解决方案空间里有什么，然后把任务拆成 AI 能可靠完成的小单元。
像用初级开发者一样用 AI
作者见过最好的工程师不会把整个应用倒进 AI 然后祈祷最好的结果。他们用 AI 的方式，就像用一个靠谱的初级开发者：一次一个任务。
认证。校验。数据库 schema。Dockerfile。后台 worker。API handler。一块接一块。AI 不是在构建系统，工程师才是。
举个实际的例子：
❌ 不推荐的问法：
"读完我的整个代码库，分析每个文件，理解我的业务逻辑，
发现我的人生目标，然后创建完美的应用。"
✅ 推荐的问法：
"创建一个用 Drizzle 的函数，fetch users，join products，
join reviews，返回结果。"
"创建一个 Kafka publisher，发布 item_added_to_cart 事件。"
小任务，明确目标，容易 review，容易 debug，容易理解。最重要的是——你仍然记得什么被构建了，因为你实际参与了。
评论区 Alex Shev 补充了一个很好的观点：资深工程师的差距通常在于把 AI 放在工作流的哪个位置。经验不足的工程师让 AI 直接产出答案；资深工程师用 AI 来扩展选项、攻击假设、生成一次性代码、或者解释不熟悉的技术领域。
AI 不消除技能需求，它暴露技能缺失
这是文章中最扎心的观点。
当东西坏掉时：理解数据库的人修数据库，理解分布式系统的人修分布式系统，理解网络的人修网络。只知道怎么往聊天框粘贴 prompt 的人——开一个新对话，打字："为什么这个不工作？"
"AI 可以生成实现。它无法生成经验。而经验，是让你在实现不可避免地出问题时，知道该往哪里看的东西。"
— Mustafa ERBAY，资深基础设施工程师
评论区的 Mustafa ERBAY 说得更透彻：初级工程师看到生成的代码会问"它能跑吗？"资深工程师会问"这段代码对事务、一致性、故障恢复、并发、安全和可观测性做了什么假设？"
差距不是 prompt 技巧。差距是有没有一个关于系统在出错时如何行为的心智模型。
资深工程师的上下文预算花在验证上
评论区的 xulingfeng 说了一句精辟的话：
"资深和初级的差距不是知道更多 prompt——是知道 AI 什么时候在自信地犯错。资深工程师把上下文预算花在验证上，而不是生成上。"
这和上一篇文章（《别再给 Agent 喂原始数据》）的思路异曲同工：工具应该帮你测量，你来做判断。AI 帮你生成代码，你来做验证。
一个实际的验证清单：
| 验证维度 | 初级做法 | 资深做法 |
|---|---|---|
| 代码正确性 | "能跑就行" | 写测试用例，覆盖边界条件 |
| 安全性 | "AI 说安全就安全" | 检查 SQL 注入、XSS、权限边界 |
| 性能 | "看起来挺快" | 检查 N+1 查询、内存泄漏、连接池 |
| 事务一致性 | "没报错" | 检查失败回滚、并发竞态、幂等性 |
| 可观测性 | "console.log 一下" | 结构化日志、metrics、distributed tracing |
最危险的模式：让同一个系统既生成又打分
Alex Shev 在评论区点出了一个关键问题：
"危险的模式是让同一个系统既生成工作又评判工作，没有任何外部证据。AI 可以留在循环里，但最终检查需要具体的东西：测试、日志、用户行为、diff、或者在答案存在之前就写好的验收标准。"
这就是为什么资深工程师总是先写测试再让 AI 生成实现——不是 TDD 教条，而是你需要一个在 AI 回答之前就存在的判断标准。
一个实用的工作流：
- 先写验收标准：这个函数应该处理什么输入，返回什么输出，边界条件是什么
- 让 AI 生成实现：给清晰的接口定义，一次一个函数
- 用测试验证：跑测试，看 diff，检查是否符合预期
- 人工 review 关键路径：认证、支付、数据修改这些路径必须人看
- 监控上线后的行为：日志、metrics、告警
这个流程的核心是：AI 生成的代码和人类写的代码应该接受完全相同的验证标准。不是因为 AI 不可信，而是因为任何代码——不管谁写的——都应该被验证。
最后引用作者的一句话：
"别再跟着科技高管的 AI 预测当圣经了。记住，那些告诉你 AI 会取代地球上所有工程师的人，往往就是那些正在融几十亿美元来卖 AI 的人。我不是说他们错了，但如果一个汽车销售员告诉我需要买车，我至少会先看看他是不是站在 4S 店旁边。"
你用 AI 写代码踩过什么坑？评论区聊聊你的经验。觉得说得到位就点个赞，让更多人看到这个观点。
参考文档与链接
原始文章
- How Senior Software Engineers Use AI — dev.to 原文及 13 条评论讨论
AI 辅助开发最佳实践
- Anthropic: Claude Code Best Practices — Claude Code 官方最佳实践指南
- OpenAI: A practical guide to building agents — Agent 构建实践指南
- GitHub Copilot: Best practices — GitHub Copilot 使用最佳实践
代码质量与验证
- Google: Modern Code Review — Google 工程实践之代码审查指南
- Martin Fowler: Refactoring — 重构与代码质量经典资源
- OWASP Code Review Guide — 安全代码审查指南
Prompt Engineering 进阶
- Anthropic: Prompt Engineering — Claude prompt 工程官方文档
- OpenAI Cookbook — OpenAI 实践示例和最佳实践集合
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
浙公网安备 33010602011771号