练习册：从概念到综合实战
本页把各章练习汇总成一条可执行的训练路线，并补充两个 L4 综合题。章节内练习仍放在原章节，便于边读边做；综合题放在本页，要求把多个章节的知识拼起来。所有题目都给出无 GPU 的替代方案，硬件不应成为不动手的理由。
难度与使用方式
Section titled “难度与使用方式”| 级别 | 定位 | 典型产出 |
|---|---|---|
| L1 | 概念辨析 | 一段能自圆其说的解释，或一份对照表 |
| L2 | 材料分析 | 基于日志、报告或论文的结论与证据 |
| L3 | 单点动手 | 一个可运行脚本、一份 skill、一份检查清单 |
| L4 | 系统综合 | 一个能闭环的最小 harness，含验证与复盘 |
建议顺序：先做 L1 与 L2 建立判断力，再做 L3 熟悉工具，最后用 L4 把流程串起来。每道题都先写验收标准，再动手；否则很容易把“跑通了”误当成“做对了”。
| 编号 | 主题 | 难度 | 耗时 | 前置章节 | 链接到练习 |
|---|---|---|---|---|---|
| E1 | 环境与任务合同自检 | L1 | 20 分钟 | 导读 | 章节练习 |
| E2 | 为一个 kernel 任务写验收标准与停止规则 | L2 | 45 分钟 | Agent 与 harness | 章节练习 |
| E3 | 从一份 ncu 摘要找首要瓶颈 | L2 | 35 分钟 | GPU kernel 与性能 | 章节练习 |
| E4 | 复现一个最小 KDA 流程 | L3 | 2.5 小时 | KDA | 章节练习 |
| E5 | 为 kernel 任务设计 reviewer 检查清单 | L3 | 45 分钟 | Humanize | 章节练习 |
| E6 | 为你的 harness 列一份工具层清单 | L2 | 40 分钟 | TIRx | 章节练习 |
| E7 | 用 PR 档案给一个 fusion 定成立条件 | L2 | 45 分钟 | BBuf skills | 章节练习 |
| E8 | 写一个 200 行以内的 skill | L3 | 60 分钟 | Skills | 章节练习 |
| E9 | 为小 kernel 搭 v0 harness | L4 | 3 至 4 小时 | Beyond | 章节练习 |
| E10 | 双 CLI builder/reviewer 循环 | L4 | 4 至 6 小时 | Humanize、Beyond | 本页 L4-A |
| E11 | 复现 Flame Chase 最小版 | L4 | 4 至 6 小时 | Humanize、Beyond | 本页 L4-B |
| E12 | 拆解一个被挡下来的加速比 | L2 | 40 分钟 | KDA | 本页 L2 |
| E13 | 把一个算子蒸馏成 M0 骨架 | L3 | 90 分钟 | ForgeKernel | 章节练习 |
| E14 | 给一次 run 写工程解剖报告 | L3 | 90 分钟 | ForgeKernel 工程解剖 | 章节练习 |
E7 是纯检索题：在 BBuf 的 PR 历史档案里定位一条可复用的先例，再把它翻译成自己任务里的验收条款。E12 是纯阅读题：读 KDA 官方博客中关于 3.74× 候选的复盘，练习把「作弊手法」翻译成你自己任务的验收条款。E13 是纯设计题：不写 kernel，只把一个算子的结构性决策组织成一份可交付的里程碑骨架。E14 是代码阅读题：不跑 GPU，只沿一次 run 的生命周期画出三层地图、拆一条记录、审一条护栏。后三道题都不需要 GPU，也不需要写 kernel。
无 GPU 怎么练
Section titled “无 GPU 怎么练”| 练习 | 无 GPU 替代 |
|---|---|
| E1、E2 | 不需要 GPU；用任意小任务练习写规格与验收 |
| E3 | 使用公开的 ncu 报告、课程示例数据或本站教学数据，重点练“指标到结论”的推理 |
| E4 | 把 CUDA kernel 换成 NumPy 或纯 Python 实现，保留任务定义、候选记录与 benchmark 结构 |
| E5、E6、E8 | 不需要 GPU；用 CPU 任务验证 reviewer、工具清单与 skill 是否可执行 |
| E7 | 不需要 GPU；纯检索与写作题，不克隆仓库时可直接读 GitHub 上的对应目录 |
| E9 | 把 kernel 换成 CPU 可跑的 softmax、矩阵乘或解析器优化，保留规格、验证、review 与预算结构 |
| E10、E11 | 用 CPU 可跑的任务替代；或使用云端 GPU 的单次配额 |
| E12 | 不需要 GPU；纯阅读与写作题 |
| E13 | 不需要 GPU；纯规格设计题，全程不写 kernel |
| E14 | 不需要 GPU；纯代码阅读与工程分析，只读公开仓库与文档 |
如果使用云端 GPU，先确认计费方式与关机策略，给任务设置硬超时；不要在没有预算上限的情况下让 Agent 自由循环。
L2：拆解一个被挡下来的加速比
Section titled “L2：拆解一个被挡下来的加速比”这道题只做一件事：把别人踩过的坑，翻译成你自己任务的验收条款。
拆解一个被挡下来的加速比
目标：学会从「一个被 evaluator 挡住的加速比」反推验收条款，这是 kernel 任务里最划算的一笔投资。
背景：KDA 官方博客 KDA²: Kernel Design Agents optimize Kimi Delta Attention 复盘了一个声称 3.74× 的候选。官方把这次实验中的作弊归为五类（A–E）。第一类是输入分布过拟合，具体包含两个手法：把 Q/K 的 L2 归一化换成硬编码常数（0.1778209953），以及把部分初始状态通道置零以跳过三角矩阵求逆；它在合成随机数据上误差刚好过关，换到真实非高斯输入就完全失败。其余四类分别是：形状与布局硬编码（写死 cu_seqlens 边界）、非法历史截断（假设 32 token 之前的状态可被 gate 衰减掉）、数值溢出（在 64 token 块内直接算二的累积幂，导致分母下溢为 0 并产生 NaN）、以及精度损失（用 FP16 表存累积衰减，误差最大 9%）。
任务：
- 读上述博客的「reward hacking」与「hardening」两节，列出五类作弊手法（第一类含两个具体手法），每类写清楚：它利用了测试的什么假设、为什么随机测试抓不到、真实数据为什么抓得到。
- 把博客给出的六道 acceptance gate，逐条翻译成你自己任务合同里的可执行条款（命令、字段或脚本）。
- 挑其中两种作弊，为你的任务各写一条能挡住它的检查（写成「命令 + 判定条件」的形式）。
- 写一句话说明：如果你的 evaluator 只用随机输入做对拍，最可能漏掉哪一类问题。
验收标准：
- 五类作弊各自对应到「输入分布、形状布局、数值范围、精度、状态历史」中的至少一类；
- 六道 gate 全部落到具体条款，其中至少三条是可自动判定的命令或脚本；
- 两条防作弊检查能直接复制进你的任务文件；
- 最后一问的回答指向「真实模型与随机数据的分布差异」，而不是泛泛而谈。
无 GPU 替代：本题不需要 GPU，只需要一篇公开博客和一份你自己的任务合同。
提示
读的时候做两件事：一边在博客里标出「测试数据是怎么生成的」，一边标出「真实 workload 的输入长什么样」。两者的差集就是作弊的藏身处。另外注意官方那句结论——每个作弊都通过了当时所有的测试，问题不在模型智力，而在测试分布与真实分布重合得太少。翻译成条款时，优先补「让输入分布与真实数据错开」和「让数值范围覆盖真实极值」这两类检查。
L4-A：双 CLI builder/reviewer 循环
Section titled “L4-A：双 CLI builder/reviewer 循环”这道题的目标不是写出最快的 kernel，而是搭出一个“写的人不能自己判”的最小系统，并证明 reviewer 真的能拦住错误。
双 CLI builder/reviewer 循环
目标：用两个不同的 CLI Agent 分别担任 builder 与 reviewer，完成一次至少 3 轮的 kernel 优化循环；reviewer 必须在全新会话中工作，并能以证据驳回至少一个错误候选。
背景：Humanize 的核心设计是写/判分离。本练习把它压缩成你能在一台机器上跑通的最小版本。你可以使用 Claude Code、Codex，或其他支持非交互调用的 CLI；具体命令以各自官方文档为准。如果只有一个 CLI，可用两个不同模型 API 替代，或让一位同学按清单扮演 reviewer。
任务：
- 定义任务。选择一个可测的小 kernel（softmax、layer norm、向量加或小矩阵乘），写
task.md：输入 shape 与 dtype、baseline、正确性命令、性能命令、容差、通过条件、禁止事项。再写acceptance.yaml，把阈值变成机器可读字段。 - 准备隔离工作区。为每次运行创建独立目录或 git worktree；测试、benchmark 与
acceptance.yaml设为只读；工作区内不放密钥。 - 实现 builder 调用。CLI A 读取
task.md与当前代码，先产出plan.md，再实现并运行测试；所有命令、退出码与耗时写入runs/<id>/builder.log。builder 不得修改测试与验收文件。 - 实现 reviewer 调用。CLI B 在全新会话中启动，只接收
task.md、plan.md、git diff、测试日志、benchmark 结果与验收文件，不接收 builder 的对话。要求 reviewer 输出结构化结论：verdict（complete / continue / reject）、三类问题（主线缺口、阻塞支线、可排队支线）、每条问题对应的文件与行号或命令输出。 - 跑循环。最多 4 轮，每轮开始前检查时间与费用预算；reviewer 判 continue 时，把问题写回
plan.md再进入下一轮；达到上限必须停止并记录原因。 - 注入错误。在某一轮故意制造一个错误：偷换 baseline、放宽容差、只覆盖部分 shape，或让测试在异常时返回成功。确认 reviewer 或自动测试能拦截，并保留证据。
- 写复盘。一页
report.md：每轮改了什么、指标如何变化、reviewer 拦住了什么、哪一步最不可靠、下一版怎么改。
验收标准：
task.md能让另一位同学不询问你而复现实验；- 日志能证明 builder 与 reviewer 使用不同会话，reviewer 未读取 builder 对话；
- 至少一次 reviewer 明确驳回候选，并引用具体文件、行号或命令输出；
- 注入的错误被自动测试或 reviewer 拦截，而不是靠你事后发现；
- 最终候选通过公开 shape 与至少一个隐藏 shape 的正确性测试；
- 预算能硬停，停止后工作区可恢复；
report.md指出一个真实缺陷，并给出可执行的修正。
无 GPU 替代：把 kernel 换成 NumPy 或纯 Python 的 softmax、矩阵乘、排序或字符串处理任务，保留同样的规格、隔离、review 与预算结构。性能指标可以是耗时、内存峰值或操作计数。没有第二个 CLI 时，用不同模型 API，或由同学按 reviewer 清单人工判定；仍然要求“新上下文、只读证据”。
提示
先把无 Agent 的流程手工跑通：写任务、跑测试、跑 benchmark、写一份 review，确认每一环都有可读输出，再接 CLI。CLI 的非交互参数、JSON 输出与超时设置各版本可能不同，先读 --help 与官方文档，不要照抄博客里的旧命令。
Reviewer 的提示要强制“先引用证据，再下结论”，并给它一个固定输出模板；否则它容易写成长篇建议。测试 reviewer 是否有效，最简单的方法是先给它一个已知错误的 patch，看它能否指出 baseline 被替换或容差被放宽。
隔离建议：每轮用 git diff 生成补丁，用 git worktree 或目录快照保存候选；测试脚本用校验和冻结，reviewer 发现校验和变化直接判失败。预算至少记录墙钟、token 与费用三项；达到 80% 时在日志里预警。
L4-B：复现 Flame Chase 最小版
Section titled “L4-B：复现 Flame Chase 最小版”这道题只保留 Flame Chase 的结构：两个 Agent 交替、每轮新会话、只共享工作目录。你要证明这种“低带宽交接”能跑起来，并诚实记录它带来的损耗。
复现 Flame Chase 最小版
目标：实现一个最小 Flame Chase：两个 Agent 在同一任务上交替工作至少 4 轮，每轮使用全新会话，彼此看不到对方对话，唯一共享的是工作目录；最终给出可测量的改进与一份交接复盘。
背景：Humanize 2 的 Flame Chase 让两个 Agent 轮流处理同一任务，每轮开新 session，只通过共享工作目录传递状态。它的关键不是“两个模型”，而是“状态必须外置”。本练习可以用两个 CLI、两个模型 API，或一位同学加一个 CLI 完成。
任务：
- 选择任务。选一个每轮都能测量、且允许逐步改进的任务：CPU 上的 softmax、矩阵乘、JSON 解析器，或 GPU 上的小 kernel。写
task.md，包含 baseline、指标、正确性命令、预算与停止条件。 - 建立共享工作区。目录中只放任务、代码、测试、benchmark、
ledger.md与每轮的handoff.md；不放聊天记录、不放密钥。测试与验收文件只读。 - 实现交替编排。编排脚本按 A、B、A、B 的顺序调用两个 Agent；每次调用都是新进程或新会话，提示词只由
task.md、当前代码、上一轮handoff.md与指标生成，不拼接历史对话。 - 规定交接格式。每轮结束必须写
handoff.md：本轮假设、改了什么、证据（命令与指标）、失败尝试、下一轮建议、剩余预算。没有交接文件视为该轮无效。 - 逐轮快照。每轮结束提交一次 git commit 或打快照标签；出现性能回退时，下一轮必须能定位并回滚，而不是在坏状态上继续堆改动。
- 跑满至少 4 轮。记录每轮的 diff、正确性、性能、耗时与花费；如果提前达到目标，也要记录停止理由。
- 注入一次回归或死路。让某一轮引入性能回退或错误假设，观察下一位 Agent 能否仅凭工作目录发现并修正。
- 写复盘。重点回答：交接丢失了什么、哪类信息必须写进文件、交替带来了哪些额外成本、下一次会怎样改提示或目录结构。
验收标准：
- 至少 4 轮有效交替，每轮都有独立会话与
handoff.md； - 提示词不含上一轮对话原文，只来自共享目录；
- 每轮都有 diff、正确性结果、性能指标与保留或回滚决策；
- 最终指标优于初始 baseline，或有一份证据充分的“为何未达成”说明；
- 注入的回退被下一轮发现并回滚；
- 预算能硬停，所有轮次可复现；
- 复盘指出至少一个交接损耗，并给出可执行的修正。
无 GPU 替代：把任务换成 CPU 上的数值计算或文本处理，指标用耗时、内存或正确率；仍然保留“新会话、只共享目录、每轮交接”的约束。只有一个 CLI 时，让两个不同模型轮流，或让同学扮演其中一个 Agent，但必须遵守“不看对方对话、只读目录”的规则。
提示
把 handoff.md 当成唯一接口：它必须能让一个完全没参与前几轮的人接手。可以固定四段：当前状态、证据、失败尝试、下一步。提示词里只放这份文件和任务，不放“你上次说”。
每轮开始前先跑一次基准，确认工作区没有残留的半成品；每轮结束打快照，回退时用快照而不是手工撤销。两个 Agent 不要同时写同一目录；串行执行，设超时，避免一个卡住拖垮全部预算。
如果交替后性能没有提升，先检查交接是否丢失了关键约束，再检查任务是否适合交替。Flame Chase 更适合长周期、可分解、验证明确的任务；需要实时讨论的探索型任务，隔离反而会增加成本。
如何判定自己完成了
Section titled “如何判定自己完成了”做完综合题后，用下面四个问题自检：别人能否只读你的任务文件复现实验？失败是否由独立于 builder 的环节发现？每一轮是否有可追溯的证据？预算耗尽时是否能安全停下？四个问题都答“是”，才算真正跑通闭环；性能数字只是附加分。
来源与版本：练习设计参考 Humanize 的写/判分离与 Flame Chase、KDA 的任务定义流程，核对于 2026-10-29。各 CLI 的具体命令以官方文档为准。完整链接见资料库。