AI Coding 提速之后，如何补上稳定性“最后一公里”？快手柯南 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。 从 AI 的视角看，这个结果有其“合理性”：它只看到了 SDK 能够运行的局部，却没有意识到配置会跨越工程边界。 SDD、Coding Harness 以及 Coding、Review 阶段的前置约束，可以提高代码生成质量，拦截一部分问题，但不可能消灭所有稳定性风险。 大前端领域有一个显著特点：线上状态空间极其庞大。以机型碎片化最严重的 Android 系统为例，线上存在超过 100 种 OEM ROM、1000 多个适配机型。对于快手这样的强运营 App，一天内由 A/B 实验、灰度和运营活动带来的变更可能超过 1 万次。用户行为路径更是千人千面，无法穷举。 没有任何测试矩阵能够在线下覆盖所有组合。从更高层面看，软件稳定性本身就是一个“不完备性证明”问题：我们无法证明所有场景都绝对稳定，只能不断加深防御纵深。 线上真实现场永远是稳定性的核心战场。 研发吞吐被 AI 拉快，稳定性处置没有跟上；AI 会陷入局部最优，而前置拦截又无法消灭所有问题。这些因素共同指向一个结论：线上稳定性处置，是完整落地 AI Native 的最后一公里。这也是我们建设柯南 AI 的出发点——聚焦稳定性领域，“用 AI 打败 AI”。 柯南 AI：嵌入工作流的稳定性数字同事 “柯南”这个名字来自《名侦探柯南》——“真相只有一个”。我们的愿景，是让柯南 AI 成为所有 Bug 的最终归宿。 完整的稳定性生命周期通常包括拦截、监控、排障和止损。现阶段，柯南 AI 主要聚焦排障与止损，也就是问题处置环节，覆盖四类场景： 报警处置，包括问题解释、影响面判断和 SOP 执行；根因分析，包括线索发现、假设提出和证据链构建；修复建议，包括修复方向、风险和验证方式；治理初检，包括优先级判断与问题分发。 我们选择问题处置环节，首先是因为它最消耗业务研发时间，建设 ROI 较高；其次，这些任务需要聚合信息并进行多步推理，适合 AI；同时，这也是稳定性专家经验能够发挥较高杠杆的地方。 在产品形态上，我们有一条原则：不额外创造孤立的交互方式，而是把柯南 AI 嵌入开发者已有的工作流。 目前主要有三种产品形态。 第一种是 IM 机器人，服务于报警处置、指标巡检和问题分发。这些任务原本就需要多人协作，通常发生在 IM 群聊中，机器人可以直接进入原有协作场景。 第二种是监控平台侧边栏。研发打开崩溃详情页后，可以拉起柯南 AI。系统会自动携带当前崩溃的上下文，触发根因分析。 第三种是 CLI。它与侧边栏都覆盖根因分析和修复建议，但主要解决监控平台信息不足的问题。有些问题需要连接手机，拉取设备上的 so 文件或其他现场信息。此时，研发可以将问题上下文从监控平台流转到 CLI，继续本地排查。 目前，柯南 AI 在内部大前端研发中的用户渗透率接近 60%，根因分析结果的完整采纳率稳定在 50% 左右。 柯南 AI 的五层工程架构 柯南 AI 的整体架构分为五层：最上层是应用层，对应 IM 机器人、监控平台侧边栏和 CLI；下面依次是 Agent 编排层、Agent Harness 层、数据服务层和端侧基建层。另有一套可观测与反馈迭代机制纵向贯穿整个系统。 编排层：确定性的归代码，概率性的归模型 Agent 编排层主要回答一个问题：什么任务应该由什么形态承载？ 我们的核心原则是：确定性的归代码，概率性的归模型。 对于流程清晰、规则明确、答案相对唯一的确定性问题，我们使用代码实现；只有涉及理解、推理和判断的部分，才让模型介入。把大模型放在它擅长的位置，才能兼顾效果稳定与成本可控。 报警处置是柯南 AI 的重要场景。在 AI 时代之前，快手已基于大量经验沉淀出一套完整 SOP：从报警发生、拉群，到多人分工排查，再到止损和复盘，包含一套严肃而复杂的协作流程。 这样的流程不适合完全交给 Agent Loop 驱动。Agent 可能遗漏步骤，也可能调用错误工具，这在报警处置中无法接受。因此，我们通过用代码复刻人工 SOP，只在部分子环节引入模型。 进入概率性任务后，我们还有一条原则：单次 LLM 请求能够解决的问题，就不使用 Agent。 任何任务都使用 Agent，是一种过度工程化。Agent Loop 每增加一轮，就会增加一次 LLM 请求，带来额外时延和 Token 消耗；Tool Call 可能失败，Agent 的自主决策也可能跑偏。如果任务确实需要长链推理，这些代价