杨夕凯现任职高德地图，担任AI智能应用与基建平台负责人，先后负责动态数据、AI 导航、智能应用及基建平台等业务方向。其长期参与的工程方向包括地图数字孪生、空间智能、AR/数字人、AI 导航算法模型，以及支撑千亿级数据的端云一体化基础设施与工业级 AI 研发体系建设。
以下内容整理自高德技术官方微信公众号发布的「超级应用的 AI 原生研发模式探索」系列文章，重点梳理其所在团队在 7x24 AI 生产线、AI 全托管 CI/CD、Self-Healing 自修复与 Benchmark 评测体系方面的实践路径。
在超级应用的复杂工程环境中，AI 编码工具已经能够显著提升代码生成速度，但真正的瓶颈并未消失，而是从「人写代码慢」转移到「人盯 AI 的成本高」。当 Coding Agent 开始承担端到端开发任务时，如果构建失败仍需人工诊断、测试失败仍需人工修复、发布决策仍需人工审批，那么 AI 的产能释放就会被人的在线时间锁死。
高德智能应用与基建平台团队在「超级应用的 AI 原生研发模式探索」中给出的解法，是建设一条 7x24 AI-Native 生产线：人定义规则、边界与验收标准，AI 在规则内自主执行编码、构建、测试、修复、部署与经验沉淀，形成无人值守的研发交付闭环。
AI 全托管：从「人盯 AI」到「AI 盯 AI」
传统 AI Coding 模式下，工程师虽然用上了代码生成工具，但工作方式往往变成「以前盯代码，现在盯 AI」。AI 开工的前提是人在线，AI 卡住后需要人补上下文，AI 产出后需要人集成、调试、补测试。这种模式下，单人同一时间通常只能推进一个任务，效率提升更多是局部提效，而不是生产模式变化。
AI 全托管模式要解决的核心问题，是让 AI 从「需要人实时在场」变成「可被异步验收」。工程师在下班前提交一条需求描述，托管系统自动完成任务理解、任务拆解、编码实现、测试验证与提交 CR；第二天早上，工程师面对的是完整的 PR、测试报告和变更说明，而不是尚未集成的代码片段。
这一模式的关键架构是自监控循环，即 Self-Monitoring Loop。Coding Agent 负责编写代码，监督 Agent 负责全程监控执行状态。当执行卡住时，监督 Agent 自动恢复；当缺少上下文时，监督 Agent 自动拉取相关信息；当任务完成时，系统输出可审查的 PR 与测试报告。
这种设计带来三个变化：
- AI 的有效生产时间从工程师的 8 小时工作日扩展到 7x24 小时。
- 工程师从执行操作转向审查决策，单位注意力可以覆盖更多并行任务。
- 交付物从代码片段升级为可合并的完整 PR，减少人工集成成本。
该团队在落地时设定了较克制的边界：不重新造一套 Agent，而是复用已有成熟 Coding Agent 能力；不搭建独立云平台，而是优先使用本地工具链；不追求大而全，而是聚焦「能输出可合并 PR」这一核心交付闭环。这种最小可行边界让系统能够以周为单位迭代验证。
从材料披露的信息看，全托管模式能够成立，依赖三个条件同时成熟：模型能够稳定完成长序列任务；工具链能够让 AI 自己写代码、运行、观察结果并作出判断；平台本身已经具备真实工程师验证过的 Coding Agent 基础，只需增加托管调度层。
Agent 驱动 CI/CD：流水线从规则引擎变成语义执行系统
传统 CI/CD 流水线本质上是规则驱动的自动化管道：触发条件、执行逻辑、失败处理大多依赖人工预设。当 AI Agent 以 7x24 节奏持续提交代码时，这种模式的局限会被放大。条件组合复杂、人工响应延迟、运维经验难以沉淀，都会成为无人化交付的瓶颈。
高德团队的做法，是把 CI/CD 流水线升级为 Agent-aware 体系。其核心不是继续增加 if-else 规则，而是让 AI 理解每一次提交的意图，并据此决定构建、测试与发布策略。
在这一体系下，AI 会对代码提交进行语义解析，并结合依赖图谱计算影响范围。例如，UI 文案修改可以只跑 UI 相关回归；核心模型变更则扩大测试范围并触发性能基准测试。功能新增、Bug 修复、性能优化、安全补丁、纯重构等不同类型提交，会触发不同的验证路径。
这种语义化触发替代了原本需要工程师在 GUI 中手动配置的规则。流水线不再只是执行固定脚本，而是根据当前上下文动态决定「构建什么、验证什么、防控什么」。
在多端场景中，AI 还会协调 Android、iOS、HarmonyOS 多平台并行构建，处理条件编译与签名差异，并在构建后执行多端一致性校验。对于超级应用而言，这类跨平台构建原本需要大量人工配置和重复操作，而 Agent 化流水线将其纳入统一交付链路。
流水线无人化还包括发布决策自动裁决。系统基于架构合规、安全扫描、性能回归等质量门禁形成多维评分，由 AI 判断变更是否可以进入下一环节。只有超出自动处理能力的问题，才会进入人工审查，并附带诊断报告与已尝试方案。
为了支撑这种持续决策，流水线维护一个全局上下文，覆盖代码层、执行层、历史层与环境层：
- 代码层：变更语义、影响范围图谱。
- 执行层：各步骤状态、产出物。
- 历史层：成功率、常见失败模式、性能基线。
- 环境层：集群资源利用率、队列深度。
上下文通过标准化协议在各环节间增量流转并自动压缩摘要，使 AI 在每个决策节点都能获得足够完整的信息视野。
Self-Healing 自修复：构建失败不再等待人工介入
7x24 生产线能否真正无人值守，关键不在正常路径是否顺畅，而在异常路径是否能自动闭环。构建失败、测试失败、依赖缺失、运行时异常，都是大规模工程中高频发生的问题。如果每次异常都需要人工介入，生产线仍然无法脱离人的在线时间。
高德团队在生产线中引入 Self-Healing 自修复机制，将失败处理分为三层。
第一层是静态诊断。系统分析构建日志和错误信息，针对编译错误、类型不匹配、依赖缺失等确定性问题直接生成修复补丁。这类问题通常有明确错误信号，适合自动化处理。
第二层是动态推理。对于运行时异常、测试断言失败等需要上下文理解的问题，Agent 会回溯代码变更历史、分析调用链路、参考相关测试用例的期望行为，再推理修复方案。这一步比静态诊断更复杂，因为它需要理解错误背后的业务语义和系统行为。
第三层是验证闭环。修复补丁提交后，系统自动触发新一轮构建和测试。如果一次修复未解决问题，Agent 会基于新的错误信息进行二次诊断，并在可配置的最大尝试次数内继续修复。超过限制后，系统才上报人工团队，并附带完整诊断报告与已尝试方案。
这种机制的价值不只是减少人工介入次数，更重要的是把失败处理变成生产线的内置能力。失败不再意味着流水线停止，而是进入「失败、诊断、修复、验证」的自愈循环。
在测试环节，系统还会区分真实 Bug 与 flaky test。对于不稳定测试，Agent 会识别其与真实代码问题之间的差异，避免无谓修复循环消耗资源。对于反复失败的测试用例，系统会进行聚类分析，识别共同根因，从而从修复个例走向消除类别。
质量效率双飞轮：质量门禁前移，避免 AI 速度制造系统熵增
AI 高速生成代码的另一个风险，是无约束产出导致系统复杂度上升。命名风格不一致、架构模式混用、隐式依赖蔓延、重复代码堆积，都会让短期速度红利被长期维护成本吞噬。因此，7x24 生产线不能只追求自动执行，还必须内置质量约束。
高德团队将质量保障从事后检查前移到事中防控。每一个进入流水线的变更都要通过多层 AI 质量门禁，包括架构合规性检查、安全漏洞扫描和性能回归检测。
架构合规性检查关注代码变更是否突破模块边界、依赖方向是否正确、接口契约是否兼容。这一步直接对抗 AI 生成代码可能带来的熵增问题，因为无约束生成往往倾向于用最短路径解决当前问题，而忽略整体架构一致性。
安全扫描集成 SAST/DAST 工具链，对新增代码进行实时分析。Agent 不仅识别已知漏洞模式，也结合上下文分析潜在风险，例如某个 API 调用是否可能被用于注入攻击，某个数据处理函数是否存在越权访问可能。
性能回归检测则针对关键路径变更运行性能基准测试，对比变更前后的指标变化。性能劣化超过阈值的变更会被自动拦截，并附带分析报告和优化建议。
在门禁之外，生产线还会持续收集构建、测试、部署过程中的数据，形成质量数据集。Agent 对这些数据进行聚类分析，识别频繁失败的测试用例、构建失败根因和代码质量趋势。通过这种方式，系统能够从「修复一个实例」进化到「消除一类问题」，并将修复模式沉淀为新的质量规则。
这就是质量效率双飞轮的逻辑：质量提升减少返工和故障处理时间，从而提升效率；效率提升又释放更多资源用于质量建设，进一步推动质量提升。两者形成正反馈，而不是彼此消耗。
Benchmark 评测体系：从任务完成率走向过程质量与架构一致性
无人值守交付并不意味着放弃度量。相反，当 AI 承担更多执行工作时，评测体系需要更完整地回答：AI 是否真的按规范交付？生成速度是否以架构漂移为代价？流水线是否具备长期可治理能力？
高德团队在 AI-Native 交付中引入面向执行过程的 Benchmark 评测，并结合结果导向评测，形成服务于规范迭代和交付治理的评测框架。
评测首先覆盖典型工程场景，而不是只测试孤立代码片段。材料中提到的场景包括 CRUD 类开发任务、复杂业务逻辑任务、跨模块协作任务、性能优化与重构任务。这些任务来源尽量贴近真实工程活动，例如真实 Issue 修复、CI 失败修复、重构需求和规范升级。
在指标设计上，评测不只看测试通过率，还包含多个维度：
- 结果指标：测试结果通过率、首次生成成功率。
- 结构指标：架构一致性得分、代码规范符合率。
- 过程指标：长时程执行中的上下文冗余、重复调用、无效步骤和过长执行链。
- 控制指标：系统可解释性、可中断性、可纠正性与可回滚性。
这种多维指标体系的意义在于，它把「AI 能不能完成任务」和「AI 是否以可治理方式完成任务」区分开来。对于超级应用而言，后者往往决定系统能否长期维护。
Benchmark 也不是一次性静态测试集，而是随规范、模型、工具链和项目形态变化持续扩展。任务会增量引入，场景会逐步覆盖端云协同、多 Agent、跨团队协作和高风险改动，指标体系也会在结果稳定后强化过程质量与控制保持维度。不同规范版本、Skill 配置和 Agent 编排方式可以进行纵向比较，用于判断哪些约束真正降低了返工与漂移，哪些流程提升了协作效率。
端云一体基建与统一规范：无人值守生产线的地基
7x24 生产线并不是孤立存在的流水线改造。它能够稳定运行，依赖两个前置基础：AI-Native 端云一体基建，以及 Spec as AIOS 的统一规范体系。
在能力底座层面，高德团队将端侧基础组件、高阶套件、工程模板，与云侧服务契约、接口协议、数据模型组织成机器可理解的标准表达。端侧采用「代码 + 知识规范 + Skills」三层结构，服务端则通过全自动流水线，把后端服务从源码自动转译为 Agent 可消费、可验证、可持续演进的 Skill。
这一层解决的是「AI 能不能找到正确能力、能不能正确调用、能不能可靠验证」的问题。如果接口语义模糊、文档碎片化、依赖关系隐式存在，AI 即使生成速度很快，也会在拼装基础设施时产生大量返工和幻觉。
在规范层面，团队将规范重构为 AI 可执行的操作系统。其核心包括仓库唯一真源、规范驱动开发和 AI 执行一致性。代码仓库不仅承载功能实现，也承载架构事实、业务规则和文档约束。AGENTS.md、README.md、架构文档、模块说明与代码共存，并通过自动化门禁验证一致性。
规范体系采用三级分层：全局规范层定义跨项目基线，项目规范层定义仓库操作手册，模块规范层提供局部上下文。AI Agent 执行任务时，按照从近到远的优先级参考模块规范、项目规范和全局规范。这种结构让多 Agent 并行生成时仍能保持架构风格、代码质量和文件组织的一致性。
生产线则在这两个基础之上释放产能。底座提供可复用积木，规范定义拼法，流水线负责 7x24 持续执行。三者共同构成从「AI 辅助写代码」到「AI 自主工业级交付」的完整路径。
从自动化流水线到自治研发系统
高德团队的 7x24 AI 生产线，并不是简单把 AI 塞进 CI/CD，而是重新定义研发流水线中的人机边界。人不再负责逐步触发、逐步审查和逐步修复，而是定义规则、设计架构、把控方向和验收结果；AI 则在规则内持续执行编码、构建、测试、修复、发布和经验沉淀。
这一模式的价值，不只在于延长生产时间，更在于把研发交付从依赖个人在线时间的协作系统，改造成可异步运行、可自动修复、可持续评测的自治系统。对于数亿用户、数百万行代码、数十团队协同的超级应用而言，这种改造的意义不仅是提效，也是控制系统熵增、沉淀工程知识、降低长期维护成本。
随着 Agent 能力和 Harness Engineering 持续演进，这类生产线还可能进一步走向更高自治：从自然语言需求直接到端到端交付、从单项目经验沉淀到跨项目复用、从固定发布流程到基于业务指标的自适应发布。研发组织的角色也会随之变化：工程师更多承担规则制定、架构设计与方向判断，而 AI 成为持续运转的执行引擎。
