AI 时代工程师的成长把能力拆回可练习的工作“会不会用 AI”不是足以衡量工程能力的问题。模型可以加快查资料、起草代码和整理日志但交付仍依赖需求理解、接口边界、验证方式与责任意识。与其构造抽象能力模型不如把成长目标落在日常工作可观察的动作上。先练清楚问题的能力拿到一个需求时先写出用户、输入、输出和不能破坏的约束。比如为后台任务加批量接口问题不只是“如何并发”还包括幂等键放在哪里、部分失败怎样返回、旧客户端是否仍能调用。能把这些问题列出来比立刻让模型生成一段实现更能减少返工。AI 工具可用于提出遗漏项但回答必须回到项目事实现有 API、数据模型、测试和发布流程。不要把模型给出的库版本、命令或性能结论直接贴进设计文档先在受控环境验证再注明适用条件。代码能力仍然包含阅读和取舍阅读陌生模块时可以让工具概括调用链但应自己打开关键实现确认。特别是权限、资金、删除数据和并发控制相关代码摘要常会漏掉默认值和失败分支。评审意见也应具体到行为哪个输入会走错分支、哪项测试缺失、回滚会影响什么而不是只说“建议优化”。写代码后把验证拆成小步骤格式化与类型检查、目标单测、异常输入、兼容路径。模型生成的测试尤其要检查断言是否真正覆盖了风险而不是只验证 mock 被调用。对耗时任务再观察日志和资源曲线但不应从一次本地运行推出通用性能结论。协作能力体现在可交接工程师的产出需要让别人接得住。提交说明写明改动范围和验证命令设计记录保留未决问题事故复盘区分事实、推测与后续动作。借助 AI 整理会议或日志时原始链接和关键信息仍需人工核对避免总结把猜测变成结论。新人可以从维护一个小模块的文档和测试开始逐步参与评审与发布经验更丰富的人则要学会将隐性的排查路径写出来。两者都不是某次课程或某个工具能替代的。模型改变的是获取候选方案的速度。工程能力的核心仍是选对问题、验证结果并对上线后的影响负责。可以为自己保留一份小型成长记录本周处理了什么不确定问题使用了哪些证据哪些判断后来被推翻。它不是绩效报表而是帮助下一次估算风险和选择验证方式。长期看来这种复盘比收集工具清单更能暴露能力缺口。团队带教也应让新人看到失败路径。让其参与一次回滚演练、一次异常输入测试或一次评审讨论比只展示最终代码更接近真实工作。AI 可以协助生成练习素材但练习结论仍须由项目约束来校验。不同岗位也可选择不同练习重点偏平台的同学关注发布与可观测性偏业务的同学关注领域约束与兼容性。共同点是把假设写下来再用实际代码和数据验证。当结论不够确定时明确写出下一步要补的日志、测试或访谈而不是用模糊措辞结束讨论。能管理不确定性本身就是工程训练的一部分。这也使协作更直接。记录过程中的反问和修正也能帮助后来者理解取舍。
