过去一年，AI 的角色正在悄然发生变化。
它已经不再是：
- 新鲜玩具
- 额外插件
- “会不会用”的分水岭
而是逐步演变为——基础设施的一部分。
在这个背景下，一个问题变得越来越重要：
当 AI 成为默认存在，工程师真正的竞争力到底是什么？
⸻
一、从“会不会用 AI”，到“用 AI 做什么”
早期讨论 AI 时，核心问题往往是：
- 会不会写 Prompt
- 用没用过大模型
- 有没有接入 API
但现在，这些已经快速变成“默认技能”。
在掘金社区里，你会发现：
- 写代码用 AI，是常态
- 查资料用 AI，是习惯
- 辅助写文档、写测试，也已普及
真正的差距，不再体现在“有没有用 AI”，而在于：用 AI 解决什么层级的问题。
⸻
二、AI 对工程流程的真实影响，而非想象中的“替代”
从实际工程实践来看，AI 对开发流程的影响，主要集中在三层。
1️⃣ 执行层：重复性工作显著减少
这是最直观的变化：
- 模板代码生成
- 单元测试初稿
- 文档、注释补全
这部分确实节省了大量时间，但本质上只是效率放大器。
⸻
2️⃣ 结构层：系统设计讨论成本降低
更有价值的是第二层。
当你让 AI 参与：
- 架构方案对比
- 模块拆分建议
- 边界条件分析
像 ChatGPT 这样的模型，往往能在“第二视角”上提供补充。
但注意：
AI 并不负责正确性，它只负责“可能性”。
⸻
3️⃣ 决策层：AI 仍然无法替代人
这是很多人容易误判的地方。
在涉及：
- 技术选型
- 风险取舍
- 成本与周期平衡
AI 给出的内容，只能作为参考输入，而不是决策输出。
工程决策，依然高度依赖经验、上下文与责任归属。
⸻
三、为什么有些工程师“越用 AI 越乱”？
在实践中，一个现象非常普遍：
使用 AI 后，信息更多了，但决策更慢了。
原因通常不在 AI，而在三个能力缺失：
❌ 问题建模能力不足
AI 非常依赖输入质量。
如果问题本身是：
- 模糊的
- 混杂多个目标
- 没有约束条件
那么输出必然是“看似全面，实则难用”。
⸻
❌ 结果评估能力不足
AI 给出的方案：
- 结构完整
- 语言自洽
但工程问题的关键从来不是“是否说得通”，而是：
- 是否符合当前系统约束
- 是否符合团队能力
- 是否符合上线周期
⸻
❌ 缺乏快速收敛的能力
AI 擅长扩散思路，但不擅长收敛。
如果工程师本身：
- 不敢拍板
- 依赖“再问一次 AI”
那么效率反而会下降。
⸻
四、AI 时代，工程师能力的“迁移方向”
如果总结一个清晰趋势，那就是：
价值正在从“写代码”迁移到“定义问题”。
具体体现在四个方面：
1️⃣ 抽象能力 > 语法能力
AI 可以写语法，但无法替你：
- 确定模块边界
- 定义接口职责
- 判断复杂度是否合理
⸻
2️⃣ 系统视角 > 局部最优
AI 很容易给出“局部最优方案”， 但工程实践中，往往需要牺牲局部性能，换整体稳定。
⸻
3️⃣ 风险意识 > 完美实现
很多 AI 生成的代码：
- 看起来很优雅
- 但忽略异常路径
真正成熟的工程师，关注的是：
“最坏情况下会发生什么？”
⸻
4️⃣ 沟通与解释能力正在升值
当 AI 负责生成内容后，人反而需要：
- 向非技术角色解释方案
- 向团队说明取舍逻辑
- 为决策承担责任
⸻
五、AI 更适合嵌入流程，而不是替代流程
一个成熟的使用方式是：
- 把 AI 放进固定节点
- 而不是随意调用
例如：
- 设计评审前，用 AI 做一次方案扫描
- 重构前，让 AI 列出潜在风险点
- Code Review 前，用 AI 做初步检查
这样，AI 才是“流程增强器”，而不是“干扰源”。
⸻
六、工具层面的变化，正在趋于“无感化”
值得注意的是，越来越多开发者开始减少工具切换。
例如：
- 不关心具体模型
- 更关注是否能快速调用
- 是否能在一个环境完成任务
这也是为什么一些聚合式工具（如 gpt1998）开始出现—— 它们并不强调“能力更强”，而是降低上下文切换成本。
⸻
七、写在最后：AI 不会降低工程门槛，只会提高下限
一个现实但重要的判断是：
- AI 让入门更容易
- 但让中高级工程师的要求更高
当代码不再是稀缺能力， 判断、设计与责任，反而变得更重要。
我会在公众号【AI效率引擎】中，持续记录一些工程实践中“AI 介入的正确姿势”，更多是流程与思维层面的总结，而不是具体工具推荐。
工具会持续演进，但工程的本质并没有变。 变化的，只是我们如何与工具协作。
