AI 时代工程师的成长：把能力拆回可练习的工作

“会不会用 AI”不是足以衡量工程能力的问题。模型可以加快查资料、起草代码和整理日志，但交付仍依赖需求理解、接口边界、验证方式与责任意识。与其构造抽象能力模型，不如把成长目标落在日常工作可观察的动作上。

先练清楚问题的能力

拿到一个需求时，先写出用户、输入、输出和不能破坏的约束。比如为后台任务加批量接口，问题不只是“如何并发”，还包括幂等键放在哪里、部分失败怎样返回、旧客户端是否仍能调用。能把这些问题列出来，比立刻让模型生成一段实现更能减少返工。

AI 工具可用于提出遗漏项，但回答必须回到项目事实：现有 API、数据模型、测试和发布流程。不要把模型给出的库版本、命令或性能结论直接贴进设计文档；先在受控环境验证，再注明适用条件。

代码能力仍然包含阅读和取舍

阅读陌生模块时，可以让工具概括调用链，但应自己打开关键实现确认。特别是权限、资金、删除数据和并发控制相关代码，摘要常会漏掉默认值和失败分支。评审意见也应具体到行为：哪个输入会走错分支、哪项测试缺失、回滚会影响什么，而不是只说“建议优化”。

写代码后，把验证拆成小步骤：格式化与类型检查、目标单测、异常输入、兼容路径。模型生成的测试尤其要检查断言是否真正覆盖了风险，而不是只验证 mock 被调用。对耗时任务，再观察日志和资源曲线，但不应从一次本地运行推出通用性能结论。

协作能力体现在可交接

工程师的产出需要让别人接得住。提交说明写明改动范围和验证命令；设计记录保留未决问题；事故复盘区分事实、推测与后续动作。借助 AI 整理会议或日志时，原始链接和关键信息仍需人工核对，避免总结把猜测变成结论。

新人可以从维护一个小模块的文档和测试开始，逐步参与评审与发布；经验更丰富的人则要学会将隐性的排查路径写出来。两者都不是某次课程或某个工具能替代的。

模型改变的是获取候选方案的速度。工程能力的核心仍是选对问题、验证结果，并对上线后的影响负责。

可以为自己保留一份小型成长记录：本周处理了什么不确定问题，使用了哪些证据，哪些判断后来被推翻。它不是绩效报表，而是帮助下一次估算风险和选择验证方式。长期看来，这种复盘比收集工具清单更能暴露能力缺口。

团队带教也应让新人看到失败路径。让其参与一次回滚演练、一次异常输入测试或一次评审讨论，比只展示最终代码更接近真实工作。AI 可以协助生成练习素材，但练习结论仍须由项目约束来校验。

不同岗位也可选择不同练习重点：偏平台的同学关注发布与可观测性，偏业务的同学关注领域约束与兼容性。共同点是把假设写下来，再用实际代码和数据验证。

当结论不够确定时，明确写出下一步要补的日志、测试或访谈，而不是用模糊措辞结束讨论。能管理不确定性，本身就是工程训练的一部分。

这也使协作更直接。

记录过程中的反问和修正，也能帮助后来者理解取舍。