你的 AI 产出总是差点意思？问题可能不在模型，在你自己。
dev.to 上有一篇文章火了，标题很直白——"资深软件工程师怎么用 AI"。评论区炸了，因为作者说了一个很多人不想听但确实是真的话：
AI 只能放大你已经拥有的能力。乘数器乘以零，还是零。
买了个 Claude Opus 订阅，就开始觉得自己马上要革新软件工程了。这就好比你刚拿到驾照，就觉得自己和 Lewis Hamilton 的差距只是人脉关系。
我读完了全文和 13 条评论，觉得这篇文章的核心洞察值得每个在用 AI 写代码的人认真看看。
作者举了一个很直接的例子。
初级开发者这样问 AI：
"像 Jeff Bezos 一样思考，给我做一个电商应用，用户可以下单、结账、付款。要安全、不能被黑、要快。"
AI 愉快地生成了 4000 行代码。初级开发者庆祝，LinkedIn 又多了一篇"我用一个周末做了 Amazon"的帖子。
资深工程师这样问：
"创建一个
confirmCheckout()函数，接收cartId和userId，验证购物车仍然属于该用户，从数据库重新计算总价，在事务内创建订单，为每个商品预留库存，事务成功后向 Kafka 发布order.created事件。"
区别在哪？
资深工程师不是因为告诉 AI "像 Amazon 的资深工程师一样思考"而更强。他们更强是因为他们知道什么东西存在。
这是文章中最有洞察力的一句话。
没有人某天早上醒来说："你知道这个应用需要什么吗？分布式事件处理。"——如果他从来没听过分布式事件处理。
作者说他经常看到有人发 20 页的 prompt，企图改变整个行业，内容全是：
到这个程度，你不是在用 AI，你是在祈祷。
真正的资深工程师不需要写 20 页 prompt。他们需要的是：知道问题是什么，知道解决方案空间里有什么，然后把任务拆成 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 来扩展选项、攻击假设、生成一次性代码、或者解释不熟悉的技术领域。
这是文章中最扎心的观点。
当东西坏掉时：理解数据库的人修数据库，理解分布式系统的人修分布式系统，理解网络的人修网络。只知道怎么往聊天框粘贴 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 生成的代码和人类写的代码应该接受完全相同的验证标准。不是因为 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人工智能时代，转载请注明出处。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。