nsfc-length-aligner

# nsfc-length-aligner ## 与 bensz-collect-bugs 的协作约定 - 当用户环境中出现因本 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）指导扩写/压缩。 ## 适用场景 - 你有一份国自然标书，想快速判断是否“某些部分偏短/偏长” - 你需要按模板的硬性篇幅要求（页数/字数/字符数）对齐 - 你希望尽量不改变原意地扩写���压缩（保持论证主线与证据链） ## 不适用场景 - 仅需要“统计字数”而不关心预算与改写闭环（可用更简单的脚本即可） - 标书不在本地（无法提供文本/文件/路径） ## 工作流（强烈建议按顺序执行） ### 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) 运行篇幅检查（确定性） 对目标标书目录（或单文件）运行检查脚本，生成报告： ```bash python3 scripts/check_length.py --input <目标标书路径> --config config.yaml...