AI Coding:从个人玩具到组织能力——AiDD 2026 公开实践拆解

📅 2026/7/9 12:16:48
AI Coding:从个人玩具到组织能力——AiDD 2026 公开实践拆解
2026 年 5 月去哪儿旅行基础架构负责人李佳奇在 AiDD 研发数字峰会做了题为《去哪儿旅行 L3 AI Coding 的研发平台与 Skills 实践》的分享1。讲述里提到的最有用的不是「Cursor 还是 Claude Code 哪个更强」而是一个更底层的问题当研发组织决定全面推广 AI Coding 时该先建什么去哪儿给出的答案轮廓很清晰先度量再分级用 Harness 管住过程用平台和 Skills 把个人经验沉淀成组织能力。 下文按四条线展开等级语言L0–L5→ 过程控制Harness→ 落地路径四步依赖链→ 组织资产Skills。个人用得爽和组织接得住往往是两件事。一、问题从哪来为什么「全员 AI Coding」还不够1. 个人提效与组织交付的裂缝AiDD 上海站多场分享指向同一个现象AI Coding 工具普及后个人写代码更快了组织交付未必同步变快2。代码生成量、工具活跃人数上涨需求到上线的周期、跨团队等待、返工率却可能停在原地。去哪儿的公开材料里业务研发团队长期维持较高出码率——据 AiDD 系列报道引演讲披露数百人规模团队出码率 75% 以上3。但分享同时强调出码率是观测点不是终点。没有 Harness 和效果指标兜底的高出码率可能只是在更快地制造待审查、待测试的中间产物。2. 过程指标 vs 效果指标李佳奇在分享中把指标分成两类。过程指标回答「AI 有没有进入现场」效果指标回答「现场有没有真的变好」。类型典型指标回答什么单独使用的风险过程出码率、需求覆盖率、工具活跃、自动化水平AI 参与了多少研发活动变成 KPI 竞赛忽视质量与交付效果交付周期、缺陷逃逸率、返工率、业务价值这些活动是否产生真实收益周期长、难归因但不能因此放弃李佳奇分享中提及用「量 × 成熟度」组织度量维度4该公式表述仅见于二手解读未在大会官网核对原文——过程看规模质看自动化水平与 Harness 成熟度。更稳妥的做法是把过程指标串成一条证据链覆盖率证明「用起来了」→ 出码率证明「参与深了」→ 交付周期和缺陷率证明「值不值」。缺了最后一环管理层看到的只是「AI 很忙」。3. 不再纠结 Prompt 技巧而是回答四个工程问题L0–L5团队现在在哪个等级下一阶段去哪里HarnessAI 参与研发时谁触发、谁约束、谁审查Tool → Infra → Automation → Insight落地四步及其依赖关系Skills重复劳动有没有变成可分发、可治理的组织资产二、L0–L5给 AI Coding 一套可对齐的「等级语言」1. 六级定义去哪儿在演讲中借用了自动驾驶分级把 AI Coding 分成 L0–L5。这是演讲中的框架定义不是 ISO 或行业标准3。价值在于给团队一套共同语言——否则有人说「我们用 AI 写代码」指的是 Copilot 补全L1有人指的是需求到 PR 的自动交付L3讨论根本无法对齐。等级名称AI Coding 定义压缩人的职责L0全手动完全不依赖 AI 生成或参与流程全部研发活动L1代码补全与辅助AI 补全片段人主导编码与决策主要编码、判断、合入L2部分自动生成AI 生成函数/类/模块人组装与验收监控、测试、集成L3有条件自动化人给需求与规范AI 编码并测试阻塞时介入定目标、补约束、关键审查L4高度自动化AI 承担大部分编码、测试、集成与流水线架构、质量验证、核心逻辑L5完全自动化需求到上线主要由 AI 完成仅异常与重大变更介入2. L2 → L3 的关键跨越L2 到 L3 的质变不是模型从 Sonnet 换到 Opus而是任务能否被流程承接L2AI 产出模块人负责拼装成可交付物L3人输入需求与规范AI 跑通编码和功能测试只在阻塞时喊人公开材料指出这一跨越依赖Skills 体系化 自动化编排平台56。A2M 课程页将其概括为从工具提效走向 Agentic Coding 平台通过 SKILL、RULE、CodeWiki 等模块把个人经验变成组织级能力5。据公开解读披露去哪儿 2026 年上半年给自己定的方向之一是提升 L3 自动化任务占比4。对多数团队而言现实目标在 L2–L3而非一步到位 L5。3. 对管理者的三条实操建议按等级配审查强度L1 可以轻审查L3 必须在合入、灰度、发布保留人工节点按等级定投入没到 L2 就上马全链路编排平台容易空转❗️等级不是越高越好没有 Harness 的 L3比有 Harness 的 L2 更危险——产出更快失控也更快三、Harness决定上限的不是模型是过程控制本章核心判断模型能力会迭代真正把 AI Coding 锁在「个人玩具」阶段的往往是缺少 Harness。1. 业界概念与去哪儿定义的对照「Harness」近一年在 Agent 工程语境里高频出现但不同出处含义侧重不同。维度Anthropic / 工程语境7社区归纳Harness Engineering8去哪儿演讲框架4核心调用循环 工具路由模型之外的一切脚手架AI 研发过程控制能力关键组件session、harness、sandbox 解耦prompts、tools、hooks、sandboxes、反馈环触发、门禁、隔离、审查关注点长跑任务、安全边界、可替换实现配置问题而非模型权重问题研发 12 环节里 AI 怎么参与据公开解读转述4去哪儿在分享中将研发全链路拆为 12 个环节的 AI 参与控制点#环节流程1需求文档编写AI Draft → 模板约束 → 人工确认2需求评审缺口识别 → 评审规则 → 关口审查3方案设计方案生成 → 架构约束 → 专家 Review4代码编写Skills 触发→ 编码规范 → 隔离环境5代码测试测试生成→ 覆盖率门禁 → 沙箱执行6Checklist/Case 编写Case 生成 → 验收标准 → 人工补充7开发自测自测助手 → 虚拟环境 → 结果校验8代码 Review风险扫描 → Review 规则 → 人工合入9QA 测试缺陷分析 → 测试准入 → QA 判断10自动化回归回归编排 → 隔离执行 → 失败拦截11灰度验证指标观察 → 灰度策略 → 人工放量12生产发布发布辅助→ 变更门禁 → 人工审批Anthropic 把 harness 描述为「调用 Claude 并把 tool call 路由到基础设施的循环」沙箱负责执行session 负责持久化事件日志——三者可独立替换7。Addy Osmani 等社区的定义则更为广泛harness 模型以外的全部代码、配置与执行逻辑8。据公开解读转述4去哪儿的定义更贴近研发流程治理Harness 衡量 AI 是否被稳定触发、被约束、被隔离、被审查——不是「模型强不强」而是「参与方式是否可控、可复用、可审计」。去哪儿没有发明 harness 这个词它做的是把业界正在形成的概念落进需求→发布的全链路。2. 四把锁据公开解读转述4去哪儿将 Harness 落实为四把锁AI 触发机制在关键环节用 Skills、Workflow、Agent 流程化调用避免「想起来才用一下 AI」约束与门禁输入模板、编码规范、质量标准、准入条件、失败拦截安全隔离环境AI 执行、测试、回归在沙箱或虚拟环境完成不直接碰生产人工审查节点需求确认、方案评审、代码合入、灰度放量、生产发布保留人工确认上表是全景视图日常落地可先从三个环节试点需求评审AI 做缺口识别 → 规则约束 → 人工关口审查代码 Review风险扫描 → Review 规则 → 人工合入生产发布发布辅助 → 变更门禁 → 人工审批3. 与出码率 KPI 的关系出码率回答「AI 写了多少」Harness 回答「写得是否可控」。高出码率 低 Harness常见结果是Review 负担加重、测试欠债堆积、线上风险后置。李佳奇在 AiDD 系列报道里明确反对把出码率当唯一目标3。过程指标必要但必须和 Harness、效果指标放在同一张表里看——否则组织只是在统计「更快制造出来的中间产物」。四、四步落地路径Tool → Infra → Automation → Insight去哪儿的落地不是四条平行线而是严格依赖链。跳步的典型症状有平台没人用、有数据没闭环、有出码率没交付改善。反馈优化反馈优化反馈优化Tool 工具引入Infra 基建接入Automation 平台编排Insight 数据采集1. Step 1 · Tool先让人用起来第一步是引入 Claude Code、Codex、Cursor 等头部工具降低个人使用门槛同时沉淀 Prompt、Workflow、Review 等最佳实践5。引入时几个硬约束成本控制、企业级安全、权限与过程管控、数据采集与治理5。很多人只盯模型能力忽略「桌面客户端 / 统一 LLM 网关」——没有统一入口后面的 Insight 无从谈起。2. Step 2 · Infra接入研发体系工具孤立使用出不了组织效果。Infra 阶段要做的事Skills 网关把研发平台接入 AI统一治理与分发统一 Rules / Skills 仓库复用与版本管理安全治理审核准入、实时更新Skills 治理流程据 AiDD 系列报道引 PPT 披露6一线私有验证PR 提交标准仓库基础研发审核Gateway 统一分发调用观测与迭代3. Step 3 · Automation天弦QDO编排据公开解读去哪儿自研研发自动化平台「天弦」Qunar Dev Orchestrator简称 QDO定位是多 Agent、多 Skills、全链路编排4。A2M 课程页用「Coding Agent 自动化平台」描述同一层能力强调把需求、能力与流程打通5。典型 L3 场景公开材料列举场景传统痛点平台能力公开披露效果一句话需求需求→编码→部署链路长、切换多Agent 编排 部署/测试 Skills据解读分钟~小时级闭环4JDK 自动升级技术债高风险、人工不敢动OpenRewrite 规则 Agent 修编译错误据解读211 应用、93% 编译通过率4线上异常修复日志排查耗人日志/配置上下文 自动修复重试课程页列为应用场景5复杂业务需求2PD 以上在公开材料中还有 Qsuperpowers 等专项框架45本篇不展开只需知道小需求走编排平台大需求还要额外的任务结构化能力。4. Step 4 · InsightQunarDevCenter 与数据飞轮规模化之后黑盒必须变白盒。去哪儿的 Insight 层核心是QunarDevCenter采集 Claude Code、Codex、Cursor 等 Session 数据按统一协议上报关联任务、测试、发布链路输出出码率、自动化水平、覆盖率等洞察45。5. 依赖链小结Tool → Infra → Automation → InsightInsight 的价值不只是报表而是驱动 Skills 迭代、Harness 收紧、平台场景扩展的反馈飞轮五、Skills 与组织资产出码率之外什么在复利出码率衡量「量」。Skills 治理衡量「质」和「复用」——AI 能力究竟留在聊天记录里还是进入组织资产池。1. 三类核心 Skills据 AiDD 系列报道引演讲披露6去哪儿沉淀了三类与 L3 交付直接相关的 Skills一句话需求自动化开发自动调试和部署性能自动优化它们支撑的场景包括JDK/Spring 框架自动升级、业务线规模化小需求交付、生产必修异常自动修复6。Skill 在这里不是「写得更漂亮的 Prompt」而是流程 工具 上下文 验证标准的组合封装。2. 治理流程有效实践先进私有仓库验证再高价值 Skills 提 PR 进标准仓库经基础研发审核后通过 Gateway 分发并记录调用情况反向优化6。这条路的难点不在技术在愿不愿意把个人摸索变成可审计的组织资产。3. 角色变化A2M 课程页有一句直白的定位开发者从「代码生产者」转向「问题定义者与能力编排者」5。出码率再高如果没人愿意定义问题、维护 Skills、设计 Harness组织仍然停在 L1–L2 的个人提效。六、方案边界与落地建议去哪儿的路径不是银弹。它假设你已经有一个数百人规模、愿意投入平台与数据体系、且研发流程有一定数字化底座的组织。1. 适用 / 不适用场景更适合去哪儿路径不太适合原因组织规模百人以上多团队研发十人以内产品团队平台建设 ROI 不足数据合规能建客户端采集 白名单上报无法接受行为数据采集Insight 层无法落地治理意愿愿意审核、分发、维护 Skills只要个人自由使用 AIInfra 层推不动目标等级追求 L2–L3 规模化仅需 L1 补全提效四步链路过重2. 可复制的最小起步不必照搬天弦和 QunarDevCenter四步可以缩小执行✔️统一 L0–L5 语言开一次对齐会让各组说清楚「我们其实在 L几」✔️一对指标1 个过程指标如覆盖率 1 个效果指标如需求交付周期✔️一个 Skills 试点选 JDK 升级、定时任务、配置变更等高频低风险场景配上审查节点✔️有底座再建平台采纳率和数据源跑通后再考虑 Workflow 编排总结AI Coding 的上限越来越取决于研发系统是否为 AI 重新设计——不是多买一个席位而是度量让它可见、Harness 让它可控、平台让它可编排、Skills 让它可复利。个人玩具阶段拼的是谁更会写 Prompt组织能力阶段拼的是谁先把反馈环跑通。去哪儿的公开样本可贵之处在于它把这条路径摊开讲了先回答「怎么量」再讨论「怎么管」最后才谈「怎么自动化」。https://www.aidd.vip/dhrc-sh2026 official-blogAiDD 2026 上海站大会日程 ↩︎https://www.keylinking.com/gywm/3653.html secondaryAiDD 系列观察报道引鲁奕志分享 ↩︎https://www.keylinking.com/gywm/3653.html secondary引李佳奇演讲 PPT 第 8/10 页 ↩︎ ↩︎ ↩︎https://mp.weixin.qq.com/s/Ug_fMuGkQmM4tECUbpfXOg secondary公众号二次解读 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎https://a2m.msup.com.cn/course/19218 official-blogA2M 课程介绍页 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎https://www.keylinking.com/gywm/3622.html secondary引李佳奇演讲 PPT 第 38/40 页 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎https://www.anthropic.com/engineering/managed-agents official-blogAnthropic Engineering2026-04-08 ↩︎ ↩︎https://addyosmani.com/blog/agent-harness-engineering/ communityAddy Osmani ↩︎ ↩︎