AI热榜 AI Coding 正在显著提升代码生产效率，但线上告警、根因定位、止损和修复等稳定性环节并未同步提速。
更值得警惕的是，缺乏全局上下文的 AI 可能沿着“最小阻力路径”消除表面现象，却留下跨工程、跨系统的稳定性隐患。
当 AI 开始规模化生产代码，谁来承接随之增长的线上问题，正成为 AI Native 研发体系必须补上的“最后一公里”。
在 AICon 全球人工智能开发与应用大会（上海站）2026 上，快手主站技术稳定性专家王泽锋分享了“柯南 AI”的工程实践。
这次分享的核心并不是简单地“让 Agent 代替人排障”，而是重新设计稳定性研发中的人机分工：确定性的流程交给代码，概率性的推理交给模型；通过 Skill 沉淀专家经验，以源码服务和端侧基建提供有效上下文，再用 Bad Case 驱动系统持续进化。
目前，柯南 AI 在快手内部大前端研发中的用户渗透率已接近 60%，根因分析结果的完整采纳率稳定在 50% 左右。
在一个只有系统堆栈的鸿蒙 C++ Crash 案例中，它通过寄存器、业务日志和源码构建证据链，约 10 分钟便定位到内部基础组件触发的纯系统堆栈 Use-After-Free 问题，并帮助团队找到止损开关。
围绕这一案例，王泽锋进一步拆解了柯南 AI 的五层架构，以及稳定性专家如何从“前线救火员”转变为“消防系统设计师”。
AI Coding 提速之后，稳定性成为“最后一公里” AI 浪潮给稳定性带来了什么影响？
如今，Cursor、Claude Code、Codex 等 AI Coding 工具已成为行业主流。
上游研发吞吐显著提升，需求到代码的转化成本大幅降低。
与之相比，线上告警、根因定位、止损决策、修复回归和经验沉淀等下游处置链路，几乎没有得到同等加速。
当代码生产与稳定性处置长期速率不对等，线上 Case 的数量、严重程度和处置时延都可能全面劣化。
更棘手的是，AI 不仅放大研发吞吐，也可能制造新的稳定性问题。
由于缺乏全局上下文，AI 往往沿着“最小阻力路径”让问题现象消失，但现象消失不等于问题被真正解决。
这就是 AI 普遍存在的局部最优陷阱。
快手内部曾遇到过这样一个案例。
在 Android 版本发布前的灰度阶段，我们发现 APK 包体突然增加了 6 MB。
紧急排查后发现，问题来自一个内部 SDK：开发者通过 AI 生成了一段 ProGuard 配置，其中包含 -dontoptimize，并将其写入 consumerProguardFiles。
从 SDK 自身看，这段配置可以让工程正常运行。
但 consumerProguardFiles 会随 AAR 传递到主工程，在构建时与 R8 配置合并，最终关闭主工程的 R8 全局优化，导致 DEX 体积膨胀，APK 增加 6 MB。
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接