京东零售-李智刚

一、前言：寻找效能的“圣杯”

在软件研发的世界里，我们都在追逐那个传说中的“圣杯”——极致的效能。

这些年，我们几乎把所有能自动化的地方都自动化了：监控体系日趋完善，CI/CD 流水线昼夜不息，可观测性让系统的每一寸肌理都变得透明。但讽刺的是，当凌晨三点的 P0/P1 告警再次响起，当面对成千上万行日志和错综复杂的微服务依赖时，那个从“发现问题”到“解决问题”的最后一公里，依然横亘着巨大的人工成本与时间损耗。

告警不是结束，而是另一场疲惫马拉松的开始。

今天，我想向大家介绍一位新伙伴，也是解决这个终极难题的答案——AI 数字员工「女娲」。她不再只是一个自动化脚本，而是一个具备感知、分析、决策与执行能力的智能体。她真正打通了从告警到发布的完整闭环，让软件研发效能完成了一次质的跃迁。

二、传统链路的痛点：断裂的最后一公里

在引入「女娲」之前，我们的研发运维链路通常是这样的：

我们的研发运维链路看似流畅，实则布满了“断点”。每一次系统切换，都是一次上下文割裂；每一次等待，都在拉长 MTTR（平均修复时间）。

我们内部曾做过一次复盘：在一次典型的 P1/P2 故障中，工程师平均需要在 4–6 个系统之间来回跳转，仅“定位 + 理解问题”就占据了超过 60% 的处理时间。而其中约 60% 的故障属于“已知模式的新实例”（如空指针、越界、资源泄露、配置错误等），却仍然消耗着最昂贵的人力。

这就是我们要缝合的裂缝。

三、产品概述：「女娲」重塑人机协作的边界

「女娲」是一款专为软件研发与运维场景打造的 AI 数字员工。她突破了传统自动化脚本的局限，是一个具备感知、分析、决策与执行能力的智能体。

女娲致力于解决研发链路中从“发现问题”到“解决问题”的最后一公里难题，通过打通从告警到发布的完整闭环，大幅降低人工干预成本，实现软件研发效能的质的跃迁。

女娲将复杂的故障处理拆解为九个标准化步骤，形成自治闭环：

步骤	工程细节
告警与感知	DongMonitor/自定义告警、业务埋点；自动提取 应用名、TraceID、时间戳等元数据。
日志检索	基于 TraceID + 时间窗口 + 异常关键字，自动检索服务日志，避免“大海捞针”。
根因分析	大模型联合推理与根因定位。
故障类型分流	非代码问题报告 / 代码问题修复。
修复方案	先生成修复方案 + 风险评估（影响面、兼容性、回滚难度），再由人决策。
编码开发	基于 AST 级别理解代码结构，而非纯文本编辑，降低误改风险。
提交 MR	自动填充 MR 模板：问题描述、根因摘要、测试建议、影响评估。
MR Review	内置 Code Review Skill 先做一轮：风格、潜在缺陷、性能、安全扫描，再交给人决策审批。
Merge & 部署	支持Coding MR 合并与行云编排发布。

四、 核心能力矩阵

1. 智能感知与精准检索能力

女娲具备对系统异常的高度敏锐度。在接收到 P0/P1 级告警后，她能自动提取服务名、环境、实例及 TraceId 等关键元数据。依托我们自己构建的日志检索 Skill（.Logbook日志检索（零售区））与路径检索 Skill（.Logbook日志路径查询（零售区）），她能基于 关键字 与时间窗进行分页轮询，精准拉取并构建完整的调用链视图，彻底告别盲目翻找日志的低效时代。

日志路径检索

使用skill发起检索： 检索结果：

2. 大模型驱动的根因推理能力

摒弃传统的关键词匹配模式，女娲内置大模型推理工作流。她能将日志上下文、近期变更记录与配置差异进行联合语义分析。同时具备智能分流判断：若判定为网络抖动、下游限流等非代码问题，将直接生成分析报告并提示无需代码变更；若确认为代码 Bug，则无缝切入修复流程。

告警触发
技能触发
根因定位	触发工作流：
京ME卡片交互	根因分析完成： 确认AI修复：
修复报告	修复报告：
修复效果	代码提交记录：

3. AST 级代码分析与AI修复能力

在确认代码缺陷后，女娲能与代码托管平台（如 Coding）深度交互，自动基于主干创建修复分支。她具备 AST（抽象语法树）级别的静态分析能力，能精准推导代码影响面，并生成包含兼容性、性能及回滚难度评估的多套修复方案，确保修复逻辑的严谨性。

AI修复插件	Coding定制插件： 脚本&AI代码修复Agent：
修复任务	创建修复任务：
自动修复过程	创建修复分支： 大模型代码修复： 修复代码自动提交：

4. 自动化交付与流程编排能力

女娲不仅是“修复者”，也是“交付者”。她能自动发起 Merge Request，并结构化填充问题根因、修复逻辑与测试建议。在获得人类审批后，自动执行 Merge 并触发部署编排流程，实现从代码提交到上线恢复的全链路自动化流转。

四、量化提效：从“小时级”到“分钟级”的跨越

我们内部通过对过去三个月的故障复盘数据进行了对比分析，发现「女娲」的介入在MTTR（平均修复时间） 和人工工时（Human Effort） 上带来了显著的量级变化。

1. 传统模式 vs 女娲模式 全流程工时对比

数据洞察：在常见的“已知模式故障”（如空指针、配置错误、数据越界等）中，人工处理往往消耗了 60% 以上的时间在定位和检索上，而这些恰恰是「女娲」最擅长的领域。

2. 效能核心指标对比

五、 交互模式：随时随地，掌握修复主动权

「女娲」不仅是一个在后台默默干活的智能体，更是一位随时待命、支持远程操控的数字搭档。我们打破了办公环境的物理限制，将人机协同延伸到了每一个碎片化场景：

• 移动端远程操控

深度集成 IM 通讯工具（如飞书/企微/钉钉）与移动端 App。无论是在通勤地铁上、深夜熟睡时，还是在出差的高铁上，只要 P0 告警响起，工程师都能第一时间在手机端收到结构化卡片。

• 对话式极简交互

无需打开沉重的电脑或登录复杂的运维控制台，直接在手机端通过自然语言与「女娲」对话。你可以随时下达指令：“女娲，拉取刚才告警的详细日志”、“展示 AI 生成的修复方案”或“批准该 MR 并触发灰度发布”。

• 全链路状态追踪：

在手机端即可实时查看「女娲」的工作进度（如：正在执行智能体 → 根因分析中 → 代码修复完成待审批）。将原本需要端坐在工位前才能完成的“人机协同”，变成了随时随地、触手可及的“口袋指挥中心”。

协同场景示例：

凌晨 02:15：手机弹出 P1 告警。 02:16：你在被窝里点开手机，点击：“女娲，开始修复”。 02:22：收到女娲推送的根因卡片与修复方案，你选择点击“执行修复”。 02:25：收到通知“MR 已提交，测试通过，已自动合并至主干”。 02:26：你安心放下手机，继续睡觉。全程耗时 11 分钟，无需起身开电脑。

交互体验对比：

六、未来：持续的产品定位与体验优化

目前，「女娲」正处于灰度验证与能力泛化的关键阶段。她已经能在部分核心业务中稳定运行，但距离我们心中的“全知全能”，还有很长的路要走。

我们将围绕三个维度持续打磨：

1. 灰度验证与场景泛化

从小范围试点出发，逐步覆盖不同技术栈、不同故障复杂度，从“能修已知问题”走向“能应对长尾边缘场景”。

2. 数据驱动的精准进化

建立精细埋点体系，追踪自动修复成功率、采纳率、执行效率。

每一次工程师的修改、驳回或点赞，都是「女娲」的进化养料。

3. 极简交互与无感融入

坚持“简约原则”，优化告警卡片与对话式交互，让「女娲」像空气一样存在：

平时润物无声，关键时刻挺身而出。

在此基础上，我们也给自己划了清晰的演进路线：

阶段	目标
L1 辅助驾驶	自动分析 + 自动修复 + 人工审批
L2 协同驾驶	低风险场景无人值守发布 + 自动回滚
L3 自动驾驶	覆盖 70% 常见故障，形成系统级自愈能力

七、 产品价值与愿景：重塑人机协作的边界

「女娲」的出现，不是为了取代工程师，而是为了把工程师从重复劳动中解放出来。

她负责的是那些确定的、标准的、耗时的事情：日志检索、根因推导、代码修补、流程流转。

而我们，可以把精力还给架构设计、复杂决策和业务创新。

从告警到发布，这条曾经漫长而焦虑的路，如今在「女娲」的脚下，变成了一条只需人类做关键决策的自动化通路。

这，就是我们眼中的软件研发效能终极闭环。而这一切，才刚刚开始...