Java 工程师 LLM 工程化

Appearance

L01-12 小节项目：能聊会查天气的助手 ​

全局中心内容：单点能力人人会，难的是六个能力干净地拼在一起。 全局讲解主线：组装会撞到什么 → Advisor 顺序是核心 → 分层收口 → 七项验收逐条打勾。

P1 · 产出页 ​

中心内容：把 01 篇六个能力拼成一个能对外演示的东西。

  • 页面内容

    • 流式输出 + 多轮记忆 + 工具调用
    • 多厂商切换 + 异常降级 + 成本统计
    • 七项验收清单

  • 讲解技巧

    • 回顾式开场：「前面十一节你都能跑通，但大概率拼不成一个东西」。承认这个事实能建立共鸣。
    • 明确本节的目标不是学新 API，是学怎么拼。

  • 时长：30s

P2 · 痛点页：组装时会撞到什么 ​

中心内容：组件打架、顺序错乱、职责不清。

  • 页面内容

    • 记忆 + 流式 → 历史被重复写入
    • 工具挂在记忆之前 → 工具结果没进记忆
    • 成本写在 Controller、重试写在 Service → 逻辑纠缠

  • 讲解技巧

    • 这三条要说是「我见过的最常见的三种」，不是理论推测。
    • 点出本质：单点能力是知识，组装能力是工程。这是本节的立意。

  • 时长：2min 30s

P3 · 核心图：Advisor 链顺序 ​

中心内容：审计在前、记忆在中、成本在后。

  • 页面内容

    • 审计(100) → 安全 → 记忆(200) → 检索 → 工具 → 模型 → 成本(900)
    • 前：必须看到未加工的原始输入
    • 中：决定模型看到什么上下文
    • 后：要拿到最终结果才能统计

  • 讲解技巧

    • 黑板留这张图，写死那句口诀。
    • 强调这类 bug 的可怕：顺序错了不报错，只是效果不对。排查靠 DEBUG 日志数消息条数。

  • 时长：4min

P4 · 陷阱页：流式 + 记忆 ​

中心内容：客户端中断时，半截回答不能写进记忆。

  • 页面内容

    • 流式在订阅后才消费，记忆在完整响应后才写
    • 中断 → 响应不完整 → 写不写？
    • 答案：只在 signal == ON_COMPLETE 时写

  • 讲解技巧

    • 这是本节的隐藏考点，前十一节都没涉及。要特别强调。
    • 讲后果：写了半截回答，下一轮模型会接着这段没说完的话继续编，产生非常诡异的对话。

  • 时长：3min

P5 · 分层图：Facade 是新增的一层 ​

中心内容：前面各节为了讲清单点，逻辑都写在 Controller 里。

  • 页面内容

    • Controller：参数校验 + 协议转换
    • Facade：编排（记忆 → 工具 → 重试 → 降级）
    • Advisor：横切（审计、成本、安全）
    • ChatModel：厂商适配

  • 讲解技巧

    • 承认前面是刻意为之：「前面为了让你看清单点，我把逻辑写在了 Controller。现在组装必须抽出来」。
    • 说明不抽的后果：重试、降级、成本统计互相纠缠，改一处动三处。

  • 时长：3min

P6 · 编码：完整配置 ​

中心内容：一行 defaultAdvisors 就是整个横切治理。

  • 页面内容

    • defaultSystem + defaultAdvisors(audit, memory, cost) + defaultTools
    • 系统提示里写明「必须调工具，不得凭记忆」

  • 讲解技巧

    • 指出 defaultSystem 里的那句约束是必须的：不写清楚，模型有时调工具有时编。
    • 把这段代码与前几节的 ChatConfig 对比：结构没变，只是在长。说明好的抽象是可扩展的。

  • 时长：5min

P7 · 编码：两个 Advisor ​

中心内容：getOrder() 决定顺序，值小的靠前。

  • 页面内容

    • AuditAdvisor：order=100，脱敏后记录原始输入
    • CostAdvisor：order=900，读 usage 记耗时与 Token

  • 讲解技巧

    • 强调审计要脱敏后再记：审计 Advisor 最先拿到输入，也是最该小心的一个。
    • 预告脱敏方案在 03B-12 展开。

  • 时长：5min

P8 · 编码：Facade 与 Controller ​

中心内容：Controller 保持极薄，编排收口到 Facade。

  • 页面内容

    • AssistantFacade.stream() / .chat()
    • Controller 只有三行方法体
    • doFinally 里记 signal

  • 讲解技巧

    • 可视化反差：把 01-02 那个「Controller 里直接调 chatClient」的版本和现在并排。
    • 点出这是「能跑」到「能维护」的分界。

  • 时长：5min

P9 · 验收：七项逐条打勾 ​

中心内容：重启后还能答出「木鱼」，才算真的完成。

  • 页面内容

    • 流式 / 工具 / 记忆 / 隔离 / 重启不失忆 / 降级 / 成本可查
    • Advisor 顺序：DEBUG 日志 audit → memory → cost
    • 中断不写记忆

  • 讲解技巧

    • 七项要一条条现场跑，打勾要看得见。这是 01 篇的结课仪式感。
    • 重启那一项必须真的重启，不能用热部署。

  • 时长：6min

P10 · 结课小结 ​

中心内容：01 篇结束，下一步是让它「知道你的资料」。

  • 页面内容

    • 01 篇六个能力回顾
    • 现在的助手只能回答通用问题
    • 缺的是：它不知道你们公司的文档
    • 下一站：02 篇 RAG 工程化

  • 讲解技巧

    • 用一句过渡点出 02 篇的必要性：「它很聪明，但不知道你在说什么。RAG 解决的就是这个」。
    • 丢出引子问题：「如果要它『帮我查订单并改状态』，需要什么？」——那就是 03 篇 Agent 的主线。

  • 时长：2min

讲师备忘 ​

项内容
课前必做docker compose 提前起好；七项验收预跑一遍；准备 DEBUG 顺序日志截图
最容易超时处P9 的验收，七项跑完容易超时——降级和成本两项可预录
学员最常问「Facade 是不是过度设计？」答：能力超过三个就必须有，否则逻辑必然纠缠
现场备用数据库起不来 → 切 H2 内存版，记忆持久化改为口头说明