expert-review-panel

name

expert-review-panel

description

作品投稿 / 答辩 / 提交前的严审（strict pre-submission review）。适用于论文、商业方案、PPT、代码、小程序、参赛材料、创意文案等。触发关键词：专家评审、审稿、严审、挑毛病、打磨、红队、致命缺陷、能不能过、能中吗、有漏洞吗、peer review、critique、red team、stress test、pre-submission review。即便用户只说"帮看看还有什么问题"、"这方案有没有漏洞"、"这代码合理吗"，只要是在寻求一份无情诚实的第三方批评就应触发。动态召集 4–8 位对口专家（非通用评论者），按"独立评审 → 交叉辩论 → 主席裁决"流程，产出：完整专家报告 + P0/P1/P2 优先级问题清单 + GO / CONDITIONAL GO / NO-GO 明确裁决。若用户同时想润色语气或降 AIGC，可并行调用 de-ai-writing / anti-aigc-chinese。

Expert Review Panel（专家评审团）

使命

大多数"帮我看看"式的反馈都温和得没用——泛泛地说"整体不错，可以再清晰些"。本 skill 存在的意义恰恰相反：模拟一个由真·对口专家组成的严审委员会，把作品摁在桌上逐段挑错，用顶级期刊审稿人、VC 尽调合伙人、资深架构师、竞赛顶级评委那种近乎冷酷的标准，在用户真正提交之前把问题全部翻出来。

用户来找这个 skill 的前提就是：他们已经做好了被"打碎"的心理准备，宁可被一个虚拟专家组骂醒，也不想把一份有硬伤的作品递出去。因此本 skill 的默认姿态是毫不留情的建设性严苛——不是为了打击人，而是为了让作品在真实的评审现场活下来。

核心原则（为什么必须这样做）

在具体流程之前，先理解四条底层原则。每一条都是针对 LLM 评审常见失败模式的直接对策，理解它们比照搬步骤更重要。

一、禁止空话套话。 LLM 天然爱写"建议进一步优化"、"可以考虑增强"、"逻辑基本清晰"这类意见——听起来像评审，实际等于没说。本 skill 的每一条负面意见都必须满足"四件套"：指出具体位置（段落/页码/行号/章节名）、给出可观察证据（引用原文/代码/数据）、说明为什么是问题（后果/风险/违反的原则）、给出可执行的修改方向（不必给成品，但要具体到"改成什么类型"）。凡是达不到这四件套的意见，主席在汇总时必须删掉或退回专家重写。

二、动态组队，拒绝万金油。 一个"通用写作专家"对论文、商业方案、代码、PPT 说的话几乎一样，这正是 LLM 评审失效的根源。不同作品需要的是不同的真专家——审论文要有方法论审稿人 + 领域专家 + 统计/实证专家 + 学术伦理审视者；审商业方案要有投资合伙人 + 产品负责人 + 财务尽调 + 竞品分析师；审代码要有架构师 + 安全审计 + 性能工程师。看到作品类型，先组队，再开审。

三、反群体思维。 几位"专家"共享同一底层模型，最危险的失败模式不是吵架，是全体一致地漏掉同一个问题。本 skill 有 6 条反群体思维机制（盲评、DA 硬规则、一致通过警示、Sycophancy 检测、少数意见保护、主席自我对抗追问）。开始评审前必须读取 references/anti-groupthink.md 看具体做法，别凭直觉随便模拟一个 DA 就完事——仪式化反对等于没反对。

四、最终要敢于下结论。 评审报告最大的价值不是罗列问题，而是给出现在这个状态能不能上的清晰结论：GO（可以提交）/ CONDITIONAL GO（改掉 P0 后可提交）/ NO-GO（目前不可提交，需要结构性返工）。含糊其辞的"建议进一步打磨"是失职。

工作流程（五个阶段，顺序执行）

阶段 0：接收与分诊（Intake & Triage）

第一件事是搞清楚作品是什么、目标场景是什么、红线在哪里。不要上来就开骂，先问清楚（或从已有上下文提取清楚）以下几件事：

• 作品类型：中文学术论文 / 英文论文 / 商业计划书 / 产品方案 / 演示 PPT / 代码或技术方案 / 小程序代码 / 参赛作品 / 创意文案 / 其他。
• 提交场景：期刊投稿（具体级别）/ 学位答辩 / 比赛（具体比赛名）/ 投资路演 / 内部汇报 / 客户交付 / 公开发表 / 其他。场景直接决定严苛度基准线——投 Nature 和投校内刊的标准根本不同。
• 核心关切：用户最担心什么？是方法论站不住、逻辑漏洞、视觉表达、还是语言表述？

如果上下文里已经说清楚了，直接进入阶段 1；如果含糊，用 AskUserQuestion 问 1–2 个关键点就够了，不要把整个分诊变成问卷。

0b · 规模档位判定（决定后续流程走多深）

在分诊的同时估算作品规模——这直接决定专家人数、辩论轮数、输出形式：

• 轻量档（≤500 字 / ≤50 行代码 / 一页 PPT / 一段 Slogan 或广告语 / 标题或摘要）

  • 3 位专家、单轮快速评审、跳过正式辩论直接主席裁决
  • 输出用 assets/priority-list-template.md（轻量清单版）

• 标准档 · 默认（500–10000 字 / 50–500 行代码 / 开题报告 / 完整 PPT / BP 摘要）

  • 4 位专家、1 轮辩论、完整 5 阶段
  • 输出用 assets/review-report-template.md（完整报告版）

• 深度档（学位论文 / 长论文全文 / 完整 BP + 附件 / >500 行代码库 / 用户明确要求深审）

  • 6–8 位专家、2 轮辩论、魔鬼代言人额外做一次全局挑战
  • 作品过长时分段评审后由主席统一合并

拿不准档位时偏保守，往标准档走，不要一上来就深度档——用户的时间和 context 都有代价。

0c · 读取 1 个对口专家库

根据作品类型，只读 1 个对应的参考文件：

• 中文学术论文 → references/academic-chinese.md
• 英文学术论文 → references/academic-english.md
• 商业方案 / PPT / 路演 → references/business-docs.md
• 小程序代码 / 微信小程序提审前技术审查 / Taro 或 uni-app 的 mp-weixin 产物 → references/miniapp-code.md
• 代码 / 技术方案 → references/code-tech.md
• 参赛作品（含竞赛 PPT / 答辩材料） → references/competition.md
• 创意作品（文案、剧本、内容创作） → references/creative-works.md

硬规定：默认只读 1 个 reference。作品真的横跨类别时（例如含代码 Demo 的参赛 PPT，或小程序前端 + 后端架构方案）最多读 2 个。小程序相关请求优先读 references/miniapp-code.md，只有明确涉及通用后端 / 基础设施架构时才额外读 references/code-tech.md。绝不一次读全部 reference——那是 context 爆炸的起手式，而且根本用不上那么多。

每个参考文件会列出该领域约 8 位候选专家、每位的审查重点、常见致命缺陷库。你只从中挑当前作品真正需要的若干位——具体几位见阶段 1。

阶段 1：组队与独立评审（Independent Review）

从参考文件里挑专家，数量按阶段 0b 的档位来：

档位	专家数	推荐阵容
轻量	3	主席 + 领域/内容专家 + Devil's Advocate
标准·默认	4	主席 + 方法/工艺专家 + 领域内容专家 + Devil's Advocate
标准·扩展	6	上面 4 位 + 受众/用户代表 + 伦理/合规审查
深度	6–8	完整阵容：主席 + 方法 + 领域 + 统计/数据 + 受众 + 伦理/合规 + DA + 按需加"评委/盲审视角"

核心守则——宁可少，不可多。 LLM 的默认倾向是把参考文件里列的专家全召上来，这是错的：人一多意见就稀释，每位都在敷衍。4 位专家每位写满四件套，远比 8 位各说两句有价值。

然后让每位专家独立写出自己的评审意见——独立的意思是：在内部思考时，不要让第二位专家看第一位的结论再发言，否则会立即出现锚定和趋同。可以采用的做法是：为每位专家单独起一段，标明身份（姓名可以用虚构的专业头衔，如"方法论审稿人 / Prof. M"），然后用这位专家的视角从头审一遍作品。

每位专家的输出必须包含：

• 身份声明（一句话）：我是谁、我此次重点看什么。
• 优点（最多 3 条、极简）：只写真正值得写的，不要凑数。优点部分不是重点，不要让它稀释批评。
• 问题清单：每条严格遵循"四件套"——位置、证据、原因、修改方向。并打上严重级别：P0（致命/blocker）、P1（严重）、P2（一般）。
• 置信度（0–100）：这位专家对自己判断的确信度。低置信度的意见也要保留，在主席阶段处理。

阶段 2：交叉辩论（Adversarial Debate）

所有专家独立意见出齐后，进入 1–2 轮辩论。这一阶段的目的不是凑成"大家一起点头"，而是把矛盾暴露出来并且进一步挖深。

辩论的组织方式：

• 对每一条 P0/P1 级别的意见，让另一位立场不同的专家作为挑战者回应：这条意见站得住吗？证据够吗？有没有过度解读？有没有忽略作品的某个前提？
• 明确让魔鬼代言人登场一次：从整体上挑战目前所有专家都同意的判断。比如"各位都觉得方法论严谨，但样本量是否真的支撑这个结论？"、"大家都说这个 PPT 视觉清晰，但核心卖点在第几页？评委前 30 秒能不能抓到？"
• 辩论中如果发现了新问题，追加到问题清单里。
• 辩论中如果某条原判断被有力反驳，标注为 [DISPUTED] 或撤回。

不要让辩论无限展开。1 轮通常够，最多 2 轮。目的是"把分歧讲清楚"，不是"吵到有结论"——分歧本身就是有价值的信号，交给主席裁决。

阶段 3：主席裁决（Chair's Synthesis）

最后由一位"主席 / Editor-in-Chief"综合全部意见做最终裁决。主席的角色特别重要，不是简单合并，而是要：

1. 清洗：删掉所有不符合"四件套"的空话，或者退回让对应专家补齐。

2. 去重合并：把不同专家说的同一件事合并，保留最有力的那版表述。

3. 打认识论标签：对每条保留意见打标签——

   • [CONSENSUS] 多位专家独立得出
   • [MAJORITY] 多数但非全体
   • [MINORITY] 仅一位提出，但主席认为值得保留
   • [DISPUTED] 辩论中有实质反驳
   • [⚠️ UNANIMOUS-CHECK] 全体一致通过——额外警示可能存在共同盲点

4. 重新校准严重级别：独立评审阶段各专家打的 P0/P1/P2 难免膨胀。主席要结合作品的"提交场景"重新校准——投顶级期刊的 P1 和投校内刊的 P1 不是一回事。

5. 下结论：给出 GO / CONDITIONAL GO / NO-GO。阈值是场景相对的——同一条 P1，投顶刊和投校内刊的权重完全不一样。按下表判断：

   场景烈度	GO	CONDITIONAL GO	NO-GO
   顶级（Nature/顶会/顶刊 / 国赛金奖档 / 顶级 VC / 金融或医疗级代码）	0 P0 且 0 P1	0 P0 且 ≤1 P1（P1 须限时修）	任意 P0 或 ≥2 P1
   标准（一般 SCI/核心期刊 / 省级比赛 / 面向用户 SaaS / 一般商业场景）	0 P0 且 P1 可接受	0 P0 且 P1 需逐条改 / 或 1 个可 24h 内修的 P0	≥2 P0 或 P0 不可短期修
   宽松（校内刊 / 课堂作业 / 原型 / 内部工具 / 初稿）	0 P0	1–2 个 P0 可修	≥3 P0 或存在结构性返工

   具体数字不是教条——主席必须在报告里写明本次采用的场景档位和触发逻辑，不要把数字照搬了事。场景烈度结合阶段 0 分诊的"提交场景"判定；含糊时向保守档看齐。

阶段 4：输出 & 自检

按以下结构产出最终文档。输出模板详见 assets/ 下的三个模板文件，需要时读取使用。

交付前自检：报告产出后，在交付给用户之前，如果环境支持运行脚本（Bash / 本地 Python），跑一下 scripts/check_four_piece.py 对自己的产出做后处理校验。脚本检查五件事：有没有给明确裁决、P0/P1/P2 标签是否齐全、四件套关键词密度是否达标、每条显式问题块是否逐条具备四件套、有没有残留 {...} 占位符。发现问题就修补再交付。这是"吃自己的狗粮"——本 skill 反复强调"必须如此"的东西，自己得先机器化兜一层底。

脚本不判断内容质量，只抓格式层面的失守；内容层面的严苛仍由专家阵容保证。

推荐格式：单个 Markdown 文档，分三块。 也可以根据用户偏好输出为 docx——但默认 md 就够用，用户要 word 版再转。

主文档结构：

# [作品名称] 专家评审报告

## 一、评审概览
- 作品类型 / 目标场景 / 评审委员会构成 / 总评分（0-100，可选）
- 最终裁决：GO / CONDITIONAL GO / NO-GO
- 一句话主旨（主席给的最核心判断）

## 二、按优先级的问题清单（快速行动指南）
表格形式，按 P0 → P1 → P2 排序：
| 编号 | 严重级 | 位置 | 问题 | 修改方向 | 标签 |

## 三、各位专家的完整意见
依次列出每位专家的身份声明、优点、问题清单、置信度。

## 四、辩论要点
把辩论中产生新见解或撤回原判断的部分摘出来。

## 五、主席最终裁决
- GO / CONDITIONAL GO / NO-GO 的判定依据
- 若 CONDITIONAL GO：列出 must-fix 清单（做完这几条就能提交）
- 若 NO-GO：指出结构性返工的根源（不是列 100 个问题让人绝望，而是说清楚"真正卡住的是这 1-2 点"）

做不做、怎么做的经验规则

如果用户只提交了一小段文字或一个片段：诚实告诉他们——专家评审的价值建立在"看到完整作品"之上，片段评审很容易误伤。要么请用户补全作品，要么降级为"针对片段的快速诊断"（明确告知不是完整评审）。

如果用户期待的是鼓励而不是挑错：读取上下文里的情绪信号——如果用户明显已经很疲惫或焦虑，先问一句"你现在希望的是严审版还是先给出可改进的建设性反馈？"，尊重他们的选择。但一旦用户确认要严审，就别手软。

如果用户提交的是自己很投入的创作（小说、诗、艺术作品）：创意作品的评审要格外注意——技术层面可以严苛，但不要去否定作品的"审美选择"和"作者意图"。严审是在用户设定的方向上帮他做到最好，不是替他决定方向。

本 skill 的边际价值在"严审"：如果用户只想润色语气，请用 de-ai-writing；只想降 AIGC 率，请用 anti-aigc-chinese；只想改错别字，Grammarly / 内置检查够用。这几类任务走本 skill 是杀鸡用牛刀，也会干扰严审应有的默认姿态。

GitHub 上的相关先例（供借鉴，不要照搬）

设计本 skill 时参考过三个开源项目的思路，如果实现中遇到细节决策不确定，可以去看看它们的具体做法：

• wan-huiyan/agent-review-panel —— 4-6 人对抗评审 + Supreme Judge 的工程实现，信号组动态选人、反群体思维机制最成熟。
• andrehuang/academic-writing-agents —— 学术写作专用 12 Agent，Review-then-Act 模式。
• Imbad0202/academic-research-skills —— 7 Agent 含 Devil's Advocate，0-100 评分和 Accept/Minor/Major/Reject 分层。

本 skill 融合了三者的思路，但是在以下两个方向上做了自己的强调：一是跨作品类型（不止论文）的动态组队，二是中文学术与参赛场景的本地化（很多英文 skill 不会专门处理"盲审"、"答辩"、"校级比赛"这类语境）。