① 问题 · 30s
场景是什么？
成功标准是什么？
只说一个业务问题。
成功标准是什么？
只说一个业务问题。
② 跑链路 · 2min
由一位代表带着真实输入，跑通一条关键链路。
③ 亮证据 · 1min
展示一次测试/复核证据：输出被谁使用，哪里仍需人确认。
④ 切换 · 30s
下组上台。问题与建议留给路演后的统一复盘。
⚡ 每组 4 分钟：业务问题与成功标准 → 跑通一条关键链路 → 展示测试/复核证据 → 切换。不逐一报个人贡献，不安排随机 Q&A。讲师只记录问题，统一在复盘时处理。
⚡ 每组 4 分钟：业务问题与成功标准 → 跑通一条关键链路 → 展示测试/复核证据 → 切换。不逐一报个人贡献，不安排随机 Q&A。讲师只记录问题，统一在复盘时处理。
👂 其他组路演时：手册P13记录至少1条"偷走的设计"——别光看，要"偷"。
一次性探索、草稿、临时判断；不必先造系统。
固定招式、单点任务；输入输出明确，就先把这一招做好。
多步骤、高频、可交接；让上游输出能被下游直接使用。
长期运行；才值得配知识、规则、测试、复核与维护。
能直接问，不建；Skill 能解决，不上复杂系统。
先看交接、复核与责任；不要把每个动作拆成一个“聪明盒子”。
长期工作流前，先准备授权资料、干净输入、验收样本与边界。
先讲清谁要用、如何接、谁复核；工具只是实现路径。
通用模型、Codex 用于探索；工作台用于固定知识、规则、测试和协作。
删掉那些不进入你的工作流、不能留住上下文与案例的 AI 使用习惯。
要展示工作流、真实输入输出、链接与互动，就用可运行的 HTML；PPT 适合静态叙事与归档。
① 哪一组的链路真正跑通？证据是什么？
② 哪个输出已被下游使用？哪个环节仍要返工？
③ 哪组的复核边界与风险测试最清楚？下一步应改什么？
每人完成一句：我交付了什么、被谁使用、下一步需要谁支持。
记录可见贡献与协作卡点，不打分、不纳入总分。
目的：让后续迭代有责任人，而不是制造课堂惩罚。
⚡ 必须给至少1条具体改进建议——没说具体建议=没评。
邻组给你的改进建议：
□ 流程改进 → 哪个节点可以更清楚？
□ 模板改进 → 输出格式可以怎么调？
□ 知识库改进 → 还可以导入什么资料？
□ 测试改进 → 测试用例还漏了什么场景？
改什么：流程 / 模板 / 知识 / 测试中的一个具体缺口
谁负责：写下业务角色或协作对象
何时验证：明确日期或下一次业务发生时
用什么指标：周期、返工、一致性或可追溯性
💡 复盘不是背方法论：把今天看到的问题，转成一个可验证的业务改进动作。
必须具体到任务——不能写"回去多用AI"
🎯 你的手册不只是笔记——是 14 页真实产出。
🔚 "从'能用'到'会建'——你今天建的不是一个 agent，是一套方法论。带着你的手册回去——下周，把今天写在行动计划上的第一步，真的做掉。"