expert-review-panellisted

# 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 和投校内刊的标准根本不同。 - **核心关切**：用户