写作 Eval：从金字塔原理到文档分类
探讨如何用确定性评分器替代传统 LLM as Judge 进行写作质量评估，包括金字塔原理和 DivIO 文档分类框架
背景
在 AI Eval System 中，核心原则是优先使用确定性评分方法，避免 LLM as Judge 的问题：递归倒退（谁来 judge judge？）、不确定性叠加、可调试性差。
写作任务也需要评分器。但写作质量评估的挑战在于：不同类型的文章需要不同的评估标准。
- 议论文、技术分析：适合用金字塔原理评估结构化程度
- 技术文档：适合用 DivIO 文档分类框架评估分类准确性
- 教程、API 文档：适合用针对性规则评估
没有"万能钥匙"式的评分器，但每种类型都可以找到明确的规则，实现半确定性的评分。
确定性谱系
这些评分器都位于确定性谱系的中间位置：
100% 确定性 ←────────────────────→ 20% 确定性
Type checker 金字塔原理/文档分类 LLM as Judge本质是：这些评分器更接近 Design compliance / Linter，而不是"让 LLM 主观评价文章质量"。
文档分类框架
DivIO 的文档分类框架提供了四种正交的文档类型，每种都有独立的写作模式：
Tutorials
- Minimal 的 learn by doing，专注于当前任务
- 如果有多种方式完成某件事，介绍最简单最通用的，然后链接到其他方式
- 走一点弯路也没关系
- 用户需要马上能看到结果，不要铺垫太多理论
- 必须可复现
How-to Guides
- 可以假设用户有基础知识，不需要太多 intro outro，直接讲分离出来的问题
- 解决特定问题，但不要太 ad-hoc，有一点点的 generalality
- Title 必须是明确的 "how to ..." 之类的
- 只讲怎么做，不讲为什么，可以链接出去
Reference Guides
- 纯信息
- 信息准确性
- 文档和 code 的结构保持一致，最好是写在 code 的旁边
- 这样容易看出来哪里缺少文档
- 更新的时候同时更新方便
Explanation
- 讨论某个特定的主题，例如 design decision、historical reason、technical constraints、多种完成某个特定 task 方式的对比
- High level 的讨论，不一定是讲当前的 software
例如：
- about the structure
- who is using the system?
这个框架的价值在于：
- 读者找方便：每种文档类型有明确的位置和模式
- 作者写效率高：知道写哪种类型，遵循对应的规则
- 正交性：四部分之间互相独立，不重叠
评分器设计
Task
根据写作 prompt 生成文章后，自动评审文章质量。
Dataset
所有写作内容（输入为 prompt，输出为文章）。
Scorer：多类型评分器
结构化评分器（金字塔原理）
- 结论先行测试：开头 3 句内是否有明确结论
- 自上而下测试：每层级是否有明确主题
- 归类分组测试：同组论点是否属同一范畴
- 逻辑递进测试：论点顺序是否合理
- MECE 测试：论点是否独立穷尽
文档分类评分器（DivIO）
- 分类测试：文章属于 tutorials、how-to guides、reference、explanation 中的哪一类？
- Tutorials 测试：
- 是否有可复现的步骤？
- 是否让新手能马上看到结果？
- How-to Guides 测试：
- Title 是否明确是 "how to" 格式？
- 是否聚焦于特定问题？
- 是否避免过多解释？
- Reference 测试：
- 是否是纯信息描述？
- 是否与代码结构一致？
- Explanation 测试：
- 是否讨论特定主题（design decision、history 等）？
- 是否是高层次讨论而非具体步骤？
运行流程
1. 遍历代码库中的所有文章
2. 运行每个 scorer 识别问题
3. 生成改进建议（不自动修改，只输出诊断报告）
4. 记录评审结果供人类 review
LLM as Judge 的结构化
即使必须使用 LLM as Judge，也可以用这些框架提升确定性。
传统方式
文章 → LLM → "逻辑混乱"问题：
- 结论黑盒，无法追溯
- 失败时无部分价值
- 难以调试
结构化方式
金字塔结构化
文章 → LLM →
结论：逻辑混乱
├─ 支撑点1：第3-4段应合并（都是数据相关）
│ └─ 证据：第3段"数据质量"，第4段"数据量"
├─ 支撑点2：结论出现太晚（第7段）
│ └─ 证据：第7段开头"总而言之..."
└─ 支撑点3：第5段"但是"破坏结构
└─ 证据：第5段引入"安全性"，前面无铺垫文档分类结构化
文章 → LLM →
分类：How-to Guide
├─ 符合项：Title 明确（"How to configure API"）
├─ 符合项：聚焦于特定问题
├─ 问题：第2-3段解释了历史原因（应链接到 explanation）
│ └─ 证据：第2段"最初设计是因为..."
└─ 建议：删除第2-3段解释部分，保持步骤聚焦价值
- 部分价值：即使最终结论错了，子结论仍有用
- 可调试：每个支撑点指向具体位置，可以逐一验证
- 确定性提高：子结论更接近"Design compliance"而非纯主观
- 可追溯：自下而上搭建结论，不是"拍脑袋"
写作 TDD
这些框架都可以作为写作 TDD 的测试用例：
TDD 流程
1. 先写测试（检查清单）
2. 开始写作
3. 迭代直到所有测试通过
测试用例
议论文/技术分析（金字塔原理）
- 文章开头 3 句话内是否有明确结论？
- 每个层级是否都有明确的主题？
- 同一组论点是否属于同一范畴？
- 论点之间的逻辑顺序是否合理？
- 论点之间是否有重叠或遗漏？
技术文档（DivIO 分类）
- 文章属于哪一类文档？（tutorials/how-to/reference/explanation）
- Tutorials：
- 是否有可复现的步骤？
- 新手能马上看到结果吗？
- How-to Guides：
- Title 是 "how to" 格式吗？
- 是否聚焦于特定问题？
- 是否避免了过多解释？
- Reference：
- 是纯信息描述吗？
- 与代码结构一致吗？
- Explanation：
- 是否讨论特定主题？
- 是高层次讨论吗？
文档 TDD 测试
写文档的时候，让 AI 判断属于上面 4 个分类的哪个，每个分类有自己的评判标准。AI 应该输出分类，和对应的建议。
这完美体现了 AI Eval System 的核心原则：确定性评分优于 LLM as Judge。
适用场景
- Sleep time compute：人类睡觉时自动评审文章
- 回归测试：文章修改后快速检查是否破坏结构
- 批量处理：一次性评审多个文档
- 文档分类：新文档自动识别类型，帮助组织
参考
- Diátaxis Framework - systematic technical documentation
- 关于 Sleep time compute 的详细讨论，见 long-running-agents