article-review-panel 是做什么的？

版本： 1.0

在技术文章草稿旁边生成最多三个审查文件，每个文件由不同的专家角色撰写：领域专家（技术主张的准确性）、编辑（结构、清晰度、受众、平台适配性）和统计学家（数据是否支持结论）。每个文件使用相同的“优点 / 错误 / 需要更多解释”结构，便于作者快速采取行动。事实依据是草稿文件夹中的原始数据、脚本和笔记，而非草稿本身对这些内容的总结。

关键规则（请先阅读）

在写出任何内容之前，先阅读整个文件夹。 包括草稿、笔记、初稿评论、关联文章、基准测试脚本和原始结果文件。只阅读草稿的审查无法发现草稿对数据的误引用。
验证草稿中陈述的每一个数字。 根据原始数据重新计算，或标记为“未验证”。引用文件和数值：results_gc.json: 173 → 166 MB。
“错误”是指确实错误，而非风格偏好。 如果文件夹中没有证据支持某个主张、数字与数据矛盾、结论不受分析支持，或者句子在目标平台上会显示异常，就属于“错误”。品味问题应归入“需要更多解释”。
每个“错误”项都必须附带具体的修复建议：替换措辞、用于验证主张的命令，或裁剪内容。
每个角色各司其职。 交叉引用其他文件（例如“技术准确性见 REVIEW-…-JVM.md”），而不是重复它们的发现。
统计学家视角：分析，而非目测。 基于原始数据运行 scripts/paired_stats.py。没有置信区间和最小可检测效应值就绝不能下“噪声”或“无效果”的结论。
遵守字数预算。 对照平台限制（LinkedIn：3,000 字）计算草稿字符数，并明确指出每增加一个内容需要削减什么。
标记机密信息。 内部名称、工单 ID、主机、客户或生产数据：说明它们需要法务/公关部门批准。切勿将受限数据（成员信息、索赔、健康数据、凭证）写入审查或搜索内容。

先读后审表

来源	路径	需要提取的内容
草稿	用户指定的文件	每一个事实主张、每一个数字、每一条命令、钩子（前约 210 个字符）、行动号召、字符数
作者笔记	`*.md` 同级文件（数据笔记、初稿评论、关联文章）	作者自己在草稿中遗漏的警告和修正；关联文章之间的重复文本
基准测试脚本	文件夹内的 `.py`、`.sh`、Dockerfile	运行顺序（随机化？分块？）、每个指标实际衡量什么及其采样时机
原始结果	`.json`、`.csv`、`*.log`	用于重新计算的数字；配对的分块大小
领域视角指南	`references/domain-lens.md`	领域检查清单；JVM 部分是示例领域
编辑视角指南	`references/editorial-lens.md`	平台规则（LinkedIn markdown、折叠、字数限制）和结构检查清单
统计学家视角指南	`references/statistics-lens.md`	分析方法和标准方法论缺陷标志
过往经验教训	`~/.claude/skill-memory/article-review-panel.md`（如果缺失则创建）	先前运行的反馈；起草前应用这些经验教训

工作流程

阶段 1. 清点

列出文件夹中的内容。阅读草稿以及每一个笔记、脚本和结果文件。计算草稿的字符数。构建一个主张列表：每一个数字和每一个事实断言，并注明其所在行。

阶段 2. 选择视角

默认使用全部三个视角。仅运行用户指定的视角（例如“扮演统计学家”）。对于领域视角，从用户处获取领域（“JVM”、“Kubernetes”、“Postgres”），或从草稿中推断并说明选择。

阶段 3. 验证

根据原始数据重新计算每一个主张。对于基准测试，运行：

python3 ${CLAUDE_SKILL_DIR}/scripts/paired_stats.py --file <results.json> --list
python3 ${CLAUDE_SKILL_DIR}/scripts/paired_stats.py --file <results.json> \
  --block-size <每轮变体数> --pair <A>:<B> [--pair ...] --metrics <m1,m2>

在文件夹中搜索每一个定性主张的证据（例如“无法启动”、“被静默忽略”）。没有证据则标记为“错误：未测试”，并给出测试命令。

阶段 4. 为每个视角编写一个文件

写入草稿所在的文件夹，命名为 REVIEW-<草稿名>-<视角>.md, 其中视角为 JVM/<DOMAIN>、EDITORIAL、STATISTICS。遵循下面的输出格式以及 references/ 中的视角指南。

阶段 5. 评分与报告

通过一个使用干净上下文的评分者子代理（仅向其提供 evals.md、草稿和审查文件）运行 evals.md。修复所有失败项并重新评分。然后向用户报告：每个视角一行，包含最重要的“错误”项和文件路径。将用户提供的任何新经验教训添加到 ~/.claude/skill-memory/article-review-panel.md（最新的在前；如果缺失则创建）。

输出格式

# 审查 <草稿文件>: <视角名称>

审查者视角：<角色名称>。针对 <检查了哪些内容，依据什么>。

## 结论

<2–4 句话：是否可发布、最强的一项、必须修复的数量。>

## 优点

- **<加粗的主张>.** <证据，包括文件和数值。>

## 错误：<发布前必须修复 | 结论并非来自数据>

### 1. <缺陷的一行描述>

<草稿的说法、数据实际表明什么、为什么重要。>

建议修复：<措辞、命令或裁剪>。

## 需要更多解释

### N. <主题>

<缺失的内容以及建议添加的行。>

## 次要问题

- **<标签>:** <一到两句话>。

统计文件在标题之后添加一个分析方法部分，并在末尾添加一个建议重新运行列表。

示例

输入：

扮演一位经验丰富的 JVM 工程师，审查 ~/aot-exploration/linkedin-cds 中的 POST-1-DEFAULT-CDS-EN.md，然后是编辑，最后是统计学家

Claude 执行的步骤：

阅读帖子、DADOS-POST.md、初稿评论、帖子 2、bench*.py 和 results*.json。计算出 2,623 个字符（3,000 字符限制）。
领域视角：确认 ZGC 映射了 classes_nocoops.jsa；未找到提及 AOTCache 的文件，因此“JVM 甚至无法启动”的主张被标记为“错误”，并附带一个测试命令。
编辑视角：87 个字符的钩子适合在折叠线以上；四个反引号命令在 LinkedIn 上会按字面显示（错误）。
统计学家视角：看到循环内有 random.shuffle(order)，因此运行 paired_stats.py --block-size 12。合并偏移量为 −2.1% [−3.2%, −1.5%]，因此“那是噪声”是错误。+2% 来自比较未配对的中间值。
编写三个 REVIEW-POST-1-*.md 文件，使用 evals.md 进行评分，然后报告。

输出（统计学家文件，摘录）：

### 1. “启动时间：−4% 到 +2%。那是噪声。”与数据不符

| 设置 | 配对偏移量 | 95% 置信区间 | 使用 CDS 更快 | 精确 p 值 |
|---|---|---|---|---|
| Serial | −69 ms | [−104, −49] | **10/10** | **0.002** |
| **合并，50 对** | **−2.1%** | **[−3.2%, −1.5%]** | **39/50** | n/a |

正确的结论是“真实但影响很小：大约 2%，或 20–70 ms”，而不是“噪声”。

本次运行的完整三个文件输出总结在 references/examples.md 中。

参考文献

references/domain-lens.md：领域专家检查清单；JVM/CDS/AOT 示例领域。
references/editorial-lens.md：编辑检查清单和 LinkedIn 平台规则。
references/statistics-lens.md：分析方法和标准方法论缺陷标志。
references/examples.md：CDS 帖子运行的逐项发现。
evals.md：通过/失败检查。在交付前通过一个干净上下文的评分者运行。
~/.claude/skill-memory/article-review-panel.md：经验教训日志，最新的在前，仅限本机（参见 memory.md）。起草前阅读。

脚本

scripts/paired_stats.py：仅使用标准库的配对 A/B 分析（精确 Wilcoxon 符号秩检验、符号翻转检验、Hodges-Lehmann 估计、bootstrap 置信区间、最小可检测效应、合并偏移量、漂移和顺序检查）。--list 显示变体和指标；--self-test 运行 8 项检查。

何时不使用此技能

审查代码、分支或 PR。请使用 diegourban:gh-pr-review、diegourban:branch-review 或 /code-review。
检查代码库的实际行为。请使用 diegourban:fact-checker。
从零开始编写或重写帖子本身。请进行直接对话；此技能仅用于审查。
检查演示文稿或幻灯片。仅当用户要求时才使用此技能审查内容；使用 create-slide-deck 构建。

article-review-panel