教学蓝图

从真实问题切入

讲清 token 与 context 的关系

给出工作流拆分练习

理解 token budget 为什么影响产品能力边界

区分常驻信息和按需注入信息

开始用预算视角观察自己的工作流

从下游系统猜意思的真实失败切入

讲清 framing、schema 和 action 三种不同职责

要求用户把自由文本输出改写成契约

知道什么时候该用自然语言、结构化输出或函数调用

会把一个真实任务改造成字段和类型清晰的输出契约

理解为什么失败必须显性化，而不能继续让系统猜

从高自信错答的真实失败切入

讲清模型能力、证据、权限和工具之间的边界

要求用户把自己的任务改成决策梯子

区分模型流畅度和真实可靠性

会用直接回答 / 澄清 / 检索 / 工具 / 拒答五种路径给任务分流

能把高自信错答改写成更稳的工作流边界

先展示失败案例

再拆解三层上下文结构

最后要求用户写出自己的方案

拆开系统规则、任务状态、即时证据

判断问题是提示问题还是架构问题

开始重构自己的长 prompt

从一个看起来很聪明、但碰到真实动作就脆弱的 workflow 切入

把链路拆成 routing、权限、执行和恢复四层职责

要求用户把一个 workflow 改写成可执行的操作设计

把模型推理和工具执行、确认逻辑分开

为一个真实 workflow 设计澄清、取证、决策、执行、校验和交接阶段

把重复 operator 行为沉淀成可复用 SOP 或 skill

从一个“有来源但还是错”的旧证据案例切入

把 freshness 拆成 class、metadata、owner 和 fallback 行为

要求用户真的治理一个知识源，而不是抽象讨论 RAG

区分 retrieval 质量与 freshness / governance 质量

为真实知识源定义 owner、review cadence 和 expiry threshold

判断 grounded 答案为什么会因为旧证据、混乱版本或无人治理而失效

从依赖最新事实却硬答的真实失败切入

讲清 evidence routing、freshness 和 provenance 的系统责任

要求用户把自己的一个问题改写成检索链

区分 retrieval 和单纯加长上下文的差别

会把真实问题设计成查询、筛选、注入、引用四步链路

能判断一次错误到底是缺证据、证据过时还是检索噪声过大

从真实注入或越权风险场景切入

讲清 trust boundary、action boundary 和 graceful downgrade

要求用户对自己的 workflow 做 guardrail 审计

知道不可信文本、系统规则和工具动作应该如何分层

能识别 prompt injection、prompt leak 和越权执行路径

能为一个真实 workflow 设计输入隔离、动作确认和降级方案

从一次无法复现的线上失败切入

讲清 trace、replay 和 failure label 各自的作用

要求用户把自己的一个坏 case 改写成可重放调试记录

知道最小 trace 应该记录哪些信息

会先重放失败，再决定该修 prompt、检索、工具还是编排

会用 failure label 把坏 case 变成后续可评估、可排期的资产

从一个大家都说“感觉更好”却没人能清楚打分的 workflow 切入

把评估拆成维度、锚点和覆盖平均分的规则

要求用户产出一份别人也能实际应用的 rubric

把一个抽象质量目标改写成带维度和评分锚点的 rubric

保留维度分和 hard-stop 规则，而不是只看总分

用 rubric 证据决定先修哪一层

从演示能跑、上线就贵又慢的真实问题切入

讲清关键路径、缓存、批处理、异步和降级策略

要求用户对自己的一个 workflow 做成本与延迟审计

区分用户感知延迟和系统总延迟

能找出请求冗余、上下文膨胀、输出过长和缺缓存这些真实浪费

能为一个 workflow 写出最小 latency/cost 审计草案

从所有请求都走一条回答路径带来的成本和可靠性损害切入

把 routing 拆成任务分类、阈值和 fallback 逻辑

要求用户写出一份显式 unsupported-answer policy

为不同任务类别设计 routing matrix，而不是默认所有请求都走同一条模型路径

定义系统什么时候该直接回答，什么时候其实不该回答

用 eval、abstention 表现、延迟和成本来判断 routing policy

从真实失败样本出发

给出最小 eval loop 模板

要求用户把失败案例变成评估样本

能收集真实失败样本

能定义最小评估集

能把评估结果绑定到上线或回滚决策

从一条因为不愿升级而过度回答的 workflow 切入

把问题拆成 hard-stop、owner、SLA 和 handoff 证据

要求用户真的设计一条 review queue，而不是喊 human-in-the-loop 口号

为风险、权限、证据和政策敏感请求定义 escalation trigger

设计人工 reviewer 可以直接接手的 handoff packet

把升级给人当成质量路径，而不是产品丢脸

先在测试环境完成商品和 webhook 配置

再对照应用里的 billing 逻辑

最后用权限和数据库状态验收

创建测试商品并正确写入环境变量

跑通 Creem Checkout、Portal 和 webhook

知道为什么不能只看 success_url

课前明确交付物和环境要求

每一步都用 checklist 推进

每一步都有成功标准和失败排查提示

完成环境准备、配置填充和启动验证

理解关键配置项的作用

遇到失败时知道优先检查什么

先展示最终状态

再接表、环境变量和 helper

最后完成页面联动

创建用户表和 RLS 规则

跑通登录、退出、会话刷新

知道 auth 为什么不能只做前端页面

从一条看似 grounded 但容易吃到旧证据的 workflow 切入

围绕 source class、metadata、owner 和 fallback 行为审计

要求交付物可以直接用于上线前 review

产出一份 freshness register，给不同来源写清 class 和过期阈值

定义文档的 version、owner 和 approval status 规则

建立 stale-content triage 路径，明确什么时候澄清、刷新或升级处理

先画 threat model 和边界，再谈 prompt 写法

用审计梯子和红队样例驱动，而不是只讲原则

要求提交可复用的交付物，而不是停在讨论

把 trusted / untrusted 内容分开，而不是把所有文本都当成一样

找出哪些工具动作会被风险输入越界触发

产出一份上线前能真正复用的 guardrail 审计报告

从一条现在还在“该停不停”的 workflow 切入

围绕 escalation trigger、owner、SLA 和 packet 设计来审计

要求交付物让升级路径可审计，而不是停留在口头承诺

定义强制升级而不是 unsupported answer 的 hard-stop trigger

分配 queue owner 和 review expectation

产出一份保留关键证据的 handoff packet 模板

先建立 baseline，再谈优化

先查系统浪费，再谈模型切换

要求用户带走可直接复用回产品里的报告

区分用户感知延迟和后台总耗时

抓出请求数、prompt 大小、输出长度和检索体量上的浪费

产出一份有优先级的优化清单和性能预算报告

从一个本该取证却直接回答的失败案例切入

围绕 evidence routing、freshness 和 citation 逐层审计

要求提交一份可用于上线评审的报告

画出系统什么时候该检索、引用、拒答或升级处理

在上线前发现证据过时、检索噪声和来源缺失

产出一份真实 workflow 可复用的 retrieval 审计报告和证据链清单

从一个现在还在过度回答或过度花钱的 workflow 切入

围绕任务分类、routing 阈值和 unsupported-answer 处理来审计

要求交付可被第二个操作者审核和执行的 policy 文档

定义一个符合任务价值、风险、证据需求和预算的 routing matrix

写出覆盖澄清、检索、拒答和升级处理的 unsupported-answer policy

产出一份 fallback ladder，而不是让系统在不确定时临场发挥

从一条现在还靠感觉评质量的 workflow 切入

围绕维度、锚点、hard stop 和 calibration 做审计

要求交付物让第二个操作者也能复查质量

为真实 workflow 写出一份 rubric 和评分锚点

定义 grader 规则和 hard-fail 条件，而不是只看总体印象

留下 calibration sheet，让评分分歧真正可见

从一个看起来很 agent、但其实很脆弱的 workflow 切入

围绕 routing 顺序、工具边界和恢复顺序来做审计

要求交付一份不依赖某个熟练操作者也能复用的成果

把 workflow 画成明确的澄清、取证、执行、校验和交接阶段

定义哪些动作需要证据、哪些需要确认、哪些绝不能自动运行

产出一份 routing 表、一份工具边界清单和一份 operator skill brief

从下游集成出错切入，而不是继续讲 prompt 技巧

按 framing、schema、验收检查三层契约梯子推进

要求提交可被第二个操作者复核的规范和清单

把自由文本推理和下游必须信任的数据结果分开

为一个真实任务定义字段、枚举、空值行为和显性失败路径

产出一份工程或运营都能直接复用的输出契约说明

提供项目范围和验收标准

按内容、Auth、订阅、数据、可信度层分阶段推进

要求提交最终 demo 和复盘

独立搭出完整产品闭环

解释自己的架构选择

展示真实可运行成果