高德广告工程团队近期在 AI Native 方向上完成了一系列阶段性探索，覆盖了研发、测试、运维及知识沉淀等多个环节。本文旨在梳理这些实践过程与经验反思，供业界同仁借鉴与探讨。
首先，我们明确一个核心观点：AI Native 并非简单地“用 AI 写代码”，而是将整个研发体系设计成一个能够让 AI 持续参与、稳定执行、可验证、可复用且可进化的工程闭环。
基于这一认知，我们将 Spec（规格说明）、知识、验收标准、执行状态及 Skills（技能）等要素，从辅助性材料升级为与代码同等重要的工程核心资产。通过配合广告 Harness、统一知识库、统一 SkillHub、Tool Gateway、Aone 沙箱以及 Agent Team，我们逐步实现了研发链、运维链与知识链的高效串联。
目前，团队已在 SDD、ATDD、垂类 Agent、Case 排查、巡检报警及 Skills 建设等领域取得了真实落地成果。根据最近两周的团队使用样本来评估，多数有效反馈集中在30% 至 60% 的阶段性效率提升区间。同时，实践也暴露了不少短板：例如知识库深度不足、测试闭环尚不完整、长任务上下文信息容易丢失、复杂需求拆分不够到位、以及接口事实信息的可靠性有待提高等。
这些问题的出现，恰恰印证了我们的另一个判断：AI Native 的核心不在于更换工具，而在于将 Harness、知识库、测试验收、执行状态以及治理闭环这些基础设施全面补齐。
下面，我们将围绕“为什么、怎么做、做到哪儿”这三个层次进行详细阐述。
一、为什么不是“用 AI 写代码”，而是研发体系的升级
AI 在研发领域的应用大致经历了三个阶段的发展演变。
第一阶段是 Prompt Engineering（提示词工程）。核心在于让模型准确理解人的意图。通过编写 Prompt 来解释代码、生成代码、编写单元测试、整理文档以及辅助问题排查——这些功能确实能解决局部的效率问题，但难以支撑起复杂的工程任务。
第二阶段是 Context Engineering（上下文工程）。模型本身的能力已经不错，但如果无法获取到业务规则、历史方案、接口事实、字段含义、上下游链路以及测试口径等关键信息，其输出依然缺乏可靠性。对广告工程而言，上下文的质量往往直接决定了 AI 产出的最终效果。
第三阶段是 Harness Engineering（工程框架工程）。核心目标是让 AI 在一个拥有明确流程、状态管理、工具支持、验收标准及结果证据的工程环境中稳定工作。我们关注的不仅仅是模型如何回答，而是任务如何启动、上下文如何注入、阶段如何推进、工具如何调用、测试如何反馈、结果如何归档、以及失败如何复盘。
因此，我们对 AI Native 的理解可以概括为三句话：
Prompt 解决局部表达问题，Context 解决事实供给问题，Harness 解决工程交付问题。
对于高德广告工程而言，真正需要解决的问题不是“某一段代码写得更快”，而是要消除在整个研发、运维、知识沉淀链路中依赖人工进行翻译、集成与兜底的环节。从产品意图转化为研发理解，再到技术方案、代码实现、测试验证、发布上线、线上排查乃至经验沉淀——每一步都可能发生信息丢失、口径偏差、重复沟通、上下文断裂以及质量风险。如果 AI 仅仅停留在“帮我写代码”的层面，最终必然会被困在需求不清晰、知识缺失、测试不通、部署受阻、上下文丢失以及结果无法验证的困境中。
模型能力决定了效果的上限，而工程环境则决定了能否稳定落地。
高德广告工程需要解决的并非某一个单点 Agent 的能力，也不是单纯的 Coding Agent，而是如何通过 Agent Team 将研发链、运维链和知识链形成一个统一的闭环体系。
| 链路 | 当前问题 | 建设目标 |
| 研发链 | PRD、原型、行为 SPEC 等输入质量不稳定。需求到研发交付存在多次人工翻译过程。SDD、CR、测试、发布、归档等环节未形成完整闭环 | 建立从需求输入、Intake Gate、研发交付、CR/Review、测试验证、发布归档到知识沉淀的研发完整闭环 |
| 运维链 | 问题反馈、日志、告警、监控、Case、巡检等信号分散，排查过程依赖个人经验，故障复盘与处理经验的沉淀不足 | 构建统一的运维 Agent 与运维 Agent 矩阵，支撑单 Case 排查、告警诊断、日常运维、自动巡检、根因分析及处理建议 |
| 知识链 | 文档、代码、规则、历史案例、排查经验、测试证据分散，缺少适合 Agent 消费和复用的知识底座 | 构建以 K/S/T 为组织方式的广告知识底座，使研发、运维、评估知识可检索、可引用、可沉淀、可复用 |
因此，我们的目标不是让 AI 替代研发人员，而是重构人、AI 与系统之间的分工关系：
人：负责确定方向、划定边界、做出关键决策
AI：负责理解、生成、排查、执行、验证、沉淀工作
系统：提供知识、工具、状态、沙箱、审批、证据和评估支持
研发同学的工作重心将从“重复翻译和重复执行”转向更有价值的判断性工作：维护业务 Spec、定义验收标准、评审 AI 产物、补充边界场景、建设知识库、沉淀 Skills、治理质量与风险。这不是一次简单的工具升级，而是整个研发体系的结构性升级。
二、实践路径：从点状探索走向统一闭环
高德广告工程并非从零开始构建一个宏大愿景，而是从一批真实的应用场景出发，逐步将点状的 AI 能力收敛为一个统一的工程体系。
目前已经过验证的基础能力包括：
- SDD / gad-sdd-all 在真实项目中的成功验证
- ATDD 测试流程与测试 MCP 的成功对接
- gad-sdd-all / gad-atdd-all / gaode-ad-rd-test 等 Skill 的实践应用
- Case 排查、巡检报警、品牌广告全链路排查等垂类 Agent 的探索
- UMA / TPP / Aone 等测试平台的接入方向
- 知识库和 Skills 仓库的初步成果沉淀
当前正在收敛的统一能力包括：将多 Skill 仓库整合为统一 SkillHub，将零散知识文档整合为 K/S/T 知识底座，将工具直连方式统一为 Tool Gateway，将一次性 Agent 输出规范化为 Trace / Artifact，将经验总结转化为 Knowledge Delta，将本地使用方式迁移至平台 Runner + 任务入口，将点状 Agent 聚合为 Agent Team。
这里需要特别强调：当前平台 Runner 方向优先收敛到 OpenCode，但这并不等同于强制统一所有个人的研发入口。像 Claude Code 等个人研发入口仍然可以保留。我们的长期原则是框架可替换、资产不可替代。
三、核心思路：五类工程产物 + 一套统一基建
3.1 五类工程产物
整套体系的底层心智可以概括为一句话：将 Spec、知识、验收、执行状态、Skills 都升级为与代码同等重要的工程产物。
| 类型 | 过去的状态 | 升级为工程产物后的状态 |
| Spec | PRD、钉钉文档、口头沟通，以自然语言为主，前后容易产生矛盾 | 结构化的 proposal / design / spec / tasks，包含目标、非目标、影响范围、风险、验收标准 |
| 知识 | 散落在文档平台、代码仓库、个人经验和聊天记录中 | 统一的知识库，支持分层索引、自动注入、证据引用、审核更新 |
| 验收 | 依赖人工 CR、灰度兜底、发现问题后再修复 | ATDD、测试建议、编译部署、冒烟、Diff、性能、稳定性等反馈闭环 |
| 执行状态 | Agent 会话中断后信息丢失，跨窗口无法记忆，难以恢复 | Harness 状态机、中间产物落盘、Trace、Artifact、Sidecar 记录 |
| Skills | 个人技巧、Prompt 片段、经验脚本 | 统一 SkillHub，可版本化、可评审、可分发、可复用 |
只有当这些要素都成为了工程产物，AI 才能在工程体系内稳定运行。否则，AI 只能依靠临时的上下文进行猜测；一旦上下文中断、需求变得复杂、知识出现缺失，AI 就会退化为“看起来很聪明，但不可控、不可复盘、不可规模化”的工具。
3.2 一套统一基建
围绕五类工程产物，我们建设了一套统一的 AI Native 基础设施。
各模块的具体分工如下：
这套体系的关键，不在于把某一个工具做得非常强大，而在于将工具、知识、流程、状态和证据组织成一个完整的闭环。
四、广告 Harness：让 SDD 变成可机器校验的工作流
4.1 为什么需要广告专属的 Harness
通用的 SDD / OpenSpec 可以解决一部分问题，但广告工程的复杂性决定了我们不能仅依赖通用骨架。广告场景涉及召回、排序、出价、计费、客资、反作弊、投放平台等众多复杂链路。一个需求往往不只是改动一个接口，而是跨系统、跨数据、跨策略、跨测试、跨发布的综合性变更。
如果 Spec 只是自然语言文档，AI 在面对以下问题时将会失控：需求是否完整？哪些字段是硬性约束？哪些边界必须进行验收？哪些业务规则不能打破？哪些测试必须执行？哪些变更需要人工确认？哪些知识需要回写？
因此，我们在通用 OpenSpec 风格工件的基础上，叠加了广告工程自己的 Harness 约束：包括强类型 Spec、阶段门禁、ATDD、测试证据、知识沉淀以及回流机制。
4.2 已得到验证的核心机制
gad-sdd 的核心并非“生成一份设计文档”，而是把 SDD 转变为一个可由机器校验的工作流。
这类机制的价值在于：AI 不再是“根据当前上下文自由发挥”，而是在一个设有门禁、有明确产物、有状态管理、有人工确认节点的工程流程中工作。
4.3 状态机：解决 AI 长周期任务容易中断的问题
一次需求的交付可以被抽象为六个阶段：start（启动新需求）→ spec（规格成文）→ apply（编码实现）→ test（ATDD 闭环）→ archive（归档变更）→ kb-flow（知识回流）。任何阶段都可以触发 clarify（澄清）子流程。
每个阶段都包含四个关键要素：进入门禁（满足什么条件才能进入该阶段）、产物清单（必须落盘哪些中间文件）、退出门禁（通过什么验证才能前进）、状态记录（如何实现跨窗口恢复、复盘和归档）。
来自一线团队的反馈中，“上下文记忆丢失”“大型项目时间周期长，每次小改动都需要重新总结”“思考时间过长”等问题非常典型。这正是 Harness Engineering 要解决的核心问题：模型的能力可以持续进化，但工程系统的状态、记忆和检查点必须由 Harness 来提供。
4.4 Intake Gate：AI Native 研发链的入口闸门
复杂的需求不能直接交给 Agent 去写代码。研发链的入口必须先进行 Intake（需求准入）。Intake Gate 需要将 PRD、原型、行为 SPEC、验收口径、Non-Goals、上下游影响范围整理成可执行、可追踪、可确认的研发输入。
它主要负责：评估需求完整度、识别业务目标、判断影响范围、召回缺失信息、生成澄清问题、拆分需求、明确 Non-Goals、提供优先级建议，以及做出准入、打回或待澄清的判断。
Intake 不是“可选项”或“增强项”，而是进入 SDD 之前的必要闸口。
五、ATDD：让测试从“事后动作”进入研发闭环
5.1 过去存在的问题
在过去，研发完成代码后，常常会遇到以下问题：编译失败后再回头找 AI 修复，部署失败后再进行人工排查，测试问题发现后需要重新进行对话，功能验证依赖人工手动操作，Diff、性能、稳定性测试与研发链相互割裂。这导致 AI 开发看起来速度很快，但实际交付过程依然卡在测试、验证、修复和回归这些环节上。
5.2 已形成的研发测试协作方式
统一的 ATDD 流程已经明确了研发侧和测试侧之间的协作方式：
- 研发侧：输入 PRD / 方案设计 / 知识库 / 人工 Prompt，输出研发 Spec / 代码 CR / 测试建议 Spec
- 测试侧：输入研发阶段产物 + PRD，输出编译结果 / 部署结果 / 功能 Case / Diff / 性能 / 稳定性测试结果
这表明，测试不再是代码完成后的纯粹人工兜底，而是逐步进入了 SDD 之后的研发闭环之中。
5.3 当前存在的短板：测试闭环尚未完全打通
ATDD 方向已经启动运行，但还未完全成熟。来自一线的反馈集中暴露了几类问题：
| 问题 | 表现 |
| 测试未被充分使用 | 部分需求并未真正执行 test 阶段，或者测试耗时过长 |
| 部署/编译环境未完全打通 | TPP、US 等场景存在自动部署、编译、功能测试不完整的问题 |
| 功能测试生成不足 | 需求对应的冒烟用例及定制化功能测试仍需人工补充 |
| Diff / bug 修复未形成闭环 | Diff 报告分析、bug 自动修复及复验流程仍需加强 |
| 测试进度感知较弱 | 环境搭建后，编译 / Diff 阶段的通知和状态感知能力不足 |
这些反馈说明，当前 ATDD 的重点不在于再次证明“能够跑测试”，而是要将测试结果结构化地回流到研发闭环中。下一步需要完成以下工作：将测试失败结果结构化地回传至研发侧，将测试证据纳入 Trace / Artifact，将复验结果作为归档门禁，将高频测试失败沉淀为 Knowledge Delta，补齐环境适配矩阵，增强功能测试/冒烟/Diff 分析能力。
这一步的关键价值在于：AI 不仅要能写代码，还要对最终的交付结果负责。
六、运维链：从经验排查走向证据化诊断
6.1 运维链已有真实场景验证
在运维和业务诊断方向，我们已经开展了多个垂类 Agent 的探索，包括 Case 排查、巡检报警、品牌广告全链路排查、客资助手等。AI 在运维链上已经不再仅仅局限于“问答”，而是开始进入真实的问题排查、日志分析、业务诊断和处理建议等场景。
6.2 运维链的关键认知
广告运维的难点并非“没有日志”或“没有监控”，而是信息分散且严重依赖个人经验进行串联。一个线上问题往往需要同时审查：用户反馈、商家反馈、日志、指标、告警、链路拓扑、近期变更、Case 历史、配置、策略和代码。这种情况非常适合 Agent Team 的介入：工具负责提供事实信息，Agent 负责将这些信息串联、解释、归因并生成处理建议。
6.3 运维 Agent 矩阵
下一阶段，运维链不应只是一个问答机器人，而应形成一个完整的 Agent 矩阵。
运维链必须坚持一个原则：Agent 的结论并非事实源，日志、指标、变更、Case、巡检结果才是真正的事实源。Agent 负责三件事：找到应该查什么，将查到的事实信息串联起来，给出诊断结论、影响范围、处理建议以及治理项。
最终的产出应包括：诊断结论、影响范围、证据链、根因分析、处理建议、稳定性治理项以及 Knowledge Delta。
6.4 运维链当前的卡点
运维链的主要短板并非“没有 Agent”，而是事实链路还不够完整：告警与业务场景的关联不足、指标与链路拓扑的关联不足、多次报警和投放策略调整之间缺少可被 AI 检索的关系、历史处理经验和 SOP 不完整、Case、变更、指标、配置之间没有统一的事实图谱。
这本质上是需要将运维领域的K（事实知识）做扎实。只有将场景、指标、链路、变更和 Case 这些事实构建成一个可以被 AI 检索的网络，Agent 才能从“看起来在诊断”升级为“基于证据在进行诊断”。
七、知识库与 SkillHub：效果上限与组织复利
7.1 知识库是当前效果上限的核心约束
AI 能否高效完成研发任务，很大程度上不取决于模型本身，而取决于它能够读取到什么上下文。广告工程的知识分散在多个系统中：KBase、钉钉文档、Aone、代码仓库、历史 CR、故障复盘、个人经验、运维记录等。
在团队使用反馈中，知识库不足是最集中的卡点之一：例如客资链路的字段映射薄弱、历史方案缺失、离线任务链路缺乏统一维护、告警诊断无法关联业务场景和指标、接口事实不可靠等问题反复出现。因此，统一知识库并非装饰性项目，而是影响 AI Native 效果上限的关键约束条件。
7.2 K/S/T：按知识用途进行组织，而非按文档来源堆积
我们按照 K/S/T 的方式组织知识：
K/S/T 的价值在于：AI 不仅仅是“搜索文档”，而是能够明确当前任务需要的是事实、规范还是任务经验。
7.3 广告工程知识库：K/S/T + 5 层业务分层
K/S/T 是知识的用途分类，回答“这条知识用于什么”；5 层业务分层是知识的工程组织方式，回答“这条知识应该放在哪里、在哪个研发阶段被消费”。两者相互支撑：
- K/S/T：事实 / 规范 / 任务
- 5 层分层：语义 / 架构 / 服务 / 项目 / 运维
广告工程知识库当前采用 5 层结构：
AI 在处理任务时，不会对整个知识库进行 Dump，而是按照以下顺序进行检索：研发阶段 → 优先读取的层级 → 当前业务域 → L3 专题 → L4 叶子文档，逐层缩小上下文范围，确保获取到“最小且正确的上下文”。
例如：
| 研发阶段 | 优先读取的层级 |
| 需求门禁 | 业务语义层、业务项目层 |
| 需求理解 | 业务语义层、业务架构层、业务项目层 |
| 方案设计 | 业务服务层、业务架构层、业务项目层 |
| 代码开发 | 业务服务层、业务项目层 |
| 测试闭环 | 业务服务层、业务项目层 |
| 线上运维 | 业务运维层、业务服务层、业务架构层 |
为了避免知识库变成“文档的堆积”，目前我们还配套建设了三类工程机制：
| 机制 | 实现方式 | 作用 |
| 写入门禁 | 文档模板在发布前强制进行 Schema 校验 | 保证知识结构合规，防止低质量知识进入知识库 |
| Case 反馈闭环 | 需求增强、架构拆解、运维事件等 Case 自动沉淀 | 将实战经验反哺给知识库 |
| Spec 同步 | global_spec / service_spec 独立同步 | 保障全局规约和服务规约的持续更新 |
这意味着，知识库不是一个静态的文档仓库，而是研发链、运维链和知识链共同的基础底座。Spec、Case、排查结论和项目经验都会通过门禁和审核机制进入知识库，然后反过来支撑下一次的需求理解、方案设计、代码开发、测试闭环和运维诊断。
7.4 SkillHub：将团队经验转化为可复用的动作
Skill 不仅仅是 Prompt，而是一种可执行的工程工作协议。它需要规定：何时使用、需要哪些输入、允许调用哪些工具、禁止做什么、何时必须暂停、何时必须找人确认、必须生成哪些产物、完成的标准是什么、失败如何处理、以及如何沉淀知识。
统一 SkillHub 需要沉淀的能力包括：需求治理 Skill、SDD Skill、ATDD Skill、CR/Review Skill、测试触发 Skill、Case 排查 Skill、知识沉淀 Skill、发布检查 Skill、工具适配 Skill。
目前，我们已经拥有 gad-sdd-all、gad-atdd-all、gaode-ad-rd-test 等实践基础，并建立了统一的广告工程 Skill 仓库 gaode-ad-skills，正在逐步收敛为统一的 SkillHub。
7.5 当前 Skills 全景
当前 gaode-ad-skills 已经沉淀出 50 多个 Skill，展现了较为丰富的能力雏形。此处不将数字包装为最终成果，而是作为“能力覆盖面”的阶段性说明。
| 类目 | 代表能力 | 解决的主要问题 |
| 研发流程 | gad-sdd-all、gad-atdd-all、OpenSpec 相关 Skill | 端到端的研发工作流支持 |
| 产品输入治理 | gad-product-intake、PRD enhancer | 提升需求输入质量和进行准入管理 |
| 知识库 | KB 检索、文档索引、知识发布 | 提供最小且正确的上下文 |
| 测试/部署 | gaode-ad-rd-test、pre-push check、deployment check | 提供测试与部署的反馈 |
| 故障排查 | ad-server troubleshooting、计费 / oCPC / 客资排障 | 支持运维诊断 |
| 配置查询 | Diamond、Libra、A/B 实验查询 | 获取配置事实信息 |
| 代码审查 | code-review、remote review | 发现 CR / MR 中的风险 |
| 元工具 | skill 管理、skill 创建、聊天转 skill | 提升 SkillHub 的生产效率 |
SkillHub 的长期目标不是“堆积更多的 Skill”，而是让团队经验实现可版本化、可评审、可复用、可评估。
八、真实反馈闭环：典型案例、效率提升区间、实际卡点
高德广告工程并非在撰写概念，而是通过真实需求来驱动 Harness、知识库、Skills、测试和执行状态的迭代优化。
8.1 三个典型场景
| 场景 | AI 参与阶段 | 收益口径 | 暴露的问题 |
| 品牌广告旧索引下线/配置清理 | Intake / SDD / ATDD 全流程 | 从约 1 天缩短至约 0.5 天，完整跑通链路 | 测试阶段有少量需要 owner 跟进的小问题 |
| openCreativeChain 迁移 | 知识库建设 / 方案设计 / 代码开发 | 主要收益体现在历史逻辑梳理、迁移方案生成和代码开发辅助，迁移周期明显缩短 | 长任务上下文、人工审核、部署链路仍需进一步补齐 |
| 汇川 ADX 程序化接入 | 历史逻辑梳理 / 方案设计 / 代码开发 | 逻辑梳理阶段反馈效率提升约 50% | ODPS / Flink / 脚本链路的知识缺口较大 |
这几个案例的共同特点是：AI 在逻辑梳理、方案设计、代码生成、迁移辅助等方面效果显著；但越是靠近复杂链路、测试部署、历史知识和跨系统事实的环节，就越依赖于工程基础设施的完善。
8.2 效率提升区间：避免包装成统一指标
从最近两周的团队样本来看，多数有效反馈集中在30% 至 60% 的阶段性效率提升区间。这里必须强调：这是基于团队使用体验的反馈，并非严格的实验统计数据。它更适合描述为“阶段性的体感和样本观察”，而非全团队统一的效率指标。
8.3 当前真实卡点与对应的工程动作
真实的卡点比成功故事更具价值，因为它们指向了下一阶段工程化建设的方向。
| 真实反馈 | 暴露的问题 | 对应的工程动作 |
| PRD 过于庞大，上下文占用高 | 输入未进行结构化处理 | Intake 增加需求拆分、Non-Goals、验收口径确认 |
| HSF 接口被 AI 自行构造 | 接口事实信息缺失 | 建设接口事实库，通过 Tool Gateway 提供可信的接口查询 |
| test 未使用或能力不足 | 验收链路薄弱 | ATDD 补充功能测试、冒烟、Diff 分析、复验闭环 |
| TPP / US 无法自动部署编译 | 环境未完全打通 | 补充仓库/环境适配矩阵 |
| 告警诊断无法关联指标 | 运维事实链路不足 | 建设场景-指标-链路-变更的事实网络 |
| 上下文丢失、长任务执行缓慢 | 执行状态不可持续 | Trace / Artifact / session 状态沉淀 |
| AI 自行进行 git commit | 行为约束不足 | 在 Skill 中明确禁止动作，关键操作必须经人工确认 |
| 默认跑错 Skill 或使用旧流程 | Skill 路由不稳定 | SkillHub 统一路由、版本、触发条件和强制入口 |
真实的反馈并非“负面信息”，而是驱动工程化迭代的重要输入。
8.4 当前阶段的真实结论
更为准确的阶段性结论是：
- SDD 是当前最先跑通的主链路
- ATDD / test 已实现打通，但仍需与测试同学持续共建完善
- 知识库是决定效果上限的核心约束
- Intake 是复杂需求进入 SDD 前的必要闸口
- 长任务状态管理和 Trace 是复杂需求能否顺利交付的关键
- 运维 Agent 的核心不在于自动给出结论，而在于基于证据进行诊断
九、下一阶段平台化方向：Agent Team 与可治理的执行
9.1 从点状 Agent 到 Agent Team
下一阶段的目标，是将研发链、运维链和知识链纳入统一的 Agent Team 平台。我们将围绕三条链进行建设：
- 研发链：需求输入 → Intake → SDD → ATDD → CR → 测试 → 发布 → 归档
- 运维链：信号 → 分流 → 排查 → 诊断 → 处理建议 → 治理项 → 回流
- 知识链：Artifact → Knowledge Delta → 审核 → K/S/T → 再注入
近期的重点不在于铺满 Agent 的名称，而是优先建设六类核心能力：需求入口治理、研发交付、测试验证、运维诊断、知识沉淀、治理评估。每类能力都需要有清晰的输入输出、工具权限、风险边界、证据要求以及归档机制。
9.2 平台 Runner 与多 Harness 的可替换性
当前平台 Runner 方向优先收敛到 OpenCode，同时保留 Claude Code 等个人研发入口和回退路径；长期来看，我们不会绑定单一框架，真正需要沉淀的是广告工程自身的 Spec、知识库、Skills、测试门禁以及 Trace / Artifact。真正不可替代的是：Spec 结构、SkillHub、知识库、Tool Gateway、Trace、Artifact、Knowledge Delta、验收标准、评估样本。
一句话总结：框架可以更换，但资产不能丢失。
这不是悲观主义，而是对模型和工具演进速度的清醒认识。只有这样，团队才能在每一次模型或框架升级中，顺利地将广告工程的能力迁移过去，而不是从零开始。
9.3 执行治理：Tool Gateway、Trace、Knowledge Delta
第八章所列出的具体工程动作，在 Agent Team 平台上需要通过 Tool Gateway、Trace、Artifact、Knowledge Delta 等治理能力来落地实现。核心原则如下：
- Tool Gateway：解决谁能调用工具、能调用什么工具、调用前是否需要审批、调用后如何审计、失败后如何降级等问题。
- Trace / Artifact：AI 不能只给出最终答案；每次执行都必须能够复盘过程；每个关键产物都必须能够归档；每次失败都必须能够定位到具体阶段和原因。
- Knowledge Delta：Agent 不直接写入正式知识库，而是先生成候选知识，附带来源、证据、负责人、置信度、有效期和冲突检查信息，经过审核后再进入 K/S/T 体系。
这些能力的目标是让 AI 从“能干活”升级为“可治理地干活”。
十、下一步：从点状探索迈向统一平台
10.1 第一阶段：统一基建骨架形成（基本完成，持续完善中）
目标是为团队提供一套统一的基建平台进行工作。
当前状态：gad-sdd 主链路已经具备真实需求验证的基础；统一的广告 Skill 仓库已建立；K/S/T + 5 层知识库结构已经形成；ATDD 测试链路已打通，仍需与测试同学持续完善；Trace / Artifact / Knowledge Delta 正在向平台化能力收敛。
完成标志：对于中型及以上需求，gad-sdd 能够稳定跑通主链路；主链路的知识库内容覆盖度显著提升；ATDD 具备编译/部署/冒烟/Diff 的基本门禁能力；每次任务都有可追溯的 Trace 和可归档的 Artifact。
10.2 第二阶段：广告内部跨团队协作闭环（持续建设中）
目标是实现跨投放、引擎、计费、客资、平台、运维等团队的协同工作。
关键事项：总控 Agent 上线；将复杂需求拆解为多个子 Agent 任务；前置跨 Agent 的技术 Spec 和数据流转 Spec；使用 Mock Server 支持前置联调；任何子 Agent 的 ATDD 失败都能精准定位；运维 Agent 矩阵覆盖核心场景。
完成标志：对于中型以上的跨上下游需求，能够通过总控 Agent 进行任务拆解；研发、测试、运维结果能够汇总到统一的 Artifact / Knowledge Delta；跨团队的需求不再主要依赖人工同步上下文。
10.3 第三阶段：跨组织的端到端闭环
目标是打破工种之间的壁垒，让产品、研发、测试、运维、平台能够围绕统一的 AI Native 工程体系进行协作。
关键事项：实现跨业务线的 Agent 协同；接入跨端 MCP 与 Browser-use；增强 CodeWiki / LSP / 图谱能力；建设面向广告业务的评测集；让 AI 参与值班和告警 RCA；实现一键预案推荐，由人工进行最终确认。
完成标志：研发同学的工作重心将从翻译需求、查阅历史、编写重复代码、人工排查，实质性地转向维护 Spec、评审 AI 产物、治理质量以及沉淀知识。
这一步的目标不是“减少人员”，而是将人从重复翻译、重复编码、重复排查中解放出来，转向架构设计、质量保障、稳定性建设和工程创新。
结语
高德广告工程的 AI Native 实践，并非在讲述一个“AI 已经完全接管研发”的故事，而是一个更真实、更具工程价值的过程：我们已经跑通了一批点状能力，观察到了 30% 至 60% 的阶段性效率提升，也清晰地看到了在知识、测试、状态、接口事实、复杂需求拆分等方面存在的瓶颈——我们正在将这些瓶颈反向沉淀为 Harness、知识库、SkillHub、Tool Gateway、Trace 和 Agent Team。
这正是 AI Native 从“个人效率工具”迈向“组织工程能力”的关键路径。最终目标并非让 AI 替代人，而是让人从重复翻译、重复编码、重复排查中解放出来，将精力投入到架构判断、边界定义、质量治理、业务创新和平台建设上。
一句话总结：AI Native 的本质，不是让 AI 偶尔参与研发，而是将整个研发体系设计成 AI 能够持续参与、稳定执行、可被验证、不断进化的工程闭环。