DDAI 简介 & ng 最新更新

Domain-driven AI 简介(35分钟)

Angular 19 的最新更新(5分钟)

关于我

  • 26 年码农
    • Angular / Spring / AIGC 应用
    • 全栈工程师 / 资深架构师
    • DDAI 方法论创立者
  • 独立咨询师
    • 咨询 / 交付 / 培训
  • ThoughtWorks 专家级咨询师
  • 北京智座科技创始人
  • Google Developer Expert

照片

领域驱动 AI

大模型应用方法论简介

由它衍生出来的工程框架

由它衍生出来的解决方案

问题:大模型落地难

  • 大模型正在走入下半场
    • 上半场的焦点在基础模型,下半场的焦点在落地
  • 大模型落地难是个共性问题
    • 不知道该用大模型做什么
    • 也不知道该如何应用大模型

不知道该用大模型做什么(What)

  • 客户(老板)太保守
    • 不了解大模型的能力
    • 受困于思维定势,无法展开想象,难以发挥价值
    • 见了兔子也不撒鹰
    • ...
  • 客户(老板)太激进
    • 不知道大模型的限制
    • 对大模型期望值过高
    • 对大模型的风险认识不足
    • ...
  • 客户(老板)盲目自信,以为用传统方式就能做出来

不知道如何应用大模型(How)

  • 定义问题
    • 对问题缺乏整体性了解,无法画出蓝图
  • 解决方案 —— 规划层面
    • 如何设计目标场景
    • 如何组织工程协作
  • 解决方案 —— 实施层面
    • 如何定义具体任务?
    • 如何实现具体任务?
    • 如何搜集对大模型最为关键的基础数据
    • 如何用好基础数据?

为什么会有这些共性问题?(Why)

  • AI 应用本身就是个复杂问题,甚至混沌问题
    • 规模大,子问题之间联系不明确
    • 缺乏约束,不知道边界在哪里
    • 缺少参考案例,不知道该如何设定目标
  • AI 应用本质上是个工程问题,而不仅是技术问题
    • 不同的角色知识背景差异巨大,互不理解
    • 缺乏统一语言,对彼此的术语非常陌生
    • 缺乏可参考的协作流程
    • 缺乏标准化的沟通工具
  • AI 应用容易牵扯到一些社会问题

AI 要落地,有哪些典型的约束

  • 人才约束
    • 客户可能没有足够的“AI/业务/工程”复合型人才
    • 因此,我们必须把任务分解得足够细,只要求单一能力模型
  • 知识约束
    • 客户可能难以接受全新的方法论
    • 因此,我们必须优先借用成熟方法论
  • 信心约束
    • 客户对于最终能否成功没有信心
    • 客户对于最终要花多少钱心里没底
    • 客户对于乙方实力没有信心

如何解决?

Domain-driven AI 就是解决方案

领域为中心,以知识为抓手,以培训为先锋

低成本迭代,快速迭代

为 AI 落地保驾护航

步步为赢,是本框架的基本目标

  • 让每一步的产出都有价值
    • 分成很多很小的迭代
    • 随时可以暂停中止
    • 即使半途而废,已有的产出仍然有足够的价值
  • 让这种价值不要局限于 AI
    • DDAI 本质上是个以领域模型为中心的知识工程
    • 领域知识是任何业务的基础
    • AI 只是表象,领域知识才是根本
    • 不要把 AI 看做目标,而应该看做一种效率工具

整合者,是本框架的基本定位

  • 没有创造新概念
  • 我只是成熟方法论的整合者
    • 针对 AI 应用场景进行定制化改造
    • 为每个步骤提供详细的操作指导和必要的软件工具
  • 成熟性来让客户安心
    • 每一个组件都经过充分的实践检验
    • 充分考虑 AI 落地时的特有挑战
    • 随需应变,高度可定制化
    • 聚焦团队、项目,但保留延展性

这套方案是怎样的

请给我20分钟,带大家走马观花看一遍

宏观工作流

  • 判定现状
    • Cynefin 框架为指导,调研环境与约束,选定行动策略
  • 知识科普
    • AI 的应用科普技术科普(不超过高中数学水平)
  • 需求与定位
    • 设计思维方法论,梳理需求,明确定位
  • 解决方案
    • 领域驱动设计方法论,识别和梳理业务知识
  • 工程实现
    • 技术为依托,完成具体的应用任务

步骤概览

在每一个具体步骤,我们该怎么做?

判定现状

  • 如何对问题的难度定性
  • 此问题是否能解决?
  • 此问题是否值得解决?
  • 解决此问题的宏观策略是什么?

Cynefin 框架

  • 清晰问题

    • 比如用 Github Copilot 辅助编码
    • 感知-分类-应对
  • 繁杂问题

    • 比如用 AI 对提交信息进行规范化
    • 感知-分析-应对
  • 复杂问题

    • 比如用 AI 进行代码审查
    • 探索-感知-应对
  • 混沌问题

    • 比如用 AI 进行业务提效
    • 行动-感知-应对
  • 失序问题

    • 比如用 AI 帮我赚钱
    • 无法应对

设计思维

解决“做什么”的问题

准备工作 —— 大模型科普(应用向)

  • 为设计思维准备知识基础
  • 内容概要
    • 什么是 AI,什么是大模型
    • AI大模型是什么关系?
    • 大模型幻觉是怎么回事?
    • 大模型典型应用案例
      • 智能客服
      • 非结构化数据整理
      • 辅助创作
      • ...

设计思维 —— 电梯演讲

  • 确定产品定位,建立团队共识
  • 实践指南(差异)
    • 虚设对手(以传统工作方式为对手)
    • 产品特色速查表
      • 能处理哪些非结构化信息
      • 能胜任哪些简单枯燥的工作
      • ...
    • ...
  • 价值
    • 寻找产品定位,建立团队共识

设计思维 —— 干系人地图

  • 了解所有利益相关方及其诉求
  • 实践指南(差异)
    • 干系人速查表
      • 客户代表
      • 用户非用户(脑力工作者)
      • 运营人员
    • 利益类型速查表
      • 省力
      • 省钱
  • 价值
    • 减少落地阻力

设计思维 —— 同理心地图

  • 考虑用户的感受
  • 实践指南(差异)
    • 想法、感受速查表
    • 听、看速查表
    • 说、做速查表
    • 痛点速查表
    • 收获速查表
    • ...
  • 价值
    • 帮助团队代入用户角色,感受用户需求
    • 设计出有温度的 AI 应用

设计思维 —— 用户画像

  • 准确描绘用户
  • 实践指南(差异)
    • 效率驱向性速查表
    • 风险承受度速查表
    • 幻觉容忍度速查表
    • 成本敏感性速查表
    • ...
  • 价值
    • 帮助团队建立虚拟仿真人
    • TA 不仅是用户,还会一直作为团队成员而存在

设计思维 —— 用户旅程

  • 描绘应用场景
  • 实践指南(差异)
    • AI 新触点速查表
    • AI 新痛点速查表
    • AI 新爽点速查表
    • AI 新炫点速查表
    • ...
  • 价值
    • 帮助团队建立用户故事的共同上下文

设计思维 —— 机会点排序

  • 寻找 AI 的最佳切入点
  • 实践指南(差异)
    • AI 机会点速查表
      • 非结构化数据处理
      • 自然语言界面
      • 多媒体交互
      • ...
    • AI 成本速查表
  • 价值
    • 帮助团队识别 AI 相关机会
    • 帮助团队评估成本收益风险

设计思维 —— 服务蓝图

  • 穿透内部协作,建立宏观视图
  • 实践指南(差异)
    • 虚拟前台员工
    • 虚拟服务员工
    • ...
  • 价值
    • 通过设立虚拟员工,把 AI 能力拟人化
    • 便于团队理解 AI 的角色协作逻辑
      • 研发团队
      • 业务团队
      • 运维团队

领域驱动设计

解决“怎么做”的问题

领域驱动设计 —— 事件风暴

  • 领域事件为线索,梳理领域知识
  • 实践指南(差异)
    • AI 相关领域事件速查表
      • 用户反馈已收到
      • 新数据已汇入
      • 模型已微调
    • AI 相关业务规则速查表
      • 幻觉容忍度
    • ...
  • 价值
    • 帮助团队以业务状态为导向审视业务流

领域驱动设计 —— 命令风暴

  • 追溯领域事件的来龙去脉
  • 识别动作及其主客体
  • 实践指南(差异)
    • AI 主体速查表
    • AI 客体速查表
    • AI 动作速查表
    • 但绝大部分工作仍然是聚焦在传统主客体
    • ...
  • 价值
    • 帮助团队尝试把传统主客体替换为 AI 主客体
    • 辅助团队定义 AI 主客体的职责

领域驱动设计 —— 聚类限界上下文划分

  • 对主客体进行聚类,判定联系强度,划分限界上下文
  • 实践指南(差异)
    • 基于大模型的辅助建模工具
    • 知识库建设指南
      • 有哪些知识实体
      • 知识实体之间有哪些联系,强度如何
      • 知识来源是什么
      • 知识数量和质量如何
  • 价值
    • 将领域知识可视化
    • 帮助团队建立知识地图,作为后续AI指引
    • 切分领域知识,降低团队的认知负载

领域驱动设计 —— 限界上下文地图

  • 梳理依赖关系,展现上下文全景图
  • 实践指南(差异)
    • 把搜集的知识库对齐到限界上下文中
    • 组建全功能团队
    • 每个团队负责一个限界上下文中的业务、技术、知识库
    • ...
  • 价值
    • 限界上下文不断向业务架构(领域模型)对齐
    • 系统架构不断向限界上下文对齐
    • 研发团队架构不断向系统架构对齐

领域驱动设计 —— 整理术语表

  • 作为领域模型的重要补充,帮助团队统一术语
  • 实践指南(差异)
    • AI 术语速查表
    • 业务术语辅助生成器
    • ...
  • 注意
    • 不是到最后才开始的实践
    • 要在领域驱动设计过程中沉淀下来
    • 要在整个生命周期里不断整理优化
  • 价值
    • 作为业务人员和研发人员双向沟通的桥梁

AI 技术科普

为 AI 落地准备技术基础

AI 基本知识(技术向)

  • AI 的分类
    • 专家系统
    • 机器学习
  • 大模型的分类
    • 语言模型
    • 图像模型
    • 音频模型
    • ...
  • 大模型基本原理(技术向)

Prompt 工程

  • 基本原理
    • 提问的智慧
  • 通用技巧
    • 要素
    • 结构化 Prompt
  • 特定大模型技巧
    • Gemini
  • 例子
    • 不同 Prompt 的效果差异
  • 练习
    • gemini-1.5-flash 工作坊

RAG(检索增强生成)

  • 什么是 RAG
    • 检索增强生成
  • 嵌入模型
    • 基本概念
  • 向量相似度
    • 基本概念
    • 常见类型及适用场景
  • RAG 成功的关键
    • 高质量的知识库!
  • 工作坊
    • 知识库的收集整理精化

微调模型

  • RAG 与微调模型
    • 对比:优缺点
    • 合用:优势互补
  • 微调模型
    • 基本原理
    • 常用技术
      • Gemini 等云服务的微调
      • Gemma 等基础模型
      • LoRA 等微调框架

大模型幻觉

  • 为什么大模型会有幻觉
  • 如何避免大模型幻觉?
    • 提高数据质量
    • 优化提示词
    • 多方案互相矫正
    • 建立反馈环
      • 步骤细分
      • 适时人工介入

Agent

  • 什么是 Agent
  • Agent 架构
    • 感知器
    • 知识库
    • 行动者
    • 决策器
    • 学习者
    • ...

AI 实施

介绍一部分具体的工程实践

DSL 为核心的 AI 实施方案

  • 什么是 DSL
    • 领域特定语言
    • 业务专家的语言来设计
    • 可能是 yamljson代码
  • DSL 从哪里来
    • 根据领域模型精心设计出来的
    • DDAI 的核心产出之一
  • 为什么 DSL 能抑制大模型幻觉?
    • 结构化,具有确定的语法语义
    • 精确性,可用程序验证,可用人工验证
    • 人类大模型传统程序之间协作的桥梁

基于整洁架构的解耦方案

  • 分离策略实现
    • 策略领域知识的体现
    • DSL策略的载体
    • 实现可以自由切换实现
      • 传统程序
      • 专家系统大模型小模型
      • 人工介入
  • 优势
    • 保护既有投资
    • 保留可扩展性

基于全功能团队的工程组织方案

  • 什么是全功能团队
    • 业务研发运维AI 专家等角色组成联合舰队
    • 制度层面组建利益共同体
    • 团队边界对齐到限界上下文
  • 为什么要这么做?
    • AI 项目的需求非常复杂,要让业务专家紧密参与,随时澄清调整
    • AI 项目的沟通需求非常强,不要让团队边界成为障碍
    • AI 项目的相关知识非常庞杂,要让知识在团队内部顺畅流动

Angular 19 的最新更新

Angular 19 已经非常成熟

升级时的代价很小(几乎完全是自动升级的)

我花几分钟时间简要更新一下新特性

如果你只是普通应用开发者,可以忽略这一部分

严格内容安全策略(预览特性)

  • 安全对网络应用是永远的主题
  • 支持基于哈希的内容安全策略
    • 构建时为内嵌脚本生成内容哈希值
    • 通过指定 autoCSP: true 来启用

默认独立版(Standalone)

  • 默认情况下,Angular 19 会生成独立版应用
  • ng update 升级时自动迁移为独立版

Zoneless(试验特性)

  • 解决 Zone.js 的性能问题
  • 解决 Zone.js 的兼容性问题
  • 通过 ng new [project-name] --experimental-zoneless 来创建
  • 这将是 2025 年的重点关注特性,可以尝试下

Signal 迁移原理图

  • Signal 是 Angular 19 的核心概念
  • 正在快速走向稳定版
  • 提供了一系列自动迁移原理图
  • 试验特性 linkedSignal 更好地表达“选取”逻辑

增量水合(预览特性)

  • 进一步提高首屏渲染速度
  • 通过增量水合技术,优先处理用户可见的部分
  • provideClientHydration(withIncrementalHydration());
  • @defer (hydrate on viewport) { <shopping-cart/> }

事件重放

  • 事件重放是 Google 系网站的核心技术之一,来自 Wiz 框架
  • 可以让用户对服务端渲染出的页面直接操作,提供用户视角的可用性
  • Angular 水合默认启用了事件重放特性
  • provideClientHydration(withEventReplay())

逐渐弃用 Karma

  • Karma 生态已经老化
  • 但开发组仍然非常重视真实浏览器环境下的测试
  • 新的测试框架选型正在对 Jest + Web Test Runner 进行试验
  • 2025 年上半年开发组会聚焦这部分工作,并可能做出最终决定
  • 有任何意见建议,欢迎反馈给开发组

Q & A

先简单介绍一下我自己。我是汪志成,26年码农。我是个全栈工程师,主要技术领域在 Angular、Spring、大模型应用这三个方面。我还是一个资深架构师。我目前是个独立咨询师,业务形态包括咨询、交付、培训等。我刚从 ThoughtWorks 出来创业,当初是专家级咨询师。我还是 Google Developers Expert。

好,今天的演讲就到这里。如果有问题或者有需求,可以通过我的微信或邮箱来找我继续探讨。感谢大家!