文章審閱面板是做什麼的？

版本： 1.0

在技術草稿旁產出最多三個審閱檔案，每個檔案由不同的專家角色撰寫：領域專家（技術主張的正確性）、編輯（結構、清晰度、受眾、平台適合度）以及統計學家（資料是否支持結論）。每個檔案使用相同的「優點 / 錯誤 / 需要更多說明」格式，方便作者據以行動。事實依據是草稿資料夾中的原始資料、腳本和筆記，絕非草稿本身的摘要。

重要規則（請先閱讀）

在動筆之前，先讀完整個資料夾。 包括草稿、筆記、初稿留言、相關文章、基準測試腳本和原始結果檔。只讀草稿的審閱無法發現草稿錯誤引用資料的情況。
驗證草稿中的每個數字。 根據原始資料重新計算，或標記為未驗證。引用檔案和數值：results_gc.json: 173 → 166 MB。
「錯誤」就是錯，不是風格偏好。 在資料夾中找不到證據的主張、與資料矛盾的數字、分析無法支持的結論，或平台會顯示錯誤的句子。品味相關的意見放在「需要更多說明」。
每個「錯誤」項目都附有具體修正： 替代的文字、可以驗證主張的命令，或刪除建議。
各視角各司其職。 交叉引用其他檔案（例如：「技術正確性請見 REVIEW-…-JVM.md」），而非重複其發現。
統計學視角：分析，而非目測。 對原始資料執行 scripts/paired_stats.py。沒有信賴區間和最小可檢測效應值，就不得做出「雜訊」或「無效應」的結論。
遵守字數預算。 計算草稿字數是否符合平台限制（LinkedIn：3,000），並說明每個新增部分的成本。
標記機密性。 內部名稱、工單編號、主機、客戶或生產數據：需標明需要法務/公關部門批准。切勿將受限資料（會員、理賠、健康、憑證）放入審閱或搜尋中。

讀取優先表

來源	路徑	要提取的內容
草稿	使用者指定的檔案	每個事實主張、每個數字、每個命令、鉤子（前約 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`（若不存在則建立）	先前執行的回饋；在起草前應用

工作流程

第一階段：盤點

列出資料夾內容。閱讀草稿以及所有筆記、腳本和結果檔案。計算草稿字元數。建立主張清單：每個數字和每個事實斷言，附上行號。

第二階段：選擇視角

預設為全部三個。僅執行使用者指定的視角（例如「扮演統計學家」）。對於領域視角，從使用者獲取領域（「JVM」、「Kubernetes」、「Postgres」）或從草稿推斷並說明選擇。

第三階段：驗證

根據原始資料重新計算每個主張。對於基準測試，執行：

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 <variants per round> --pair <A>:<B> [--pair ...] --metrics <m1,m2>

搜尋資料夾中每個質性主張的證據（例如「無法啟動」、「被默默忽略」）。無證據則標示為「錯誤：未經測試」，並附上測試命令。

第四階段：為每個視角撰寫一個檔案

寫入草稿資料夾，命名為 REVIEW-<DRAFT-STEM>-<LENS>.md，其中 LENS 為 JVM/<DOMAIN>、EDITORIAL、STATISTICS。遵循以下輸出格式和 references/ 中的視角指南。

第五階段：評分與報告

透過一個乾淨上下文的評分子代理執行 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 毫秒 | [−104, −49] | **10/10** | **0.002** |
| **合併，50 對** | **−2.1%** | **[−3.2%, −1.5%]** | **39/50** | 不適用 |

正確的結論是「一個真實但微小的效應：約 2%，或 20–70 毫秒」，而非「雜訊」。

此次執行的完整三個檔案輸出已總結在 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。

文章審閱面板