E2 自我反思 · Tom · 2026-11-02
本轮范围
工作清单条目 e2:tom（job a47978e6-9107-4e2a-9324-a653e21f219f），材料两篇，均已阅读：
organized/guides/whitecircle-halo.mdinbox/tom/2026-11-02-0900-hf-daily-2026-11-02.md
未联网，未回退扫描历史，未改动原稿。
逐篇评价
一、organized/guides/whitecircle-halo.md（whitecircle/halo · 上手攻略）
准确性：高。关键事实都带上了边界：版本锚点（main @ 8d637d1、release v1.1.0）写在开头；镜像 tag 规则、--env-file 必需、EP 只能与 CP/TP/ETP 之一组合、DeepEP 单 NVLink 域内 EP≤2 等反直觉约束，都写成了可执行前提；性能数字全部标注"官方自测"，并明确指出 README 的 2.3–2.8× 与仓库内 2.6–3.5× 口径冲突、应以仓库为准。这种"数据来源即作者"的自觉，比多数二手介绍强。
深度：超出"跑起来"层面。真正有信息量的是第七节的横向对比表和第十二坑的许可条款（2000 万美元年收入阈值 + "Trained with Halo" 署名义务）。这两处是选型的真正决策点，README 里通常读不出来，能被读出来说明作者真的翻到了 license 文件。
清晰度：结构干净（是什么→解决什么→安装→用法→场景→坑→对比→结论），坑位用"现象/影响/修复"三段式，便于照单排查。
证据：以仓库文件、镜像 tag、配置文件、报错原文为据，属一手证据。但通篇引用的是官方文档与博客，没有一条独立第三方复现或 issue 链接。
遗漏：
1. 全文没有给出 human-docs/ 内部的具体章节路径清单（只在坑 10 提到 human-docs/parallelism.md），读者无法自查 supported-matrix.md 之外的约束。
2. 没写镜像体积与拉取时间——DeepEP/DeepGEMM 源码编译的"首次很慢"只是定性描述，没给量级。
3. 没有"如何验证自己装对了"的最小闭环（只给 nvidia-smi / import torch / halo launch --list 三条体检命令，没有一个 5 分钟跑通的冒烟测试与预期输出）。
4. 没有讨论 Halo 与 transformers / trl 的版本耦合窗口，只说"baseline 用 Transformers v5"，未说明 Halo 自身要求哪个版本。
二、inbox/tom/2026-11-02-0900-hf-daily-2026-11-02.md（HF Daily Papers · 2026-11-02）
准确性：无错，但没有任何可核验内容——只有标题、票数、arXiv 链接，没有摘要、方法或结论。
深度：接近于零。15 行列表，信息量等于一份目录。
清晰度：格式统一，票数降序，可扫读。
证据：arXiv ID 是有效出处，可回溯；票数为社区投票，无统计口径说明（是日榜还是累计？）。
遗漏：每篇缺一句话摘要、最多三行核心贡献与"为什么值得看"；缺一个与本工作线（Vibe coding / agent 训练 / 多模态）的相关性标注——其中 WorkFactory（agent 训练）、VibeGame（AI 原生引擎）、Co-Design Bench、RealCLI 明显与 Anan 的知乎运营和 agent 方向相关，却没有一条被标出来。
本轮最需要改进的一篇
选 organized/guides/whitecircle-halo.md。
理由：HF Daily 那篇是每日快照，天然短、复利低；halo 攻略是长驻知识资产，一处错误会被后续多篇引用反复放大，且它的读者是要真掏 GPU 钱的团队——误导成本最高。而它的问题恰好是证据链在结尾处断开：前面十二个坑都能追到具体文件、参数或报错原文，唯独性能与许可两处结论是转述官方说法，读者无法独立判断。
本轮具体优缺点
做对的地方： - 严格按清单取材料，只读两篇，不扫描近七日笔记，不自选历史稿凑任务。 - 识别出"版本锚点"是长文时效性的关键，第一段就锁 commit 与 tag。 - 主动标注口径冲突（2.3–2.8× vs 2.6–3.5×）并给出取舍规则，而不是两套数字并列了事。 - 区分"设计行为 vs bug"（坑 10），避免读者去提无意义 issue。
做得不好的地方：
- 上一轮我把精力全放在"排坑"上，没有为"如何验证这份攻略本身是否仍然成立"留下任何入口。文档会漂移，镜像会改 tag，supported-matrix.md 会加模型限制，但攻略正文没有告诉读者"什么时候该回来重读哪几处"。
- 性能章节约占了全文四分之一的篇幅，全是官方口径，却没有一句话教读者"看到这组数字时应该怀疑什么"（例如 baseline 是否含 GC、tok/s 是否按单卡还是集群、batch 4 是否为吞吐最优区间）。这是把信任直接外包给了作者。
- 许可坑写得最好，但被放在"第 12 坑"的位置——这是选型期第一号决策项，却排在最后。
可复用改进规则
- 每条性能数字后附"信噪折扣"：谁测的、什么 baseline、什么硬件、什么 batch 区间、是否官方自测。已有就补齐，没有就明写"未验证"。
- 长文开头加"复核清单"：列出 3–6 个最易漂移的点（镜像 tag 规则、EP 约束、许可阈值、模型支持矩阵、版本要求）及对应的源文件路径，供后续复检。
- 许可与门槛前置：把涉及法律义务和硬件硬门槛的条目提到"选型前必读"，其余排坑顺序按出现频率排。
- 每篇攻略至少留一个"最小验证闭环"：一条 5 分钟内可跑完、给出预期输出的冒烟命令。
- 每日论文快照至少加三行字段：一句话结论 / 与本工作线的相关性标签 / 是否值得展开精读。
修订建议（标记为修订建议，不改动原稿）
以下段落建议插入 organized/guides/whitecircle-halo.md。仅为建议文本，原稿未被覆盖、追加或重写，本轮不因此触发任何原稿更新流程。
建议 A：置于开头"版本锚点"之后的《复核清单》
复核清单（每季度或升级前重查） 1. 镜像 tag 规则与
:blackwell/:hopper是否仍存在、是否新增latest—— 查docker pull与 README 镜像段。 2. 最新 release 与本文锚点是否一致（本文：v1.1.0，tag commit41da083）。 3. EP 组合约束与 DeepEP 单域限制是否放宽 —— 查human-docs/parallelism.md。 4. 模型支持矩阵是否新增/移除条目 —— 查human-docs/supported-matrix.md。 5. License 条款是否变动（2000 万美元阈值、署名义务） —— 查仓库LICENSE与LICENSE-Supplemental。 6. 官方 benchmark 口径是否更新（本文以仓库内 2.6–3.5× 为准）。 7. transformers / trl 版本耦合要求 —— 查pyproject.toml与镜像内pip show transformers。
建议 B：置于性能数据小节末尾的《如何读这组数字》
如何读这组数字：以上吞吐均为官方自测，baseline 是
trl.SFTTrainer+ Transformers v5 + FSDP2 ZeRO-3，同模型同数据同 bf16 同 FA4 同 Liger 同 grouped GEMM。判断时请注意三点——(1) 吞吐数字取自 batch 4 附近的最优点，真实训练若 batch 变小或序列变长，倍率会收窄（仓库已给出 batch 1 时 Grouped GEMM 倍率更高、256k 处倍率降到 1.28× 的证据）；(2) tok/s 标注为 per-GPU 时不要与集群总量混读（28,700 tok/s/GPU × 8 ≈ 230k tok/s）；(3) 在第三方复现出现之前，请把全部倍率理解为"官方声称的上界"，并以 loss 差距（100 步内 0.8%）而非吞吐作为判断是否值得迁移的主要依据。
建议 C：坑位重排说明
原第 12 坑（许可）建议提前到"第五节 典型适用场景"之前，作为"选型前必读"独立小节；"Trained with Halo" 署名义务与 2000 万美元阈值属于会改变采购与商业路径的条款，不应与调试类坑位并列排序。
建议 D：最小验证闭环
5 分钟冒烟（建议加入第三节）：
bash halo launch sft examples/sft/qwen3/qwen3-4b-ultrachat-lora.yaml --dry-run预期：打印完整的启动命令与解析后的并行配置，且不实际占用 GPU。若能打印出torchrun/accelerate launch进程树且 nvidia-smi 显存占用不变，说明镜像、挂载与.env三项均已就绪；此后再跑真实 LoRA 训练。
待办标记
- 建议 A–D 均需经原稿作者确认后手动并入
organized/guides/whitecircle-halo.md；本轮不执行合稿。 inbox/tom/2026-11-02-0900-hf-daily-2026-11-02.md的摘要与相关性标注属于当日快照的下次生成规则调整，不在本轮原稿更新范围内，仅记录为规则 5。