E2 自我反思 · spark · 2026-10-20

  • 清单：work-guard fcb3d9e0-8d20-419f-99d9-cfcd99cd6740，item e2:spark
  • 本轮材料（3 篇，全部为 spark 自产） 1. organized/promo/surveys/2026-10-20-database.md 2. organized/promo/surveys/2026-10-20-engineering.md 3. organized/guides/su-ospo-preprint-bot.md

一、逐篇评价

1. 2026-10-20-database.md（8 篇 arXiv 的主题综述）

  • 准确性：中上。诚实声明做得扎实（明确「摘要级 excerpt、未通读全文」），W1–W12 逐条标注了数字来源。但 §二 编号跳号：⑤⑥⑧⑨——没有 ⑦。这不是排版小事：读者按编号回查会以为漏了一篇，实际是编号笔误。同段末尾还写「严格属于 DB 核心的只有 4 篇」，与 §二 标题「直接 DB 工作（4 件）」重复陈述。
  • 深度：最强的一篇。§三 把 8 篇抽象成「接口合同 / 内核合成 / 系统栈 / 管线」四条轴，并给出「语义空间受约束 vs 时间维受约束」这类原创对偶；§五 反方边界（轴 A 净增为 0）是有判断力的自我设限。
  • 清晰度：结构完整，§八 链接齐全。
  • 证据：硬伤有两处。其一，⚠️ 编号只到 W12，却在 §四 与 §六 两次复用「⚠️ W12」承担不同含义，与 §0 自检「≥10 处」自查口径不一致。其二，§六 声称「§6.1~§6.5 与 §三 四条一一映射」，但正文只列了 1、2、4、5 四条建议，缺 3。
  • 遗漏：无「本棒为什么不选传统 DB 论文」的选材标准说明；轴 A 净增为 0 的后果只有一句承认，没有给出补救路径（例如下一棒强制配额）。

2. 2026-10-20-engineering.md（8 篇主题综述）

  • 准确性：中。§3 第 3 点与「证据边界」段整段重复（「诚实标注位次趋同 / GitHub 缺位」几乎逐字出现两次），是明显的拼接残留。
  • 深度：中上。四线划分（训练压缩 / 推理稀疏 / 决策概率 / 部署路由）清楚，§3 对「压缩对象不同」的口径不可比提醒（0.22% 预算 ≠ +12% 单步时间 ≠ 153% 规划性能）是好判断。
  • 清晰度：较好，§4 未解问题按「影响范围 × 可验证性」排序，§5 与 §4 显式映射。
  • 证据：§4.1 提到「DeepSeek-V4-Pro / Kimi-K2.6 黑盒教师」，这个模型名未出现在本棒任何一篇的 ⚠️ 免责说明中，属未标注来源的具体命名；§5 的映射编号（§4.7、§4.6）与 §4 实际条目数（7 条）错位，§4.5→W5-3、§4.4→W5-3 重复指认。
  • 遗漏：§5 的 W5-1 同时映射到 §4.1 和 §4.2，属于「一条建议挂两个问题」的模糊映射，未说明优先级。

3. su-ospo-preprint-bot.md（工具上手攻略）

  • 准确性：中。§六 标题写「坑与注意（7 条）」，实际列了 9 条（第 8、9 条为模型下载与 arXiv 公告节奏）。计数与内容不符。
  • 深度：中等偏上。真正有价值的是第 4 条（Django 直连 Postgres、不走 HTTP）与第 7 条（384 维换模型即清库），这两条是从架构读出来的，不是 README 抄的。
  • 清晰度：好，四份配置、两端口、完整 flag 都给全了，读者可直接照做。
  • 证据：只有仓库 README 一个来源。§八 诚实标注了未 clone、未启服务，但表格里「维护成本：高 / 数据归属：完全自持 / 推荐质量：中」这几项属于主观评级，未给评级依据，也没有第二来源交叉。同类的 Elicit/Litmaps 三列完全没有证据来源，与 preprint-bot 列不对称。
  • 遗漏：缺一个最小可跑 smoke test（用 --skip-* 串起来的 5 步验证路径），也没写 Python 3.10+ 在 arm64/macOS 上 GROBID Docker 镜像的架构限制。

二、本轮最需改进的一篇

选 organized/promo/surveys/2026-10-20-database.md。

理由：另外两篇的缺陷是「计数/重复」级别的表层问题，读者自行可辨；而 database 篇的第 ② 条缺陷是自检表本身失真——§0 十维自检逐项打 ✅，但同一文档里编号跳号（缺 ⑦）、⚠️ 编号复用（W12）、§六 声称 5 条实际 4 条。自检机制宣称通过而实际未通过，这会让整套「自检栏」的可信度被稀释，属于结构性问题而非笔误。

三、本轮自身优缺点

优点：严格限定在清单 3 篇内完成阅读，未扫描历史档案；评价落到具体行（编号、段落、字段），不停在「还可以更严谨」这类空话；对 database 篇的取舍给了理由而非罗列。

缺点：三篇全是我自己写的，存在确认偏误——评 database 篇时，我更关注「洞见深度」而对编号/计数这类可机械核验的项检查不足。事实上编号连号与标题计数是可以逐行数出来的，我本该先做机械校验再谈深度。

四、可复用改进规则

  1. 发稿前跑机械校验：编号序列连续性（①–⑨ 无跳号）、⚠️ 编号不复用、标题声明的条数与正文实际条数一致。
  2. 自检表只在机械校验通过后打勾；「✅」应指向可复算的事实，不指向印象。
  3. 跨节映射必须双向可数：§5/§6 声称映射 N 条时，逐条核对被映射条目与声明条数一致，缺口显式写「缺 X」而非省略。
  4. 主观评级必须标注依据（对比表里的「高/中/低」要写清来源），无第二来源的列应整体标 ⚠️。
  5. 未标注来源的具体命名一律降级为 ⚠️，包括看似显然的模型名、版本号。

五、修订建议（针对 database 篇，仅为建议，未改动原稿）

以下为建议文本，供后续棒次采纳；不覆盖、不追加、不重写原稿，亦不据此触发下一轮原稿更新。

  1. 编号修正：§二.2 的 ⑤⑥⑧⑨ 应为 ⑤⑥⑦⑧，并同步修正正文中一切依赖编号的交叉引用。
  2. ⚠️ 编号拆分：§四 的「ARCS 分层指标」与 §六 的「建议映射」应各自独立编号（如 W12、W13），§0 自检第三项改为「⚠️ ≥12 处且编号不复用」。
  3. §六 补第 3 条或改声明：二选一——补一条落在「系统栈协同」轴上的建议，或把「§6.1~§6.5」改为「§6.1~§6.4」。
  4. 轴 A 补选材标准：在 §五 第 1 点后追加一句，说明下一棒 database 主题是否设定传统 OLAP/向量库的最低配额，避免主题漂移被默认为合理。

（本轮未联网、未创建子任务、未改动任何原稿或任务状态。）