nsfc-length-aligner

SKILL.md

nsfc-length-aligner

目标:把“篇幅”从主观感觉变成可量化、可闭环的指标,并围绕预算(budget)指导扩写/压缩。

适用场景

  • 你有一份国自然标书,想快速判断是否“某些部分偏短/偏长”
  • 你需要按模板的硬性篇幅要求(页数/字数/字符数)对齐
  • 你希望尽量不改变原意地扩写或压缩(保持论证主线与证据链)

不适用场景

  • 仅需要“统计字数”而不关心预算与改写闭环(可用更简单的脚本即可)
  • 标书不在本地(无法提供文本/文件/路径)

工作流(强烈建议按顺序执行)

0) 锁定隐藏工作区(先做)

  • 以标书工作目录为根,统一使用 <workdir>/.nsfc-length-aligner/ 托管所有中间文件与报告
  • 不要把 length_report.*、临时分析稿、计划文件写到工作目录根层或仓库其他位置
  • 若显式传入 --out-dir,优先使用相对路径 .nsfc-length-aligner;脚本会将相对 --out-dir 解析到 --input 对应的工作目录,而不是 shell 当前目录
  • 若工作目录本身不可写,应先切换到可写副本后再运行;不要为了省事把中间文件散落到项目外部

1) 需求确认(预算口径)

先确认你要对齐的“硬标准”是什么:

  • 2026 调研共识的“黄金比例”(面上/青基 C 类,供校对用):立项依据 30%(6–10 页,约 8000–10000 字)/ 研究内容 50%(12–15 页,约 12000–15000 字)/ 研究基础 20%(5–8 页,约 5000–6000 字);合计建议 ≤28 页留缓冲(原则上不超过 30 页)
  • 页数(硬约束):2026+ 改版后“原则上不超过 30 页”,实操建议 ≤28 页留缓冲;不要通过缩小字体/行距“挤页数”
  • 字符预算(代理指标):中文字符 / 总字符等,用于“改写→复检”的确定性闭环(页数最终以 PDF 复核)
  • 预算范围:总篇幅 + 各部分/关键章节预算(至少覆盖:立项依据/研究内容/研究基础)

说明:本 skill 默认使用 config.yaml:length_standard示例口径(已对齐 2026 调研建议)。你应按当年指南/模板校对后再使用。

2) 运行篇幅检查(确定性)

对目标标书目录(或单文件)运行检查脚本,生成报告:

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml

如需显式声明输出目录,请使用:

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml --out-dir .nsfc-length-aligner

如果你的标书基于 NSFC_Young / NSFC_General 模板(项目根目录包含 main.tex),建议把 --input 指向项目根目录:脚本会自动沿 main.tex\input/\include 依赖树收集“实际会编译进 PDF 的文件”,并忽略被注释掉的 \input{...}(避免把可选章节误计入篇幅)。

如果你已编译出最终 PDF(推荐;页数是硬约束),把 PDF 一并传入做页数统计:

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml --pdf <标书.pdf>

输出:

  • 控制台摘要(总篇幅、超/欠预算项)
  • <input>/.nsfc-length-aligner/length_report.md(默认输出目录;可用 --out-dir 自定义)
  • <input>/.nsfc-length-aligner/length_report.json(默认输出目录;可用 --out-dir 自定义)

注意:--out-dir 若使用相对路径,会被解析到 <input> 对应的工作目录下;这能避免从其他目录启动命令时把报告误写到 shell 当前目录。

运行完成后,必须读取 length_report.md(必要时辅助读取 length_report.json),将“文件级偏差表 +(可选)章节级统计”作为步骤 3 的输入。

3) 解读差距(差在什么地方)

基于报告做 3 件事:

  1. 定位“超长/偏短”的文件或章节
  2. 判断差距属于:
    • 证据链不足(需要补数据/对照/局限)
    • 逻辑跳跃(需要补过渡/定义/假设)
    • 冗余重复(需要合并/删减)
  3. 生成行动清单(扩写/压缩的优先级)

章节级数据用法(更精准定位):

  • length_report.md 出现章节表格(或 JSON 中存在 sections 字段),优先在“超长/偏短”的文件内,定位到贡献最大的具体章节,再做定点改写,而不是只在文件级做平均删改
  • 当某个文件超长/偏短时:对比其章节统计,若差距主要集中在 1–2 个章节,优先只改这 1–2 节(更容易保持原意与结构稳定)

参考:references/MEANING_PRESERVING_REWRITE_RUBRIC.md

4) 扩写/压缩(尽量不改变原意)

扩写策略(偏短时)

  • 先补“可验证信息密度”:定义、假设、对照、消融、风险与备选方案
  • 再补“论证闭环”:为什么做 → 怎么做 → 预期怎么验证 → 失败怎么办
  • 避免空泛扩写:不引入新主张、不堆形容词

压缩策略(偏长时)

  • 去重复:同一论点只保留一次最强表达
  • 去背景:把泛背景压成 1-2 句,把篇幅留给“问题-方法-验证”
  • 结构化改写:把长段拆成要点(不改变事实顺序)

⚠️ 改写完成后,必须执行步骤 5 复检,确认偏差已消除。未复检视为未完成。

2026 三部分“该瘦/该厚”清单(用于排优先级)

用法(把“静态建议”变成“按差距触发”):

  • 先看报告里对应文件的偏差 delta+N 表示超长(优先“该瘦”);-N 表示偏短(优先“该厚”);OK 表示该部分无需为了预算而改动
  • delta 的绝对值越大,越优先处理;处理顺序建议:先改 |delta| 最大的文件,再做次大项

立项依据(为什么做):

  • 该瘦:教科书式科普、泛化综述、弱相关“国家需求”铺陈、重复意义、文献凑数
  • 该厚:Gap(卡点)→ Key Idea(突破口)→ 价值论证(为什么值得做)

研究内容(做什么/怎么做):

  • 该瘦:重复表述、过细操作细节、罗列式方法堆砌
  • 该厚:逻辑框架、关键实验设计与对照/消融、预期结果与可验证指标、用图说话

研究基础(为什么你能做):

  • 该瘦:无关成果堆砌、过度铺垫背景
  • 该厚:强相关预实验数据、核心技术能力、平台条件(与研究内容对位)

5) 复检闭环

改完必须再次运行脚本,确认“达标且不超标”:

python3 scripts/check_length.py --input <目标标书路径> --config config.yaml

格式红线(2026+ 常见)

  • 不缩小字体、不缩小行距来“挤页数”(页数要求是评审风险点)
  • 不顶格写到 30 页:建议 ≤28 页留缓冲
  • 若当年指南要求声明生成式 AI 使用情况:务必按要求如实说明(合规项)

约定与输出格式

  • 报告以“文件级 +(可选)章节级”呈现
  • 预算以 config.yaml:length_standard 为唯一真相来源
  • 中间文件统一托管到 config.yaml:output_settings.intermediate_dir(默认 .nsfc-length-aligner
  • 所有改写应遵循“最小改动、保持原意”的准则(见 references)
Weekly Installs
35
GitHub Stars
1.2K
First Seen
Feb 23, 2026
Installed on
github-copilot32
codex32
kimi-cli32
gemini-cli32
cursor32
opencode32