前言¶

投过稿的人都知道一个循环：把稿子发出去，等几周，收到审稿意见，发现最容易被攻击的那几点（novelty 的表述、样本量、图表和正文的对不上）其实自己在投稿前就能看出苗头。问题在于，作者是最不适合判断自己稿子的人，因为整个论证链条已经在心里跑过无数遍。

下面介绍的这个 Skill 就是解决这个问题的。它把 Nature 式的审稿评估流程做成可复用的 SKILL.md 工作流，从审稿人（referee）一侧出发，对一篇手稿做有证据支撑的模拟评审。它的定位很明确：只做评审，不写回复。返修回复是同仓库里另一个 Skill nature-response 的事。

这是什么¶

Nature Reviewer Assessment Skill，技能名 nature-reviewer，是 nature-skills 仓库（github.com/Yuan1z0825/nature-skills）里的一个技能单元，作者袁一哲，核心开发者马昕瑞、胡彬参与维护。SkillHub 上的条目由发布者 RealQ 提交，来源标记为 enterprise，分类 ai-agent，坐标 @org-eyw2ohcx/yuan1z0825-nature-skills-nature-reviewer。

它解决的问题是：在投稿前，用一套固定的、可追溯的审稿流程对手稿做压力测试，产出三份互盲的 reviewer reports 和一份事后综合，让作者在送审之前就看到最可能被攻击的位置。

需要先说明一点口径：仓库里 skills/nature-reviewer/manifest.yaml 的版本是 1.5.0，CHANGELOG 记录的发布日期是 2026-09-27；SkillHub 条目上标的版本是 1.0.0。两边不一致，本文以仓库 manifest 为准。

核心功能¶

固定产出：三份互盲报告加一份综合¶

默认输出结构是写死的：三份 reviewer reports，加上一份 Cross-review synthesis (post-review; not shown to reviewers)。只有在用户明确要求别的结构时才改。

关键约束是「互盲」。每份报告只拿到三样东西：同一份不可变的手稿与来源包、同一套期刊评审标准、以及该报告预先分配的评审侧重点（emphasis brief）。一份报告写完之前，另一份不能看到它的内容；也不能为了降低重复度把意见互相分发协调。三份报告都冻结之后，才进入综合阶段。

这意味着环境必须能真正隔离上下文。SKILL.md 明确写了：如果运行环境无法隔离，就每次调用只生成一位审稿人的报告，或者直接声明互盲无法保证；把共享上下文起草当成独立评审是不允许的。

评审依据：五个轴¶

评审按五个有来源支撑的轴展开：

• originality
• scientific importance
• interdisciplinary readership
• technical soundness
• readability for nonspecialists

仓库里另有一份 12 轴技术问题分类表（references/technical-concern-taxonomy.md），它只作为内部覆盖度检查清单使用，补充但不替代上面这五个轴。

意见分级与可追溯¶

每条实质性意见都要有稳定编号、claim_pointer（指向手稿中的声称）和 evidence_pointer（指向可核验的证据位置）。意见分成 Major Concerns 和 Minor Comments 两级，Minor 永不阻断。只有当某个 Major 问题不解决、手稿就无法确立核心论点时，才标 Blocking Yes。

SKILL.md 还明确禁止设定意见数量配额：某个层级如果确实没有有依据的问题，就直说没有，不要硬凑。

定稿后的取证一致性审计¶

1.5.0 版本新增了一个强制执行的审计阶段，在三位审稿人报告全部冻结之后、综合之前运行，对应 references/forensic-consistency-audit.md。审计覆盖：

• 算术恒等式、总数、百分比、delta、区间和精度一致性
• 指标上下限与聚合层级是否自洽
• 正文、表格、图件之间的排序与最高级表述矛盾
• 重复行、相同区间、可疑重复输出、离散度异常
• train / validation / test / placebo / support / query 的来源与排除
• 空间、时间、层级、目标、被试层面的泄漏
• 复现门槛：先用已有标题数字验证能否复现，再谈新实验

审计结果不会回喂给审稿人上下文，也不会改动已冻结的报告，只进入综合和风险部分，并且与「审稿人共识」分开呈现。审计发现会被归类为 confirmed_internal_error、aggregation_ambiguity、provenance_gap、suspected_duplication、unresolved_input_needed、not_assessable 或 passed。

共识的判定标准同样严格：只有至少两位审稿人独立提出同一个底层问题时，才在综合中标记为共识。

领域闸门¶

当手稿明显属于化学、工程、材料、大气科学、气候-生态、水文或遥感方向时，加载 references/domain-specific-review-gates.md 做支撑性检查，但输出仍然保持三审稿人结构不变。

明确的边界¶

SKILL.md 里写得很直白：不声称编辑的最终决定，也不声称稿件一定符合 Nature；不虚构审稿人身份、专业背景或机构；不把语言问题和实质问题混为一谈；区分清楚什么是有支撑的、什么是弱的、什么是当前材料下无法评估的。

还有一个容易忽略的细节：审稿报告和综合的行文要求尽量不用破折号和冒号来连接句子，优先另起一句、用逗号、分号、括号或短标签。稳定编号和标准复合词里的连字符不受影响。这是为了产出读起来像正式审稿报告，而不是模型口水话。

安装与启用¶

用 npx skills 安装¶

需要 Node.js 18 或更高版本。先列出仓库里可安装的技能名：

npx skills add Yuan1z0825/nature-skills --list

只装 nature-reviewer 到当前项目（以 Codex 为例）：

npx skills add Yuan1z0825/nature-skills --agent codex --skill nature-reviewer --yes --copy

需要跨项目使用时加上 --global。CHANGELOG 说明本次改动没有引入新的运行时依赖，纯提示词与参考文件类技能，不需要额外配 key；SkillHub 条目上的标签也是 requires_api_key=false。

有一点要留意：manifest.yaml 里有一条路由指向 ../nature-shared/core/consistency-sweep.md，也就是共享支持包 nature-shared 里的文件。仓库 README 说 nature-shared 默认不计入技能索引，只为 nature-reader、nature-paper2ppt、nature-polishing、nature-writing 这四个技能建议同时安装。装 nature-reviewer 时如果发现一致性检查那一步读不到文件，就把它一起装上：

npx skills add Yuan1z0825/nature-skills --global --agent codex \
  --skill nature-reviewer --skill nature-shared --yes --copy

想一次拿到全部技能，用通配：

npx skills add Yuan1z0825/nature-skills --global --agent codex --skill '*' --yes --copy

装完检查并更新：

npx skills list --global --agent codex --json
npx skills update --global --yes

在 Claude Code 里启用¶

Claude Code 不能直接用仓库里的 scripts/update-codex-skills.sh，那个脚本只负责同步到 ~/.codex/skills/。推荐的做法是保留一份稳定的本地 clone，然后建一个 subagent wrapper 指向真实的 SKILL.md。

mkdir -p ~/ai-skills
cd ~/ai-skills
git clone https://github.com/Yuan1z0825/nature-skills.git

mkdir -p ~/.claude/agents
cat > ~/.claude/agents/nature-reviewer.md <<'EOF'
---
name: nature-reviewer
description: Use for Nature-style mock peer review, pre-submission assessment, and reviewer-side evaluation.
---

When invoked, first read `~/ai-skills/nature-skills/skills/nature-reviewer/SKILL.md` and follow it as the governing workflow.
Read supporting files from `~/ai-skills/nature-skills/skills/nature-reviewer/` and `~/ai-skills/nature-skills/skills/nature-shared/` only when needed.
Do not replace this skill with a generic review response.
EOF

然后在新会话里直接请求使用这个 subagent：

Use the nature-reviewer subagent to review this manuscript and give me three blind reviewer reports plus a synthesis.

这样做的好处是技能目录结构不被破坏，references/、manifest.yaml、脚本和资产都还能读到。

Cursor 的安装方式在仓库文档里另有说明（docs/open-source-agent-frameworks.md），本文没有核实到具体差异，不展开。

典型用法¶

技能接受的输入范围比较宽，可以是完整手稿、摘要或 cover-summary 式文本、引言/结果/讨论/方法的某一段、图注或选中的图件、中英文作者说明、投稿前的定位说明。材料不完整时做一次有边界的评审，并明确标出评估边界。

可以直接复制使用的请求（来自技能 README）：

• 像 Nature reviewer 一样审这篇 introduction 和 Figure 1。
• 投稿前帮我找最可能被审稿人攻击的技术问题。
• 给我三份 reviewer reports 和一个综合判断，不要写 rebuttal。

使用前最好同时提供：目标期刊、学科领域、你最担心的审稿风险，以及已有补充实验或「不能再加实验」的限制。这些会直接影响 emphasis brief 和审计的严格程度。

输出长什么样¶

固定输出骨架如下（字段名按 SKILL.md）：

Review setup
- **Input scope**
- **Assessment boundary**
- **Shared manuscript claim summary**
- **Visible evidence base**
- **Missing materials affecting confidence**

Reviewer 1 / Reviewer 2 / Reviewer 3
- **Overall assessment**
- **Who would be interested in the results, and why**
- **Major strengths**
- **Major Concerns**
- **Minor Comments**
- **Technical failings that need to be addressed before the case is established**
- **Assessment against Nature-style criteria**
- **Recommendation posture**

每条 Major Concern
- **Concern ID** 例如 R1-M1
- **Severity** Major
- **Blocking** Yes / No
- **Axis**
- **Claim pointer**
- **Evidence pointer**
- **Concern**
- **Why it matters**
- **Resolution test**

每条 Minor Comment
- **Concern ID** 例如 R1-m1
- **Severity** Minor
- **Axis**
- **Affected element**
- **Evidence pointer**
- **Issue**
- **Required correction**

Cross-review synthesis (post-review; not shown to reviewers)
- 共识的 Blocking 问题
- 其他 Major 问题
- Forensic consistency findings
- minor revision checklist
- 评审侧重点与判断上的真实分歧

其中 resolution test 这一项比较实用，它给出一个可验证的判据，用来判断某个问题到底解决了没有，而不是停留在「请补充分析」这种无法验收的表述上。

适用场景与限制¶

适合谁：准备投高影响力综合性期刊、需要在投稿前做一次结构化自审的作者；想按 Nature 审稿维度检查自己论证链的课题组；以及做科研 Agent 工作流、需要可追溯评审产出的开发者。

适合的场景是投稿前自审、模拟审稿、审稿人视角评估。不适合的场景是写返修回复，那应该转给 nature-response；如果你要的是润色和重建叙事，仓库里另有 nature-writing，统计层面的深入审查另有 nature-statistics。

几个实际使用上的限制，都是 SKILL.md 里写明的：

1. 输出质量取决于输入材料。只给摘要就只能做有边界的评审，缺材料会直接反映在 Assessment boundary 和 Missing materials affecting confidence 两栏。
2. 互盲依赖环境能力。如果 Agent 环境给不出独立上下文，就只能每次调用生成一位审稿人的报告，或声明互盲无法保证。这是最容易被忽略、也最容易悄悄失效的一条。
3. 综合只在冻结之后产生。不能先写一份综合再「分发给」审稿人，也不能因为某两位审稿人意见重复就去改写其中一位的报告，自然重复本身就是独立评审的证据。
4. 不会给编辑决定。技能明确禁止声称编辑最终会怎么判，也不能声称稿件符合 Nature。

结语¶

这个 Skill 的价值不在于它写出的评审意见有多漂亮，而在于它把一套容易走样的流程固定下来：互盲、冻结、审计、再综合。这几个顺序约束是它最实在的部分，也是普通「帮我审一下这篇稿子」提示词做不到的部分。

官方地址：https://api.skillhub.cn/org-eyw2ohcx/yuan1z0825-nature-skills-nature-reviewer
SkillHub 页面：https://www.skillhub.cn/skills/org-eyw2ohcx/yuan1z0825-nature-skills-nature-reviewer
源码：https://github.com/Yuan1z0825/nature-skills/tree/main/skills/nature-reviewer