荣耀杨杰AICon演讲：ADD资产驱动开发如何让AI Coding端到端交付

AI的角色正在变。它不再只是回答问题，而是开始理解目标、调用系统、把活干完。当Agent真正进入企业流程，关键问题已经换了：哪些工作能交给AI，结果怎么验收，权限、成本与风险怎么兜住？50 + 实战案例将在AICon现场揭晓答案。大模型往推理、工具调用、多模态和长任务方向延伸，开发重心也从单次调用转向上下文、工具、执行环境和反馈回路的设计。Coding Agent同样在变，从代码补全走到能读懂代码库、跑测试、完成复杂任务的工程协作者。OpenAI、Google Cloud、Anthropic 的最新实践都指向同一点：模型决定 Agent 能做什么，工程决定它能不能进生产、能不能产生价值。

2026 年 AICon 人工智能开发与应用大会 · 北京站已经启动，定于 12 月 18–19 日在北京新云南皇冠假日酒店举办。大会主题是探索 A 应用边界，13 大技术专题覆盖大模型后训练、推理优化、Agent 工程、知识工程、智能体评测与安全、自进化系统、AI 软件交付、原生架构及组织变革等方向，一线技术专家会到场分享技术突破与企业规模化落地的真实实践。

荣耀首席 IT 技术架构师杨杰已确认参加“Agentic Software Engineering｜从代码生成到软件交付”专题，带来主题分享《ADD 资产驱动开发：让 AI Coding 懂业务、守规范、稳架构、实现端到端交付》。AI Coding 工具的能力一直在迭代，可三个天然局限绕不开：企业私域认知缺失，工程规范、业务上下文、共享依赖关系都不在模型里；上下文窗口装不下太多东西；生成结果本身带概率性误差。把这套工具用到存量系统上——历史文档缺、技术栈碎、代码几十万行——麻烦就来了：全仓扫描 Token 消耗太高，同一个功能实现风格不统一，改一处牵出关联故障，代码和文档对不上，研发过程也没法追溯。这些问题靠升级模型工具解决不了，根子不在模型侧，在企业侧的知识与治理体系。

ADD（Asset-Driven Development，资产驱动开发）的做法，是把企业私域知识结构化成两套资产，与代码同仓管理。Framework 层是「技术宪法」，讲清楚「代码应当如何编写」的统一规范；Endpoint 层是「四件套」——时序、规则、不变量、索引，定义「每个端点当前的业务逻辑」，每个环节都绑代码锚点。再往上，三套工作流（WorkFlow）规定 AI 在工程初始化、端点梳理、日常开发三大场景下怎么执行、哪些不能碰；单需求五阶段交付件归档机制则保证全流程可审计、可追溯。

杨杰的分享分三大阶段。第一阶段盯单个需求的精准交付；第二阶段引入架构度量，把目标从「功能实现正确」抬到「系统结构健康」，防止 AI 的快速交付变成技术债的快速累积；第三阶段从资产驱动开发延伸到资产驱动测试与可执行流程，最终做到「需求输入、代码输出」的端到端自动化交付。每个阶段的落地成果、推进路径和踩过的坑，他都会讲。

杨杰是荣耀首席 IT 技术架构师，有 18 年架构和开发经验。2023 年起他负责荣耀 IT 新质生产力平台的技术架构设计，从 0 到 1 搭起企业级 AI 落地底座——数字员工平台、企业统一知识库、AI 评测中心；并主导 AI 编码使能框架 ADD，在 30 万行大型代码库上做到单次开发成本降 40%、Token 用量降 30%。更早之前，他在华为主持电信计费系统平台架构，产品服务全球 130+ 运营商。

本次会议他的详细演讲内容如下：

演讲提纲

1. 工具能力升级，为什么仍然解决不了核心问题

• AI Coding 的三大天然局限——私域知识缺失、上下文容量受限、生成结果概率性误差——碰上大型存量系统的现状会怎样叠加

• 上下文压缩的恶性循环：系统越大，AI 越容易丢掉关键上下文

• 核心结论：问题出在企业侧，解法也只能建在企业侧

2. ADD 框架全景：三套工作流、两类资产、一套交付体系

• 两类核心资产。Framework 层按领域拆分「技术宪法」，覆盖 Web 层、数据访问、消息队列、缓存、日志等领域，非功能约束内嵌在各专题里；Endpoint 层是以 API、MQ 消费、定时任务为入口的「四件套」，配套全局统一的业务对象类图与接口契约

• 全链路可追溯：从接口契约到时序步骤、代码锚点，再到业务规则与不变量，正向能推导，反向能溯源

• 四方角色协同，四条核心铁律：改代码必同步更新资产、新增端点必先构建资产、修改共享组件必做影响分析

3. 第一阶段：单个需求的精准交付

• 五阶段工作流：资产检索（只读资产、不扫全量代码）、影响范围分析、资产前置变更、代码实现、双向校验

• 跨端点涟漪分析：共享组件索引在梳理阶段自动维护，引用端点数量超过阈值就自动暂停，转人工确认

• 资产先行：先给出资产变更差异让人确认意图，再动代码；审资产变更的成本，比审代码变更低得多

• 人机协同机制：确认节点怎么设、校验脚本与 Git Hook 如何兜底、交付件归档怎样支持会话中断后续接

• 降本提效的原理：把开放式生成变成「查表+填空」的确定性推理，同时讲清 ADD 方案的适用边界

4. 第二阶段：架构腐化的防控与治理

• 现状与缺口：ADD 已在资产里定义了结构约束（依赖方向、数据所有权、不变量），缺的是合规性校验，以及架构健康度的度量反馈闭环

• AI 写代码会带来五类架构腐化风险：照着局部样例模仿，风格走样；偏爱做加法，冗余越堆越多；设计意图没进上下文；变更吞吐量和审查节奏对不上；验证逻辑只顾迎合眼前的验收标准。

• 治理要看四个维度，外加一个横切维度：代码质量、端点与契约、数据资产、技术组件，再叠上设计意图和系统现状之间的偏离度，做到可追溯。

• 执行路径是这样落下去的：从架构主张出发，转成仓库适用的规则，再落到可检查的证据。特殊场景走例外登记，而不是把规则放宽；存量系统的问题先分类治理，增量变更则严格走门禁。

• 机械信号和模型判断各有边界：代码克隆不等于知识重复，规则声明了也不代表运行时真的生效。

5. 第三阶段：朝「需求输入、代码输出」的端到端交付走

• 回头看现状：编码环节已经比较成熟，自测是眼下体系里最薄的一环，过程合规不等于质量达标。

• 资产驱动测试：业务规则、不变量、接口契约本身就是现成的测试断言来源，把它们转成可执行的测试，自修复循环才有输入。

• 流程也要升级：从「给模型读的散文式流程」换成「能被程序执行的流程图式流程」，流程定义和执行分开，状态可以落盘，循环逻辑显式写出来。

• 端到端交付的边界和验收标准要划清：哪些环节必须人工参与，哪些环节可以完全自动化。

6. 落地实践：效果、踩过的坑和下一步方向

• MVP 的落地节奏：1 周完成框架初始化，3 周完成核心端点梳理，第 5 周正式切换运行。

• 几个常见认知误区要说清：ADD 是不是等于写文档？AI 能力够强是不是就不需要约束？先写代码再补资产行不行？

• 实践踩坑总结：规范写成散文式文本，模型理解会出偏差；校验重流程轻产出；不同 Skill 执行口径不统一。

听众收益

• 了解一套可直接复用的存量系统 AI Coding 治理框架：资产怎么分层、Skill 怎么定义、人工确认节点怎么设。

• 了解一把 AI Coding 流水线成熟度评估标尺：编码前、编码中、自评审、自测、合并门禁各阶段的能力水位看得清。

• 学架构度量怎么起步：先把架构主张定下来，再定度量指标，别让度量变成纸面报表。