本文介绍高德广告工程团队在 AI Native 研发、测试、运维和知识沉淀方向的阶段性实践。
我们的核心判断是：AI Native 不是“用 AI 写代码”，而是把研发体系设计成 AI 能持续参与、稳定执行、可验证、可复用、可进化的工程闭环。
围绕这一判断，我们把 Spec、知识、验收、执行状态、Skills 升级为与代码同等地位的工程产物，并通过广告 Harness、统一知识库、统一 SkillHub、Tool Gateway、Aone 沙箱和 Agent Team，逐步打通研发链、运维链和知识链。
当前，高德广告工程已经在 SDD、ATDD、垂类 Agent、Case 排查、巡检报警、Skills 建设等方向完成了一批真实探索；最近两周团队使用情况收集中，已覆盖 20+ 同学，并形成多条有效样本反馈，多数有效样本集中在 30%-60% 阶段性提效区间。与此同时，团队也暴露出知识库厚度不足、测试闭环不完整、长任务上下文丢失、复杂需求拆分不足、接口事实不可靠等问题。
这些问题反过来证明：AI Native 的核心不是换一个工具，而是补齐 Harness、知识库、测试验收、执行状态和治理闭环。
本文按“为什么、怎么做、做到哪儿”三层展开。
AI 在研发中的应用大致经历了三个阶段。
第一阶段是 Prompt Engineering，核心是让模型听懂人的意图。研发同学通过提示词让模型解释代码、生成代码、写单测、整理文档、辅助排查。这解决了很多局部效率问题，但很难承载复杂工程任务。
第二阶段是 Context Engineering，核心是让模型读到正确上下文。模型本身能力很强，但如果读不到业务规则、历史方案、接口事实、字段含义、上下游链路和测试口径，输出仍然不可靠。对广告工程来说，上下文质量往往直接决定 AI 产出质量。
第三阶段是 Harness Engineering，核心是让 AI 在有流程、有状态、有工具、有验收、有证据的工程环境中稳定工作。它关注的不只是模型怎么回答，而是任务如何启动、上下文如何注入、阶段如何推进、工具如何调用、测试如何反馈、结果如何归档、失败如何复盘。
所以我们对 AI Native 的理解是：
Prompt 解决局部表达问题，Context 解决事实供给问题，Harness 解决工程交付问题。
对高德广告工程来说，真正要解决的不是“某一段代码写得更快”，而是整个研发、运维、知识沉淀链路中的人工翻译、人工集成和人工兜底。
产品意图↓研发理解↓技术方案↓代码实现↓测试验证↓发布上线↓线上排查↓经验沉淀
每一步都可能发生信息丢失、口径偏差、重复沟通、上下文断裂和质量风险。AI 如果只停留在“帮我写代码”，最终会被卡在需求不清、知识缺失、测试不通、部署不通、上下文丢失和结果不可验证上。
这也是我们的基本判断：
模型能力决定上限，工程环境决定能不能稳定落地。
高德广告工程要解决的不是某一个单点 Agent 能力，也不是单纯的 Coding Agent，而是研发链、运维链、知识链如何通过 Agent Team 形成统一闭环。
因此，我们的目标不是让 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 都升级为与代码同等地位的工程产物。
只有这些要素都变成工程产物，AI 才能稳定地在工程体系里运行。
否则，AI 只能靠临时上下文猜测；上下文一断、需求一复杂、知识一缺失，就会退化成“看起来很聪明，但不可控、不可复盘、不可规模化”。
3.2 一套统一基建
围绕五类工程产物，我们建设一套统一 AI Native 基建：
各模块分工如下：
这套体系的关键，不是把某个工具做强，而是把工具、知识、流程、状态和证据组织成完整闭环。
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 之前的必要闸口。
5.1 过去的问题
过去研发完成代码后，常见问题是：
编译失败后再回头找 AI 修部署失败后再人工排查测试问题发现后再重新对话功能验证依赖人肉操作Diff / 性能 / 稳定性测试与研发链割裂
这导致 AI 开发看似很快，但实际交付仍然卡在测试、验证、修复和回归阶段。
5.2 已经形成的研发测试协作方式
统一 ATDD 流程已经明确了研发侧和测试侧的协作方式：
研发侧：输入 PRD / 方案设计 / 知识库 / 人工 Prompt输出研发 Spec / 代码 CR / 测试建议 Spec测试侧：输入研发阶段产物 + PRD输出编译结果 / 部署结果 / 功能 Case / Diff / 性能 / 稳定性测试结果
这说明测试不再是代码完成后的纯人工兜底，而是逐步进入 SDD 之后的研发闭环。
5.3 当前短板：测试闭环还没有完全打通
ATDD 方向已经跑起来，但还没有完全成熟。
一线反馈集中暴露出几类问题：
这些反馈说明，当前 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 才能从“看起来在诊断”升级为“基于证据在诊断”。
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 叶子文档
逐层缩小上下文范围，确保拿到“最小正确上下文”。
例如：
为了避免知识库变成“文档堆”，当前还配套建设了三类工程机制：
这意味着，知识库不是静态文档仓库，而是研发链、运维链和知识链的共同底座。Spec、Case、排查结论和项目经验都会通过门禁和审核机制进入知识库，再反过来支撑下一次需求理解、方案设计、代码开发、测试闭环和运维诊断。
7.4 SkillHub：把团队经验变成可复用动作
Skill 不只是 Prompt，而是可执行的工程工作协议。
它要规定：
什么时候使用需要哪些输入允许调用哪些工具禁止做什么何时必须暂停何时必须找人确认必须生成哪些产物完成标准是什么失败如何处理如何沉淀知识
统一 SkillHub 要沉淀的能力包括：
需求治理 SkillSDD SkillATDD SkillCR / Review Skill测试触发 SkillCase 排查 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，展现出较丰富的能力雏形。这里不把数字包装成最终成果，而是作为“能力覆盖面”的阶段性说明。
SkillHub 的长期目标不是“堆更多 Skill”，而是让团队经验可版本化、可评审、可复用、可评估。
高德广告不是在写概念，而是在用真实需求推动 Harness、知识库、Skills、测试和执行状态迭代。
8.1 三个典型场景
这几个案例的共同点是：AI 在逻辑梳理、方案设计、代码生成、迁移辅助上效果明显；但越靠近复杂链路、测试部署、历史知识和跨系统事实，越依赖工程基建补齐。
8.2 提效区间：不要包装成统一指标
从最近两周团队样本看，多数有效反馈集中在 30%-60% 阶段性提效区间。这里必须强调：这是团队使用反馈，不是严格实验统计。它更适合表达为“阶段性体感和样本观察”，而不是全团队统一效率指标。
8.3 当前真实卡点与工程动作
真实卡点比成功故事更重要，因为它们指向下一阶段工程化建设方向。
真实反馈不是“负面信息”，而是工程化迭代的输入。
8.4 当前阶段的真实结论
更准确的阶段性结论是：
SDD 是当前最先跑通的主链路ATDD / test 已打通，但需跟测试同学持续共建完善知识库是效果上限的核心约束Intake 是复杂需求进入 SDD 前的必要闸口长任务状态和 Trace 是复杂需求能否交付的关键运维 Agent 的核心不是自动给结论，而是证据化诊断
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 GatewayTraceArtifactKnowledge Delta验收标准评估样本
也就是说：
框架可以换，资产不能丢。
这不是悲观主义，而是对模型和工具演进速度的清醒认知。只有这样，团队才能在每一次模型 / 框架升级中，把广告工程的能力顺着迁移过去，而不是从零开始。
9.3 执行治理：Tool Gateway、Trace、Knowledge Delta
第八章列出的具体工程动作，在 Agent Team 平台上需要通过 Tool Gateway、Trace、Artifact、Knowledge Delta 等治理能力落地。这里不展开成完整架构，只保留核心原则。
Tool Gateway 解决：
谁能调用工具能调用什么工具调用前是否需要审批调用后如何审计失败后如何降级
Trace / Artifact 解决：
AI 不是只给最终答案每次执行必须能复盘过程每个关键产物必须能归档每次失败必须能定位阶段和原因
Knowledge Delta 解决：
Agent 不直接写正式知识库先生成候选知识带来源、证据、owner、置信度、有效期和冲突检查审核后再进入 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 能持续参与、稳定执行、可被验证、不断进化的工程闭环。
本文转载自@高德技术公众号，原文链接
https://mp.weixin.qq.com/s/BfMATkYSLgVWgsORHwmiSg