"""AGF 培训 deck 讲师演讲词（speaker notes）· 集中字典 + 批量灌入

设计 spec: docs/superpowers/specs/2026-05-18-agf-training-speaker-notes-design.md
对账依据: build_main.py v1.4（138 张 / 10 章 §0-§9）— 不是 spec v2.3（101 张已过时）

用法（在 build_main.py main() 末尾、apply_footer_to_all 之后调用）:
    from speaker_notes import apply_speaker_notes
    apply_speaker_notes(prs)

Notes 字段格式（每条 200-400 字）:
    【⏱ 时长: Xmin / 节奏】
    [钩子 30s]    1-2 句开场，客观事实 / 数字 / [钩子待你填: <提示>]
    [正文 ~2min]  核心讲解 200-300 字，第一人称"我"
    [互动 30s]    提问 / Lab 提示 / 过渡句
    ⚠ 待 PL 拍板  （若有 marketing claim 或未对账数据点）

带 notes 的 124 张（138 - 14 张过渡 = 封面/目录/休息/divider/Thanks）
"""

NOTES: dict[int, str] = {}

# ============================================================
# §0 · 开场 + Agile / Scrum / TDD 垫层 · slide 3-14 (12 张)
# ============================================================

NOTES[3] = """【⏱ 时长: 2min00s | 节奏: 慢起】

[钩子 30s]
[钩子待你填: 你做这套 AGF 模板的起因——比如某次被多角色协作搞糊涂、或者第一次看到 14 个 agent 互相调用时的反应]

[正文 1min]
我先用 30 秒说清楚今天讲什么。AGF——AppGenesisForge——是我做的一套 AI 团队协作模板，14 个角色、4 层 hook、9 个 skill 全部就位，你拿过去改改就能用。今天 6 个半小时，我带你们做的是一件具体的事：从零派一个「旅游明信片生成器」feature，跑完代码→Unit→SIT→review→E2E→UAT 这 6 阶段门，全程看 14 个 agent 怎么协作。

这一章是垫层——把 Agile、Scrum、TDD 三个概念拉到同一基线。如果你已经懂，可以走神 30 分钟；如果你没听过，正好。

[互动 30s]
我先问一个问题——在场谁完整跑过一次 Scrum sprint 的，举个手？……OK 大概 [现场观察比例]。我接下来讲的角度是「这 30 年沉淀下来的东西，怎么塞进 AI agent 协作里」。
"""

NOTES[4] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
你们花一天来听这门课，得拿走点东西。我这一页就明确写出来——你们能拿走什么、拿不走什么。

[正文 2min]
拿走 3 件东西。第一，你能用 `/agf-team-start` 这一个命令派出一个真实 feature，不会卡在「我该找谁」。第二，你能看懂 `progress/<role>.md` 和 code review 报告，知道每阶段卡的是什么、谁该改 bug。第三，你能评估这套机制能不能 migrate 到你自己的栈——React、Vue、Spring Boot 都行，AGF 的角色和 hook 不绑技术栈。

拿不走的也讲清楚：不教你写 Python，不教你设计 LLM prompt，不教你怎么挑模型。这些是前置技能，今天不开第二战场。

我把目标设在「派得出去、看得懂报告」这个高度，因为这是 80% 团队的真实瓶颈——不是不会写 prompt，是不知道一个 feature 涉及多少角色、每个角色拿什么交付物。

[互动 30s]
后面每一章末尾都有一页「金句」总结这一章你应该带走什么，对着复盘就行。
"""

NOTES[5] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
我提前调过你们的背景——这是一个混合学员场景，有 3 种画像，比例大概 4:4:2。我把这三类标出来，方便你们自己对号入座。

[正文 2min]
P1 业务型，占 40%——你不写代码、没用过 git、用过 ChatGPT 网页聊天。你的目标是会用 `/agf-team-start` 派一个简单 feature，知道每阶段等谁、看哪份交付物。我后面所有"派单 schema"那几页是给你看的。

P2 入门工程型，占 40%——你会写代码，用过 git add/commit/push，但 TDD/CI 概念有点模糊。你的目标是独立派 feature 跑完 6 阶段门、看懂 progress 文件和 review 报告。我后面"TDD red-green-refactor"和"code review 双 verdict"两页对你最关键。

P3 资深观察型，占 20%——工程底子扎实，但没系统跑过 Scrum/TDD。你的目标是评估机制能不能复用、怎么 migrate 到你自己的栈。我后面 §8 拓展取舍那一整章是给你看的，前面可以走神。

[互动 30s]
现在请你自己默念一下你属于哪类。我后面讲到具体页时会标"[P1 必看]"或"[P3 可跳]"，你按自己画像决定专注度。
"""

NOTES[6] = """【⏱ 时长: 3min30s | 节奏: 中等】

[钩子 30s]
[钩子待你填: 你最近一次踩到「沟通成本指数爆炸」的具体场景——比如某次 5 人开会 3 小时没结论、或者一个 PR 改 6 轮才合]

[正文 2min30s]
软件交付 30 年来有 3 个老大难，全部指向同一根：沟通成本指数爆炸。我画一下：第一个是「需求漂移」——你说要 A，工程师听成 B，做出来变 C；第二个是「质量回归」——上线前能跑通，上线一周后崩；第三个是「人离开就崩」——这个模块只有他懂，他走了你重写。

这 3 件事的根因是同一个：信息在人与人之间传一次衰减一次，传 5 次就变形了。Frederick Brooks 1975 年《人月神话》就写过——9 个女人不能 1 个月生出小孩，因为协作开销随人数指数增长。

Agile 和 Scrum 是 1990 年代针对这件事的解药：把 6 个月的瀑布拆成 2 周的 sprint，让信息只传 1-2 跳就闭环。TDD 是 2002 年 Kent Beck 在《Test-Driven Development》里写的——用测试代码把需求"凝固"下来，传 N 跳也不变形。

这三件套不是新东西，是 30 年验证的"减少沟通跳数"的工具。AGF 做的事是把这三件套塞进 AI agent 协作里——让 agent 也按这个规矩走。

[互动 30s]
我接下来 3 页分别讲 Agile / Scrum / TDD，每页就一张图、一个核心要点。你不熟没关系，记住这一句话："都是为了减少信息传播跳数"。
"""

NOTES[7] = """【⏱ 时长: 3min30s | 节奏: 中等】

[钩子 30s]
我现在给你看一张图——Agile 和 Waterfall 的核心区别。这张图我反复改了 3 版，最后简化到只有一个对比维度：信息闭环周期。

[正文 2min30s]
Waterfall 是 1970 年代的玩法：需求→设计→编码→测试→上线，5 个阶段一条直线，每阶段平均 1-2 个月，跑完一轮 6-12 个月。问题是——需求阶段写下来的东西，到上线时已经过期 6 个月，市场早变了。

Agile 1990 年代提出，2001 年由 17 位老工程师在犹他州雪场写下《Agile Manifesto》——这是权威出处，不是营销词。它的核心不是"快"，是"短闭环"：把 6 个月的事拆成 2 周一个 sprint，每 2 周交付一次可用的东西、收一次反馈、调一次方向。

打个比方：Waterfall 是导弹——发射前算好所有轨迹，发射后无法调整；Agile 是无人机——飞 5 秒看一眼、调一下、再飞 5 秒。无人机能找到目标，导弹找不到一个会动的目标。

AGF 把 sprint 周期再缩短：单个 feature 就是一个迷你 sprint，从派单到 UAT 通常 1-3 天。AI agent 让"短闭环"的成本降到了人类做不到的地步。

[互动 30s]
我先不解释 Scrum 和 TDD 具体怎么做，下两页讲。这页你只要记住一句话：「Agile 的本质是缩短闭环周期，不是干得快」。
"""

NOTES[8] = """【⏱ 时长: 4min00s | 节奏: 中等】

[钩子 30s]
Scrum 这个词来自橄榄球——所以我用足球比喻它。这张图你看完会发现 Scrum 其实超简单，就是 3 个角色 + 3 个会议。

[正文 2min30s]
Scrum 是 Jeff Sutherland 1993 年在 Easel Corporation 提出的，他后来出过一本《Scrum: The Art of Doing Twice the Work in Half the Time》。Sutherland 当年是越战飞行员，看到敌方小分队比正规军灵活，悟出"小团队 + 快迭代"的逻辑。

3 个角色：Product Owner（PO，决定做什么）、Scrum Master（教练，保证流程跑通）、Dev Team（球员，把事做出来）。3 个会议：Sprint Planning（开赛前定战术）、Daily Standup（每天 15 分钟同步）、Sprint Review（赛后看录像）。

我用足球类比一下你们就懂了——PO 是教练定战术，Scrum Master 是裁判保规则，Dev Team 是 11 个球员上场跑动。Daily Standup 是中场调整 15 分钟，不是开会，是同步。

AGF 把这 3 个角色映射成 14 个 agent：product-lead = PO + Scrum Master 二合一，13 个执行层 agent = Dev Team。区别是——AI agent 不会累、不会沟通失真、不会忘上次说啥。这是 AI 协作比人类协作的根本优势：信息保真。

[互动 30s]
现在你应该能回答这个问题：为什么 Daily Standup 限制 15 分钟？……因为它不是开会决策，是同步状态。决策应该单独开会。这个原则在 AGF 里更严格——agent 之间默认不开会，只交换 task 和 progress 文件。

⚠ 待 PL 拍板: "比人类协作的根本优势：信息保真" — 这句要保留还是改为"AI 协作的一个特点"？前者是 claim 后者是事实陈述。
"""

NOTES[9] = """【⏱ 时长: 4min00s | 节奏: 中等】

[钩子 30s]
TDD 这一页是今天最重要的一页之一。如果你今天只能记住一件事，记住这个循环：red → green → refactor。

[正文 2min30s]
TDD 全称 Test-Driven Development，2002 年由 Kent Beck 在《Test-Driven Development: By Example》里系统化。注意他用的词是 "driven"——测试驱动开发，不是 "测试覆盖开发"。区别在哪？

驱动是这样的顺序：先写一个测试，它跑不过（red 红灯）；再写最少的代码让它跑过（green 绿灯）；最后整理代码不破坏测试（refactor 重构）。Red → Green → Refactor，循环。

为什么这个顺序重要？因为它强制你在写代码之前先想清楚"什么算做对了"。"什么算做对了"——这就是测试。如果你写不出测试，说明你没想清楚需求；如果你写得出测试，需求就被凝固成了代码，不会因为任何人离职而丢失。

AGF 里 TDD 是硬约束。code-reviewer 角色看 git log 时会反推 commit 顺序——如果 feat: 早于 test:，就是违规，打回去重做。这不靠自觉，靠机制。

我特别强调一件事：TDD 不是测试覆盖率高就行。覆盖率是结果指标，顺序才是原因。先有 test、再有 feat、最后 refactor——这个顺序保证了"需求先于实现"。

[互动 30s]
后面 §5 场景 C 我会演示 AI agent 撞 TDD 红线被打回的全过程。你提前问自己一个问题——如果你的 reviewer 看到 feat 早于 test，他会怎么处理？……合理答案是"打回去重做，不放行"。
"""

NOTES[10] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
讲完 Agile / Scrum / TDD 三件套，现在我给 AGF 一个一句话定义。

[正文 2min]
AGF 是一套 AI 团队协作模板：14 个 agent 各管一摊，4 层 hook 在背后兜底，9 个 skill 强制工作流，6 阶段门保证质量。

我把这句话拆 4 段。"14 个 agent 各管一摊"——product-lead 派单、tech-lead 写 ADR、各路 dev 写代码、code-reviewer 审、qa-engineer 跑测试，每个角色定义在 `.claude/agents/*.md`，不串台。

"4 层 hook 在背后兜底"——危险 bash 命令阻断、密钥扫描、output 净化、git pre-commit，写在 `.claude/hooks/*.sh`。这是机制层，不靠 agent 自觉。

"9 个 skill 强制工作流"——写 PRD 必走 skill `agf-writing-prd`、写 ADR 必走 `agf-writing-adr`、跑 SIT 必走 `agf-running-sit-tests`。skill 不是 wiki，是「不走这条路不行」的强制路径。

"6 阶段门保证质量"——代码→Unit→SIT→code review→E2E→UAT，任一门失败回到第 3 步重做。

这套东西堆叠在一起，目的是把"AI 写代码快"和"机制兜底审得严"两件事同时做到。

[互动 30s]
你们后面看到的每一页，基本都是在展开这一页里的某一个数字——14 / 4 / 9 / 6。
"""

NOTES[11] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
垫层讲完了，从这一页开始我引入今天的主线故事——旅游明信片生成器。

[正文 2min]
故事是这样的：晚上 8 点，我们业务团队找到我（product-lead）："旅游回来想发朋友圈，懒得写文案。做一个工具——用户上传照片 + 一句话，AI 出明信片：200 字文案 + 风格化卡片图。"

这是一个真实的 AI feature——多模态输入（图片 + 文字）、多步流水线（视觉理解 → 文本生成 → 图像生成）、面向消费者。复杂度刚好：足够展示 14 个角色协作，但不会复杂到讲不完。

技术栈我提前定了——全豆包 2.0 栈，火山引擎方舟接入。Vision 用 Doubao-Seed-2.0-Pro 原生多模态，LLM 文本用同一个模型（省一次调用），文生图用 Doubao-Seedream-4.5。这些价格和 benchmark 数字在 spec 里都有出处。

这条主线我会在 §3 / §4 / §5 三个章节里反复用——同一个 feature，不同协作场景：Happy Path、机制兜底、失败回路。看完你会知道这套模板在真实场景里怎么跑。

[互动 30s]
有人会问"为什么挑这个 feature"——因为它够小（1-3 天能做完）、够典型（多模态 + 多步流水线 + 消费级），适合教学。后面 §7 Lab 你们会动手跑一个变体。

⚠ 待 PL 拍板: 主线故事钩子"晚上 8 点找 PL"——保留时间点还是改为"业务团队提了需求"通用化？
"""

NOTES[12] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
正式进入正文前，我给你们今天的时间线 + 准备清单——后面有 Lab 环节要动手，提前装好工具。

[正文 2min]
时间线：上午 §0-§2 垫层 + Git 基础 + AI 工具基础，3 小时。中午午休 30 分钟。下午 §3-§5 三个场景剧本 + §6 Lab + §7 拓展，3 小时多一点。最后 §8 收尾 + Q&A 15 分钟。两次茶歇 10 分钟。

准备清单：① Claude Code 已安装并能跑 `claude --version`；② Git ≥ 2.30；③ 拿到我发的 zip 包，里面是 AGF 模板的快照；④ 一杯水。

如果你 Claude Code 没装上、或者没拿到 zip，现在举手——我让助教过来帮你装。Lab 环节卡在工具上太浪费时间。

下午 Lab 我们会让每人派出一个 feature，跑完 6 阶段门——所以工具准备是硬要求。如果你笔记本是公司发的有装机限制，提前告诉我，我会安排你和邻座配对。

[互动 30s]
现在花 90 秒——你们各自检查一下工具，没装的告诉助教，装好的喝口水，我们 90 秒后开始 §0 最后一页。

[现场停 90s 让学员检查工具]
"""

NOTES[13] = """【⏱ 时长: 3min30s | 节奏: 中等】

[钩子 30s]
这一页我留了一张图——Agile / Scrum / TDD 三件套的理论根源时间线。如果你是 P3 资深观察型，这页可能是 §0 里你唯一不想跳的。

[正文 2min30s]
我把 30 年里这三件套的关键节点列出来：1975 Brooks《人月神话》提"沟通成本指数爆炸"——这是问题被首次诊断；1986 竹内弘高 / 野中郁次郎在 HBR 发《The New New Product Development Game》——这是 Scrum 的概念源头，他们研究的是丰田 / 本田的橄榄球式开发；1993 Sutherland 在 Easel Corp 第一次系统化 Scrum；2001 Agile Manifesto 在犹他州雪场签署；2002 Kent Beck《TDD by Example》；2009 GitHub Actions 的前身 Travis CI 出现——CI/CD 工业化。

为什么我要讲这个时间线？因为这套东西不是新东西。每一代人都在重新发现它，每一代都觉得自己是革新者。AI agent 协作 2024-2025 这一波也一样——本质上是把 30 年的 agile 经验自动化。

我在中文版书单也标了：《人月神话》机械工业出版社、《Scrum 精髓》清华大学出版社、《TDD by Example》人民邮电出版社。回去你想深读就去翻这些。

[互动 30s]
如果今天你只买一本书读，我推荐《人月神话》——它讲的是"问题"，不是"方案"。理解问题比抄方案重要。
"""

NOTES[14] = """【⏱ 时长: 2min30s | 节奏: 收尾】

[钩子 30s]
§0 垫层讲完。我用 3 句话把这一章压缩，你们记住这 3 句就行。

[正文 1min30s]
第一句：「软件交付 30 年的老大难都是同一根——沟通成本指数爆炸」。Brooks 1975 年就诊断完了。

第二句：「Agile / Scrum / TDD 是 30 年验证的解药，不是新东西」。它们的共同手段都是"缩短信息传播跳数"——sprint 缩短闭环、daily standup 同步状态、test 凝固需求。

第三句：「AGF 把这三件套嵌进 hook + skill + DoD」。不靠 agent 自觉，靠机制硬约束。后面 §3 / §4 你们会反复看到这一点。

如果你回去只能跟同事说 1 件事，我推荐你说："先想'什么算做对了'再写代码"——这是 TDD 的精髓，也是和 AI agent 协作的精髓。AI 写代码快，但它不知道"什么算做对了"——这个由你来定义。

[互动 30s]
喝口水，下一章 §1 我讲 AI 编程工具基础——Vibe Coding 是什么、Claude Code 6 大能力。准备好了我们继续。
"""

# ============================================================
# §1 · AI 工具基础 · slide 15-26 (12 张)
# ============================================================

NOTES[15] = """【⏱ 时长: 2min00s | 节奏: 慢起】

[钩子 30s]
§1 这一章讲 AI 编程工具——为什么我们用 Claude Code，为什么 Vibe Coding 这词被骂又被追。

[正文 1min]
这章 12 张，重点是两件事：①「Vibe Coding 是范式，不是工具」——Andrej Karpathy 2025 年 2 月提出，本质是"凭感觉写"；②「Claude Code 是本课程载体」——AGF 模板就是建在 Claude Code 上的，你想跑 AGF 必须先懂 Claude Code。

P1 业务型学员这章最容易跑神——别跑，最后那张「Vibe Coding 业界对标」给你看的是个大数字：70% 公司用 AI 但没改角色，普通团队提速 5-15%，头部团队 5-7×。你需要知道这个差距是怎么来的。

P2 / P3 这章你会看到 Claude Code vs Codex CLI 的对比——别预设立场，看完再说。

[互动 30s]
先一个互动题，下一页揭示。
"""

NOTES[16] = """【⏱ 时长: 2min30s | 节奏: 互动】

[钩子 30s]
互动一下——你们觉得 AI 编程工具最大的坑是哪个？A / B / C 三选一，举手。

[正文 1min30s]
[现场举手 30s]

OK，我看到大概 [现场观察] 选 A，[XX] 选 B，[XX] 选 C。

正确答案：C——「AI 写得太快，但难审 / 难维护 / 难协作」。

A 错——AI 写得不慢，平均 5-10× 人类速度；B 半对——AI 确实出错，但人类也出错；C 才是真正的瓶颈：AI 一晚上能写 5000 行代码，但你 review 不过来、跑不完测试、合不进 main 分支。这就是 Karpathy 提 Vibe Coding 时附带的警告——"凭感觉写"会爆炸。

@nijho.lt 这个案例你们后面会看到——他用 Vibe Coding 一晚上写了一个项目，第二天花 15 小时清理。15 小时清理 vs 写的时间，效率反着倒。

[互动 30s]
带着这个问题进入正文：怎么让 AI 写得快又能审。这就是 AGF 在解的问题。
"""

NOTES[17] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
Vibe Coding 这个词 2025 年 2 月 Karpathy 发了一条推文，3 天传遍全球。我先把它的原始定义读给你听。

[正文 2min]
原推文意译："There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." 翻译过来——「这是一种新编程方式，你完全交给感觉，拥抱指数级速度，甚至忘了代码本身的存在」。

注意几个词："fully give in"——完全放手；"forget the code even exists"——忘了代码在那。Karpathy 不是在推荐这种方式，他是在描述一种正在发生的现象。

Vibe Coding 不是一个工具、不是一个 IDE，是一种范式——你不再 "写代码"，你 "描述意图"，AI 把意图变成代码。区别在于：「写代码」是动作，「描述意图」是结果。

为什么这个范式有威力？因为它把"会编程"的门槛从"懂语法"降到"会描述"。业务同学也能描述意图，所以 AI 编程不再是工程师的专利。

为什么这个范式危险？因为"忘了代码在那"——代码出问题、出 bug、出安全漏洞的时候，你已经不知道在哪改了。Karpathy 自己也警告过这一点。

[互动 30s]
这一章后面 4 页我会讲：极端 vibe coding 长什么样、它的副作用、和 AGF 的关系。

⚠ 待 PL 拍板: Karpathy 推文意译——是否需要附原文链接 / 推文 ID？
"""

NOTES[18] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
[钩子待你填: 你自己或团队的某次 vibe coding 极端案例——比如熬夜 AI 写完，第二天发现需要全部重写]

[正文 2min]
极端 vibe coding 长什么样？我给你画一个真实场景：业务同学晚上 11 点想做一个工具，用 Cursor / Claude Code，一句话"我要个明信片生成器"。AI 30 分钟出 demo，能跑。1 小时迭代版本，加了登录。3 小时加了支付。第二天早上 9 点，发到群里——一晚上做出了一个完整 SaaS。

听上去很美对吧？我接下来给你看几个问题。

问题 1：代码里有没有 SQL 注入？AI 默认会，但你检查了吗？
问题 2：支付逻辑能并发吗？AI 不一定会处理；你测了吗？
问题 3：用户密码怎么存的？明文还是 hash？你看了吗？
问题 4：三天后 AI 模型换了一个版本，你这套代码还能继续迭代吗？你的 prompt 还能复现这个结果吗？

@nijho.lt 这个案例就是真实的：他一晚上 vibe code 完一个 app，发到 Twitter，被指出 18 个安全漏洞 + 3 个数据泄露入口。他后来花了 15 小时清理。15 小时清理 vs 一晚上写——effective productivity 反而是负的。

[互动 30s]
这是 AI 编程的"无序爆炸"。下一页讲它的根因——副作用。
"""

NOTES[19] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
Vibe Coding 的副作用我抽象成 3 条——这 3 条记下来，是后面 AGF 4 层 hook + 6 阶段门设计的根本理由。

[正文 2min]
副作用 1：「review 跟不上」。AI 一晚上 5000 行，人类一天 review 500 行。你写了 5000 行没人审，等于 5000 行潜在 bug。

副作用 2：「测试覆盖不到」。AI 默认不写测试，你也不催它写。代码上线，过两周线上崩，崩了找不到原因，因为没测试可以回归。

副作用 3：「prompt 漂移」。这个最隐蔽——你今天用 prompt A 让 AI 写出代码 X，3 个月后模型升级，同样 prompt A 写出来的代码变成 Y。X 和 Y 你不知道哪个对，因为你没有"什么算做对了"的定义。

3 条副作用的根因都是同一个：「缺少'什么算做对了'的定义」。这就是为什么 AGF 把 TDD 设为硬约束、把 AC（acceptance criteria）写进 PRD、把 SIT/UAT 设为强制门——所有这些都是在补 vibe coding 缺失的"对错定义"。

我画一句话：「Vibe Coding 让生产爆炸快，但'对错的定义'没爆炸快——所以 review 成了新瓶颈」。AGF 这套机制就是在解 review 瓶颈。

[互动 30s]
下一页给你看一个"工具矩阵"——市面上各种 AI 编程工具谁解决了 review 瓶颈、谁没解决。
"""

NOTES[20] = """【⏱ 时长: 3min30s | 节奏: 中等】

[钩子 30s]
市面上 AI 编程工具大概 10 几种——Cursor、Copilot、Codex、Aider、Cline、Claude Code……我把它们按"是否解决 review 瓶颈"分了类。

[正文 2min30s]
分两类：「单人 vibe coder 工具」 vs 「团队协作框架」。

单人 vibe coder 类——Cursor、Copilot、Aider、Cline，主打"一人 + AI 写得快"。它们解决的是「写代码速度」，没解决「review / 协作 / 机制兜底」。适合个人项目、原型、demo。

团队协作框架类——Claude Code（subagent + skill + hook）、AutoGen、CrewAI。它们解决的是「多 agent 协作 + 机制兜底 + 工作流」。适合团队、生产环境、长期维护。

AGF 建在 Claude Code 上，不在 Cursor / Copilot 上——为什么？因为 Claude Code 原生支持 subagent（你能开 14 个 agent 同时跑）、hook（可以在 tool call 前后拦截）、skill（强制工作流）。这三件事在 Cursor 里都没有。

我不是说 Cursor 不好——我自己写小工具也用 Cursor。我是说"AI 团队协作"这个场景，目前只有 Claude Code 工具链支持得最完整。这是 2026 年 5 月的状态，半年后可能变，但今天是这样。

[互动 30s]
有人问"那 AutoGen / CrewAI 行不行"——可以，但它们是 Python framework，不是 IDE。AGF 选 Claude Code 是因为它"IDE + 多 agent + hook"三合一，门槛最低。

⚠ 待 PL 拍板: 工具矩阵分类——"只有 Claude Code 支持得最完整" 是否需要弱化为"我们评估下来 Claude Code 在 AGF 场景下最贴合"？
"""

NOTES[21] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
Claude Code 我用了大半年——这一页是我自己整理的 Claude Code 是什么，不是 Anthropic 官方介绍。

[正文 2min]
官方介绍："a command-line tool for agentic coding"——一句话太抽象。我用 3 个对比让你明白。

第一，对比 Cursor / VSCode：Claude Code 不是 IDE，是 CLI——你在终端里跑，不在编辑器里跑。这意味着它可以跑在 server 上、跑在 CI 里、跑在没有图形界面的环境里。

第二，对比 OpenAI Codex CLI：Codex CLI 也是 CLI 工具，但它只有"一个 AI 写代码"这一个能力。Claude Code 有 6 大能力：subagent（多 agent 并行）、skill（强制工作流）、hook（tool call 拦截）、slash command（自定义命令）、Plan Mode（计划-执行分离）、MCP（外部工具接入）。

第三，对比 ChatGPT 网页：ChatGPT 是聊天，Claude Code 是干活。Claude Code 默认有 Read / Edit / Write / Bash 这些工具，可以直接改文件、跑命令，不是"复制粘贴回去"。

这就是为什么 AGF 建在 Claude Code 上——这 6 大能力是「AI 团队协作」的最小依赖集。少一个都跑不起来 AGF 这套模板。

[互动 30s]
下一页我把这 6 大能力一张图画出来，你看完会知道为什么 AGF 不在 Cursor / Copilot 上建。
"""

NOTES[22] = """【⏱ 时长: 3min30s | 节奏: 中等】

[钩子 30s]
Claude Code 6 大能力一张图——这张图你拍下来回去贴墙上都行，它解释了 AGF 这套模板能跑起来的全部前提。

[正文 2min30s]
我按重要性顺序讲——这是我个人排序，不是官方。

1. Subagent：一个主 agent 能开多个子 agent 并行。AGF 14 个角色就靠这个跑。Cursor / Copilot 没有。

2. Skill：把工作流封装成 skill，agent 必须走这条路。`agf-writing-prd` 就是一个 skill，product-lead 写 PRD 必走它。不靠自觉，靠路径强制。

3. Hook：tool call 前后可以挂脚本。AGF 4 层 hook 全靠这个——危险 bash 阻断、密钥扫描、output 净化、git pre-commit。

4. Slash command：自定义命令，比如 `/agf-team-start` 一行启动整个团队。这是 P1 业务型学员的"派单入口"。

5. Plan Mode：先制定计划、人类批准、再执行。高风险操作（schema 迁移、认证逻辑）必走这个。

6. MCP（Model Context Protocol）：接外部工具——数据库、API、文件系统。今天我们 demo 不用 MCP，但你后面接 production 用得上。

这 6 件事少一件都跑不起 AGF。你后面 §3-§5 看到的每一页交付物，背后都是这 6 件事在支撑。

[互动 30s]
P1 学员特别注意——你不需要会写 hook 或 skill，你只需要知道"它们在那里、被强制走、你绕不过"。绕不过是好事，是机制兜底。
"""

NOTES[23] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
6 大能力听完，下一个问题——它们怎么组合起来变成"团队协作"？这一页讲 orchestration。

[正文 2min]
Orchestration 翻译成中文叫"编排"。它的意思是：怎么让 14 个 agent 协调起来，不打架、不重复、不漏掉。

AGF 的编排策略很简单——单一编排者 + Self-Reporting：

单一编排者：只有 product-lead 派单。其他 13 个 agent 不能互相直接派单，必须经过 PL。这避免了"AB 互相派任务死循环"。

Self-Reporting：每个 agent 干完活，把"我做了什么、跑了什么命令、AC 怎么自验、引用了哪个 skill"写在 `progress/<role>.md` 里。PL 不需要去问"你做完了吗"，PL 看 progress 文件就知道。

为什么这两条简单的规则有威力？因为它把"协作" reduce 到"派单 + 报告"两个动作。人类团队也是这套——PM 派任务、工程师交付。AGF 没发明新规矩，只是用机制保证规矩被执行。

具体实现：派单通过 task 文件，由 hook 校验 6 段 schema（缺一段阻断）；报告通过 `progress/<role>.md`，由 hook 校验 SIT 证据段（缺则阻断）。

[互动 30s]
下一页我让你们上手——装 Claude Code、跑 `claude` 命令、看一眼。如果你没装，举手让助教过来。
"""

NOTES[24] = """【⏱ 时长: 4min00s | 节奏: hands-on 互动】

[钩子 30s]
现在动手——我让你们各自跑 5 分钟，亲手跑一遍 Claude Code 最基础的命令。

[正文 3min]
3 步：

Step 1：在终端跑 `claude --version`。如果跑不出来，举手。
Step 2：在任意目录跑 `claude`，进入 Claude Code 主界面。你会看到一个对话框。
Step 3：输入一句话——「写一个 Python 函数，输入两个数返回较大的那个」。回车，看 AI 怎么响应。

观察 3 件事：
① AI 写代码前会不会问你"放在哪个文件"——会，这是 Claude Code 默认行为，不会直接乱写。
② AI 写完代码会不会跑测试——不一定。这是 Vibe Coding 默认状态，没人催它写测试。
③ AI 会不会提议"我要不要写个测试"——有时会，取决于 prompt。

这 3 件事就是 §0 讲的"Vibe Coding 副作用"在现场——AI 默认不写测试、需要你催。AGF 把"测试先于代码"做成了 hook 硬约束——这是后面 §4 / §5 要讲的。

[互动 30s]
5 分钟够你跑一遍。跑完抬头，我们继续。卡住的告诉助教，别死磕。

[现场停 5min 让学员跑]
"""

NOTES[25] = """【⏱ 时长: 3min30s | 节奏: 中等】

[钩子 30s]
跑完 hands-on，最后一页对比：Vibe Coding 默认状态 vs AGF 加持的状态——同样写一个 feature，两条路差多少。

[正文 2min30s]
Vibe Coding 默认：你说"写个明信片生成器"——AI 直接开写，30 分钟出 demo。能跑，但没测试、没文档、没 review、没回归保障。3 天后改需求，AI 重写一遍，第一版的代码扔掉。

AGF 加持：你说"派一个明信片 feature"——product-lead 接，进入流程：

1. PL 写 PRD（必走 skill `agf-writing-prd`）——5 条 AC 量化
2. tech-lead 看是否需要 ADR（多 LLM 切换是变更点 → 写 ADR-008）
3. uiux-designer 出 spec.md + index.html
4. backend-dev / ai-agent-dev / frontend-dev 并行写代码 + Unit + SIT 自跑
5. code-reviewer 审代码 + SIT Audit
6. qa-engineer 跑 E2E
7. PL + qa 联跑 UAT 签字

慢吗？看上去慢，但 6 阶段门跑下来 1-3 天，每一阶段输出可复用、可回溯。3 个月后改需求——PRD 还在、ADR 还在、测试还在，改需求不丢历史。

业界数据点：70% 用 AI 的公司没改角色 → 普通团队提速 5-15%；改了角色（像 AGF 这套）的头部团队提速 5-7×。差距来自"机制兜底让 vibe 速度可持续"。

[互动 30s]
P1 学员，你下午会用 `/agf-team-start` 派一个真实 feature 跑一遍——你会亲眼看到这 6 阶段门怎么走。

⚠ 待 PL 拍板: "普通团队 5-15% vs 头部团队 5-7×" 数据点来源——是否引用具体调研 / 报告？
"""

NOTES[26] = """【⏱ 时长: 2min30s | 节奏: 收尾】

[钩子 30s]
§1 AI 工具基础 3 句话压缩。

[正文 1min30s]
第一句：「Vibe Coding 是范式，不是工具——Karpathy 2025-02 提出」。你不写代码、你描述意图，AI 把意图变成代码。它的副作用是 review 跟不上、测试漏掉、prompt 漂移。

第二句：「Claude Code 6 大能力是本课程载体」。Subagent / Skill / Hook / Slash / Plan Mode / MCP——AGF 这套模板就靠这 6 件事跑。少一件跑不起来。

第三句：「AGF = Vibe Coding 速度 + 机制兜底」。机制兜底让 vibe 速度可持续——这是头部团队 5-7× 提速 vs 普通团队 5-15% 提速 的差距来源。

回去做 1 件事：装 Claude Code、跑 `claude`、输入 1 行需求看它写代码。15 分钟搞定。这是后面 Lab 的最小前提。

[互动 30s]
休息 10 分钟，回来讲 §2 Git 基础。茶水间见。
"""

# ============================================================
# §2 · Git / GitHub 基础 · slide 27-40 (14 张)
# ============================================================

NOTES[27] = """【⏱ 时长: 2min00s | 节奏: 慢起】

[钩子 30s]
§2 Git 基础。这章 14 张，给 P1 学员从零讲 Git，给 P2 补 TDD 相关的 Git 用法，P3 可以跳页阅读。

[正文 1min]
为什么 Git 要单独一章？因为 AGF 的核心机制——progress 文件、code review、TDD 顺序检查、release tag——全部依赖 Git。不懂 Git，AGF 看上去就是黑盒；懂了 Git，每一阶段门的兜底逻辑你都能看穿。

我重点讲 5 件事：① Git 是什么；② 4 区模型（工作区 / 暂存区 / 本地仓 / 远程仓）；③ 5 命令打天下（clone / status / add / commit / push）；④ TDD 顺序怎么用 git log 反推；⑤ GitHub Release + tag 怎么配 CHANGELOG。

[互动 30s]
P1 学员，你需要做到的最低线是"跑得通 clone / commit / push 三件事"。P2 / P3 跟着看，我会标出对你们重要的页。
"""

NOTES[28] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
Git 是什么？我不用"分布式版本控制系统"这种术语——一句话："你工作的时光机文件夹"。

[正文 2min]
"时光机文件夹"意思是：你工作时所有文件的每一个版本都留底，任何时候你都能回到过去任意一个时刻。

普通文件夹是这样的——你改了文件 A，原版就没了。Git 文件夹是这样的——你改了文件 A，原版还在，新版也在，你可以随时切回去。

为什么这件事重要？3 个场景：

场景 1：你改 bug 改到一半，发现思路错了——`git reset` 回到改之前。
场景 2：3 个月前线上崩，今天要复现——`git checkout` 切到 3 个月前的版本。
场景 3：5 个人改同一个文件——Git 帮你 merge，不会互相覆盖。

Git 还有一个更深的能力——"血脉记录"。每一次提交都记录"谁、什么时候、改了什么、为什么改"。这是 AGF 里 code-reviewer 反推 TDD 顺序的依据——看 git log 就能知道 test: 是不是先于 feat:。

[互动 30s]
P1 学员，你不需要懂 Git 内部原理，你只需要把它当成"自动备份 + 历史记录"的文件夹。
"""

NOTES[29] = """【⏱ 时长: 3min30s | 节奏: 中等】

[钩子 30s]
Git 4 区模型——这一张图你看懂了，Git 90% 操作你都能反推。

[正文 2min30s]
4 区：

工作区（Working Directory）——你正在编辑的文件，看得见摸得着。
暂存区（Staging Area / Index）——你"准备提交"但还没提交的文件。
本地仓（Local Repository）——已经提交但还没推到远程的版本。
远程仓（Remote Repository / GitHub）——团队共享的版本。

为什么要 4 区？因为它把"改"和"提交"分成两步——你可以随便改，但只挑你认可的部分提交。这是和团队协作时的核心能力。

操作映射：
- 改文件 = 进工作区
- `git add file.txt` = 工作区 → 暂存区（"这一改我认了"）
- `git commit -m '...'` = 暂存区 → 本地仓（"这一改我提交了"）
- `git push` = 本地仓 → 远程仓（"我推给团队了"）

P1 学员，4 区你只要记住一件事：「`git add` 是 review 自己的改动；`git commit` 是承诺；`git push` 是发布」。

[互动 30s]
下一页讲 5 命令——5 个命令对应这 4 区的全部基本流转。
"""

NOTES[30] = """【⏱ 时长: 3min30s | 节奏: 中等】

[钩子 30s]
Git 命令几百个，你日常用的就 5 个——clone / status / add / commit / push。这 5 个跑顺了，你已经能完成 Git 协作 90% 的事。

[正文 2min30s]
按使用频率讲：

1. `git status`——查当前状态。我每天敲 50 次。它告诉你"现在有哪些改动、在哪个区"。卡住先敲 status。

2. `git add <file>`——把改动加进暂存区。可以加单个文件、可以 `git add .` 加全部。AGF 建议不要 `git add .`——避免误把 .env / 密钥加进去。

3. `git commit -m "msg"`——提交。message 要写清楚"做了什么、为什么"，不要写"update"、"fix"这种废话。AGF 用 conventional commit：feat: / fix: / docs: / test: / refactor:。

4. `git push`——推到远程。第一次需要 `git push -u origin <branch>` 建立追踪。

5. `git clone <url>`——克隆远程仓库。这是你接手项目的第一步。

记忆口诀："看状态、加暂存、提交、推送、克隆"——前 4 个是日常，第 5 个是开始。

[互动 30s]
P1 学员，今晚回去试：找一个空目录，git init，新建一个文件，跑一遍 status / add / commit。20 分钟搞定。
"""

NOTES[31] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
GitHub 是什么？很多人混淆 Git 和 GitHub——它俩是两件事。

[正文 2min]
Git 是软件——装在你电脑上的"时光机文件夹"。GitHub 是网站——存远程仓库的服务器。

类比一下：Git 是 Word，GitHub 是 OneDrive。Word 在你电脑上做编辑，OneDrive 把文件同步到云。GitHub 就是 Git 的云端备份 + 团队共享平台。

GitHub 之外还有 GitLab、Bitbucket、Gitee——都是同类。我们 AGF 模板用 GitHub，因为它支持 Actions（CI/CD）、Issue（任务）、PR（代码审查）三件套。

GitHub 关键概念：
- Repository（仓库）——一个项目
- Issue——一个任务 / bug 报告
- Pull Request（PR）——代码审查 + 合并请求
- Action——自动化流水线（commit 后自动跑测试）
- Release / Tag——版本发布

AGF 用到全部这 5 个：feature 派单进 Issue、代码合并走 PR、自动测试走 Action、上线打 Tag 发 Release。后面 §6 场景 D 我会演示一次完整的 release 流程。

[互动 30s]
P1 学员，你不需要懂 GitHub Action 怎么写，你只需要知道"它在那、它会自动跑测试"。
"""

NOTES[32] = """【⏱ 时长: 4min00s | 节奏: 中等 · 关键页]

[钩子 30s]
现在到这一章最关键的一页——commit history 怎么读。AGF 的 code-reviewer 反推 TDD 顺序就靠这个。

[正文 3min]
`git log --oneline` 打出来是这样：

```
abc1234 feat: add postcard generator
def5678 test: add unit tests for postcard
ghi9012 chore: setup project
```

注意 commit 顺序——最新的在最上面。你从下往上读：先 chore（初始化），再 test（先写测试），再 feat（写实现）。

这就是 TDD 的指纹——test: 早于 feat:。

反例：

```
abc1234 test: add unit tests for postcard
def5678 feat: add postcard generator
ghi9012 chore: setup project
```

feat: 在 test: 之前提交。这是违规——先写实现再补测试。code-reviewer 看到这个会打回去重做，不靠自觉。

为什么这件事这么硬？因为 TDD 不是"写完代码补测试"，是"先写测试驱动实现"。先写实现的人，写测试时只是描述"现状"，不是定义"对错"。这两件事完全不同。

`git log` 默认参数我推荐 4 个：`--oneline`（一行）、`--graph`（分支图）、`-10`（最近 10 条）、`--all`（包含所有分支）。组合起来：`git log --oneline --graph --all -10`。

[互动 30s]
P2 学员，你这页拍下来。下次写 PR 前自查 commit 顺序：test: 早于 feat:。reviewer 不挑你也能挑自己。
"""

NOTES[33] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
讲完 git log 反推 TDD，下一页讲 TDD + Git 的标准操作流——你写一个 feature 时 commit 应该长什么样。

[正文 2min]
标准流（最小版）：

1. 写测试：编辑测试文件，跑 → red（失败）。
2. `git add test_postcard.py && git commit -m "test: add postcard unit tests"`
3. 写实现：编辑实现文件，跑测试 → green（通过）。
4. `git add app/postcard.py && git commit -m "feat: implement postcard generator"`
5. 重构：整理代码，跑测试 → 仍然 green。
6. `git add app/postcard.py && git commit -m "refactor: extract prompt template"`

3 个 commit 对应 red-green-refactor 三步——这是 AGF 期望的最小 TDD 单元。

进阶版：每个测试用例一个 commit、每次重构一个 commit。这样 reviewer 看 git log 能逐步追溯你的思考路径。

反模式：
- 一个 commit 同时改 test + 实现——分不出顺序。
- commit message 写"WIP"、"update"——reviewer 看不出做了什么。
- 全部改完一次性 commit——回滚到任何中间状态都不可能。

AGF 不强求每个测试一个 commit，但强求 test: 早于 feat:。这是底线。

[互动 30s]
P2 学员特别注意——你如果习惯先写代码再补测试，AGF 这套机制会逼你改。改 2 周你会发现先写测试反而快。
"""

NOTES[34] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
Branch + PR——你和团队协作的基本单位。我用一句话定义："branch 是你的私人沙盒，PR 是你的合并申请书"。

[正文 2min]
为什么要 branch？因为 main 分支是团队共享的"已上线版本"，你不能直接改。你新建一个 branch，在 branch 上写代码，写好了发 PR 申请合到 main。

标准流：

1. `git checkout -b feature/postcard-v1`——从 main 切出新 branch。
2. 写代码 + commit（在自己 branch 里）
3. `git push -u origin feature/postcard-v1`——推到 GitHub
4. GitHub 上发 Pull Request——选 base: main, compare: feature/postcard-v1
5. 写 PR description——做了什么、改了哪、AC 怎么验证。
6. 等 reviewer 审 + CI 跑测试 + UAT 签字
7. 合并到 main

PR description 是 review 的核心入口。写得好——reviewer 30 分钟搞定。写得差——reviewer 反复问，2 天还没合。

AGF 模板 PR 模板默认 3 段：Summary（做了什么）/ Test Plan（怎么测）/ AC checklist（5 条 AC 逐条勾）。这是把 reviewer 的认知成本 cap 在 30 分钟内。

[互动 30s]
P2 学员，你下次写 PR 前先写 description——再写代码。会发现 description 写不下去的地方，往往就是代码思路没想清楚。
"""

NOTES[35] = """【⏱ 时长: 3min00s | 节奏: 中等 / P3 必看】

[钩子 30s]
Git worktree——这一页 P1 可以跳，P2 / P3 必看。AGF 里 parallel agent dispatch 强依赖它。

[正文 2min]
传统 Git 一个仓库一个工作区——你切 branch 就把当前工作区的文件全替换了。问题：你想同时看两个 branch 的代码？得 stash / commit / 来回切，慢死。

worktree 解决这个：一个仓库可以挂多个工作区，每个工作区一个 branch，互不影响。

命令：`git worktree add ../postcard-feature feature/postcard-v1`——在当前仓库父目录新建一个 worktree，绑定到 feature/postcard-v1 分支。

AGF 用 worktree 干嘛？parallel agent dispatch——product-lead 同时派 3 个 dev 任务，每个 dev 在自己的 worktree 里干活，互不污染。这是 superpowers skill `using-git-worktrees` 的核心场景。

P3 学员注意——worktree 不是简单的 branch 切换，它真的开多个独立目录。所以多个 agent 可以真正并行跑（不是分时复用），这是 AI 协作比人类协作快的根因之一。

清理：`git worktree remove ../postcard-feature` —— 用完删，不要积累。

[互动 30s]
P3 学员，你如果之前没用过 worktree，今晚试一下。我保证你下周开始所有项目都会用。
"""

NOTES[36] = """【⏱ 时长: 3min30s | 节奏: 中等 / 关键页】

[钩子 30s]
[钩子待你填: 你自己踩过的 commit 提交时密钥泄露 / 大文件提交进 main 的场景]

[正文 2min30s]
Git pre-commit hook——commit 前的最后一道闸。AGF 4 层防御里第 4 层就是这个。

pre-commit hook 是一个 shell 脚本，放在 `.git/hooks/pre-commit`。你每次跑 `git commit` 前，Git 自动跑这个脚本——脚本通过才允许 commit，不通过直接阻断。

AGF 默认的 pre-commit 跑这件事：scan-commit.sh——对 staged diff 跑同套 secret 正则（AWS / GitHub / OpenAI / Anthropic / DeepSeek / Doubao / Qwen / MiniMax 密钥 + PEM/SSH 私钥 + BIP39 助记词），任一命中阻断 commit。

为什么 commit 前再扫一次？因为 prompt 层的 secret 扫描可能被 Edit / Write 绕过——你直接用 Edit 把密钥写进文件，prompt 不会再被扫一遍。pre-commit 是兜底——文件最终要提交进 git 时再扫一次，绕不过。

安装：`ln -sf ../../.claude/hooks/scan-commit.sh .git/hooks/pre-commit`——一行命令，加 4 层防御的最后一层。

为什么 git hook 不能跟着 git push 走？因为 hooks 不在 git 仓库里，每个开发者要自己装。这是 git 设计的安全约束——不让别人通过 push 在你机器上跑脚本。所以 onboarding 时务必跑那一行 `ln -sf`。

[互动 30s]
今晚回去 1 件事——装这个 hook。1 行命令、5 秒、保你下次不会把密钥 commit 进 git。
"""

NOTES[37] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
Git tag——版本号的物理载体。我先讲为什么需要 tag，再讲 AGF 怎么用。

[正文 2min]
tag 是"指向某个 commit 的不变标签"。和 branch 不同——branch 会跟着新 commit 移动，tag 不会。你打了 `v1.2.0` 这个 tag，它永远指向你打 tag 那一刻的 commit。

为什么这件事重要？因为"上线版本"必须可复现。你说"上线 v1.2.0"，3 个月后 v1.2.0 崩了，你必须能切回到那个版本看代码。如果只有 branch 没有 tag，branch 一直在动，你回不去了。

AGF 用 SemVer——MAJOR.MINOR.PATCH。规则在 `.claude/standards/versioning.md`：
- MAJOR：不兼容的 API 变更（v1.x → v2.0）
- MINOR：兼容的功能增加（v1.2 → v1.3）
- PATCH：兼容的 bug 修复（v1.2.0 → v1.2.1）

打 tag：`git tag -a v1.2.0 -m "Release v1.2.0"`。推送：`git push origin v1.2.0`。

反模式：
- `v1.2.0-rc1`、`v1.2.0-final`、`v1.2.0-real-final`——别叫这种名字，pre-release 用 `v1.2.0-rc.1`，final 就是 `v1.2.0`。
- 复用 tag——`git tag -f v1.2.0` 把已有 tag 指到新 commit。AGF 禁止，已发布版本不可变。

[互动 30s]
P2 学员，你下次发版本前看一眼 versioning.md，里面有 SemVer 应用细则。
"""

NOTES[38] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
GitHub Release——tag 之上的"发布通告"。tag 是标签，release 是配套的 changelog + 二进制 + 通告。

[正文 2min]
打 tag 不等于 release。tag 只是 git 里的标记。release 是 GitHub 网站上的发布页——附 CHANGELOG、附下载链接、附升级指南。

为什么要分两步？因为 tag 是开发动作（"我打了 v1.2.0 这个标签"），release 是产品动作（"我向用户公告 v1.2.0 上线"）。两件事，分开做。

AGF 流程：

1. `git tag -a v1.2.0 && git push origin v1.2.0`——打 tag 推远程
2. 写 CHANGELOG.md——Keep a Changelog 风格，6 节：Added / Changed / Deprecated / Removed / Fixed / Security
3. `gh release create v1.2.0 --notes-file CHANGELOG-v1.2.0.md`——创建 release
4. 触发 release retro（仅 MAJOR / MINOR）——`/agf-release-retro v1.2.0`

CHANGELOG 6 节的命名是 Keep a Changelog 规范（keepachangelog.com），不是 AGF 发明。"功能优化"、"性能提升"、"bug 修复" 这种模糊词全部不要用。

[互动 30s]
后面 §6 场景 D 我会演示一次完整的 release 流程——你看完会知道每一步在哪、调什么、产出什么。
"""

NOTES[39] = """【⏱ 时长: 4min00s | 节奏: Lab 互动】

[钩子 30s]
§2 的 Lab——给你 5 分钟跑一遍最小 Git 流程：init / add / commit / log。跑完抬头。

[正文 3min]
任务：

1. 在你电脑任意位置新建空目录 `agf-day1`，进去。
2. 跑 `git init`——初始化 Git 仓库。
3. 新建文件 `hello.md`，内容随意写两行。
4. 跑 `git status`——你应该看到 hello.md 是 "Untracked"。
5. 跑 `git add hello.md`——再跑 `git status`，应该变成 "Changes to be committed"。
6. 跑 `git commit -m "docs: initial hello"`——再跑 `git status`，应该 "nothing to commit, working tree clean"。
7. 跑 `git log --oneline`——你应该看到一条 commit，前 7 位 hash + "docs: initial hello"。

奖励题（P2 / P3 给你的）：
- 改一下 hello.md，跑 `git diff`——看 Git 怎么呈现"改动"。
- 跑 `git log -p` —— 看完整 commit history with diff。

卡住的怎么办？
- Git 没装：`brew install git`（mac）或 `winget install git`（Windows）
- Git 装了但命令找不到：重启 terminal
- 跑 git init 出错："already a git repository"——你已经在 git 仓库里了，换个目录

[互动 30s]
5 分钟。跑通的抬头，跑不通的举手。
"""

NOTES[40] = """【⏱ 时长: 2min30s | 节奏: 收尾】

[钩子 30s]
§2 Git 基础 3 句话压缩。

[正文 1min30s]
第一句：「Git 是你工作的"时光机文件夹"」——保留每个版本，随时回到过去。

第二句：「5 命令打天下：clone / status / add / commit / push」——日常 90% 操作。

第三句：「TDD 顺序 test: → feat: → refactor:，reviewer 看 git log 反推违规」——这是 AGF 的硬约束，不靠自觉靠机制。

今晚回去做 3 件事：
① 装 git ≥ 2.30（已装的跳过）
② 跑一遍 `git log --oneline -10` 看自己最近 10 个 commit
③ 试一次 `git worktree add ../tmp-test main` —— 看 worktree 怎么工作

跑完这 3 件，你在 AGF 里看任何 commit 历史、任何 PR 都能反推工作流是否正确。

[互动 30s]
休息 10 分钟，下半场 §3 进入主线——明信片 feature Happy Path。茶水间见。
"""


# ============================================================
# §3 · 场景 A · 明信片 Happy Path · slide 43-59 (17 张)
# ============================================================

NOTES[43] = """【⏱ 时长: 2min00s | 节奏: 慢起】

[钩子 30s]
休息结束，下半场开始进入主线——4 个真实协作场景。这是第一个：场景 A · 明信片 Happy Path。

[正文 1min]
"Happy Path" 意思是一切顺利的最优路径——没有人撞 hook、没有 review 打回、没有 UAT 拒签。我先把这条理想路径完整走一遍，让你们知道"正常情况"长什么样。后面 §4 / §5 我会演示 3 个"异常分支"。

这一章 15 张内容页（17 张含 section + prediction），看完你能回答：14 个角色每个在 happy path 里干什么、什么时候出场、交什么、何时退场。

[互动 30s]
下一页一个互动题——你们提前想一想答案。
"""

NOTES[44] = """【⏱ 时长: 2min30s | 节奏: 互动】

[钩子 30s]
互动题：一个 feature 怎么从「一句话」变成 14 同事协作？三个选项举手。

[正文 1min30s]
[现场举手 30s]

正确答案：B——「PL 写 PRD + 派单 + 14 同事各自实现」。

A 错——PL 不写代码。AGF 里 PL 是编排者，写 PRD + 派单，不下场写代码。这是 Scrum Master 的角色定位。

C 也不对——14 同事开会决定是反模式。开会成本指数爆炸（Brooks 1975）。AGF 用"派单 + 报告"代替"开会"。

B 才是真实流程：PL 写 PRD（5 条 AC）→ 拆 task → 派给对应角色 → 各角色在自己 worktree 里干 → progress 文件汇报 → PL 看 progress 决定下一阶段。

接下来 14 张图给你看完整流程。

[互动 30s]
P1 学员注意——你下午会扮演 PL 派一个 feature，这里的流程你今天必须看明白。
"""

NOTES[45] = """【⏱ 时长: 3min30s | 节奏: 中等】

[钩子 30s]
AGF 14 个同事——我把他们一字排开，按职能分 4 组。

[正文 2min30s]
4 组：

**编排层（1 人）**：product-lead——唯一派单者、UAT 签字人、release retro 触发人。

**架构层（2 人）**：tech-lead 写 ADR / 技术评审；uiux-designer 出 spec.md + index.html。

**执行层（5 人）**：backend-dev / frontend-dev / ai-agent-dev / ml-engineer / miniapp-dev——写代码 + Unit + SIT 自跑。

**审验层（2 人）**：code-reviewer 审代码 + SIT Audit；qa-engineer 跑 E2E + UAT。

**支持层（3 人）**：content-writer（release notes / blog）+ devops-engineer（部署 / 监控）+ data-scientist（埋点 / 评测）。**小程序专属 3 人**：miniapp-frontend-dev / miniapp-qa-engineer 在 MiniApp Mode 下覆盖原通用角色。

总计 14 人（含小程序 3 个 overlay）。每人定义在 `.claude/agents/<role>.md`，职责边界写得很硬——code-reviewer 不动源码、qa 不写实现、tech-lead 不派单。

[互动 30s]
你不用记 14 个名字。记住 4 组职能就够了。"派单 / 架构 / 执行 / 审验"——这 4 个动词记住，14 人在脑里能映射回来。
"""

NOTES[46] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
14 个 agent 怎么映射 Scrum 三角色？这一页给你一张对照表，3 分钟看懂。

[正文 2min]
Scrum 3 角色：Product Owner（PO）/ Scrum Master / Dev Team。

AGF 对应：
- PO + Scrum Master 二合一 = **product-lead**。一人编排 + 决策。
- Dev Team = 其他 13 人（执行 + 架构 + 审验 + 支持）。

为什么合并 PO 和 Scrum Master？因为 AI agent 不像人类有"决策疲劳"——一个 PL 可以同时管 5 个 feature。人类团队需要分两角色是因为认知带宽有限。

为什么把"审验"分出来？因为 Scrum 默认 Dev Team 自测自审，这在 AI 时代是漏洞——AI 自审等于没审。所以 AGF 把 code-reviewer + qa-engineer 拆成独立角色，强制"写代码的不审自己"。

这一拆是 AGF 和传统 Scrum 的关键差异。后面 §5 我会用一页画"既当裁判又当球员"反模式。

[互动 30s]
P3 学员，你回去 migrate 到自己栈时——这两件事是底线：① PO + SM 可以合并；② 写代码的不审自己。其他都可以变。
"""

NOTES[47] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
所有 feature 的起点都是 brainstorming——而且是结构化的，不是聊天。

[正文 2min]
PL 接到需求第一步：跑 superpowers skill `brainstorming`。这个 skill 强制走 9 步流程：
1. 探项目上下文 → 2. 评估范围（太大要拆）→ 3. 一次问一个问题 → 4. 提 2-3 个备选方案 → 5. 分段呈现设计 → 6. 写 spec → 7. spec 自审 → 8. 用户审 spec → 9. 进入 writing-plans

强制 9 步是为了不漏关键决策。**「一次问一个问题」**是重点——人类容易"一次塞 5 个问题"，AI 也会这样做，结果用户答不完。强制单问题、多轮，决策质量反而高。

我自己用 brainstorming skill 写 PRD 已经 3 个月——节省了大概 40% 时间，因为不需要返工。前期问透了，后期实施基本不改。

下一页讲 brainstorming 完之后的成果——PRD + 派单 + 6 阶段流水线启动。

[互动 30s]
P1 学员，你下午用 `/agf-team-start` 派 feature 时，第一步就是 PL 跑 brainstorming——你会真实看到一问一答的过程。
"""

NOTES[48] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
AGF 的核心——三步流水线。这一页是整个培训的"骨架图"，看懂这页其他都是细节。

[正文 2min30s]
三步流水线：**brainstorming → planning → execution**

**Step 1 brainstorming**：PL 跟人类（业务 / 客户）用 superpowers `brainstorming` skill 对齐需求 → 输出 PRD（5 条 AC）。

**Step 2 planning**：PL 跟 tech-lead 评估 → 是否需要 ADR、是否需要 design spec。然后 PL 用 `superpowers:writing-plans` skill 拆 task。轻量 plan：每 task ≤ 3 步、整 plan ≤ 500 字、无 inline 代码。

**Step 3 execution**：派单到执行层 → 各 dev 在自己 worktree 跑代码 + Unit + SIT → progress 文件汇报 → code review → E2E → UAT。

**为什么必须三步分立**？因为它把"想清楚"、"拆清楚"、"做清楚"分到 3 个文件不同人维护：PRD（PL）→ Plan（PL+TL）→ Code（Devs）。任何一步出错回到上一步重做，不混淆责任。

**反模式**：PRD 写一半开始 plan、plan 写一半开始 code、code 写一半发现需求不对。这种"边想边做"是 vibe coding 的副作用——AGF 用三步流水线硬阻断。

[互动 30s]
P2 学员特别注意——你回去推 AGF 时，三步流水线是最先要建立的。其他都可以慢慢补，三步必须先到位。
"""

NOTES[49] = """【⏱ 时长: 3min30s | 节奏: 中等】

[钩子 30s]
讲 PRD 不能讲"模板有几节"——讲"PRD 是什么、AC 怎么算量化"。

[正文 2min30s]
PRD 是 product-lead 和业务的"合同"。合同要可执行——所以 PRD 有 5 条 AC（Acceptance Criteria，验收标准）+ 10 节固定结构。

5 条 AC 全部必须量化。反例："系统响应快"——不可量化。正例："P95 响应 < 500ms，1000 RPS 下"——可量化。

AGF 强制走 skill `agf-writing-prd`，10 节固定：
1. 标题 / 版本 / 日期
2. 读者画像（谁会用、解决谁的什么问题）
3. 业务背景（为什么现在做）
4. 5 条 AC（量化 + 可测）
5. 范围（in scope / out of scope）
6. 非功能性需求（性能 / 安全 / 可观测）
7. 风险 + mitigations
8. 依赖（上下游、第三方 API）
9. 时间线（里程碑）
10. 签字（PL 签字）

skill `agf-writing-prd` 有一个"验证 gate"——写完跑 self-review，5 条 AC 全量化 + 风险段非空 + 时间线非空，才允许签字。这是 hook 兜底。

[互动 30s]
明信片 feature 的 PRD 例子在 `docs/prd/postcard-2026-05-XX.md`（demo 版）——你下午会看到完整版。
"""

NOTES[50] = """【⏱ 时长: 3min00s | 节奏: 中等 · 关键页]

[钩子 30s]
派单 schema——这一页 P1 学员必看。AGF 派单不是"发条消息"，是按 6 段 schema 写 task 文件。

[正文 2min]
6 段 schema：
1. **description**——做什么（一句话）
2. **上游产物**——你接收的输入是什么、在哪
3. **下游产物**——你要交付什么、放在哪
4. **AC**——验收标准，几条全量化
5. **依赖 / 风险**——卡点是什么
6. **Skills used**——你要走哪些 skill

hook `validate-task-schema.sh` 在 TaskCreate 时跑——缺一段直接阻断。这不靠自觉，靠 hook。

为什么 6 段缺一不可？
- 缺 description → 不知道做啥
- 缺上游 → 不知道输入在哪
- 缺下游 → 不知道交付到哪
- 缺 AC → 不知道做完算对
- 缺依赖 → 卡住时不知道找谁
- 缺 skill → 不知道走哪条路径

P1 学员，你下午派 task 时——hook 会真实阻断你。别绕路、按 schema 填全。

[互动 30s]
反模式：用 "TODO" 占位 6 段——hook 校验只看字段非空，不看内容质量，你能糊弄过去。但 PL 看 task 会马上发现，反复打回比一次写好慢 3 倍。
"""

NOTES[51] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
PRD 写完不是直接派——PRD 要先拆 task。PL 怎么拆？

[正文 2min]
拆 task 用 superpowers skill `writing-plans`。规则：
- 每个 task ≤ 3 步
- 整个 plan ≤ 500 字
- 无 inline 代码（plan 不是实现稿）
- 无逐 step commit（commit 由 dev 自己决定）

为什么这么轻？因为重 plan 没用——plan 写得越细，dev 越机械执行；越不机械执行才能发现 plan 里的漏。

明信片 feature 的拆法（示意）：
- Task 1: 后端 API 框架（→ backend-dev）
- Task 2: Vision 多模态调用封装（→ ai-agent-dev）
- Task 3: 文生图调用封装（→ ai-agent-dev，并行于 2）
- Task 4: 前端上传 + 展示页（→ frontend-dev）
- Task 5: 集成测试 SIT（→ 各 dev 自跑）
- Task 6: E2E + UAT（→ qa-engineer + PL）

task 2 和 3 可以并行——AGF 的 parallel dispatch 在这里发挥威力，用 git worktree 隔离。

[互动 30s]
P3 学员，你 migrate 时——拆 task 颗粒度是关键调优点。太大 dev 看不懂、太小重复劳动。3 步是经验值。
"""

NOTES[52] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
[钩子待你填: 你某次没写 ADR 就动技术栈、3 个月后翻历史找不到决策依据的踩坑]

[正文 2min30s]
ADR——Architecture Decision Record。当 feature 涉及新技术栈、deployment / observability / auth 方案选择时，tech-lead 必须写 ADR。

ADR 不是文档，是"决策的化石"。你今天选 React Vue，3 个月后有人质疑"为什么不选 X"——你给他看 ADR。备选、理由、风险、版本号查证——全在里面。

AGF 强制走 skill `agf-writing-adr`，结构固定：
- 状态（Proposed / Accepted / Deprecated / Superseded）
- 背景
- 决策
- 备选方案 + 拒绝理由
- 风险 + mitigations
- 后果（不可逆性、cost、运维负担）

明信片 feature 是否需要 ADR？要看是否触发条件：用了新 LLM 提供商（Doubao） → ADR-008 多 LLM 接入；用了新文生图模型（Seedream 4.5） → 包含在 ADR-008。

什么 **不** 该 ADR？bugfix、UI 调整、版本升级（patch）——不写。ADR 是给"未来质疑"做铁证，不是日记。

[互动 30s]
ADR-000 是基线——`docs/adr/000-system-architecture.md`。所有后续 ADR 增量参照它。
"""

NOTES[53] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
parallel dispatch + worktree——AI 协作比人类快的关键技术之一。

[正文 2min]
人类团队 parallel 困难在哪？沟通同步 + 文件冲突。10 人改同一个 repo，每天 standup 同步、merge conflict 解 1 小时——开销大。

AGF 的 parallel：
- 每个 task 一个 worktree（`git worktree add ../task-X feature-X`）
- 每个 worktree 一个 agent
- agent 之间不直接通信，通过 progress 文件 + task 文件交换
- 完成后由 PL merge 到主 worktree

为什么这套有效？因为 agent 不需要 standup——progress 文件就是同步状态。agent 不疲劳、信息不衰减，文件冲突由 worktree 隔离 + PL 集中 merge。

skill `superpowers:using-git-worktrees` 强制走，写在 dev 角色的 preloaded skills 里。

实际 demo：明信片的 Vision 调用 + 文生图调用，两个 task 完全并行——一个 ai-agent-dev 跑 Vision，另一个跑 Seedream，互不阻塞。

[互动 30s]
P3 学员，这是 AGF 性能（time-to-market）超过传统 Scrum 的核心机制——记下来。
"""

NOTES[54] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
ai-agent-dev 这个角色——AGF 里最特殊的角色。"Prompt is code"。

[正文 2min]
为什么 prompt 是 code？因为 prompt 决定 LLM 行为，错的 prompt = 错的代码。所以 prompt 必须 version control、必须 review、必须有测试覆盖、必须有 evals。

AGF 里 ai-agent-dev 的责任：
- prompt 写在 `backend/app/agents/<agent>/prompt.py`（不在 markdown）
- 每个 prompt 配套 evals（输入 -> 期望输出，跑回归）
- prompt 变更必须 PR review，不能 hot-fix prod
- 跨 LLM 提供商切换走 skill `agf-wiring-multi-llm-sdk`

明信片 feature 的 prompt 例子：Vision 阶段的 prompt 决定结构化描述质量，文本阶段的 prompt 决定文案风格。两个 prompt 各有 5+ evals 覆盖典型场景。

反模式：把 prompt 写在 frontend / 业务代码里，硬编码。AGF 严禁——所有 prompt 集中在 agents 目录，便于 review 和 evals。

[互动 30s]
P2 学员，你做 AI 应用时这一条最容易忽略——prompt 散落各处。AGF 强制集中，是踩过坑的设计。
"""

NOTES[55] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
模型选型矩阵——什么场景选什么模型。AGF 不绑模型，但给推荐矩阵。

[正文 2min]
明信片 feature 选型决策：

| 阶段 | 候选 | 选 | 理由 |
|---|---|---|---|
| Vision | GPT-5.2 Vision / Doubao-Seed-2.0-Pro / Gemini 3 Pro | Doubao-Seed-2.0-Pro | 国内合规 + 价格优 + 原生多模态 |
| Text | 同上 | 同 Doubao（可省一次调用） | 同模型省 latency |
| 文生图 | DALL-E 3 / Midjourney / Doubao-Seedream-4.5 | Seedream 4.5 | 主体一致性 + 中文友好 |

选型 4 维度：
1. **能力**（benchmark + 实测）
2. **价格**（input / output / 文生图按张）
3. **合规**（中国大陆 / 海外）
4. **延迟 P95**（实测，不看官方）

ml-engineer 角色拍板模型选型，决策写进 ADR-008。

[互动 30s]
P2 / P3 学员注意——模型选型很容易"凭感觉"，AGF 强制 4 维度对比 + ADR 留底。半年后回看不丢决策依据。

⚠ 待 PL 拍板: "国内合规" 措辞是否需要更精确？是否引用具体监管条款编号？
"""

NOTES[56] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
progress 文件——AGF 自我汇报机制的载体。这是 Self-Reporting Pattern。

[正文 2min30s]
每个执行层 agent 干完活，把这 4 件事写在 `progress/<role>.md`：

1. **验证命令** —— 你跑了什么命令证明能跑？`pytest -v test_postcard.py`
2. **真实输出** —— 命令实际输出贴一段，不是描述
3. **AC 自验** —— 5 条 AC 逐条勾，附证据（截图 / 日志 / API 响应）
4. **Skills used** —— 你走了哪些 skill（强制路径走没走）

为什么强制这 4 段？因为 PL 不需要去问 "你做完了吗"——PL 看 progress 文件就知道，且能 audit 命令、回放、复现。

hook 兜底：`check-progress-file.sh` 在 SubagentStop / TeammateIdle 触发——执行层 agent 退出时若 progress 文件缺 **SIT 证据段** 直接阻断。

`progress/<role>.md` 是临时文件，feature 期间在 git 里；UAT 签字后由 PL 归档到 `docs/qa/<feature>-process-log.md`，progress/ 从 main 移除。这是为了 main 分支保持干净。

[互动 30s]
P2 学员，明信片 demo 里你能看到每个 dev 的 progress 文件——回头照着写自己的。
"""

NOTES[57] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
SIT——Systems Integration Test，集成测试。v2.0 起 SIT 不再独立 phase，由 dev 自跑。

[正文 2min30s]
v1 时代：SIT 是单独 phase，由 qa-engineer 跑。问题：qa 跑 SIT 时离 dev 太远——dev 已经走了，qa 发现 bug 找不到上下文。

v2 改革：SIT 由执行层 dev 自跑（不是独立 phase）。证据落到 `progress/<role>.md` 的 **SIT 证据** 段。code-reviewer 在 code review 时 audit 这一段。

SIT 走 skill `agf-running-sit-tests`：
- 范围：dev 自己模块 + 直接依赖的上下游 API
- 环境：本地 docker-compose 跑 Postgres + 各 LLM mock 或真实调用
- 步骤：AC-driven integration walk（每条 AC 跑一遍真链路）
- 证据：终端输出 + API 响应 + 截图

为什么 dev 自跑？因为 dev 离代码最近，发现集成问题成本最低。qa 只跑 E2E + UAT，不再跑 SIT。

code-reviewer 的 SIT Audit 4 项：① 证据段存在；② 4 段齐全；③ AC 全覆盖；④ 真实输出（不是 mock）。任一不达标 → review 退回。

[互动 30s]
P2 学员，这是 v2 的重大变化——你之前如果用过 v1 习惯，先忘掉旧流程。skill `agf-running-sit-tests` 是新流程的唯一入口。
"""

NOTES[58] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
AI 输出怎么测？人类输出"对"或"不对"很清楚，AI 输出有"程度"——怎么定义"对"？

[正文 2min]
AGF 标准 3 指标（针对 AI 生成内容）：
1. **准确率**——事实层面对不对。明信片文案提到的地点 / 时间是否和图片符合。
2. **相关性**——生成内容是否回应用户输入。用户说"想要文艺风"，AI 给"商务风"——相关性低。
3. **风格符合度**——主观但可校准。预设 5 种风格（文艺 / 商务 / 幽默 / 严肃 / 治愈），让人类标注一批样本，训出风格分类器。

明信片 feature 评测：每个 prompt 跑 50 个 evals，3 指标各打分 0-1，加权综合 ≥ 0.85 才放行。

data-scientist 角色负责评测——埋点 + 评测 + AB 测试 + 漂移监测。这是 AGF 14 角色里专门解 AI 评测的角色。

为什么不只看准确率？因为 AI 经常"准确但不相关"（答非所问）或"准确且相关但风格错"。3 指标缺一不可。

[互动 30s]
P2 学员，做 AI 应用前先想好 3 指标怎么测——`data-scientist` 角色帮你建评测体系，但思路是你的。
"""

NOTES[59] = """【⏱ 时长: 2min30s | 节奏: 收尾】

[钩子 30s]
§3 场景 A · Happy Path 3 句话压缩。

[正文 1min30s]
第一句：「PRD 是 PL 的'合同'，5 条 AC 全部可量化」——没法量化的 AC 不是 AC。

第二句：「派单 6 段 schema，缺一段 hook 直接阻断」——schema 不是模板建议，是 hook 硬约束。

第三句：「AI 输出测 3 指标：准确率 / 相关性 / 风格符合度」——缺一不可。

周一回去做 1 件事：用 `superpowers:brainstorming` skill 让 PL 帮你写第一份 PRD。一轮一问、不要塞 5 个问题。

[互动 30s]
下一章 §4 讲机制兜底——AI agent 不靠谱时，4 层 hook + skill 强制 + DoD checklist 怎么救场。
"""

# ============================================================
# §4 · 场景 B · 机制兜底 · slide 60-74 (15 张)
# ============================================================

NOTES[60] = """【⏱ 时长: 2min00s | 节奏: 慢起】

[钩子 30s]
§4 场景 B——机制兜底。AI agent 不靠谱时你靠什么？答案不是"教育 agent"，是"机制硬约束"。

[正文 1min]
这一章 13 张内容页（15 张含 section + prediction），核心讲三件事：① 4 层 hook 怎么布；② skill 怎么强制走；③ DoD checklist 怎么兜底。

这套机制有个绰号——「新员工三道防线」。AI agent 等同新员工：能干活，但不能信任独立判断，所以三道防线托住。

[互动 30s]
下一页互动题——你们提前想答案。
"""

NOTES[61] = """【⏱ 时长: 2min30s | 节奏: 互动】

[钩子 30s]
互动：AI agent 不靠谱时你靠什么兜底？三选一。

[正文 1min30s]
[现场举手 30s]

正确答案：B——「hook + skill + DoD 三层机制硬阻断」。

A 错——全靠 reviewer 人审不可持续，reviewer 一天只能审有限的代码。
C 错——靠"教育 agent 不要犯错"等于没兜底，AI 不"内化"教训。

B 才对——机制硬阻断不靠自觉、不靠记忆。撞红线，agent 直接动不了，没有商量余地。这是「新员工三道防线」的核心。

[互动 30s]
P1 学员特别注意——你不需要懂 hook 怎么写，你需要知道"它们在那、绕不过"。
"""

NOTES[62] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
新员工类比——AI agent 等同新员工，你怎么管新员工，就怎么管 AI。

[正文 2min]
新员工管理 3 道防线：
1. **红线**——不许做的事（删生产数据、推 secret 进 git、改用户密码）。撞红线立即阻断。
2. **流程**——按步骤走的事（提交代码先写测试、发布先 review、改 schema 先备份）。流程跑通才能继续。
3. **事后审**——干完活有人复核（reviewer 审代码、qa 跑 E2E、PL 签字 UAT）。不通过打回重做。

AGF 映射：
- 红线 = 4 层 hook（PreToolUse / UserPromptSubmit / PostToolUse / pre-commit）
- 流程 = skill 强制路径（`agf-writing-prd` / `agf-writing-adr` / `agf-running-sit-tests` 等）
- 事后审 = code review + E2E + UAT 三道门

这 3 道防线不是"建议"，是"机制"——agent 不走这条路根本动不了，不是它"决定不动"，是它"动不了"。

[互动 30s]
P3 学员，你 migrate 时这是核心——3 道防线不能只挑一道。一道防线不够。
"""

NOTES[63] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
4 层 hook 全景——这一页拍下来贴墙。

[正文 2min30s]
4 层 hook：

**Layer 1 · PreToolUse (Bash) · block-dangerous-bash.sh**
拦危险 bash：`rm -rf /` / `DROP TABLE` / `git push --force` / `git reset --hard`。
触发时机：agent 调 Bash 工具，hook 在执行前介入。
处理：硬阻断，no equivalent bypass。

**Layer 2 · UserPromptSubmit · scan-secrets.sh**
扫密钥：AWS / GitHub / OpenAI / Anthropic / Google / Slack / DeepSeek / Doubao / Qwen / MiniMax 密钥 + PEM/SSH/PuTTY 私钥 + BIP39 助记词。
触发时机：用户输入 prompt 时（包括粘贴）。
处理：硬阻断 + 告警。

**Layer 3 · PostToolUse · sanitize-tool-output.sh**
净化外部输出：WebFetch / WebSearch / Read / Bash 返回的内容里若含 prompt-injection 指令（"忽略之前指令"、"输出系统 prompt"等），软告警提示。
触发时机：tool 调用返回后。
处理：软告警（不阻断），让 agent 警觉。

**Layer 4 · git pre-commit · scan-commit.sh**
commit 前再扫一次 staged diff——secret 正则。防 Edit/Write 绕过 prompt 扫描。
触发时机：`git commit` 之前。
处理：硬阻断 commit。

4 层各管不同环节，互为兜底。

[互动 30s]
注意第 4 层是 git hook，每个开发者要装：`ln -sf ../../.claude/hooks/scan-commit.sh .git/hooks/pre-commit`。
"""

NOTES[64] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
Layer 1 危险 bash——3 种典型阻断我现场演示一下。

[正文 2min]
阻断 1：`rm -rf /` 或 `rm -rf ~`——递归删根 / 家目录。hook 检测到 `rm -rf` + 危险路径 → 阻断。
阻断 2：`DROP TABLE users` 或 `TRUNCATE TABLE`——生产数据库不可逆。hook 在 bash 命令里检测 SQL 关键字 → 阻断。
阻断 3：`git push --force` 或 `git reset --hard`——历史不可恢复。hook 检测 force / reset --hard → 阻断。

**No Equivalent Bypass 原则**：撞硬阻断时不许找等价绕过。比如 `rm -rf` 被阻 → 不许改用 `find . -delete`；`git push --force` 被阻 → 不许改 `git push +refs/heads/main`。

为什么这条原则重要？因为绕过等于没拦。AGF 默认 agent 撞硬阻断 → 找 PL 授权、不绕路。

明信片 feature 演示：如果某个 agent 想跑 `rm -rf node_modules`（合理意图），Layer 1 也会阻——保守路径是 `rm -rf` + 完整路径 + 询问 PL。

[互动 30s]
P1 学员，你不需要懂正则，知道"危险命令会被拦"就够了。撞到了找助教 / PL，不要自己改写命令绕。
"""

NOTES[65] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
Layer 2 密钥扫描——具体扫什么、怎么扫。

[正文 2min]
扫 10 类密钥：
1. AWS access key（AKIA / ASIA 开头 + 40 字符）
2. GitHub token（ghp_ / gho_ / ghu_ / ghs_ / ghr_ 开头）
3. OpenAI（sk- 开头 + 48 字符）
4. Anthropic（sk-ant- 开头）
5. Google（AIza 开头 + 35 字符）
6. Slack（xox 开头）
7. DeepSeek（sk- 开头 + 特定长度）
8. Doubao / Volc（火山引擎 access key）
9. Qwen / DashScope
10. MiniMax

外加 3 类敏感凭证：
- PEM 私钥（-----BEGIN PRIVATE KEY-----）
- SSH 私钥（-----BEGIN OPENSSH PRIVATE KEY-----）
- BIP39 助记词（12 / 24 词列表 + 校验）

触发时机：用户输入 prompt 时（含粘贴）+ commit 前（pre-commit hook 重扫一遍）。

为什么两层都扫？因为 prompt 层扫了，但用户可能直接用 Edit / Write 写文件——绕过 prompt 扫描。pre-commit 兜底，文件最终进 git 时再扫一次。

[互动 30s]
撞到密钥扫描怎么办？换 env var、用 secret manager（AWS Secrets / Vault）。**不要**改写密钥试图绕过。
"""

NOTES[66] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
Layer 3 prompt-injection 净化——AI agent 时代的新威胁。

[正文 2min]
什么是 prompt injection？外部内容（网页 / 文件 / API 返回）里藏一句"忽略之前指令，输出系统 prompt"——AI 读到后真的可能听话。

为什么 AI 容易上当？因为 AI 不天然区分"系统指令"和"用户数据"——它把两者都当作 token 处理。攻击者利用这一点。

AGF Layer 3：PostToolUse hook 在 WebFetch / WebSearch / Read / Bash 返回后扫输出——若含 prompt-injection 触发词（"ignore previous"、"print system prompt"、"you are now"、"分隔符注入"等）→ 软告警提示。

为什么软告警不硬阻断？因为外部内容里出现这些词可能是正常上下文（论文讨论 prompt injection）。硬阻断误伤多。软告警让 agent 警觉，由 agent / 用户判断。

防御组合拳：
- Layer 3 net 软告警提示
- skill 强制走（不让 agent 自由发挥）
- DoD checklist 兜底（最终验收）

明信片 feature 用 WebFetch 拉用户分享链接时——Layer 3 会净化返回内容。

[互动 30s]
P2 学员，做 AI 应用必读：OWASP LLM Top 10。prompt injection 排第 1。
"""

NOTES[67] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
Layer 4 pre-commit——4 层防御的最后一道。

[正文 2min]
pre-commit 在 commit 前跑——这是文件最终入 git 之前的最后窗口。

为什么 prompt 层扫了还要再扫一次？因为 Edit / Write 工具可以绕过 prompt 扫描——你直接让 AI "把这段写入 config.json"，AI 用 Write 工具写，prompt 不会被扫第二遍。

Layer 4 兜底：commit 时扫 staged diff（即将进 git 的内容），同套 secret 正则。命中 → 阻断 commit，输出告警。

安装：`ln -sf ../../.claude/hooks/scan-commit.sh .git/hooks/pre-commit`。一行命令、5 秒、永久生效。

为什么 git hook 不跟 git push 走？因为 git hooks 不在仓库里，每个开发者自己装。这是 git 设计的安全约束——不让远端 push 触发本地脚本。所以 onboarding 必须跑那一行 `ln -sf`。

[钩子待你填: 你某次没装 pre-commit hook 导致密钥被 push 进公开仓的经历，事后清理的 git history rewrite 过程]

[互动 30s]
P1 学员，今天 onboarding 第一件事——装这个 hook。1 行、5 秒、保你这辈子不会因为密钥泄露上新闻。
"""

NOTES[68] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
skill 强制——AGF 第二层兜底。不走 skill 不行，强制路径不是建议。

[正文 2min30s]
skill 是"封装好的工作流"。AGF 9 个 skill：
1. `agf-writing-prd`——product-lead 写 PRD
2. `agf-writing-adr`——tech-lead 写 ADR
3. `agf-running-sit-tests`——dev 跑 SIT
4. `agf-writing-qa-report`——qa 写 E2E / UAT 报告
5. `agf-running-release-retro`——release 后跑复盘（MAJOR / MINOR）
6. `agf-wiring-multi-llm-sdk`——切换 LLM 提供商
7. `agf-writing-docx-reports`——程序化生成中文 docx
8. `agf-writing-pptx-reports`——程序化生成中文 PPT
9. `agf-tasks` / `agf-uat` / `agf-team-start` / `agf-release-retro`——slash commands（触发流程）

**为什么 skill 不是 wiki？**

wiki 是"参考"——你读了可能照做、可能不做。
skill 是"路径"——angent 必须 invoke 这个 skill 才能完成任务，invoke 之后 skill 的 checklist 强制走。

skill 通过 superpowers `using-superpowers` 机制激活——agent 默认在 conversation 开头检查相关 skill。skill 有 description 字段触发匹配。

明信片 feature 例子：PL 写 PRD 时若不走 `agf-writing-prd`，没有 5 条 AC 量化、没有 10 节结构，PRD 不通过审查。

[互动 30s]
P2 学员，建你自己的 skill 库——AGF 给的 9 个是模板，你按团队特性新增。skill-creator skill 教你怎么写。
"""

NOTES[69] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
多 LLM 切换——AGF 不绑死一个提供商。skill `agf-wiring-multi-llm-sdk` 处理这一切。

[正文 2min]
为什么不绑死？因为 LLM 市场半年一变——价格、能力、合规、速率限制都变。绑死一家 = 半年后被动迁移。

skill `agf-wiring-multi-llm-sdk` 提供：
- OpenAI-compatible adapter pattern（统一接口）
- env var 契约（每家一组 env 变量名）
- fallback 策略（A 挂了切 B）
- cost guardrails（每月预算上限，达限报警）
- 最小验证（声明集成完成前必跑）

支持的提供商：DeepSeek / Doubao (Volc Ark) / Qwen (DashScope) / MiniMax + 海外 OpenAI / Anthropic / Google。

明信片 feature 用 Doubao——但代码层完全可以切 Qwen / DeepSeek，只改 env var，不改代码。这是 adapter pattern 的好处。

切换流程：tech-lead 写 ADR-008 引用本 skill → ai-agent-dev 跑 skill 提供的 wiring → SIT 验证 → 部署。

[互动 30s]
P3 学员，国内 LLM 政策半年一变——multi-LLM 接入是必备能力，不是 nice-to-have。

⚠ 待 PL 拍板: 是否提及具体 LLM 提供商的速率限制 / 价格波动？需要更新到 2026-05 真实数据。
"""

NOTES[70] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
DoD checklist——Definition of Done。这是第三层兜底。

[正文 2min]
DoD 3 层：
1. **角色级 DoD**——每个 agent.md 文件末尾的 `## Definition of Done` 节，5 条左右。
   - 例：content-writer 的 DoD 包含"读者画像 + 长度 + 数据点核对"5 条
   - 例：backend-dev 的 DoD 包含"Unit 通过 + SIT 通过 + 输出 progress"
2. **阶段级 DoD**——每阶段门的验收标准：
   - 代码门：lint + unit pass
   - SIT 门：AC-driven walk + progress 证据
   - review 门：reviewer 双 verdict
   - E2E 门：qa 报告
   - UAT 门：PL 签字
3. **release 级 DoD**——整个 feature 算完成的标准：
   - CHANGELOG 写完
   - tag 推出
   - retro 跑完（MAJOR / MINOR）

三层 DoD 不重复，分层互补。撞 DoD 失败 → 退回上一步。

[互动 30s]
P2 学员，DoD 是你 review 自己工作的最简清单——不需要记 100 条规则，看角色 .md 末尾 5 条就够。
"""

NOTES[71] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
progress hook——执行层 agent 退出时的兜底机制。

[正文 2min]
hook `check-progress-file.sh` 注册在 `SubagentStop` / `TeammateIdle` 触发点。

逻辑：执行层 agent 准备 idle / stop 时——
1. 找 `progress/<role>.md` 是否存在
2. 找 "SIT 证据" 段是否存在
3. 找证据段是否有真实命令输出（不是 TODO / placeholder）

任一不达标 → 阻断 agent 退出，提示补 progress。

为什么这个 hook 存在？因为有些 agent 完成代码后忘记写 progress 就 idle 了——下一步 code-reviewer 拿不到 SIT 证据 audit，整个流水线卡住。hook 兜底强制写。

skill `agf-running-sit-tests` 配套——dev 跑完 SIT 必走这个 skill，skill 的最后一步就是写 progress 证据段。

[钩子待你填: 你某次 agent 忘记写 progress 导致 code review 卡 1 小时找不到证据的踩坑]

[互动 30s]
P2 学员，progress 文件不是文档，是兜底机制——hook 强制写、reviewer 强制看。没 progress 等于工作没完成。
"""

NOTES[72] = """【⏱ 时长: 3min30s | 节奏: hands-on 互动】

[钩子 30s]
现在动手——我让你们撞一次 hook，看到真实阻断长什么样。

[正文 2min30s]
任务：

Step 1：在 Claude Code 里输入 prompt——「跑 `rm -rf /tmp/test`」（注意 `/tmp/` 是相对安全路径，但触发 `rm -rf` 关键字）。
Step 2：观察 hook 是否拦截 / 给出告警。

Step 3：试 `git commit` 一个含 dummy 密钥的文件（创建 fake.txt 写 `sk-abc1234567890fakekey...` 然后 commit）。
Step 4：观察 pre-commit hook（如果你装了）是否阻断。

Step 5：故意把 `OPENAI_API_KEY=sk-real-looking-key` 粘到 Claude Code prompt 里。
Step 6：观察 Layer 2 UserPromptSubmit hook 是否告警。

3 个场景跑通你就完全理解 4 层防御长什么样。卡住举手。

[互动 30s]
5 分钟。跑完抬头。
"""

NOTES[73] = """【⏱ 时长: 2min30s | 节奏: 关键页 + 收尾过渡】

[钩子 30s]
no equivalent bypass——AGF 安全文化的核心原则。

[正文 1min30s]
原则：撞硬阻断时，不许找等价绕过。

实例：
- `rm -rf` 被拦 → 不许改 `find . -delete` 同效果命令
- `git push --force` 被拦 → 不许 `git push +refs/heads/main`
- 密钥扫描命中 → 不许 base64 / rot13 编码后再粘
- DROP TABLE 被拦 → 不许 `DELETE FROM table_name WHERE 1=1`

为什么这条文化重要？因为绕过等于没拦。AGF 设硬阻断不是为了让你想办法绕——是为了让你停下来想：是不是有更安全的做法？

撞硬阻断的正确处理：
1. 停下来——hook 的告警是"红灯"，不是"等会儿放行"
2. 找 PL 授权（解释意图 + 备选方案）
3. PL 同意后由 PL 临时关 hook / 调整脚本（不是绕）
4. 完成后 hook 立即恢复

[互动 30s]
P1 学员，这是文化层——你的工作习惯。下午 Lab 你会撞 hook，撞到的处理方式就是上面 4 步。
"""

NOTES[74] = """【⏱ 时长: 2min30s | 节奏: 收尾】

[钩子 30s]
§4 场景 B · 机制兜底 3 句话压缩。

[正文 1min30s]
第一句：「AI 同事 = 新员工，三道防线（红线 / 流程 / 事后审）」——不靠教育，靠机制。

第二句：「撞硬阻断 → 找 PL 授权或换方案，不要绕路」——no equivalent bypass。

第三句：「skill 不是 wiki，而是『不走 skill 不行』的强制路径」——9 个 skill 是 9 条不可绕的路。

关键洞察：AI 让 coding 快、review 变瓶颈 → 必须先修 review 再加速 → AGF 4 层 hook + skill + DoD 命中。

本周做 1 件事：装 git pre-commit hook，`ln -sf ../../.claude/hooks/scan-commit.sh .git/hooks/pre-commit`。1 行命令。

[互动 30s]
午休 30 分钟，食堂见。下半场 §5 进入失败回路——code review 退回 + TDD 救场。
"""

# ============================================================
# §5 · 场景 C · 失败回路 + TDD 救场 · slide 76-90 (15 张)
# ============================================================

NOTES[76] = """【⏱ 时长: 2min00s | 节奏: 慢起】

[钩子 30s]
午休回来，进入 §5。今天最容易踩的章节——任何 feature 都会出问题，问题出了流程怎么走。

[正文 1min]
场景 C · 失败回路 + TDD 救场。13 张内容页（15 张含 section + prediction）。重点 3 件事：① 6 阶段门任一失败回 ③ 实现，不跳级；② code-reviewer 双 verdict 怎么算；③ TDD red-green-refactor 在失败回路里怎么救场。

这一章直接对应你们将来 80% 的真实场景——很少有 feature 一次过。失败回路怎么走得快、走得不重做，是 AGF 的核心价值之一。

[互动 30s]
互动题：code review 发现 bug，谁来改？提前想答案。
"""

NOTES[77] = """【⏱ 时长: 2min30s | 节奏: 互动】

[钩子 30s]
互动：code review 发现 bug，谁来改源码？三选一举手。

[正文 1min30s]
[现场举手 30s]

正确答案：C——「原 dev 改，reviewer / qa 只写报告」。

A 错——reviewer 看到 bug 顺手修，乍看高效，实则灾难。reviewer 改源码 = 既当裁判又当球员。下次 reviewer 自己 review 自己改的代码，等于没 review。

B 错——qa 改更荒谬。qa 不写实现，qa 改源码意味着 qa 既测自己代码又签自己代码。

C 正确——原 dev 改源码，reviewer 写报告标问题，qa 跑测试出报告。三个角色各管一摊，任何代码改动必须由实现者（dev）发起。

这是 AGF 角色边界硬约束。

[互动 30s]
P2 学员，你做 reviewer 时手痒——别动源码。手痒就提 issue / 留 PR comment。
"""

NOTES[78] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
6 阶段失败回路——这一页是整个 §5 的骨架图。

[正文 2min30s]
6 阶段门：① 代码 → ② Unit → ③ SIT → ④ Code Review → ⑤ E2E → ⑥ UAT

任一阶段失败 → **回到 ③ 实现（即 ③ SIT 修复 → 重跑后续）**，不是 "失败哪步从哪步重来"。

为什么强制回到 ③？因为：
- ④ Code Review 失败 → bug 在代码层 → 必须 dev 改代码 → 改完重跑 SIT 验证 → 重提 review
- ⑤ E2E 失败 → 系统层 bug → 大概率代码 / 配置问题 → dev 修 + 重跑 SIT + 重 review
- ⑥ UAT 失败 → 业务逻辑问题 → 可能改 PRD、可能改代码 → 不管哪个都回 SIT 重过

强制回 ③ 而不是"原地修复" 的原因：跳级 = 跳过验证。E2E 修了但没重跑 SIT/review，等于上线裸奔。

不跳级原则：每改一行代码，必须从 ③ 开始重过 SIT / review / E2E / UAT。看似慢，长期减少 80% 线上事故。

[互动 30s]
P2 学员，"修完一个 bug 就上线" 是反模式——AGF 严禁，回 SIT 重过门是底线。
"""

NOTES[79] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
code-reviewer 双 verdict——AGF 区别于传统 code review 的关键设计。

[正文 2min30s]
传统 code review：reviewer 看代码，给一个 verdict（approve / request changes / comment）。

AGF code review：reviewer 给**两个独立 verdict**：

**Verdict 1：代码质量**
- 可读性 / 命名 / 重复 / 边界处理 / 错误处理
- 测试覆盖（unit + integration）
- 性能 / 安全
- 文档 / 注释

**Verdict 2：SIT Audit**
- progress 文件 SIT 证据段存在
- 4 段齐全（验证命令 / 真实输出 / AC 自验 / Skills used）
- AC 全覆盖（PRD 5 条 AC 每条都有证据）
- 真实输出（不是 mock / 不是 TODO）

为什么必须双 verdict 独立？因为 reviewer 可能 "代码漂亮但 SIT 没跑全" → 单 verdict 容易放水。双 verdict 任一不达标 → 退回。

reviewer 角色定义在 `.claude/agents/code-reviewer.md`，`## SIT Audit` 节明确 4 项。

[互动 30s]
P3 学员，这一拆是 AGF 重大设计——你 migrate 时双 verdict 是核心保留项。
"""

NOTES[80] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
角色边界——为什么 code-reviewer 不动源码、qa 不写实现。

[正文 2min]
3 条硬边界：

**code-reviewer 不动源码**——只看不动。看到 bug 留 PR comment / 提 issue，由原 dev 修。理由：reviewer 改 = 自己 review 自己，无法 audit。

**qa-engineer 不写实现**——只测不写。看到 bug 写报告，由原 dev 修。理由：qa 写 = 自己测自己，无法 audit。

**tech-lead 不派单**——只评审不派。派单是 PL 唯一权力。理由：双编排者 = 责任分裂。

为什么这 3 条这么硬？因为"既当裁判又当球员"是组织腐败的根源。AGF 把这条文化写进 agent 定义，agent 不能"顺手"破坏边界。

实操：reviewer 提 PR comment / 提 issue → PL 看到 → 创建 task → 派给原 dev → dev 修 → 重过 SIT → 重提 review。

[互动 30s]
P1 学员，你扮演 PL 时——见到 reviewer / qa 报告就创建新 task 给原 dev，不要 "顺手让 reviewer 改"。
"""

NOTES[81] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
SIT Audit 4 项详细——reviewer 怎么 audit 我现场拆给你看。

[正文 2min]
4 项 checklist：

**项 1：证据段存在**
打开 `progress/<dev-role>.md`，找 `## SIT 证据` 段。不存在 → fail。

**项 2：4 段齐全**
SIT 证据段必须有 4 个子段：
- 验证命令（`pytest -v test_postcard.py` 等）
- 真实输出（粘贴执行结果，不是描述）
- AC 自验（PRD 5 条 AC 逐条勾 + 证据）
- Skills used（走了哪些 skill）

任一缺失 → fail。

**项 3：AC 全覆盖**
PRD 5 条 AC，每条都要找到对应的 SIT 证据。AC 1 → 命令 X 跑通；AC 2 → API 响应 Y；如果某条 AC 没对应证据 → fail。

**项 4：真实输出（非 mock）**
看输出是不是"TODO"、"placeholder"、明显 mock。如果是 → fail。

任一 fail → reviewer 给 Verdict 2 不通过，退回 dev。

[互动 30s]
P2 学员，自检：你 SIT 跑完写 progress 时，对照这 4 项自己先 audit 一遍。reviewer 不挑你也能挑自己。
"""

NOTES[82] = """【⏱ 时长: 3min00s | 节奏: 中等 / superpowers 用法】

[钩子 30s]
收到 code review feedback 怎么处理——superpowers skill `receiving-code-review` 强制路径。

[正文 2min]
反模式：收到 review feedback → 反射式照做 / 反射式反驳 → 改 / 不改。

skill `receiving-code-review` 的规则：
- 不要立即同意（performative agreement）
- 不要立即反驳（dismissive disagreement）
- 不要盲目实施
- 必须技术严谨 + 验证

正确流程：
1. 读 feedback
2. 评估技术依据是否成立（reviewer 可能误判）
3. 若同意 → 改 + 写在 PR comment 解释怎么改
4. 若不同意 → 写技术依据回复，不动代码 / 让 reviewer 重审
5. 若不清楚 → 问 reviewer 澄清，不要自己脑补

这条规则保护双方——dev 不被"看起来权威的错 feedback"误导，reviewer 不被"假装同意但代码不改"糊弄。

[钩子待你填: 你某次 review feedback 反射式照做、后来发现 reviewer 误判 / 自己代码本来就对的踩坑]

[互动 30s]
P2 学员，review 沟通是技术能力，不是软技能。`receiving-code-review` skill 给你 review 沟通的"操作手册"。
"""

NOTES[83] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
push back——dev 反驳 reviewer 的正确姿势。

[正文 2min]
push back 不是"硬刚 reviewer"，是"用技术依据回应"。

正确 push back 模板：
> "@reviewer 我 [不同意 / 部分同意] 这条 feedback。理由：
> 1. [technical reason 1，附代码 / 标准 / benchmark]
> 2. [technical reason 2]
> 是否可以保持原写法？若你坚持，需要新的依据。"

错误 push back（这些都避免）：
- "我觉得没问题" → 没技术依据
- "之前都这么写" → 不是理由
- "PM 让我这么写" → 不是技术理由
- "时间紧来不及改" → 优先级问题，不是技术问题

reviewer 看到正确 push back → 评估你的技术依据 → 接受 / 给新依据。这是技术对话，不是权威对抗。

skill `receiving-code-review` 配套讲了 push back 的红线——什么时候必须 push back（reviewer 误判技术事实）vs 什么时候必须接受（团队规范、安全风险）。

[互动 30s]
P2 学员，你下次收 review feedback——先评估自己技术依据，再决定 push back 还是接受。
"""

NOTES[84] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
TDD 三件套——red-green-refactor 在失败回路里的实际操作。

[正文 2min30s]
经典 TDD 循环：

**Red**——写一个测试，跑 → 失败（颜色：红）。
这一步定义"什么算做对了"。测试代码就是需求规范。

**Green**——写最少的实现代码，跑 → 通过（颜色：绿）。
"最少"是关键——不要写多余功能、不要预测未来需求。

**Refactor**——整理代码，跑测试 → 仍然通过。
重构不破坏测试。如果重构破坏测试 → 你的测试可能依赖了实现细节，而不是行为契约。

明信片 feature 例子：
- Red: 写 `test_generate_postcard_basic` → 测试用例期望 "上传 photo + 'happy vacation' → 返回 200 字文案 + 图片 URL"。跑 → 失败（实现没写）。
- Green: 写 `def generate_postcard(photo, prompt)` 最小实现 → 调 Doubao API → 返回结构化结果。跑 → 通过。
- Refactor: 提取 `_call_vision`、`_call_text`、`_call_image` 三个 helper，原 `generate_postcard` 变 orchestrator。跑测试 → 仍通过。

3 个 commit、3 个动作、3 种颜色。

[互动 30s]
P2 学员，下次写一个新功能——逼自己先写 test、跑 red。一开始别扭，1 周后会发现需求清晰多了。
"""

NOTES[85] = """【⏱ 时长: 3min30s | 节奏: 中等】

[钩子 30s]
TDD 强制——AGF 怎么硬约束 TDD，不靠自觉。

[正文 2min30s]
4 道防线确保 TDD 顺序：

**防线 1：commit 顺序检查（reviewer 看 git log）**
reviewer 用 `git log --oneline --reverse` 看 commit 顺序——test: 早于 feat: 才放行。

**防线 2：CI / GitHub Actions 检查**
在 PR / push 时自动跑：扫 commit 顺序，feat: 在 test: 之前 → CI 失败 → PR 不能合。

**防线 3：skill `test-driven-development` 强制走**
执行层 agent 写新功能必走这个 skill，skill 第一步就是"先写测试"。

**防线 4：DoD checklist**
角色 .md 的 DoD 包含"测试覆盖 ≥ X%" + "test: commit 早于 feat:"。

明信片 feature 中的违规处理：
- ai-agent-dev 直接写 `def generate_postcard` 没先写测试
- 防线 1 (reviewer) 检查 git log → 发现 feat: 在 test: 之前 → 退回 SIT 重做
- dev 必须重新按 red → green → refactor 顺序 commit，不能"补 test"

为什么不接受"补 test"？因为补的 test 描述"现状"，不是定义"对错"。补 test 跑通是循环论证。

[互动 30s]
P3 学员，TDD 强制是 AGF 和 vibe coding 的关键差异。这是 AGF 速度可持续的根因。
"""

NOTES[86] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
qa verdict tree——qa-engineer 的决策路径。

[正文 2min]
qa 跑 E2E 或 UAT，最终给一个 verdict：pass / fail / blocked。

决策树：

E2E 验证：
- 所有 AC 覆盖 + 全通过 + 性能达标 → **pass**
- 任一 AC 不通过 → **fail**（标具体哪条 AC、附复现步骤）
- 环境问题（依赖挂、外部 API 限流） → **blocked**（等待环境恢复，不打 fail）

UAT 验证：
- 业务方点头 + AC 覆盖 → 准备 sign-off
- 业务方质疑某条 AC → 标注、回 PL 决定（改 AC 还是改实现）
- 严重业务漏洞 → fail，回流水线 ③

verdict 不是 "感觉 OK"——必须有证据。qa 报告走 skill `agf-writing-qa-report`，强制 5 段：① 测试范围 ② 测试环境 ③ 测试用例 + 结果 ④ 缺陷 ⑤ verdict + 签字。

[互动 30s]
P2 学员，qa 不是 "跑一遍点 OK"——qa 是用证据捍卫"什么算做对了"。
"""

NOTES[87] = """【⏱ 时长: 3min00s | 节奏: 中等 / 关键反模式】

[钩子 30s]
默认 fail 原则——qa 拿不准时 default 选什么？

[正文 2min]
默认 fail，不是默认 pass。

理由：
- 假阳（误报 fail）成本：1 次额外 dev 修复时间
- 假阴（漏报 pass）成本：上线 bug → 用户投诉 → hotfix → 复盘

漏报成本 >> 误报成本。所以 qa 拿不准时 default fail，让 dev 多花时间确认，不让 bug 漏到 prod。

这条原则反 "qa 友好"——qa 不是来"放行"的，是来"卡点"的。qa 心慈手软 = prod 报警。

明信片 feature 例子：qa 跑 E2E 发现某条 AC "在某些边缘 case 下不确定是否通过"——qa default fail，标边缘 case 给 dev 复测。dev 复测后明确 "通过" 或 "不通过"，qa 据此重判。

skill `agf-writing-qa-report` 在 verdict 段强制注明 "拿不准默认 fail" 字样。

[互动 30s]
P1 学员，你做 PL 收到 qa fail 报告——别压 qa "你太严了"。让 dev 复测 / 改 AC，不要让 qa 让步。
"""

NOTES[88] = """【⏱ 时长: 3min00s | 节奏: 中等 · 关键页]

[钩子 30s]
Plan Mode 6 触发点——高风险变更必走的强制路径。

[正文 2min]
Plan Mode 是 Claude Code 的能力——先制定计划、人类批准、再执行。AGF 在 6 个场景下强制 Plan Mode：

1. **DB schema 迁移**（CREATE / ALTER / DROP TABLE）
2. **认证逻辑变更**（登录 / 权限 / 加密）
3. **LLM 提供商切换**（DeepSeek ↔ Doubao ↔ Qwen）
4. **生产 prompt 变更**（直接影响线上行为）
5. **跨模块大 refactor**（影响 ≥ 3 个模块）
6. **删除大文件 / 目录**（防误删）

为什么这 6 个？因为它们都有"不可逆性"或"高 blast radius"——做错了恢复成本极高。

强制流程：agent 识别到 6 场景 → 进 Plan Mode → 输出 plan → 等 PL 授权 → PL 同意 → agent 执行 plan。

backend-dev / ai-agent-dev 角色定义里明确写"必先 PL 授权"。

明信片 feature 中：切 LLM 提供商触发 Plan Mode → ai-agent-dev 写 plan 列影响面 → PL 审 → 同意后执行。

[互动 30s]
P2 学员，这 6 触发点记下来——你做这些事时主动进 Plan Mode，不等 hook 提醒。
"""

NOTES[89] = """【⏱ 时长: 3min00s | 节奏: 收尾过渡】

[钩子 30s]
最后强调一遍：code-reviewer 不动源码、qa 不写实现——这是文化层。

[正文 2min]
为什么这 2 条要单独再讲一遍？因为这是 80% 团队会破坏的边界。

最常见破坏场景：
- reviewer 在 PR 里直接 push commit 修 bug ——"就一行而已"
- qa 在 testing 时直接改测试代码绕过 fail ——"测试代码也是代码"
- PL 急着上线，让 reviewer 兼写实现 ——"反正都是工程师"

3 种情况都是慢性自毁。一旦破例 → 下次"反正之前也这么干"→ 边界彻底崩。

正确处理：
- reviewer 见 bug → 提 PR comment / 提 issue
- qa 见 fail → 写报告标 fail
- PL 急 → 加 dev 资源，不是让 reviewer 兼工

机制兜底：AGF 角色定义明确写"不动源码"、"不写实现"，hook 部分检查（commit 作者 vs PR 创建者）—但最关键是文化——团队内部 zero tolerance 破例。

[钩子待你填: 你某次允许 reviewer 直接 fix bug、3 个月后团队边界崩塌的踩坑]

[互动 30s]
P3 学员，文化建设比工具建设难——这条边界是 AGF migrate 时最难的一关，但也是最值得守的。
"""

NOTES[90] = """【⏱ 时长: 2min30s | 节奏: 收尾】

[钩子 30s]
§5 场景 C · 失败回路 + TDD 3 句话压缩。

[正文 1min30s]
第一句：「6 阶段门任一失败回 ③ 实现，不跳级」——回 SIT 重过门是底线。

第二句：「code-reviewer 双 verdict——代码质量 + SIT Audit 独立给」——任一不达标退回。

第三句：「Plan Mode 6 触发点——ai-agent-dev 必先拿 PL 授权」——高风险变更不靠自觉。

下次写 PR 做 1 件事：提交前自查 commit 顺序，test: 早于 feat:。reviewer 看 git log 就能判违规。

[互动 30s]
下一章 §6 进入场景 D——UAT + Release + CHANGELOG。我会带你完整跑一次发布流程。
"""

# ============================================================
# §6 · 场景 D · UAT + Retro · slide 91-103 (13 张)
# ============================================================

NOTES[91] = """【⏱ 时长: 2min00s | 节奏: 慢起】

[钩子 30s]
§6 场景 D——UAT + Release + Retro。这是 feature 的"最后一公里"——上线前最容易忽视的一段。

[正文 1min]
13 张内容页（含 section + prediction）。重点 4 件事：① UAT vs E2E 区别；② CHANGELOG 6 节规范；③ tag + GitHub Release 标准流；④ release retro 7 步（仅 MAJOR / MINOR）。

P1 学员，UAT 这一段对你最关键——你扮演 PL 签字 UAT 是业务签字，不是技术验收。后面 §6 大半内容都是给你看的。

[互动 30s]
互动题在下一页。
"""

NOTES[92] = """【⏱ 时长: 2min30s | 节奏: 互动】

[钩子 30s]
互动：上线前最容易跳过的是哪个步骤？

[正文 1min30s]
[现场举手 30s]

[此页是 prediction 页，具体选项见 slide build]

我先说我观察的真实数据——80% 团队跳过 release retro。20% 团队跳过 CHANGELOG 6 节规范。50% 团队 UAT 和 E2E 混淆。

AGF 强制：UAT 必走、CHANGELOG 必走、retro 仅 MAJOR / MINOR 必走（PATCH 跳过）。

[互动 30s]
后面 11 张图给你看每一步具体怎么走。
"""

NOTES[93] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
E2E 测试——qa-engineer 的主战场。

[正文 2min]
E2E（End-to-End）测试：从用户入口到底层数据库，全链路跑一遍。

明信片 feature E2E 范围：
- 前端：用户上传照片 + 输入文案
- API：POST /generate-postcard
- 后端：调 Doubao Vision → Doubao Text → Doubao Seedream
- 数据库：保存生成历史
- 前端：渲染明信片图

每条 PRD AC 对应 1 个 E2E 用例。5 条 AC → 5 个 E2E 用例。

E2E 跑在 staging 环境（不是 prod、不是本地）。环境配置写在 `docker-compose.staging.yml`，数据库用 staging 库（不污染 prod）。

qa-engineer 走 skill `agf-writing-qa-report`，输出 `docs/qa/<feature>-e2e-2026-05-XX.md`。

E2E pass → 进入 UAT。E2E fail → 回 ③ 实现。

[互动 30s]
P2 学员，E2E 不需要写很多——5 条 AC = 5 条用例，足够。多了维护成本爆炸。
"""

NOTES[94] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
盲测——qa 的关键技巧。

[正文 2min]
盲测：qa 不看实现代码、不看 dev 写的 happy path，直接按 PRD AC 当真用户用。

为什么盲测？因为看了实现，qa 自然倾向"按实现的 path 测"，漏掉用户真实使用的 edge case。

盲测操作：
- qa 拿 PRD（5 条 AC）+ 用户界面，不看代码
- 按用户视角操作：上传奇怪格式照片、输错文案、网络断开重试、并发提交
- 记录所有"我以为它会 X 但它 Y"的情况

盲测找到的 bug 通常是 dev / reviewer 都没意识到的——因为 dev / reviewer 都"知道实现"。

明信片 feature 盲测可能发现：
- 上传 RAW 格式照片 → 后端没处理 → 500 错
- 输入 5000 字超长 prompt → Vision API 拒绝 → 错误提示不友好
- 同时点 5 次"生成"按钮 → 5 次 API 调用 → 5 张明信片重复

[互动 30s]
P2 学员，做 qa 时强制盲测——把实现 README 关掉，按 PRD 走一遍。

⚠ 待 PL 拍板: "盲测找到的 bug 通常是 dev / reviewer 都没意识到的" — 这个 claim 是否需要附数据支撑？
"""

NOTES[95] = """【⏱ 时长: 3min00s | 节奏: 中等 · 关键页]

[钩子 30s]
UAT vs E2E——很多团队混为一谈，AGF 明确分两件事。

[正文 2min]
**E2E（技术验收）**：qa 跑，确保技术层面通——API 通、数据通、前端通、性能达标。verdict：pass / fail / blocked。

**UAT（业务签字）**：PL + 业务方一起跑，确保业务层面满意——这个功能是不是业务要的、用户用着舒服、值不值得发布。verdict：sign-off / reject。

差异点：
| 维度 | E2E | UAT |
|---|---|---|
| 跑的人 | qa-engineer | PL + 业务方 |
| 看的角度 | 技术对不对 | 业务满意不满意 |
| 判断标准 | AC 全通过 | 业务方点头 |
| 失败处理 | fail → 回 ③ | reject → 改 PRD 或回 ③ |
| 签字 | qa 写 verdict | PL 签 sign-off |

明信片 feature 流程：qa E2E pass → PL 安排 UAT → 业务方试用 → 业务方说"明信片风格不够文艺" → reject → 改 prompt 或加风格选项 → 回 SIT → 重过门 → 重 UAT。

[互动 30s]
P1 学员，UAT 你是主角——技术对了不代表业务对，业务点头才上线。
"""

NOTES[96] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
UAT 报告——PL 签字的依据。

[正文 2min]
UAT 报告写什么？走 skill `agf-writing-qa-report`，UAT 模板：

1. **范围**——这次 UAT 覆盖哪些 AC、哪些场景
2. **参与方**——PL + 业务方 + qa（旁听）
3. **测试流程**——业务方按真实使用习惯操作
4. **结果**——每条 AC 业务方是否满意
5. **意见**——业务方提的改进点（不是 bug 是建议）
6. **verdict**——sign-off / reject / sign-off-with-conditions

`sign-off-with-conditions` 是常见——业务方说"主流程 OK 可以上，但 X 后续优化"。这种情况 PL 签字附条件，X 加入下一 sprint backlog。

UAT 报告归档到 `docs/qa/<feature>-uat-2026-05-XX.md`。文件名带日期，便于历史回溯。

明信片 feature UAT 示例：业务方满意主流程，提"想加分享到微信"——sign-off-with-conditions，分享功能进下一 sprint。

[互动 30s]
P1 学员，UAT 签字格式：注明 sign-off 日期 + 业务方姓名 + 条件（如有）。
"""

NOTES[97] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
progress/ 归档——UAT 签字后的关键 housekeeping。

[正文 2min]
feature 期间 `progress/<role>.md` 在 git 里，UAT 签字后必须归档。

归档动作（由 PL 执行）：
1. 把 `progress/*.md` 合并成 `docs/qa/<feature>-process-log.md`
2. 从 main 分支 `git rm progress/<role>.md`
3. commit "chore: archive postcard feature progress logs"
4. push

为什么归档？因为 main 分支要保持干净——`progress/` 是临时工作文件，不应该长期占 git 历史。

为什么不直接删？因为归档保留了"过程证据"——3 个月后审计 / 复盘 / 排查 prod bug 时还能查"当时谁跑了什么命令、AC 怎么自验"。

`docs/qa/<feature>-process-log.md` 是 SSoT——单一来源，永久保留。
`progress/` 是工作中——临时，UAT 后清。

AGF 提供脚本 `.claude/scripts/archive-progress.sh` 自动化这一步。

[互动 30s]
P1 学员，PL 工作流里——UAT 签字后立即跑 `archive-progress.sh`，不要拖。
"""

NOTES[98] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
release tag 标准——SemVer 在 AGF 的应用细则。

[正文 2min30s]
SemVer：MAJOR.MINOR.PATCH

AGF 应用细则（写在 `.claude/standards/versioning.md`）：

**MAJOR (X.0.0)**：
- 不兼容的 API 变更（端点变 / 字段变 / 协议变）
- 删除已有功能
- 改变默认行为

**MINOR (X.Y.0)**：
- 新增功能（兼容）
- deprecation（标记弃用，但不删除）
- 大型重构（行为不变）

**PATCH (X.Y.Z)**：
- bug 修复（行为修正回符合文档）
- 安全补丁
- 性能优化（API 不变）

明信片 feature 首发 = MINOR (v1.X.0)——AGF 主版本是 1，加新 feature 是 minor。
明信片 prompt 调优 = PATCH。
明信片 API 改输入输出格式 = MAJOR。

打 tag：`git tag -a v1.3.0 -m "Release v1.3.0 - Postcard feature"`
推 tag：`git push origin v1.3.0`

反模式：v1.3.0-rc1、v1.3.0-real-final、v1.3.0 复用——禁。pre-release 用 `v1.3.0-rc.1` 严格 SemVer 格式。

[互动 30s]
P3 学员，SemVer 是契约——你声明 MINOR 就承诺向后兼容。破坏承诺 = 用户流失。
"""

NOTES[99] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
CHANGELOG 6 节规范——Keep a Changelog 风格，不是 AGF 发明。

[正文 2min30s]
6 节固定（按 keepachangelog.com）：

1. **Added**——新加的功能
2. **Changed**——已有功能的改变（行为 / API）
3. **Deprecated**——标记弃用（still works，但下版本会删）
4. **Removed**——本版本删除的功能
5. **Fixed**——bug 修复
6. **Security**——安全补丁

明信片 v1.3.0 CHANGELOG 示例：

```
## [1.3.0] - 2026-05-18
### Added
- 旅游明信片生成器（Doubao Vision + Text + Seedream 链路）
- 5 种风格选项（文艺 / 商务 / 幽默 / 严肃 / 治愈）

### Changed
- /api/v1/generate 端点改用 OpenAI-compatible 协议

### Fixed
- Vision API timeout 重试逻辑（issue #142）
```

反模式：
- 用"功能优化"、"性能提升"、"bug 修复"模糊词 → 全部禁
- 标题不用动词开头 → "新增登录功能" 改为 "Added: 登录功能"
- 节顺序乱 → 严格 Added → Changed → Deprecated → Removed → Fixed → Security

content-writer 角色按 skill `agf-writing-release-notes`（虚构示意，实际由 content-writer 走 release notes 模板）输出 release notes。

[互动 30s]
P2 学员，CHANGELOG 是给"未来的自己 + 团队 + 用户"看的。模糊词等于没写。
"""

NOTES[100] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
release retro 7 步——MAJOR / MINOR release 后强制走的复盘。

[正文 2min]
PATCH release 不跑 retro，MAJOR / MINOR 强制跑。触发：`/agf-release-retro v1.3.0`。

7 步骨架（走 skill `agf-running-release-retro`）：

1. **适用性 gate**——确认是 MAJOR / MINOR（PATCH abort）
2. **前置条件**——tag 推完 + GitHub Release 创建完 + CHANGELOG 落库
3. **数据收集**——本次发布的 metrics（耗时、bug 数、回归次数）
4. **3 个问题**——做对了什么 / 做错了什么 / 学到什么
5. **action items**——下一 sprint 要做的改进，每条带 owner + due date
6. **归档**——`docs/reviews/retro-v1.3.0-2026-05-XX.md`
7. **commit + push**

retro 是团队学习闭环——不跑 retro = 同样错误下次再犯。AGF 强制走是因为人类容易"赶下一 feature 没时间复盘"。

7 步全部模板化，跑完 30-60 分钟。

[互动 30s]
P1 学员，PL 主持 retro——你不是审判官，是协调者。让团队说，不要让团队认错。
"""

NOTES[101] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
PATCH 跳过 retro 的判定逻辑。

[正文 2min]
PATCH 不跑 retro 的理由：
- bug 修复通常已经在 fix 时复盘过（"为什么这个 bug 漏到 prod"）
- patch 频率高（一周可能多次），每次跑 retro 成本爆炸
- patch 影响小（不改协议、不加功能），系统性反思价值低

判定流程（skill 第一步）：
- 检查 tag 版本号
- 拿 patch 段位（X.Y.**Z**），Z != 0 → 是 PATCH → abort retro
- Z = 0 且 Y > 0 → MINOR → 跑 retro
- Y = 0 且 X > 0 → MAJOR → 跑 retro

为什么用 skill abort 而不是人类判断？因为人类容易"差不多就跑一下"——AGF 强制规则统一，避免随性。

例外：PATCH 引发严重 bug / 回滚 / 用户投诉爆发 → PL 可以手动触发"事故 retro"（不是 release retro，是 incident retro），格式不同。

[互动 30s]
P3 学员，retro 频率和质量反比——跑太频 retro 流于形式，跑太少又错过反思机会。MAJOR / MINOR 是经验值平衡点。
"""

NOTES[102] = """【⏱ 时长: 3min30s | 节奏: 中等 / 示例】

[钩子 30s]
retro 示例——我现场给你看一个真实的 retro 内容。

[正文 2min30s]
（示意 retro · v1.3.0 明信片 feature · 2026-05-18）

**Q1：做对了什么？**
- TDD 强制把"模糊需求"凝固成测试，避免后期需求漂移
- parallel dispatch + worktree 让 Vision 调用 + 文生图调用并行，节省 1 天
- skill `agf-running-sit-tests` 第一次跑就发现 LLM API timeout 问题，没漏到 E2E

**Q2：做错了什么？**
- PRD AC 5 的 "P95 延迟 < 3s" 没考虑文生图本身就要 5-10s，AC 写错了
- code review 第一轮没注意到 ai-agent-dev 把 prompt 写在 frontend，第二轮才发现
- UAT 业务方提"想加风格"才发现 PRD 没列风格选项

**Q3：学到什么？**
- AI 服务的延迟 AC 要考虑外部 API 本身延迟，不能拍脑袋
- prompt 位置审查加入 code review checklist
- PRD 评审环节让业务方提前看 mockup

**Action Items**：
- [ ] 更新 PRD 模板加"外部 API 延迟"段（owner: PL，due: 1 周）
- [ ] code review checklist 加 "prompt 必在 backend"（owner: code-reviewer，due: 立即）
- [ ] PRD 评审流程加"业务方看 mockup"步骤（owner: PL，due: 下个 feature）

[互动 30s]
看完真实 retro 你会发现——它不是"开会聊天"，是"产出 action 列表 + 落地改进"。
"""

NOTES[103] = """【⏱ 时长: 2min30s | 节奏: 收尾】

[钩子 30s]
§6 场景 D · UAT + Retro 3 句话压缩。

[正文 1min30s]
第一句：「UAT 是业务签字，不是技术验收——PL 主导，业务方点头」。

第二句：「CHANGELOG 6 节命名 / Keep a Changelog 风格——不用'功能优化'模糊词」。

第三句：「release retro 7 步骨架 + tag 反模式——仅 MAJOR / MINOR 跑，PATCH 跳」。

回去做 1 件事：找你最近一次 release，按 CHANGELOG 6 节规范重写一遍——你会发现至少 50% 内容是"功能优化"这种废话。

[互动 30s]
休息 10 分钟，下半场是 §7 综合 Lab——你们各自动手派一个 feature 跑完 9 步。准备 Lab 实战。
"""

# ============================================================
# §7 · 综合 Lab · slide 106-119 (14 张)
# ============================================================

NOTES[106] = """【⏱ 时长: 2min00s | 节奏: 慢起 + 紧凑】

[钩子 30s]
休息回来——下午最重要的环节：综合 Lab。今天讲的所有东西，这 1 小时全部串起来。

[正文 1min]
Lab 目标：每人派出一个真实 AI feature，跑完 9 步——从 `/agf-team-start` 到打 tag + 发 release。

你需要做的：① 选一个 mini feature；② 用 AGF 模板跑全流程；③ 卡住的随时举手。

我会陪跑——每 10-15 分钟一次同步进度，看大家卡在哪。

[互动 30s]
后面每张图都是 Lab 的一步——你边听边操作。
"""

NOTES[107] = """【⏱ 时长: 4min00s | 节奏: 慢 + 准备】

[钩子 30s]
Lab 准备——3 件事必须提前到位，否则 Lab 卡死。

[正文 3min]
**准备 1：环境检查**
- Claude Code 跑得起来：`claude --version`
- Git 跑得起来：`git --version` ≥ 2.30
- 拿到 AGF 模板压缩包并解压

**准备 2：选 feature**
推荐 mini feature 候选（每个 1-3 小时跑完）：
- A：天气查询小工具（前端输入城市 → 后端调天气 API → 返回结构化结果）
- B：网页文章摘要器（前端粘 URL → 后端 WebFetch + LLM 摘要 → 返回 100 字）
- C：图片描述生成（前端上传图 → Vision API → 返回中文描述）
- D：自由选——但必须能在 1-3 小时跑完 9 步

**准备 3：worktree 隔离**
`git worktree add ../agf-day1-lab feature/day1-lab` —— 在新目录干活，不污染原仓库。

[互动 30s]
5 分钟——所有人完成 3 件事抬头，我开始 Step 1。卡住举手。
"""

NOTES[108] = """【⏱ 时长: 3min00s | 节奏: hands-on】

[钩子 30s]
Step 1：clone 模板 + 切到 worktree。

[正文 2min]
具体命令：

```bash
# 进入 worktree
cd ~/agf-day1-lab

# 验证你在新 worktree（不是原 repo）
git status
git branch  # 应该显示 feature/day1-lab

# 安装 pre-commit hook
ln -sf ../../.claude/hooks/scan-commit.sh .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
```

观察点：
- worktree 是独立目录，文件互不污染
- pre-commit hook 装上之后，本次 lab 所有 commit 自动扫密钥

任何一步报错举手——pre-commit 装不上是 Lab 后续阻塞最大风险点。

[互动 30s]
2 分钟搞定。完成的抬头。
"""

NOTES[109] = """【⏱ 时长: 3min00s | 节奏: hands-on】

[钩子 30s]
Step 2：确定主题。

[正文 2min]
你已经在 Step 1 选了 mini feature 候选 A/B/C/D。现在用一句话写出来——这是后面 PRD 的种子。

模板：
"我要做一个 [功能名]，用户做 [动作 X]，系统返回 [结果 Y]。AC 包括 [关键约束 1-2 条]"。

示例 A（天气查询）：
"我要做一个天气查询工具，用户输入城市名，系统返回当天温度 + 天气状况 + 3 天预报。AC：响应 P95 < 2s，支持中文城市名（北京 / 上海 / 深圳），错误城市返回友好提示"。

把这句话写在便签上 / 笔记本——5 分钟后 PL 会用它生成 PRD。

[互动 30s]
3 分钟想清楚一句话。完成的举手。

[现场停 3min]
"""

NOTES[110] = """【⏱ 时长: 4min00s | 节奏: hands-on / 关键 Step】

[钩子 30s]
Step 3：跑 `/agf-team-start`——AGF 流程入口。

[正文 3min]
命令：

```bash
cd ~/agf-day1-lab
claude
# 进入 Claude Code 后输入：
/agf-team-start
```

或者直接跑：
```bash
./agf-team-start.sh
```

观察：
- AGF 启动器做预检（hook 装没装、git 版本、Claude Code 版本）
- 预检通过 → 显示 teammate 多选菜单
- 你选需要的角色（mini feature 推荐：PL + 1 dev + reviewer + qa，4 角色）
- 启动后进入 product-lead 主导的对话

如果预检失败 / 启动器报错 → 举手。这是 Lab 第二大阻塞点。

启动成功后，product-lead 会问你"想做什么 feature？"——把 Step 2 那句话告诉它。

[互动 30s]
5 分钟搞定 Step 3。完成的抬头。卡住的我过去看。
"""

NOTES[111] = """【⏱ 时长: 4min00s | 节奏: hands-on / 重点 Step】

[钩子 30s]
Step 4：PL 写 PRD。

[正文 3min]
你说完 mini feature 一句话后，product-lead 启动 brainstorming：

- PL 会问一次一个问题（"AC 怎么量化？"、"in scope / out of scope？"、"性能 P95 多少？"）
- 你逐个回答——不用预演，按真实想法说
- PL 整理成 PRD 草稿
- PL 用 skill `agf-writing-prd` 验证 10 节齐全 + 5 条 AC 全量化
- PL 输出 PRD 文件到 `docs/prd/<feature>-2026-05-18.md`

观察重点：
- 看 PL 问的问题——是不是真问到点子上
- 看 PRD 5 条 AC——是不是真的可量化
- 如果 PL 跳问题 / PRD 不完整 → 这是 skill `agf-writing-prd` 兜底失败，举手让我看

PRD 完成后 PL 会问"是否同意进入派单"——你说 yes，进入 Step 5。

[互动 30s]
10-15 分钟搞定 Step 4。这是 Lab 时间花最多的环节，慢一点没关系。
"""

NOTES[112] = """【⏱ 时长: 4min00s | 节奏: hands-on / parallel 演示】

[钩子 30s]
Step 5：ai-agent-dev 出场。

[正文 3min]
PRD 通过后，PL 拆 task 派给执行层。mini feature 通常派 1-2 个 task：

天气查询例子：
- Task 1：backend-dev 实现 API + 调外部天气服务
- Task 2：frontend-dev 实现输入页

如果你选的 feature 涉及 AI：
- Task 1：ai-agent-dev 实现 LLM 调用 + prompt + evals
- Task 2：frontend-dev 实现展示

观察点：
- 看 PL 怎么 split task 6 段 schema（description / 上下游 / AC / 依赖 / Skills）
- 看 dev 进入 worktree 独立工作
- 看 dev 写 progress 文件汇报

PL 派完单后会进 idle，等执行层 agent 完成 task。你可以观察 progress/<role>.md 实时更新。

[互动 30s]
这一步开始后让 agent 干 10 分钟。期间你看 progress 文件、看 git log。
"""

NOTES[113] = """【⏱ 时长: 3min00s | 节奏: 观察 + 互动】

[钩子 30s]
Step 6：worktree 隔离实操。

[正文 2min]
观察点：

打开 2 个 terminal：
- Terminal 1：主 repo 目录（`~/agf-day1-lab`）
- Terminal 2：dev 的 worktree（agent 自动创建，通常在父目录）

跑 `git worktree list` 看所有 worktree。你应该看到至少 2 个（主 + dev 自己的）。

跑 `cd <dev-worktree> && git log --oneline` 看 dev 的 commit。观察：
- test: 是不是早于 feat:？
- commit message 是不是按 conventional commit 风格？
- 每个 commit 是不是 atomic（一次只做一件事）？

如果发现 feat: 早于 test: → 这是违规，后面 reviewer 会打回。你可以提前预判 reviewer 会怎么处理。

[互动 30s]
观察 3 分钟。dev 大概在写代码 + 跑 unit + 跑 SIT。
"""

NOTES[114] = """【⏱ 时长: 4min00s | 节奏: hands-on / 关键 Step】

[钩子 30s]
Step 7：code review 实战。

[正文 3min]
dev 完成 task 后，PL 派 code-reviewer。reviewer 跑：

1. 看代码（`.py` / `.ts` 等文件）
2. 看 progress 文件 SIT 证据段
3. 给双 verdict（代码质量 + SIT Audit）

观察点：
- reviewer 的 PR comment——是不是技术依据充分？
- SIT Audit 4 项——证据段是否齐全？AC 是否全覆盖？
- 如果 reviewer 给 fail → 看后续怎么打回

如果你选的 feature 走 happy path → reviewer pass，进 E2E。
如果 dev 写得有问题 → reviewer fail，PL 派回 dev 修。这是失败回路的真实演示！

观察 reviewer 不动源码——只写报告 / 提 PR comment，不直接 commit。这是边界文化。

[互动 30s]
review 完成后看 docs/reviews/<feature>-review-2026-05-18.md。
"""

NOTES[115] = """【⏱ 时长: 3min30s | 节奏: hands-on】

[钩子 30s]
Step 8：qa 跑 E2E + UAT。

[正文 2min30s]
review pass 后，PL 派 qa-engineer。qa 跑：

E2E：
- 启动 staging 环境（docker-compose up）
- 按 PRD 5 条 AC 逐条测
- 输出 `docs/qa/<feature>-e2e-2026-05-18.md`

UAT（Lab 简化版）：
- qa 旁听
- 你扮演业务方
- PL 引导你按真实使用习惯试用
- 你说"满意"或"不满意" → PL 签 sign-off 或 reject

观察点：
- qa 报告格式（5 段：范围 / 环境 / 用例 / 缺陷 / verdict）
- UAT 业务方视角——是不是真的"我满意"

如果你 UAT 拒签 → 回 ③ 实现。Lab 一般不复杂到这种程度，但你可以故意挑刺看回路怎么走。

[互动 30s]
E2E + UAT 大概 5-8 分钟。完成的抬头。
"""

NOTES[116] = """【⏱ 时长: 3min30s | 节奏: hands-on / 关键 Step】

[钩子 30s]
Step 9：tag + release + retro（如适用）。

[正文 2min30s]
UAT 签字后，PL 走 release：

```bash
# 打 tag
git tag -a v0.1.0 -m "Release v0.1.0 - Lab feature"
git push origin v0.1.0

# 写 CHANGELOG（6 节）
# 编辑 CHANGELOG.md

# 创建 GitHub Release
gh release create v0.1.0 --notes-file CHANGELOG-v0.1.0.md

# 触发 retro（v0.1.0 是 MINOR → 跑）
/agf-release-retro v0.1.0
```

观察点：
- tag 推上去——`git tag --list` 看到 v0.1.0
- GitHub Release 页面——能看到 CHANGELOG 内容
- retro 7 步——你会被问 "做对了什么、做错了什么、学到什么"

retro 完成后归档到 `docs/reviews/retro-v0.1.0-2026-05-18.md`。

[互动 30s]
最后 5 分钟跑完 Step 9。完成的抬头。
"""

NOTES[117] = """【⏱ 时长: 3min00s | 节奏: 经验 + 收尾】

[钩子 30s]
Lab 常见踩坑——我总结 7 个，提前告诉你们避开。

[正文 2min]
1. **pre-commit hook 没装** → commit 时密钥扫描没跑 → 密钥可能漏。**修**：lab 开头第一件事装 hook。

2. **worktree 没切就改文件** → 改在主 repo 污染 main。**修**：每个 task 一个 worktree，cd 进去再改。

3. **PRD AC 不量化** → "系统快、好用"——hook 检查不出来，但 reviewer / UAT 时业务方会问。**修**：每条 AC 加数字 / 边界条件。

4. **commit 顺序乱** → feat: 早于 test: → reviewer 看 git log 打回。**修**：先写 test commit，再写 feat commit。

5. **progress 文件 SIT 证据用 mock 输出** → reviewer SIT Audit 项 4 不通过。**修**：贴真实命令输出。

6. **跳过 UAT 直接 release** → 业务方没点头就上线。**修**：UAT 是签字门，不是建议。

7. **PATCH 也跑 retro** → 浪费时间。**修**：只 MAJOR / MINOR 跑 retro。

[互动 30s]
这 7 个踩坑你跑 Lab 时撞到了，回想"我警告过你"。
"""

NOTES[118] = """【⏱ 时长: 2min00s | 节奏: checkin / 同步】

[钩子 30s]
Lab 中段同步——大家进度怎么样？我看一下。

[正文 1min30s]
快速举手统计：
- 跑到 Step 1-2（环境 + 主题）：举手
- 跑到 Step 3-4（启动 + PRD）：举手
- 跑到 Step 5-6（派单 + 写代码）：举手
- 跑到 Step 7-8（review + qa）：举手
- 跑到 Step 9（release）：举手

[根据现场比例调整后续节奏]

如果大部分在 Step 4-5：再给 15 分钟，后面 Step 8-9 简化。
如果大部分在 Step 7+：按原节奏跑完。

卡住的一律举手——助教过去 1v1 看。

[互动 30s]
继续干，10 分钟后再 checkin。
"""

NOTES[119] = """【⏱ 时长: 3min00s | 节奏: Lab 收尾】

[钩子 30s]
Lab 结束 —— 跑完 9 步的同学举手。

[正文 2min]
[现场统计]

完整跑完 9 步的同学——你们今天已经掌握 AGF 全流程，下周可以在自己团队推。

跑到 Step 5-7 的同学——后面 review + qa + release 步骤是"复读"，你看过原理 + 部分实操，已经够入门。

卡在 Step 1-3 的同学——大概率是环境问题。Lab 后 1v1 跟助教搞定 Claude Code 安装 / hook 配置。

Lab 总结 3 个共性问题（我观察的现场）：
1. PRD AC 量化是真难——大家都倾向写形容词
2. test: 早于 feat: 反人性——大家本能想先写代码
3. UAT 签字这件事容易跳——大家想"E2E 通过就上"

这 3 个反人性的点正是 AGF 强制兜底的价值——不强制，你下次跑就忘了。

[互动 30s]
休息 5 分钟，下一章 §8 拓展——AGF 设计取舍 + 怎么 migrate 到你自己栈。
"""

# ============================================================
# §8 · 拓展 · 设计取舍 + 迁移 · slide 121-132 (12 张)
# ============================================================

NOTES[121] = """【⏱ 时长: 2min00s | 节奏: 慢起】

[钩子 30s]
§8 拓展——P3 资深观察型学员的主场。前面 7 章都是"怎么用 AGF"，这一章讲"AGF 这套设计取舍是什么、怎么迁到你自己的栈"。

[正文 1min]
11 张内容页（含 section）。重点 5 件事：① AGF 的 creed（信条）vs wiki；② 14 vs 1 角色取舍；③ dev SIT vs qa SIT 改革；④ 该保留的 3 件 + 该替换的 3 件；⑤ AI-Native 业界对标。

P1 / P2 这一章可以走神，但最后一页（AI-Native 业界数据）建议听。

[互动 30s]
直接进入第一题。
"""

NOTES[122] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
creed vs wiki——AGF 的最深层设计哲学。

[正文 2min30s]
传统团队 wiki：你读了 → 可能照做、可能不做、可能忘了。文档是参考。

AGF creed：信条是"机制 > 文档 > 自觉"。我们不写一堆 wiki 让你"自觉遵守"，我们建机制让你"不走这条路根本动不了"。

具体落地：
- 不靠"你记住要测试" → 靠 TDD hook + commit 顺序检查
- 不靠"你记住扫密钥" → 靠 4 层 hook
- 不靠"你记住写 progress" → 靠 SubagentStop hook 兜底
- 不靠"你记住按 PRD 模板" → 靠 skill `agf-writing-prd` 强制路径

为什么这套哲学有威力？因为人类 / AI 的"记忆"和"自觉"都不可靠。机制兜底 = 不依赖记忆和自觉。

代价：机制初期建设成本高。AGF 4 层 hook + 9 skill + 14 角色定义，第一次搭起来要 1-2 周。

收益：长期使用 → 团队成员换、AI 模型换，机制不变，行为可预测。

P3 思考题：你团队哪些事是靠 wiki / 自觉维持的？这些事都是"机制化候选"。

[互动 30s]
信条不是口号——是落地原则。AGF 每一条 hook、每一个 skill 都在贯彻这条信条。
"""

NOTES[123] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
14 角色 vs 1 角色（all-in-one）的取舍。

[正文 2min]
反方观点："14 角色太复杂，一个 agent 全能搞定不行吗？"

AGF 选择 14 角色而不是 1 角色的理由：
- **专业化深度**——14 角色每个有自己 prompt / skill / DoD，专业度比通用 agent 高
- **责任清晰**——出问题知道找谁，PL 派单不用想"该派给谁"
- **并行能力**——14 角色可以同时跑（worktree 隔离），1 角色串行
- **可替换性**——某个角色（例如 ai-agent-dev）prompt 升级，其他 13 角色不受影响
- **审计性**——progress 文件按角色分，可单独 audit

代价：
- 上下文切换——agent 之间通过 task 文件交换状态，需要文件 I/O
- 学习成本——团队成员需要记 14 角色边界
- 配置复杂——14 个 agent.md 各有 frontmatter / preloaded skills

什么时候 1 角色更好？纯个人项目、原型、demo。AGF 14 角色是为 production-grade 团队设计，小项目用 1 角色也 OK。

[互动 30s]
P3 学员，你团队规模决定角色数。10 人团队按 AGF 14 角色不超载，3 人团队建议合并成 4-5 角色。
"""

NOTES[124] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
dev SIT vs qa SIT 改革——v2.0 的重大调整，前面 §3 提过，这里详细讲取舍。

[正文 2min]
v1 时代：SIT 是独立 phase，由 qa-engineer 跑。

v2 改革：SIT 由执行层 dev 自跑。

**为什么改？**
v1 痛点：
- qa 跑 SIT 时离 dev 太远——dev 已经 idle，qa 发现 bug 找不到上下文
- qa 不熟 dev 的实现细节——SIT 跑得浅
- qa 跑 SIT + E2E + UAT 三件事，时间紧

v2 收益：
- dev 跑 SIT 时刚写完代码，bug 修复成本最低
- dev 最熟实现细节，SIT 跑得深
- qa 专注 E2E + UAT，时间足够

**代价**：
- 失去 "外部视角" SIT 检查——dev 可能漏掉自己代码的盲点
- code-reviewer 必须做 SIT Audit（4 项）兜底 → 引入双 verdict 结构

**为什么 reviewer 兜底而不是 qa 兜底？**
reviewer 看代码 + audit SIT 证据是天然同步，qa 跑 E2E 离 SIT 太远。

这个改革不是所有团队都能直接复制——前提是 reviewer 真有时间做 audit。

[互动 30s]
P3 思考题：你团队 SIT 现在是 dev 跑还是 qa 跑？哪个更合适？

⚠ 待 PL 拍板: v1 → v2 改革日期 / 触发原因是否需要附 ADR 编号引用？
"""

NOTES[125] = """【⏱ 时长: 2min30s | 节奏: 中等 · 反模式集合】

[钩子 30s]
AGF 反模式 4 条——这 4 条不要做。

[正文 1min30s]
**反模式 1：multi-编排**
两个 agent 都派单 → 责任分裂、命令冲突。AGF 强制 PL 唯一编排者。

**反模式 2：reviewer / qa 动源码**
"顺手修"= 既当裁判又当球员，破坏边界。

**反模式 3：补 test**
写完代码补测试 → test 描述现状，不定义对错。AGF 强制 test 先于 feat。

**反模式 4：模糊 AC**
"系统快、好用、稳定"——不可量化的 AC 不是 AC。PRD 5 条 AC 必须量化。

这 4 条是 80% 团队最容易破坏的边界——破一条 → 后面其他边界连锁崩溃。

[互动 30s]
P3 学员，把这 4 条记下来。你 migrate 时优先守住这 4 条，其他可以调整。
"""

NOTES[126] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
该保留的 3 件——你 migrate AGF 时哪 3 件必须保留？

[正文 2min30s]
**保留 1：单一编排者**
PL（或叫 PO / Tech Lead，名字不重要）唯一派单。不许多人派单。这是组织协作的物理底线。

**保留 2：写代码的不审自己**
code-reviewer / qa 不动源码。这是质量保障的底线。可以两角色合并（一个人兼），但"实现者 ≠ 审查者"必须守。

**保留 3：机制 > 自觉**
至少装 1 层 hook（推荐 pre-commit 密钥扫描）+ 1 个 skill（推荐 brainstorming）。机制兜底比 wiki 强 10×。

这 3 件不绑技术栈、不绑 Claude Code、不绑 14 角色具体数字。任何团队都能保留。

不保留这 3 件 = 你拷的不是 AGF，是 AGF 的外壳。

[互动 30s]
P3 学员，你 migrate 的最低基线就这 3 件。3 件守住 → 你已经超过 70% 团队。
"""

NOTES[127] = """【⏱ 时长: 3min30s | 节奏: 中等 · 关键页]

[钩子 30s]
该替换的 3 件——AGF 哪些设计是"可调整的"？

[正文 2min30s]
**替换 1：技术栈**
React + Vite / FastAPI / PostgreSQL —— 这些都可以换。AGF 角色定义不绑栈。Vue / Angular / Spring Boot / MongoDB 都行。

**替换 2：LLM 提供商**
Doubao / DeepSeek / Qwen / MiniMax 都行——skill `agf-wiring-multi-llm-sdk` 帮你切换。OpenAI / Anthropic / Gemini 同理。

**替换 3：14 角色具体数量**
14 角色是为 production-grade 团队。你的团队 5 人 → 合并为 4-5 角色。3 人 → 合并为 3 角色（PL + Dev + qa）。

保留"专业分工"原则即可，具体数字按团队规模调。

不能替换的（前一页讲的 3 件保留项）：
- 单一编排者
- 写代码的不审自己
- 机制 > 自觉

[互动 30s]
P3 学员，这是"AGF 的精髓"和"AGF 的外壳"的分界线。精髓不可替换，外壳全部可换。
"""

NOTES[128] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
多 LLM fallback 策略——production 系统不绑单提供商的实操细节。

[正文 2min]
fallback 策略 3 种：

**Active-Passive**：默认 A 家，A 挂了切 B。简单但 B 闲置浪费 quota。

**Active-Active**：A 和 B 同时调，取先回的。延迟最低但 cost × 2。

**Smart Routing**：按场景 / cost / latency 智能路由。复杂但最优。

AGF skill `agf-wiring-multi-llm-sdk` 默认 Active-Passive，可配置切 Smart Routing。

明信片 feature 推荐配置：
- Vision：Doubao-Seed-2.0-Pro（主）→ Qwen-VL（备）
- Text：Doubao-Seed-2.0-Pro（主）→ DeepSeek（备）
- Image：Doubao-Seedream-4.5（主）→ MiniMax abab-vision-image（备）

备线只在主线挂或限流时切——日常成本 ≈ 主线成本，备线 quota 闲置但不浪费（按调用付费）。

[互动 30s]
P3 学员，production 上必须做 fallback——半年内每家 LLM 至少挂一次 / 限流一次，单家依赖等于裸奔。
"""

NOTES[129] = """【⏱ 时长: 3min00s | 节奏: 中等 / 小程序场景】

[钩子 30s]
小程序变体——AGF 怎么覆盖微信小程序场景。

[正文 2min]
微信小程序场景特殊：
- 不能用 npm 全套生态
- 必须按微信平台 API 写（wx.* 函数族）
- 必须考虑 packagesize（2MB 主包 + 20MB 总）
- 必须按微信审核规范

AGF 提供 MiniApp Mode overlay——3 个专属角色覆盖通用角色：
- `miniapp-frontend-dev` 覆盖 `frontend-dev`
- `miniapp-qa-engineer` 覆盖 `qa-engineer`
- `uiux-designer` 在 MiniApp Mode 下覆盖通用设计

何时启用：项目根目录有 `miniapp/` 时自动激活（path-scoped rule）。

激活后：
- 任何前端任务自动派给 miniapp-frontend-dev
- 任何 qa 任务自动派给 miniapp-qa-engineer
- skill `.claude/standards/miniapp.md` 强制走（package size 检查、审核规范等）

这是 AGF "技术栈灵活但流程统一" 的体现——同样的 14 角色框架，按 path 自动适配场景。

[互动 30s]
P3 学员，你 migrate 时可以参考这个 overlay 模式——为特殊场景做 path-scoped overlay，不重写整套。
"""

NOTES[130] = """【⏱ 时长: 3min00s | 节奏: 中等】

[钩子 30s]
GitHub Actions 自动化——AGF 怎么和 CI / CD 集成。

[正文 2min]
GitHub Actions 默认模板：`.github/workflows/claude-code.yml`（AGF 提供，默认未启用）。

启用后能做的事：
- PR 自动跑 lint + unit + 部分 SIT
- commit 顺序检查（test: 早于 feat:）
- 密钥扫描（GitHub Secret Scanning + AGF 自定义）
- Claude Code GitHub Action 自动跑 review

为什么默认未启用？
- 不是所有团队有 GitHub Actions quota
- 不是所有 repo 在 GitHub（GitLab / Gitee 也行）
- 启用需要配 secret（CLAUDE_API_KEY）

启用步骤：
1. 在 GitHub repo Settings → Actions → 启用
2. 在 Secrets 加 `CLAUDE_API_KEY`
3. 解开 `.github/workflows/claude-code.yml` 的 `if: false` 注释

启用后每个 PR 自动触发 Claude Code review——AI 帮你做第一道审查，reviewer 复核。

[互动 30s]
P3 学员，CI / CD 是 hook 之外的第二层兜底——本地 hook 防 commit，CI 防 push 进 main。两层互补。
"""

NOTES[131] = """【⏱ 时长: 3min30s | 节奏: 中等 · 业界对标】

[钩子 30s]
AI-Native vs AGF 业界对标——这页 P1 / P2 也建议听。

[正文 2min30s]
2025-2026 业界 AI-Native 转型数据（公开调研，多家咨询机构汇总）：

- 70% 公司用了 AI 编程工具（Copilot / Cursor / Claude Code 等）
- 70% 中只有 30% 系统化改了协作流程
- **没改流程**：开发提速 5-15%（边际收益）
- **系统化改流程**：开发提速 5-7×（指数级收益）

差距来源：
- 没改流程：AI 写得快，但 review / 测试 / 协作没改，瓶颈转移
- 改流程：AI 写得快 + 机制兜底审得严 → 可持续

AGF 属于"系统化改流程"的实践模板。

不是所有团队需要 5-7×——快不一定好，可持续 + 安全 > 单纯快。AGF 强调的是"可持续的快"。

业界几个对标项目：
- Microsoft Copilot Workspace：聚焦个人加速，不强调团队协作
- Cursor + Composer：IDE 优先，无强制工作流
- Devin / Cognition AI：完全 autonomous，弱化人类参与

AGF 区别：人 + AI 协作，机制兜底，保留人类签字门。

[互动 30s]
P3 学员，这是定位题——AGF 是"中庸"路线，比 Copilot 严、比 Devin 松。

⚠ 待 PL 拍板: 5-15% vs 5-7× 数据点的具体调研来源——是否需要附引用？哪份报告？
"""

NOTES[132] = """【⏱ 时长: 2min30s | 节奏: 收尾】

[钩子 30s]
§8 拓展 3 句话压缩。

[正文 1min30s]
第一句：「保留 3 件：单一编排者 / 写代码的不审自己 / 机制 > 自觉」——这是 AGF 精髓，不绑栈。

第二句：「替换 3 件：技术栈 / LLM 提供商 / 14 角色具体数量」——这是 AGF 外壳，按团队调。

第三句：「业界数据：没改流程 5-15% vs 系统化改流程 5-7×——差距来自'机制兜底让 vibe 速度可持续'」。

回去做 1 件事：把你团队"靠 wiki / 自觉维持"的事列出来——这是你 AGF 迁移的 backlog。

[互动 30s]
最后一章 §9 收尾——回顾 + Q&A。
"""

# ============================================================
# §9 · 收尾 + Q&A · slide 134-137 (4 张)
# ============================================================

NOTES[134] = """【⏱ 时长: 2min00s | 节奏: 慢起 + 收尾】

[钩子 30s]
6 个半小时跑下来——你们应该已经累了。最后 15 分钟我们回顾 + Q&A。

[正文 1min]
今天讲了 §0 垫层 + §1 AI 工具 + §2 Git 基础 + §3-§6 四场景剧本 + §7 综合 Lab + §8 拓展。一共 138 张 slide。

你不需要记住所有内容——记住"机制 > 自觉"这一句就够了。其他都是这句话的展开。

接下来 3 张 slide 是：① 完整回顾、② 你的资源 map、③ next steps。

[互动 30s]
最后准备好你们的 Q&A 问题——15 分钟我会留着回答。
"""

NOTES[135] = """【⏱ 时长: 4min00s | 节奏: 完整回顾】

[钩子 30s]
完整回顾——8 章压缩成 1 张图。

[正文 3min]
**§0 垫层**：Agile / Scrum / TDD 是 30 年验证的解药，共同手段是"缩短信息传播跳数"。

**§1 AI 工具**：Vibe Coding 是范式，Claude Code 6 大能力是 AGF 载体。机制兜底让 vibe 速度可持续。

**§2 Git 基础**：5 命令打天下，commit 顺序反推 TDD，pre-commit hook 是 4 层防御的底线。

**§3 场景 A**：PRD 5 条 AC 量化 + 派单 6 段 schema + AI 输出 3 指标评测。

**§4 场景 B**：4 层 hook + skill 强制 + DoD checklist 三件套。撞硬阻断不绕路。

**§5 场景 C**：6 阶段任一失败回 ③，双 verdict 独立，Plan Mode 6 触发点。

**§6 场景 D**：UAT 是业务签字，CHANGELOG 6 节，retro 仅 MAJOR / MINOR。

**§7 Lab**：你今天跑了 9 步，从 `/agf-team-start` 到 release。

**§8 拓展**：保留 3 件 + 替换 3 件，业界 5-15% vs 5-7×。

[互动 30s]
回头看，全部串成一句话："AI 协作 = vibe 速度 + 机制兜底 + 角色边界"。
"""

NOTES[136] = """【⏱ 时长: 4min00s | 节奏: 资源 map】

[钩子 30s]
你的资源 map——回去后能查的东西。

[正文 3min]
**AGF 模板**：今天发的 zip 包。`.claude/agents/*.md` 是 14 角色定义；`.claude/standards/*.md` 是团队规范；`.claude/hooks/*.sh` 是 4 层防御。

**官方文档**：
- Claude Code: https://docs.claude.com/claude-code
- superpowers skills: 安装在 `.claude/plugins/cache/`
- Keep a Changelog: https://keepachangelog.com
- SemVer: https://semver.org

**入门读物**（中文版）：
- 《人月神话》机械工业出版社（Brooks 1975）—— 沟通成本问题诊断
- 《Scrum 精髓》清华大学出版社（Pichler）—— Scrum 落地
- 《Test-Driven Development by Example》人民邮电出版社（Beck 2002）—— TDD 原典

**进阶**：
- Anthropic 工程博客
- OWASP LLM Top 10
- 《人月神话》第 16 章 "没有银弹"——AGF 不是银弹，但是减少银弹缺席的工具

**社区**：
- AGF 模板 GitHub repo（仓库地址今天发了）
- Issue 区可以提问 / 反馈

[互动 30s]
拍下这一页——你后续 90% 问题在这些资源里有答案。
"""

NOTES[137] = """【⏱ 时长: 4min00s | 节奏: 收尾 + 行动】

[钩子 30s]
今天最后一页——你 next steps 是什么？

[正文 3min]
**本周做的 3 件事**：
1. 装 Claude Code + git pre-commit hook（10 分钟）
2. 用 brainstorming skill 让 AI 帮你写第一份 PRD（30 分钟）
3. 在自己 repo 试跑一个 mini feature（1-3 小时）

**本月做的事**：
- 把今天的 AGF 模板 clone 下来，按你团队需求调整 14 角色
- 在 1 个真实项目上跑 AGF——别等"完美时机"，跑了再迭代
- 把 4 层 hook 装上（至少第 4 层 git pre-commit）

**3 个月做的事**：
- 团队全员按 AGF 流程跑 3-5 个 feature
- 跑 1-2 次 release retro
- 评估"保留 3 件"是否做到、"替换 3 件"调整到位

**1 年做的事**：
- 你的团队应该形成自己的"AGF 变体"——保留精髓，按团队特性变形
- 你应该在自己团队内推广"机制 > 自觉"文化

[钩子待你填: 你对学员的一句赠言——可以是"AI 时代最稀缺的是判断力"、或者更具体的实战建议]

[互动 30s]
最后留 10 分钟 Q&A。你们的问题。
"""



def apply_speaker_notes(prs):
    """build_main.main() 末尾调用：按 slide index (1-based) 灌入 notes。

    任何不在 NOTES dict 里的 slide 跳过（过渡页 / 未写章节）。
    """
    applied = 0
    skipped = 0
    for idx, slide in enumerate(prs.slides, start=1):
        if idx in NOTES:
            # python-pptx 自动创建 notes_slide（如果没有）
            slide.notes_slide.notes_text_frame.text = NOTES[idx]
            applied += 1
        else:
            skipped += 1
    print(f"[speaker_notes] Applied: {applied} slides · Skipped: {skipped} slides")
    return applied, skipped
