AI 处理事故，工程师与系统逐渐脱节
随着 AI 系统越来越多地负责诊断和修复生产事故，许多工程师担心自己正在失去亲手理解并安全运维复杂软件所需的直觉。评论者将此类比为航空业的“自动化悖论”：当机器处理常规工作时，人类练习变少，面对罕见且高风险的故障时可能准备不足——尤其是在新一代工程师于 AI 介导的环境中开启职业生涯时。也有人反驳说，如果使用得当，AI 可以提高运维“下限”、加速排障，并让专家专注于架构与护栏，但前提是组织要有意识地投入培训、模拟，以及对自动化动作设置清晰边界。
AI 在事故与运维中的角色
- 许多人认为，LLM 在可观测、标准化系统（例如 Kubernetes、云基础设施）中的分诊已经比人类更强，能够迅速缩小根因范围。
- 也有人认为，任何由 AI 产生的改动本质上仍是人类可以检查的信息系统；真正棘手的事故仍然需要有能力的操作者。
- 有人担心“AI 把容易的工单都清掉了”，导致人类只剩下罕见、严重的事故，却没有足够的实战经验，这让人联想到航空业的自动化问题。
技能退化与系统直觉的流失
- 一个反复出现的主题是：使用 AI 感觉像“流沙”——它写代码、调试得越多，工程师对自己系统和代码的直觉把握就越弱。
- 资深工程师表示，看到同事在退化：直接跳到 AI，硬怼错误信息，失去调试纪律和架构思维。
- 最令人担忧的是初级工程师，他们可能永远建立不起基础，尤其是在时间压力和“用 AI，不然你就太慢”的文化下。
AI 生成代码与调试的质量
- 批评包括：过度工程化、冗长、重复且不一致的代码；会随着每次生成而变化的不稳定“库”；以及技术债的爆炸式增长。
- 也有人反驳说，在许多现有代码库中，LLM 的输出已经比平均人类代码更好，而且在有指导时，对重构/移植非常出色。
- 基准测试结果和轶事都表明，模型表现“起伏很大”：有些 bug 上惊艳，有些则糟糕甚至容易产生幻觉。信任仍然是核心问题。
组织激励与文化
- 一些评论将问题归咎于管理层：OKR 明确激励重度使用 AI、低代码工具，以及把交付速度置于理解和可靠性之上。
- 也有人认为，这反映的是行业长期存在的模式（外包、RPA、“靠脚本运维”），而不是某种全新的现象。
- 将开发者视为工匠，还是可互换的交付劳动力，这两种观点之间存在张力；AI 放大了这种冲突。
缓解措施与建议实践
- 建议包括：演练/混沌工程、桌面式事故模拟、明确的护栏（AGENTS.md）、RPI/SDD 循环，以及充当工具中介的“AI chef”角色。
- 强调人类应继续掌控架构、边界和高风险区域，把 AI 当作凿子，而不是自动驾驶。
- 也有人主张职业化/执照化（类似飞行员），以强制进行事故训练并避免偷工减料。
更长期的轨迹与未解问题
- 观点分歧：
- 一方预测会达到一种平衡，抽象层级稳定下来，AI 只是“另一种工具”。
- 另一方则预见深度依赖：人类不再理解底层系统，AI 既构建又看护不透明的技术栈。
- 在 AI 优先的世界里如何培养专家，仍然没有定论。