线上自动修 20%，线下 60%：京东海博怎么验 AI 代码

线上自动修 20%，线下 60%：京东海博怎么验 AI 代码

京东云开发者社区在 2026 年 7 月 22 日发了海博 AI-Native 的落地记录。页面作者是社区账号星星****，不是具名团队。技能迭代、开发期测试和上线后自测写在同一篇里，分母并不一样。

海博要解决的是对话式编程助手不好规模化：流程不固定、规范不统一、业务经验留不下来。他们的做法不是再堆提示词，而是把流程、规范和领域知识收成文件，让技能、Agent 和规则去执行。

先把随机对话收成可校验的文件

体系分两层目录。用户级放团队通用规范和技能，作为全项目基线。项目级跟代码仓走，只放这个业务自己的配置。加载顺序是项目优先、用户兜底。团队改一处基线，各项目不用逐个改；项目差异只留少量配置。

运行机制有两块。一块是 Preamble 自检：自动上报数据、对照规则做静态校验，偏差可以审计。另一块是五阶段串行流水线，把一次研发走完并留下过程资产。外面再配 13 类任务路由，按需求轻重选流程、按需加载上下文。13 类是路由分类数，不是评测准确率。

权责拆成三层：流程编排、专项执行、决策管控分开。框架写了 17 项全链路技能，另有知识蒸馏，用来把项目里做过的事留下来。审查拆成 3 类只读 Agent，写代码的不审自己写的。规则层是硬约束，跨阶段有门禁，逐层校验。17 和 3 同样是架构数字，原文没有给出这 17 项技能各自的通过率。

技能本身按研发环节拆开，顺序是固定的：

• 需求拆分：把 PRD、流程图、语音和会议纪要放在一起解析，用知识库、图谱、历史工时和向量检索做影响分析和工时预估。
• 技术方案：同一类多源输入，加上历史项目，输出方案、任务清单和风险。
• 任务拆分与编码：前置校验、信息对齐、智能拆分、审查确认。先看需求和设计是否完整，再拆优先级和依赖，多轮 Reviewer 看过才出 README、任务文档、依赖图和风险清单。
• 缺陷修复：定位、生成修复、风险自查后提交。定位靠日志、技能关联和代码上下文。
• Code Review：先查命名、注释、复杂度和空指针；再拿 PRD 对业务是否一致；再看 MySQL、RPC、Redis 和配置中心上的稳定性风险。产出是一份审查报告。
• 上线检查：从代码变更抽出发布清单，在泰山、行云后台做实测，再触发行云部署。串起来的是 JoyClaw、京 Me 和 Agent 技能。

这些步骤说明的是门禁放在哪，不是某一次上线的缺陷密度。

技能要先评测，再发布

技能铺开以后，原文把问题写成两句：效果怎么评估，以及自动化过程里人工打断太多、怎么把人工辅助比例降下来。

采集侧用 Agent 代理工具记下会话、工具调用、执行结果和用户反馈。分析侧定期看高频问题、回答质量、工具调用效率和用户行为，从里面找技能缺口。优化侧可以生成 Prompt、知识库和工具编排的修改建议，形成新的 Skill 版本。发布前要过历史案例评测、版本发布和效果监控。闭环顺序写成：数据采集，智能分析，自动优化，评测验证，持续发布。

Code Review 技能是唯一写了操作的例子：先统计采纳和未采纳的案例，AI 给出要改的方向，人确认最终改什么。原文没有写统计窗口、采纳定义，也没有写评测集有多少条、新版本相对旧版本抬了多少。

技能迭代里，原文说 90% 的需求卡在同一处：项目历史逻辑补不全，代码分析细节不够。这个 90% 没有样本量和统计口径，不能当成知识库命中率。

知识库按需加载，冲突仍要人审

知识库用 Google 的 OKF 开放知识格式。约定只有三样：目录树定结构，正文用 Markdown，Frontmatter 区分知识类型。其余由业务自己写。版本放在 Git 里，人和模型读的是同一份。

索引是为了按需加载，避免一次把库读进上下文。目录已铺到后端、前端、测试、产品、运营，并按 Git 仓库分成技术、前端、业务、产品、跨项目。新项目可以一键生成仓库骨架，再用 AI 回填存量知识，扫描外部依赖后入库。

更新分三条：主干代码合并时自动同步；AI 会话钩子从对话里抽知识；人也可以主动补。内容冲突要人工审核。生命周期写到产生、提取、审核、入库、索引、使用、迭代和废弃归档。海博库存库被当作例子，图里能看到内容和索引，以及更新可以追溯。原文没有给这个库的条目数、冲突率和检索命中率。

代码质量是两层循环，不是模型自证

开发期走 TDD。每个最小任务先拆开、写下验收标准、先写会失败的测试，再让 AI 写到测试变绿。单测通过才做 Code Review。合入时跑本次增量，也跑历史全量回归。目的是不要等大功能堆完才发现整包都要返工。

部署后再做一层接口自测。服务起来以后，用真实 baseUrl 打接口，用 mysql-mcp 查真实库，并核对真实日志。这一层要盖住单测 mock 碰不到的东西：签名口径、写库是否落地、下游回调、依赖串起来之后的行为。判定不由写代码的 Agent 自己说了算，要回到原始证据做独立审计。

两层外面再加四道护栏：验收标准共享、测试冻结、独立审计、熔断。原文的意思是，AI 不能靠改测试或改口径把自己说成通过。

这篇只给了闭环形状，没有给开发期红转绿的比例、回归失败率，也没有给熔断阈值。更细的多 Agent 接口自测写在另一篇神灯文章里，本文没有把那篇的数字搬过来。

故障修复的 20% 和 60% 没有分母

线上故障修复以女娲智能体为中心，分成人工干预和 AI 自治两种模式。链路是用户交互、感知、根因、自动修复、交付验证、知识沉淀。入口包括京 ME 和 JoyClaw，目标是 7×24 跑，关键环节人兜底。底座写了大模型、知识库、Skill 市场和海博磐石平台。

结果句只有一句：线上 20%、线下 60% 的问题可以自动修复。原文没有写统计窗口、问题总量、什么叫修复成功，也没有写剩下的是否转人工。这两个百分比不能相加，也不能当成整体自动化率。

两个业务数字也不能当成代码评测分

堂食判官对着 6 月 1 日餐饮新规。5 月 22 日接到需求，5 月 25 日第一版跑通，5 月 28 日加上批量。低峰 700 条/分钟，高峰仍有 100 条/分钟，效率最高写成提升 1680 倍。70 万历史数据零积压。单条判定从 2 元降到 0.015 元，降幅 99.25%，每百万条大约省 200 万元。1680 倍和 99.25% 是吞吐、成本相对人工或原单价的算法，不是审核准确率。原文没有写误判率和抽检比例。

AI POS 从 0 到 1，原文写 100% 代码由 AI 生成，技术栈从 Java 研发跨到 AI 视觉，已部署到外部商业化门店。对照是人工收银 24.43 秒/单，提升 25%–50%。24.43 秒是人工基线，不是 AI 的实测秒数；25%–50% 没有写清是速度、人效还是别的口径，也没有样本量。

原文自己留下的缺口

第十一条没有给新数字。它承认：交给 AI 的任务变多以后，生成代码涨得很快，代码质量、评审和运维成本、线上稳定性都还没解完。现有流程还罩不住。所以前面的 17 项技能、双循环和 20%、60%，都还不是一套已经量完的质量体系。

能直接拿去用的是顺序：技能改版先过历史案例再发布，人确认采纳方向；知识冲突人工审核；开发期先写失败测试再让模型变绿；上线后用真实接口、真实库和真实日志复核，并且不让写代码的 Agent 给自己判过。

京东云开发者社区，星星****，拆解海博 AI-Native 落地保障：Harness、双 Loop、知识库与技能自主迭代实践，2026-07-22，https://developer.jdcloud.com/article/4538