---
title: 高德广告工程 AI Native 全流程提效实践：Spec/知识/验收/状态/Skills 五类工程产物 + K/S/T 知识底座 + Agent Team 平台化
source_url: https://mp.weixin.qq.com/s/BfMATkYSLgVWgsORHwmiSg
publish_date: 2026-06-15
tags: [wechat, article, agent, harness, sdd, atdd, skills, knowledge-base, ad-engineering]
review_value: 8
review_confidence: 8
review_recommendation: ingest
sha256: a9ea437db8f81db662fc0befd4c16eee5882cb3500a28c110b3b432cad7c22ae
---
# 高德广告工程 AI Native 全流程提效实践
> Source: https://mp.weixin.qq.com/s/BfMATkYSLgVWgsORHwmiSg
> Author: 信息业务中心 (高德技术公众号)
> Date: 2026-06-15
> Collected: 2026-06-16

## 导读：核心判断

**AI Native 不是"用 AI 写代码"，而是把研发体系设计成 AI 能持续参与、稳定执行、可验证、可复用、可进化的工程闭环。**

围绕这一判断，高德广告工程把 **Spec、知识、验收、执行状态、Skills 升级为与代码同等地位的工程产物**，并通过**广告 Harness、统一知识库、统一 SkillHub、Tool Gateway、Aone 沙箱和 Agent Team**，逐步打通研发链、运维链和知识链。

**当前进展**（2026-06-15）：
- SDD、ATDD、垂类 Agent、Case 排查、巡检报警、Skills 建设方向已有真实探索
- 团队使用覆盖 20+ 同学，多数有效样本集中在 **30%-60% 阶段性提效区间**（体感，非严格实验）
- 暴露问题：知识库厚度不足、测试闭环不完整、长任务上下文丢失、复杂需求拆分不足、接口事实不可靠

## 一、AI 研发的三个阶段

1. **Prompt Engineering**（2024前）：让模型听懂人的意图（局部效率，难承载复杂工程）
2. **Context Engineering**（2024-2025）：让模型读到正确上下文（业务规则、历史方案、接口事实、字段含义）
3. **Harness Engineering**（2025+）：让 AI 在**有流程、有状态、有工具、有验收、有证据**的工程环境中稳定工作

**核心论断**：Prompt 解决局部表达，Context 解决事实供给，Harness 解决工程交付。**模型能力决定上限，工程环境决定能不能稳定落地。**

## 二、三链闭环：研发链 / 运维链 / 知识链

| 链路 | 当前问题 | 建设目标 |
|---|---|---|
| 研发链 | PRD/原型/SPEC 输入质量不稳，多次人工翻译；SDD/CR/测试/发布/归档未闭环 | 需求输入 → Intake Gate → 研发交付 → CR/Review → 测试验证 → 发布归档 → 知识沉淀 |
| 运维链 | 信号分散（问题反馈、日志、告警、监控、Case、巡检），排查依赖个人经验 | 统一运维 Agent 矩阵：单 Case 排查、告警诊断、日常运维、自动巡检、根因分析 |
| 知识链 | 文档/代码/规则/历史案例/排查经验分散，缺 Agent 友好底座 | 以 **K/S/T** 为组织方式的广告知识底座 |

**人 / AI / 系统分工重构**：
- 人：定方向、定边界、做关键决策
- AI：理解、生成、排查、执行、验证、沉淀
- 系统：提供知识、工具、状态、沙箱、审批、证据和评估

研发同学工作重心转移：从"重复翻译和重复执行" → **维护业务 Spec / 定义验收标准 / 评审 AI 产物 / 补充边界场景 / 建设知识库 / 沉淀 Skills / 治理质量与风险**

## 三、五类工程产物

整套体系底层心智：**把 Spec、知识、验收、执行状态、Skills 升级为与代码同等地位的工程产物。**

| 类型 | 过去 | 升级后 |
|---|---|---|
| Spec | PRD/钉钉/口头，自然语言易矛盾 | 结构化 proposal / design / spec / tasks，带目标/非目标/影响范围/风险/验收标准 |
| 知识 | 散落文档平台/代码仓库/聊天记录 | 统一知识库，支持分层索引、自动注入、证据引用、审核更新 |
| 验收 | 依赖人工 CR/灰度兜底 | ATDD、测试建议、编译部署、冒烟、Diff、性能、稳定性反馈闭环 |
| 执行状态 | Agent 会话断了就丢，跨窗口失忆 | Harness 状态机、中间产物落盘、Trace、Artifact、Sidecar 记录 |
| Skills | 个人技巧、Prompt 片段、经验脚本 | 统一 SkillHub，可版本化、可评审、可分发、可复用 |

只有这些要素都变成工程产物，AI 才能稳定运行；否则会退化成"看起来聪明，但不可控、不可复盘、不可规模化"。

## 四、广告 Harness：让 SDD 变成可机器校验的工作流

### 4.1 为什么需要广告自己的 Harness

通用 SDD/OpenSpec 能解决一部分问题，但广告工程复杂性（召回/排序/出价/计费/客资/反作弊/投放平台）决定不能只依赖通用骨架。在通用 OpenSpec 风格工件之上，**叠加广告工程自己的 Harness 约束**：强类型 Spec、阶段门禁、ATDD、测试证据、知识沉淀和回流机制。

### 4.2 状态机：解决 AI 长周期任务跑断问题

六阶段状态机：
```
start → spec → apply → test → archive → kb-flow
```
任何阶段都可触发 **clarify 澄清子流程**。

每阶段四要素：**进入门禁 / 产物清单 / 退出门禁 / 状态记录**（跨窗口恢复、复盘、归档）。

一线反馈典型问题："上下文记忆丢失"、"大型项目时间周期长每次小改动都要重新总结"、"思考时间过长"。Harness Engineering 核心：**模型能力可进化，但工程系统状态、记忆、检查点必须由 Harness 提供**。

### 4.3 Intake Gate：AI Native 研发链的入口闸口

复杂需求不能直接交给 Agent 写代码。Intake Gate 把 PRD/原型/行为 SPEC/验收口径/Non-Goals/上下游影响范围整理成**可执行、可追踪、可确认**的研发输入：

- 需求完整度评估
- 业务目标识别 / 影响范围判断
- 缺失信息召回 / 澄清问题生成
- 需求拆分 / Non-Goals 明确
- 优先级建议
- 准入 / 打回 / 待澄清判断

**Intake 不是"可选增强"，而是进入 SDD 之前的必要闸口。**

## 五、ATDD：测试从"事后动作"进入研发闭环

### 5.1 协作方式

**研发侧**：输入 PRD/方案设计/知识库/人工 Prompt → 输出 研发 Spec/代码 CR/测试建议 Spec

**测试侧**：输入 研发阶段产物 + PRD → 输出 编译结果/部署结果/功能 Case/Diff/性能/稳定性测试结果

### 5.2 当前短板

| 问题 | 表现 |
|---|---|
| 测试未充分使用 | 部分需求没真正跑 test 阶段，或测试耗时过长 |
| 部署/编译环境未完全打通 | TPP、US 等场景自动部署、编译、功能测试不完整 |
| 功能测试生成不足 | 冒烟用例、定制化功能测试仍需人工补齐 |
| Diff/bug 修复未闭环 | Diff 报告分析、bug 自动修复、复验流程待加强 |
| 测试进度感知弱 | 编译/Diff 阶段通知和状态感知能力不足 |

下一步：测试失败结果结构化回流研发侧 / 测试证据纳入 Trace/Artifact / 复验结果作为归档门禁 / 高频测试失败沉淀为 Knowledge Delta / 环境适配矩阵补齐。

**关键价值**：AI 不仅要能写代码，还要对交付结果负责。

## 六、运维链：从经验排查到证据化诊断

### 6.1 运维链关键认知

广告运维难点不是"没有日志/监控"，而是**信息分散且依赖经验串联**。一个线上问题往往需要同时看：用户反馈/商家反馈/日志/指标/告警/链路拓扑/近期变更/Case 历史/配置/策略/代码。

适合 **Agent Team 介入**：工具负责提供事实，Agent 负责串联、解释、归因和生成建议。

### 6.2 运维 Agent 矩阵原则

**Agent 的结论不是事实源，日志、指标、变更、Case、巡检结果才是事实源。**

Agent 三件事：找到应该查什么 / 把查到的事实串起来 / 给出诊断、影响范围、处理建议和治理项

最终产出：诊断结论 / 影响范围 / 证据链 / 根因分析 / 处理建议 / 稳定性治理项 / Knowledge Delta

### 6.3 当前卡点

- 告警与业务场景关联不足
- 指标与链路拓扑关联不足
- 多次报警和投放策略调整之间缺少可被 AI 检索的关系
- 历史处理经验和 SOP 不完整
- Case、变更、指标、配置之间没有统一事实图谱

**本质是把运维领域的 K：事实知识 做扎实。**

## 七、知识库与 SkillHub

### 7.1 K/S/T：按知识用途组织（不是按文档来源堆积）

- **K**（事实知识）：业务事实、接口事实、字段映射、链路拓扑、配置事实
- **S**（规范知识）：编码规范、流程规范、CR 规范、测试规范、发布规范
- **T**（任务知识）：故障排查 SOP、迁移案例、设计模式、Skill 触发条件

K/S/T 价值：AI 不只是"搜文档"，而是知道当前任务需要**事实、规范还是任务经验**。

### 7.2 5 层业务分层

| 层级 | 内容 |
|---|---|
| 业务语义层 | 业务概念、产品语义 |
| 业务架构层 | 链路架构、上下游依赖 |
| 业务服务层 | 接口事实、字段映射、服务规约 |
| 业务项目层 | 项目结构、代码组织、配置 |
| 业务运维层 | 监控、告警、Case、巡检 SOP |

**K/S/T + 5 层分层 是互补关系**，不是替代：K/S/T 回答"用于什么"，5 层回答"放在哪里 / 哪个研发阶段被消费"。

### 7.3 最小正确上下文策略

AI 不做全库 Dump，而是按：**研发阶段 → 优先读取层 → 当前业务域 → L3 专题 → L4 叶子文档**，逐层缩小上下文范围。

| 研发阶段 | 优先读取层级 |
|---|---|
| 需求门禁 | 业务语义层、业务项目层 |
| 需求理解 | 业务语义层、业务架构层、业务项目层 |
| 方案设计 | 业务服务层、业务架构层、业务项目层 |
| 代码开发 | 业务服务层、业务项目层 |
| 测试闭环 | 业务服务层、业务项目层 |
| 线上运维 | 业务运维层、业务服务层、业务架构层 |

### 7.4 知识库门禁三机制

| 机制 | 实现方式 | 作用 |
|---|---|---|
| 写入门禁 | 文档模板发布前强制 Schema 校验 | 保证知识结构合规 |
| Case 反馈闭环 | 需求增强/架构拆解/运维事件自动沉淀 | 实战经验反哺 |
| Spec 同步 | global_spec / service_spec 独立同步 | 全局/服务规约持续更新 |

### 7.5 SkillHub：把团队经验变成可复用动作

**Skill 不只是 Prompt，而是可执行的工程工作协议**：什么时候使用 / 需要哪些输入 / 允许调用哪些工具 / 禁止做什么 / 何时必须暂停 / 何时必须找人确认 / 必须生成哪些产物 / 完成标准 / 失败如何处理 / 如何沉淀知识

统一 SkillHub 沉淀的能力：
- 需求治理 Skill、SDD Skill、ATDD Skill
- CR/Review Skill、测试触发 Skill、Case 排查 Skill
- 知识沉淀 Skill、发布检查 Skill、工具适配 Skill

### 7.6 当前 Skills 全景（50+ Skill）

| 类目 | 代表能力 | 解决问题 |
|---|---|---|
| 研发流程 | gad-sdd-all、gad-atdd-all、OpenSpec | 端到端研发工作流 |
| 产品输入治理 | 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"，而是让团队经验可版本化、可评审、可复用、可评估。**

## 八、真实反馈闭环

### 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 统一路由、版本、触发条件和强制入口 |

**真实反馈不是"负面信息"，而是工程化迭代的输入。**

## 九、平台化方向：Agent Team 与可治理执行

### 9.1 三链 Agent Team 平台

- **研发链**：需求输入 → Intake → SDD → ATDD → CR → 测试 → 发布 → 归档
- **运维链**：信号 → 分流 → 排查 → 诊断 → 处理建议 → 治理项 → 回流
- **知识链**：Artifact → Knowledge Delta → 审核 → K/S/T → 再注入

近期重点（六类能力）：**需求入口治理 / 研发交付 / 测试验证 / 运维诊断 / 知识沉淀 / 治理评估**

### 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/Artifact 解决**：
- AI 不是只给最终答案，每次执行必须能复盘过程
- 每个关键产物必须能归档
- 每次失败必须能定位阶段和原因

**Knowledge Delta 解决**：
- Agent 不直接写正式知识库，先生成候选知识
- 带来源、证据、owner、置信度、有效期和冲突检查
- 审核后再进入 K/S/T

**目标**：让 AI 从"能干活"升级为"可治理地干活"。

## 十、三阶段路线图

### 第一阶段：统一基建骨架形成（基本完成，持续完善）
- ✅ gad-sdd 主链路已具备真实需求验证基础
- ✅ 统一广告 Skill 仓库已建立（gaode-ad-skills）
- ✅ K/S/T + 5 层知识库结构形成
- 🟡 ATDD 测试链路打通，仍需测试同学持续完善
- 🟡 Trace/Artifact/Knowledge Delta 正在向平台化能力收敛

**完成标志**：中型以上需求中 gad-sdd 稳定跑通主链路；主链路知识库覆盖度明显提升；ATDD 具备编译/部署/冒烟/Diff 基本门禁；每次任务都有可追踪 Trace 和可归档 Artifact

### 第二阶段：广告内部跨团队闭环（持续建设中）
关键事项：总控 Agent 上线；复杂需求拆成多子 Agent 任务；跨 Agent 技术 Spec 和数据流转 Spec 前置；Mock Server 支持前置联调；任何子 Agent ATDD 失败都能精准定位；运维 Agent 矩阵覆盖核心场景

### 第三阶段：跨组织端到端闭环
关键事项：跨业务线 Agent 协同；跨端 MCP 与 Browser-use 接入；CodeWiki/LSP/图谱能力增强；面向广告业务的评测集建设；AI 参与值班和告警 RCA；一键预案推荐，人最后确认

**完成标志**：研发同学工作重心从翻译需求、查历史、写重复代码、人工排查，实质性转向维护 Spec、评审 AI 产物、治理质量和沉淀知识

## 结语

> **AI Native 的本质，不是让 AI 偶尔参与研发，而是把研发体系设计成 AI 能持续参与、稳定执行、可被验证、不断进化的工程闭环。**

高德广告工程的实践不是"AI 已完全接管研发"，而是更真实的过程：
- 已跑通一批点状能力，看到 30%-60% 阶段性提效
- 清楚看到知识/测试/状态/接口事实/复杂需求拆分瓶颈
- 正把这些瓶颈反向沉淀为 Harness、知识库、SkillHub、Tool Gateway、Trace 和 Agent Team

这是 AI Native 从"个人效率工具"走向"组织工程能力"的关键路径。