# Nsfc Length Aligner

> Nsfc Length Aligner

- Skill: `huangwb8/nsfc-length-aligner` (Agent Skill, multi-file: 13 files)
- Install (CLI): `npx skillmds@latest add huangwb8/nsfc-length-aligner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/huangwb8/nsfc-length-aligner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: huangwb8 (https://skillmd.com/u/huangwb8)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/huangwb8/nsfc-length-aligner

---

# nsfc-length-aligner

### 适用场景

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

### 不适用场景

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

## 流程

### 输入

按用户请求和配置文件提供必要输入；缺失信息应明确列出并停止依赖该输入的步骤。

### 执行步骤

- 当用户环境中出现因本 skill 设计缺陷导致的 bug 时，优先使用 `bensz-collect-bugs` 按规范记录到 `~/.bensz-skills/bugs/`，严禁直接修改用户本地 Claude Code / Codex 中已安装的 skill 源码。
- 若 AI 仍可通过 workaround 继续完成用户任务，应先记录 bug，再继续完成当前任务。
- 当用户明确要求“report bensz skills bugs”等公开上报动作时，调用本地 `gh` 与 `bensz-collect-bugs`，仅上传新增 bug 到 `huangwb8/bensz-bugs`；不要 pull / clone 整个 bug 仓库。


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

### 锁定隐藏工作区（先做）

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

### 需求确认（预算口径）

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

- 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 调研建议）**。你应按当年指南/模板校对后再使用。

### 运行篇幅检查（确定性）

对目标标书目录（或单文件）运行检查脚本，生成报告：

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

如需显式声明输出目录，请使用：

```bash
python3 scripts/check_length.py --input <目标标书路径> --config config.yaml --out-dir .bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner
```

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

如果你已编译出最终 PDF（推荐；页数是硬约束），把 PDF 一并传入做页数统计：

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

输出：
- 控制台摘要（总篇幅、超/欠预算项）
- `<input>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner/length_report.md`（默认输出目录；可用 `--out-dir` 自定义）
- `<input>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner/length_report.json`（默认输出目录；可用 `--out-dir` 自定义）

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

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

### 解读差距（差在什么地方）

基于报告做 3 件事：

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

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

参考：`references/MEANING_PRESERVING_REWRITE_RUBRIC.md`

### 扩写/压缩（尽量不改变原意）

#### 扩写策略（偏短时）

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

#### 压缩策略（偏长时）

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

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

用法（把“静态建议”变成“按差距触发”）：
- 先看报告里对应文件的偏差 `delta`：`+N` 表示超长（优先“该瘦”）；`-N` 表示偏短（优先“该厚”）；`OK` 表示该部分无需为了预算而改动
- `delta` 的绝对值越大，越优先处理；处理顺序建议：先改 `|delta|` 最大的文件，再做次大项

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

研究内容（做什么/怎么做）：
- 该瘦：重复表述、过细操作细节、罗列式方法堆砌
- 该厚：逻辑框架、关键实验设计与对照/消融、预期结果与可验证指标、用图说话

研究基础（为什么你能做）：
- 该瘦：无关成果堆砌、过度铺垫背景
- 该厚：强相关预实验数据、核心技术能力、平台条件（与研究内容对位）

### 复检闭环

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

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

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

### 输出

- 报告以“文件级 +（可选）章节级”呈现
- 预算以 `config.yaml:length_standard` 为唯一真相来源
- 中间文件统一托管到 `config.yaml:output_settings.intermediate_dir`（默认 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-length-aligner`）
- 所有改写应遵循“最小改动、保持原意”的准则（见 references）

### 输出管理

本 Skill 的新任务中间文件统一写入 `./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/`。同一任务复用一个任务根目录；多 Skill 协作才创建 `shared/`。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。

### 校验

完成后执行 Skill 已有的静态检查、脚本验证或人工复核，并记录通过标准。

### 失败与恢复

保留错误证据和已完成产物；仅在输入、环境或外部依赖恢复后从最近的失败步骤重试。

## 约束

遵守以下公共约束，并执行本 Skill 的专属边界。

### 公共硬约束

- 任务需要落盘时，使用唯一的 `./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/` 根目录；共享材料放入 `shared/`，Skill 专属材料放入该 Skill 的 `input/`、`output/`、`log/`。
- 正式交付物、源代码和正式计划按项目约定保存，不写入任务工作区；未经授权不覆盖、删除、迁移或远程写入。
- 项目维护变更检查 BAC 可用性并记录需求、AI 产出、工具结果、文件改动和验证摘要；BAC 只做过程审计，不替代署名、责任或合规判断。
- 不记录 API Key、访问令牌、密码、Cookie、环境/凭据文件、私有 Prompt、身份信息、本地用户名、主机名或不必要的大体积原始数据。
- 文件路径必须规范化并限制在授权项目范围内；外部 URL、子进程和网络访问遵循最小权限，防止路径遍历、SSRF 和命令注入。
- Skill 版本唯一记录在自身 `config.yaml:skill_info.version`；公开 API、协议、目录或配置变更同步文档与 `CHANGELOG.md`。
- 仅将 Skill 或 Bensz 基础设施本身的设计缺陷交给 `bensz-collect-bugs`；先脱敏写入 `~/.bensz-skills/bugs/`，当前任务不中断，只有用户明确要求才公开上报，禁止直接修改用户已安装的 Skill 源码。
<!-- End of canonical common constraints. -->

### Skill 专属约束

不得超出本 Skill description 和上方流程所声明的范围；不将未验证的信息伪装成确定结论。