nsfc-justification-writer

# 科研立项依据写作器 ## BenszAPI 任务工作区 本 Skill 的新任务中间文件统一写入 `./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/`。同一任务复用一个任务根目录；多 Skill 协作才创建 `shared/`。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。 ## 与 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 仓库。 ## 任务边界 - 先理解用户指定的文件、段落和目标，再输出建议正文或 unified diff；默认 `preview`，不直接改文件。 - 只改用户明确授权的正文内容。保留现有标题、章节/环境命令、标签、引用命令和配置命令。 - 不修改 `main.tex`、配置文件、`.cls`、`.sty`，除非用户明确授权；目标路径不唯一时先询问或只读列出候选。 - 可使用项目配置声明目标文件，也可由用户显式提供路径；不要把某个固定文件名当成普遍规范。 - 引用 key 必须能在项目 `.bib` 中核验；不新增无法核验的引用、实验结果或绝对化结论。 ## 语义写作规则 1. 说明领域价值与现实/理论必要性，再梳理已有研究及其证据边界。 2. 将“瓶颈/局限”转译为待解释的未知关系、机制、性质或适用边界。 3. 科学问题用疑问句表达；科学假设用可证伪的陈述句表达。研究目标、技术路线和验证终点不要冒充科学问题或假设。 4. 假设之前以领域事实、已有研究和认知缺口为主；项目干预、比较、终点和技术路线集中放在假设之后。外部文献的方法学描述可以作为证据保留，不等于本项目方案前置。 5. “项目切入点/贡献”是可选的语义表达，不要求固定标题或固定段落数量；重点是前后逻辑能互相支撑。 6. 理论、混合、工程导向只影响措辞和证据重心，不作为结构通过/拒写条件。 7. 在逻辑和引用检查之后，必须执行 Tier2 宿主 AI 语义检查，由宿主 AI 自主规划术语、论证维度与专业可读性复核：定位长句层级过多、指代不清、缩写/新概念未界定、抽象名词堆叠、段内衔接缺失或不增加准确性的修饰。输出“位置/障碍/影响/保真改法”的表达建议；不把专业正文改成科普文，也不因术语密度或必要限定而强行改写。宿主 AI 不可用时必须明确标记 Tier2 未完成并转人工复核，不得默认为通过。 8. 可读性改写必须保留已核验事实、研究对象、必要限定、科学问题/假设、引用命令、标签和 LaTeX 结构；无法保真时只说明风险，不补写事实或证据。 措辞边界：吹牛式、绝对化或无依据夸大表述不由 Python 固定词表判定；宿主 AI 应按 `references/boastful_expression_g...