NSFC 标书专家评审模拟器

重要声明（非官方）

• 本技能输出仅用于写作改进与自查，不代表任何官方评审口径，也不构成资助结论或承诺。
• “评审等级/资助建议”仅作为优先级与改进方向的参考；用户如未明确要求，可不输出该部分。

技能依赖

• 并行多组评审模式依赖 parallel-vibe 技能。
• 若 parallel-vibe 不可用、被禁用，或 panel_count == 1，自动退化为单组模式（仍包含 5 位专家）。
• 专家 prompt 模板位于 references/expert_*.md，聚合规则位于 references/aggregation_rules.md。

安全与隐私（硬规则）

• 默认将标书内容视为敏感信息：仅处理用户明确提供的文件/目录；不擅自扩展扫描范围。
• 除非用户明确要求且确认风险：不联网、不把原文大段外发、不在输出中复述不必要的个人信息/单位信息。
• 只做“文本读取与评审”，默认不执行任何编译/运行（例如不运行 LaTeX 编译，不执行脚本）。
• 输出若需分享：优先提供“问题摘要 + 可执行修改建议”，必要引用原文时只引用最短必要片段。

输入

用户至少提供其一：

• proposal_path：标书目录（推荐，包含多份 .tex）
• proposal_file：单个 .tex 主文件（如用户只有一个文件）
• proposal_zip：压缩包（若用户提供，先解压到临时目录再评审，并在报告中记录解压位置）
  • 解压安全：禁止路径穿越（如 ../）；避免覆盖用户已有文件；必要时先让用户确认解压位置。

可选补充（用户未给时不要强行假设）：

• focus：优先关注某一维度（如“创新性/可行性/研究基础”）
• output_path：输出文件路径（默认见“输出”）
• style：口吻偏好（如“严格/温和/非常具体”）
• panel_count：评审组数量（每组固定 5 位专家）
  • 默认值见 config.yaml:parallel_review.default_panel_count
  • 上限见 config.yaml:parallel_review.max_panel_count

输出

• 默认输出文件名见 config.yaml:output_settings.default_filename，默认写入标书目录下：./{default_filename}。
• 若用户指定 output_path，以用户为准；但当路径不可写/目录不存在时应 fail-fast 并提示用户更换路径。
• 并行模式下输出“专家共识 + 独立观点 + 汇总建议”；可按配置附带每位专家原始意见。
• 并行模式下建议将各组原始评审整理为最终交付文件：./{panel_dir}/G{组号}.md（panel_dir 见 config.yaml:output_settings.panel_dir）。
• 中间过程文件默认隐藏到 config.yaml:output_settings.intermediate_dir（默认 .nsfc-reviewers/），避免根目录出现大量计划/日志/并行运行环境。

工作流（执行规范）

读取配置（强制）

开始前先读取本技能目录下的 config.yaml，并将以下配置作为执行时的单一真相来源：

• review_dimensions：评审维度、权重、要点与常见问题（作为检查清单）
• severity_levels：P0/P1/P2 分级口径（用于分级）
• review_grades：等级与建议（仅在用户需要时输出）
• proposal_files.patterns/exclude：标书文件识别规则
• output_settings：输出文件名、面板目录、中间过程隐藏策略与章节开关
• parallel_review：并行评审开关、专家画像、聚合策略

阶段一：前置检查（Fail Fast）

1. 校验输入路径存在且可读；若是目录，先按 proposal_files 规则筛选出待读文件列表。
2. 若 .tex 文件数量为 0：直接报错并请求用户提供正确路径/文件。
3. 若文件数量异常多/目录明显包含大量无关文件：先请用户确认评审范围（避免读错目录/读太多）。

推荐的确定性做法（避免“漏扫子目录 / 误扫中间目录 / 扫到交付产物”）：

# 列出将被纳入评审的 .tex 文件（递归扫描，并自动跳过 panels/、.nsfc-reviewers/、.parallel_vibe/）
python3 <nsfc_reviewers_path>/scripts/list_proposal_files.py --proposal-path <proposal_root>

# 可选：限制最大文件数（超限退出码=3）
python3 <nsfc_reviewers_path>/scripts/list_proposal_files.py --proposal-path <proposal_root> --max-files 200

阶段二：通读与结构化理解

1. 按章节顺序快速通读，提取“项目主题/科学问题/假说/目标/技术路线/创新点/研究基础/团队与条件/预期成果”。
2. 生成“标书结构索引”（只需到章节级别），作为后续引用的定位锚点。

阶段三：并行多组评审（优先）或单组模式（退化）

前置判断

1. 计算 effective_panel_count：优先用户输入 panel_count，否则使用 parallel_review.default_panel_count。
2. 将 effective_panel_count 限制在 [1, parallel_review.max_panel_count]。
3. 若任一条件成立，直接走单组模式：
   • parallel_review.enabled == false
   • effective_panel_count == 1
   • 找不到 parallel-vibe 脚本

parallel-vibe 脚本路径发现顺序

按顺序查找以下路径，命中即使用：

1. ~/.claude/skills/parallel-vibe/scripts/parallel_vibe.py
2. ~/.codex/skills/parallel-vibe/scripts/parallel_vibe.py
3. <当前仓库>/parallel-vibe/scripts/parallel_vibe.py

若全部不存在：记录警告并退化为串行模式，不中断整体评审。

并行模式步骤

0. 准备中间目录结构（强烈建议）：

mkdir -p <proposal_root>/<intermediate_dir>/{logs/plans,snapshot}

• 其中 <intermediate_dir> 对应 config.yaml:output_settings.intermediate_dir（默认 .nsfc-reviewers）。

1. 构造 Master Prompt（由宿主 AI 完成）：
   • 从 references/expert_*.md 读取 5 位专家画像（对应 config.yaml:parallel_review.reviewer_personas[*].prompt_file）
   • 从 references/master_prompt_template.md 读取 master prompt 模板
   • 注入上下文：阶段二产出的“标书结构索引 + 关键信息摘要”
   • 注入统一质量门槛：问题分级、证据锚点、输出格式
   • 注入独立性约束：每位专家只做独立判断，不假设其他专家意见
   • 注入输出约束：将评审组输出写入当前 thread 的 workspace/ 根目录下的 config.yaml:parallel_review.panel_output_filename
   • 替换模板占位符：将 {panel_output_filename} 替换为 config.yaml:parallel_review.panel_output_filename
   • 将 master prompt 落盘到一个临时文件（推荐放在 <proposal_root>/<intermediate_dir>/logs/ 下，便于追溯且不污染根目录），记为 <master_prompt_path>
2. 生成 parallel-vibe 计划文件（强制）：
   • 原因：避免在 CLI 里转义超长 prompt；并避免 parallel-vibe --prompt 的自动拆分逻辑（本技能需要“同一 master prompt 在 N 个独立工作区重复执行”）。
   • 优先使用本技能自带脚本生成计划文件：

python3 <nsfc_reviewers_path>/scripts/build_parallel_vibe_plan.py \
  --panel-count <effective_panel_count> \
  --master-prompt-file <master_prompt_path> \
  --out <plan_json_path>

• 若无法使用脚本，则手工生成 plan.json（最小结构）：

{
  "plan_version": 1,
  "prompt": "nsfc-reviewers parallel panels",
  "threads": [
    {
      "thread_id": "001",
      "title": "Panel G001",
      "runner": { "type": "<config:parallel_review.runner>", "profile": "<config:parallel_review.runner_profile>", "model": "", "args": [] },
      "prompt": "<master_prompt>"
    }
  ],
  "synthesis": { "enabled": false }
}

3. 调用 parallel-vibe（基于 plan-file）：

• 推荐先在 <proposal_root>/<intermediate_dir>/snapshot/ 下准备一份标书快照（如 proposal_snapshot/），并将其作为 --src-dir，以避免把 .nsfc-reviewers/、panels/ 等中间/交付目录再次复制进各 thread 的 workspace/。
• 最小做法：将“待评审标书目录”复制到 snapshot/ 下，并排除中间/交付目录（具体命令依平台工具而定；原则是：快照目录应只包含标书源文件）。

python3 <parallel_vibe_path> \
  --plan-file <plan_json_path> \
  --src-dir <proposal_snapshot_root_or_proposal_root> \
  --out-dir <proposal_root>/<intermediate_dir> \
  --timeout-seconds <config:parallel_review.timeout_seconds> \
  --no-synthesize

4. 收集并校验各组输出：
   • 从每个 thread 的 workspace/ 中读取 panel_output_filename
   • 典型路径（运行结束但尚未整理输出时）：<proposal_root>/<intermediate_dir>/.parallel_vibe/<project_id>/<thread_id>/workspace/<panel_output_filename>
   • 若你已执行“阶段五：输出整理”，则 parallel-vibe 环境通常位于：<proposal_root>/<intermediate_dir>/parallel-vibe/<project_id>/...
   • parallel-vibe 会在 stdout 打印本次 project_root 路径；优先以该路径为准
   • 若个别 thread 缺失输出，记录缺失并继续聚合已完成结果（fail-soft）
   • 建议将每组最终评审报告复制/整理为最终交付文件：<proposal_root>/{panel_dir}/G{thread_id}.md

单组模式步骤（退化）

1. 读取 references/expert_*.md 获取 5 位专家画像（创新/方法/基础/严格/建设性）
2. 模拟并行流程：让 5 位专家依次完成“独立评审”（不得相互参考）
3. 执行组内聚合（共识识别/严重度升级/去重合并）
4. 输出单组评审组报告到 panel_output_filename

阶段四：聚合、排序与可选结论

跨组聚合（并行多组模式）

1. 从 references/aggregation_rules.md 读取跨组聚合规则。
2. 交叉比对 N 组 panel_review.md，识别同一问题的不同表述。
3. 跨组共识门槛：至少 ceil(N * consensus_threshold) 组指出 → 跨组共识（阈值见 config.yaml:parallel_review.aggregation.consensus_threshold）。
4. 严重度二次升级：跨组共识问题 P2→P1→P0（P0 不再升级）。
5. 合并重复问题，保留最完整的证据锚点与可执行建议。
6. 独立观点保留并标注来源组（如“来自组 G001”）。
7. 结果按 P0→P1→P2 输出，并给出最小可行修改序列。
8. 若 keep_individual_reviews == true，附录保留各组原始评审报告。

单组汇总

输出“修改建议汇总”，按 P0→P1→P2 排序，并给出最小可行修改序列。

可选综合结论

仅当用户明确要求时，输出“综合评分/资助建议”（并重申其为改进参考）。

阶段五：输出整理（强制执行）

重要性：本阶段是确保输出可追溯的关键步骤，不可跳过。当 config.yaml:output_settings.enforce_output_finalization == true 时，你不得在未完成本阶段的情况下结束评审。

目标：最终交付清晰可见；中间过程统一托管到 config.yaml:output_settings.intermediate_dir（默认 .nsfc-reviewers/），避免根目录出现计划/日志/并行环境等杂项。

前置检查（按顺序执行）

1. 计算并确认 effective_panel_count（见阶段三）。
2. 判断本次评审模式：
   • 若 effective_panel_count > 1 且你实际调用了 parallel-vibe（或发现 .parallel_vibe/ 运行环境）→ 视为“并行模式”
   • 否则 → “串行模式”（仍必须创建最小中间目录与日志）

推荐做法：使用脚本自动化输出整理（确定性，强烈推荐）

python3 <nsfc_reviewers_path>/scripts/finalize_output.py \
  --review-path <proposal_root> \
  --panel-count <effective_panel_count> \
  --intermediate-dir <config:output_settings.intermediate_dir> \
  --apply

不加 --apply 为 DRY-RUN：只打印将执行的动作，不会改动文件。

手动整理（脚本不可用时的 fallback）

并行/串行都必须至少创建最小目录结构：

mkdir -p <proposal_root>/<intermediate_dir>/{parallel-vibe,logs/plans,snapshot}

并行模式：将 .parallel_vibe/ 的 项目目录迁移到 <intermediate_dir>/parallel-vibe/（兼容两种来源位置）：

# 1) 优先从 <proposal_root>/<intermediate_dir>/.parallel_vibe/ 迁移（parallel-vibe --out-dir 指向 intermediate_dir 时常见）
if [ -d "<proposal_root>/<intermediate_dir>/.parallel_vibe" ]; then
  mv "<proposal_root>/<intermediate_dir>/.parallel_vibe/"* "<proposal_root>/<intermediate_dir>/parallel-vibe/" 2>/dev/null || true
  rmdir "<proposal_root>/<intermediate_dir>/.parallel_vibe" 2>/dev/null || true
fi

# 2) 兼容旧实例：从根目录 .parallel_vibe/ 迁移
if [ -d "<proposal_root>/.parallel_vibe" ]; then
  mv "<proposal_root>/.parallel_vibe/"* "<proposal_root>/<intermediate_dir>/parallel-vibe/" 2>/dev/null || true
  rmdir "<proposal_root>/.parallel_vibe" 2>/dev/null || true
fi

迁移日志与计划文件（仅在存在时执行）：

mv "<proposal_root>/master_prompt.txt" "<proposal_root>/<intermediate_dir>/logs/" 2>/dev/null || true
mv "<proposal_root>"/plan*.json "<proposal_root>/<intermediate_dir>/logs/plans/" 2>/dev/null || true
mv "<proposal_root>/proposal_snapshot" "<proposal_root>/<intermediate_dir>/snapshot/" 2>/dev/null || true

验证清单（执行后自检，未通过不得结束）

• <proposal_root>/<intermediate_dir>/ 已创建，且至少包含 logs/ 与 logs/plans/
• 若为并行模式：<proposal_root>/<intermediate_dir>/parallel-vibe/ 下可看到 <project_id>/... 运行环境
• master_prompt.txt（或其副本）可在 <proposal_root>/<intermediate_dir>/logs/ 中找到
• 最终交付仍位于根目录：{default_filename} 与 {panel_dir}/G*.md（无关中间文件不应散落在根目录）

报告格式（硬门槛）

对每条 P0/P1 问题，必须包含至少一个“证据锚点”：

• 证据锚点：文件名 + 章节标题/关键句（可选行号）
• 现象：为什么这是问题（不要空泛）
• 影响：会如何影响评审判断/可行性/说服力
• 建议：可执行的修改方案（优先给“怎么改”和“改到什么程度算够”）
• 验证：改完如何自检（例如“补一张路线图”“补一段对照坐标系”“补一条预实验证据链”）

并行模式建议结构：

# 国自然标书评审意见（N 组独立专家）

## 评审配置
- 评审组数：N 组
- 每组专家：5 位
- 总专家人次：N×5 人次

## 跨组共识（多组一致指出）
### P0 级

## 独立观点（单一组提出）
### 来自 组 G001

## 修改建议汇总

## 附录：各组原始评审报告（可选）

使用示例

用户输入：

请评审 /path/to/nsfc_proposal 这个国自然标书，并把意见保存到 /path/to/output.md

配置参数

详见 config.yaml：

• review_dimensions：评审维度配置（权重/要点/常见问题）
• severity_levels：问题严重程度定义
• review_grades：评审等级与建议（可选输出）
• proposal_files：标书文件识别规则
• output_settings：输出设置（默认文件名/面板目录/中间目录/章节开关；以及输出整理校验：enforce_output_finalization / warn_missing_intermediate / validation_level）
• parallel_review：并行多组评审配置（开关/组数/专家画像引用/跨组聚合策略）