汽车产业正从”软件定义”驶向”AI 定义”的深水区。在百万级代码、企业级SDK交付的工程场景下，我们面对的已不只是”AI 能不能写代码”的疑问，而是”AI 能否像工程师一样稳定交付”的工程命题。
过去数月，高德汽车业务中心进行了一场系统性实践。我们将这段旅程总结为四篇文章：
架构篇：搭建AI Native全链路流水线，让 AI 从”单点辅助”走向”端到端协作”；
知识篇：将深度耦合业务场景的知识体系化沉淀，让AI“懂业务”；
质量篇：以 Harness 约束与 AI 自测构建工业级质量防线，守住交付的确定性；
进化篇：以可观测驱动、持续自进化的 Loop Engineering，让研发体系成为活的有机体。
我们始终坚持一个信念——能力交给模型，秩序交给系统。这不是一次对单点工具的技术改良，而是一场面向 ToB 复杂工程的范式重构——让 AI 交付从”偶尔成功”走向”稳定可复现”，让研发体系从”静态工具集”进化为”自我迭代的工程生命体”。
希望这四篇分享，能与大家共同探讨 AI Native 时代下，汽车软件工程的新篇章。
一、企业级交付：AI编码的双重难关
汽车行业对软件的信任，是用极高的验证成本换来的:一款车型在量产前，主机厂往往要投入数百万公里的实车路测，跨越数年、覆盖多样路况与极端工况。如此庞大的路测投入与漫长周期，正意味着上车的每一行代码都要经得起长期、真实场景的反复检验——缺陷必须在量产之前被充分暴露与收敛。此为第一重难关。
第二重难关来自 SDK 形态：AutoSDK ToB 导航 SDK产品，累计百万行 C++ 存量代码，有大量车企客户基于它进行二次开发并已量产交付，任何 Breaking Change 都可能触发下游数十家车企的连锁反应，甚至影响已量产车型的产线节奏和 OTA 计划。这种车规级交付的硬约束意味着 AI 生成的代码不仅要”能跑”，还必须通过 API 兼容性校验、向后兼容评估等层层把关。这不是效率问题，而是关乎产品可靠性与商务承诺的质量红线。因此，以单点生成见长的通用 AI Coding 能力，并不能很好地适配 AutoSDK，我们的落地关键不仅要考虑 AI 编码的能效提升，还需要能满足行业交付标准并抑制不可控性，形成真正的企业级交付。
二、构建ToB领域的AI Native解法：以工程化让交付标准长在AI能力里
交付标准并非不存在，而是长期以隐性约束的形态，散落于人脑、流程与客户协议之中。传统 AI 编码的”生成加事后把关”模式靠人力兜底，一旦规模化便审核不及、质量随人波动。
我们的解法，是以工程化让交付标准长在 AI 能力里：将隐性标准转化为 AI 可感知、可执行、可验证的显性规则，内生为其输入、约束与自校验闭环。其核心理念可概括为以领域知识为锚、以工程治理为纲、以数据闭环为驱，沿领域、流程、质量、配套与追溯逐层内建，并持续自进化。
基于此，交付标准才能真正生长在 AI 能力之中，形成 AI Coding 可控、可信、可追溯且可持续迭代，跨越由”能用”至”生产可用”的鸿沟。
三、AI Coding构建方案 : 从交付标准到工程落地
企业级 AI Coding 的关键，是把每一项交付标准从 AI 外部的事后检查，前置为 AI 内化的输入、约束与自校验。
为此，我们构建了”三纵一横”的 AI 工程解决方案：
- 流程一致：确保 AI”守规矩”，把成熟的研发纪律固化为 AI 必须沿循的运行路径；
- 领域深化：确保 AI”懂行”，把行业与业务的隐性知识内化为 AI 的认知底座；
- 质量守护：确保 AI”靠得住”，实施四层漏洞守护机制、逐层拦截，让质量由体系保证；
- 可观测与自进化：确保 AI”持续变好”，让整条链路的执行过程可见、可度量、可归因，再以数据闭环反哺前述三纵，使整套能力随任务演变不断迭代。
三纵沿研发链路顺序展开：领域深化在前端为 AI 立起认知底座，流程一致在中段规定其行进路径，质量守护在各环节层层设防，标准由此被逐段内建进 AI 的每一步动作;一横则横切三纵之上，持续采集执行数据、度量交付效果，并把暴露出的问题回灌为领域知识的补全、流程的调整与守护规则的迭代。如此，三纵把标准写进过程、一横让标准随运行不断校准，整个系统在”内建标准 → 执行生成 → 观测度量 → 反哺优化”的循环中自我运转——AI 便始终带着标准工作，且越跑越准。
这四条里，”流程一致”是地基：流程立不住，懂行、靠谱、能自进化都无从谈起。所以我们从它讲起——从意图识别到自测的全链路，如何被复刻成一条可稳定运行的流水线。
流程一致 : 把研发流水线复刻进 AI
软件的交付从来不是一步生成，而是遵循一条成熟的研发流程：意图识别、DDD 设计、编码、自测，环环相扣。这条流程沉淀的是工程纪律，不会因为实现者从人变成 AI 就消失或缩短——它只会依据新的人机协同关系被重新分工与优化。让 AI”守规矩”，第一步就是把这条流程复刻成一条能稳定运行的流水线：先建流水线，再谈提效。
1. 为什么先建流水线，再谈提效
让 AI 写好一个函数不难，难的是稳定交付一个完整的 SDK 功能。差别不在模型能力，而在有没有一条完整的交付流水线：
由人串联全链路，人就成了不可靠的”信息中转站”；
把流转交给系统，交付才能从”偶尔跑通”变成”稳定可复现”。
举个例子，给车载导航 SDK 加一个”电子眼提醒”，PRD 也许只有三行字，却要走完理解业务、探索代码、设计方案、编写实现、跑通验证一整条链路，一环都不能少。人来串联时，每轮对话都得重新交代背景，上一轮已理解的约束换一轮就忘——于是三个断裂随之暴露 :
- 上下文靠人手动搬运，搬漏就出偏差；
- 跨仓库的接口约束中途发现、后半段又遗忘；
- 过程没有完整记录，出了问题只能凭记忆倒推。
根源在于人的上下文带宽有限 ： 多轮之间的依赖、版本与约束需要同时维护，其复杂度早已超出一个人能稳定把控的极限——跑一次能成功，跑十次大概率出错。
全链路的思路是把流转交给系统：上下文自动传递、产物自动落地、门禁自动判定通过或打回，人也就从”执行每个环节”变成”在关键节点做决策”。这好比从一个人盯着多条产线、进度质检全靠脑子记，升级成一座自动化工厂：流水线自动流转，每道工序有质检，异常自动报警。
2. 全链路架构：不是拼工具，是建流水线
全链路架构不是拼现成工具，而是先想清一次交付要经过哪些不可省略的阶段，再为每个阶段配一个执行角色和一个独立质检——像工厂里每道工序既有操作员也有质检员，不合格就地返工。
流程拆成意图识别、编排规划、代码调研、领域设计、编码实现、自动化验证六个阶段，由专职 Agent 接力。
每个执行 Agent 都外挂一个独立质检（Eval），并按”脚本秒级拦截 → 结构校验 → 领域深检”逐层递进，先用最便宜的方式滤掉明显不合规的产物。
其中，质检结论分成四态：通过、带警告通过、不通过（就地回环、超阈值才升级人工）、无法判定则交人决策。失败由此从不可控的意外变成受控事件，被约束在最小范围内消化。
此外，数据平面与控制平面严格分离：产物统一落地固定目录，Agent 之间只传路径、不传内容，信息通道从平方级压回线性增长。
而设计与编码这两道定调的工序，在机器质检之后再叠加一道人工确认(Human-in-the-loop) : 机器守”合不合规”的下限，人守”要不要这么做”的方向。
3. Multi-Agent : 边界比能力更重要
链路骨架已经搭好，但真正开始执行SDK需求，一批工程治理问题接连浮现。
它们大多不是模型能力不足，而是 AI 缺乏人类天然的自我约束。反复验证下来的一个判断是 : Multi-Agent 出问题，通常不是某个 Agent 能力不够，而是边界没划清——就像一支没有阵型的球队，人人都追着球跑，看似都在拼命，却没人守住自己该守的位置。
于是我们为每类角色划清边界，且发现”禁止事项”往往比”允许事项”更有效 :
- 入口只驱动、只透传，禁止自做分析设计；
- 编排只管调度与能力分配，禁止产出计划文档；
- 执行各守本阶段，禁止越权；
- 门禁只判定通过或打回，禁止修改产物；
- 文档聚合只汇总产物，禁止反向参与决策。
其中入口与编排最易失守。入口一旦顺手压缩需求，下游拿到的就不再是原始诉求，可追溯性就此断裂；编排逻辑则必须收在同一个 Agent 里，只定顺序、分配能力，不产出任何独立文档——没有文档就没有漂移。再叠加结构化契约：输出严格遵循约定格式、不夹带多余文字，上游用规则即可解析。
并行度按任务特点取舍，而非一味求快 : 调研可并行，开发与门禁强制串行。深业务库里，隔离成本往往高于并行收益——曾让两个独立开发任务并行，编译冲突与互相覆盖带来的返工，反而超过串行等待的时间。
4. Skill 分层 : 把领域经验从人脑里搬出来
边界划清后，Agent 的”专业能力”从哪来？答案是 Skill——它不是更长的提示词，而是把某领域经过验证的规则与操作流程封装成可复用、可版本化的工程资产，让团队最值钱的知识从”个人记忆”变成”可加载、可演进的资产”。
但能力不能一锅烩。我们把 Skill 分成通用、领域、流程三层，并立一条硬规矩：通用层不掺领域知识，领域层不含流程编排，流程层不重写通用能力——一旦跨层混用，Skill 就退化成”提示词补丁”，难复用也难维护。
分层后，对于Skill的绑定 : 为了避免同一需求两次跑出的能力组合可能不同，在编排阶段一次性锁定。预绑定把能力清单一次性写入 skill-bank.json，下游只能读取、无权自行加载，牺牲一点灵活性，换来可复现与可审计。
且对于Skill的使用权限，还有一层白名单 ：开发 Agent 只拿开发能力，设计 Agent 拿不到验证能力。它既防越权，也防大模型”把手上工具都用一遍”的幻觉扩张，强行把工具箱缩到最小必要集合。
此外，分层还带来演进上的好处 : Agent 是骨架，Skill 是可独立生长的肌肉。一次领域升级不改 Agent，只新增一个 Skill 并更新白名单——骨架长期稳定，能力每天小步迭代，新人加载 Skill 即可上手，积累不归零。
5. 交付可控 : 依赖走系统，执行分两层
多阶段、多依赖的复杂流程，容易让 AI 执行偏移或漏掉环节。早期尝试过把依赖写进plan.md，结果Agent反复改写、计划与执行逐渐分叉，几轮后置信度几乎归零。
因此，我们把执行顺序建模为一张有向无环图（DAG），且让依赖由任务系统承载，让系统成为唯一来源，执行者便无从篡改。
这张图还分粗细两层：高层任务图管住主链路”不跑偏”，保证长程任务不在后段涣散；低层任务图覆盖单个 Agent 内部步骤，保证”局部不遗漏”。
两层解耦、各自兜底——单个步骤失败不必整条主链路重跑，主链路调整也不会推翻所有细节。
至此，流水线的骨架就完整了：
- 阶段拓扑规定”走哪几步”；
- 执行/质检配对与门禁四态守住”每一步的出口”；
- 角色边界与契约通信划清”谁干什么、怎么交接”；
- Skill 分层沉淀”各自的专业能力”；
- DAG 与双层编排让”依赖与秩序由系统承载”；
- 它解决的核心问题始终只有一个——让 AI 交付从”偶尔成功”变成”稳定可复现”。
阶段性成效，与三个尚未回答的问题
把这条流水线真正跑在 AutoSDK 的日常交付上，最先兑现的是流程本身的价值：上下文不再靠人手动搬运、依赖不再中途丢失、每一步都有据可查，人也从”执行每个环节”退回到”在关键节点做决策”，交付随之从”偶尔跑通”变成”稳定可复现”——同一个需求换个人、换一天跑，结果不再飘。
在体感之外，业务效果上也有显著的变化 :
- 质量上，研发自测的效率及效果显著提升，较引入前缺陷漏出下降约 73%；
- 效率上，面对定义清晰、约束成熟的需求，端到端交付周期从月迭代转向周迭代；
此外我们也在持续观测更细颗粒度的指标，用来判断这条流水线是否真的越跑越顺 :
- 一是代码采纳率达到84%，编码工作的主要承担者已经从人转移到AI；
- 二是基于埋点统计的API规范遵守率达到80%，说明API规范已很好的融入AI Native能力中；
从体感、业务数据来看，整条链路的AI Native化已经初见成效。但骨架之上，还有三个问题尚未回答。
其一，AI 守得住流程，却未必懂这个行业、这个 SDK。流程保证了”按正确的步骤做”，不保证”做得对”。AutoSDK 百万行 C++ 存量代码里，复杂的业务全景、隐蔽的代码坑、跨仓的调用链路，大多是只存在于专家脑中的隐性知识——如何把它们沉淀成 AI 可消费、可演化的资产，并在每一步只精准喂给它最相关的上下文。
其二，跑通不等于交付得了。车规级的质量红线远不止”能跑对”：一次看似局部的改动，可能顺着公开头文件在组件边界扩散成兼容性隐患，触发下游数十家车企的连锁反应。Breaking Change 拦截、API 兼容校验、向后兼容评估如何层层设防，流水线里每阶段的 Eval 之外还要靠哪些手段协同兜底。
其三，这条非确定性的多 Agent 链路，如何越跑越准。链路一旦是黑盒，产出偏离预期时就难判断问题出在规划、上下文还是生成环节。怎样让全过程可见、可度量、可归因，再以数据闭环反哺前面这些能力，让它随任务演变持续自我校准。
这三个问题，恰恰是”跑通”之后真正决定交付质量的部分，每一个背后都藏着一串关键取舍与精巧设计，关系到AI编码的上限，将在后续专题文章中逐个展开。
四、面向交付的可控性，才是分水岭
当代码的正确性需要用”企业级”、”ToB 交付”来衡量时，”能写”和”可交付”之间隔着一道巨大的鸿沟。填平这道鸿沟的，不是更大的模型或更多的数据，而是将组织交付智慧——那些散落在评审会、Checklist、事故复盘中的隐性知识——编码为 AI 可感知、可执行、可验证的结构化规则，使其成为 AI 工作时的原生约束，而非事后检验的尺子。
AutoSDK的实践，揭示了一个反直觉的事实决定 AI 交付上限的，不是模型的能力边界，而是工程化的标准密度。
当标准真正从”人把关”变为”AI 自带”——被逐段内建进 AI 的每一步动作，并随运行不断校准——企业级交付才完成从经验驱动到 AI Native 的范式迁移。走到这一步，AI 不再是一个只管生成的代码生成器，而是一个带着交付标准工作的执行者：这不是用 AI 加速旧流程，而是让 AI 成为新流程本身。
本文作者@高德技术，原文https://mp.weixin.qq.com/s/5FLTrxNkiVwg9td_dHyQfA