NSFC Budget Justification Writer

NSFC 预算说明书生成器

先做适用性判断

• 如果用户没有指定工作目录：立即暂停，先让用户给出工作目录。
• 如果用户只是问“预算怎么写/有哪些原则”，直接回答或给建议，不启动本 skill。
• 如果用户是 2026 青年 A/B/C 且场景属于包干制：先明确提醒“通常无需预算说明书”；只有在用户明确说明是历史模板、特定单位要求或预算制场景时才继续。

必要输入

优先让用户按 skills/nsfc-budget/references/info_form.md 提供。最少要拿到：

• 工作目录（必需）
• 标书正文或其它材料
• 项目类型：general | local | youth
• 预算口径：至少说明“这是申请总额”还是“这是需要解释的直接费用口径”

若用户没给全，按下面规则处理：

• 总预算未给：按 config.yaml:defaults.total_budget_wan 取默认值。
• 正文目标字数未给：按 config.yaml:defaults.target_chars 推荐区间执行。
• 每节上限：按 config.yaml:defaults.per_section_max_chars。
• 模板未给：按 config.yaml:defaults.template_id。
• 预算模式合法值：见 config.yaml:rules.budget_modes。
• 预算口径合法值：见 config.yaml:rules.budget_scopes。

流程

输入

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

执行步骤

• 当用户环境中出现因本 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 仓库。

目标：基于标书正文与补充材料，写出一份“经得起财务与学术双重审视”的预算说明书，并交付可编辑 LaTeX 项目与 budget.pdf。

初始化 run

先创建隐藏工作区与 budget_spec.json 骨架：

python3 skills/nsfc-budget/scripts/init_budget_run.py \
  --workdir <workdir> \
  --project-type <general|local|youth> \
  --template-id 01

如用户已给材料路径，可追加多个 --material <path>。脚本会把材料快照复制到 .bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/{yyyy-mm-dd-hh-mm}/input/materials/。 若同一分钟重复初始化，脚本会自动追加后缀避让目录名冲突，避免 run 目录互相污染。

吃透材料，形成“任务-需求-金额-依据”链

读取正文与补充材料后，先在隐藏工作区内形成内部判断，再填写 budget_spec.json：

• 每一笔钱都必须能追溯到具体研究任务。
• 每一节都要说明为什么要花、花在哪里、怎么测算、为什么这个数合理。
• 不能捏造设备、合作单位、测试次数、出差频次、劳务人数、价格依据。
• 证据不足时，要么追问用户，要么保守写“暂不列支/暂无合作转拨/暂无其他来源资金”，不要编造。

写作原则见：skills/nsfc-budget/references/budget-writing-rules.md。

填写 budget_spec.json

脚本生成的 budget_spec.json 是唯一结构化中间稿。至少补齐：

• meta：项目题目、项目类型、预算模式、工作目录、输出目录、模板 ID、字数目标
• budget：总预算口径、直接费用总额（若已知）、设备/业务/劳务/合作转拨/其他来源金额
• sections：五个部分的正文段落（数组）
• evidence：关键测算依据、必要假设、待确认点

要求：

• 设备费 + 业务费 + 劳务费 = 直接费用总额（若你已明确直接费用口径）
• budget.*_wan 与 sections.*.amount_wan 必须保持一致，避免出现两份金额源漂移。
• 合作研究转拨资金 不能与前三项形成逻辑冲突
• 其他来源资金 必须写明来源与用途；若无，则显式写“无”
• 金额、字数上限、容差等数值不得为负数；不合法时优先修正 JSON，而不是带病渲染。

渲染、校验、迭代

用脚本把 JSON 渲染为 LaTeX 项目，并把校验报告与编译日志留在隐藏目录：

python3 skills/nsfc-budget/scripts/render_budget_project.py \
  --spec <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/{yyyy-mm-dd-hh-mm}/budget_spec.json

脚本会：

• 复制模板到 <workdir>/<output_dirname>/
• 将五个 section 写入对应 extraTex/*.tex
• 校验金额关系、段落长度、可见字符数与模板/路径约束
• 校验 budget_spec.json 是否仍位于 <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/，保证隐藏工作区承诺不被破坏
• 自动转义常见 LaTeX 特殊字符（如 %、#、&、_），减少自然语言正文导致的编译失败
• 在隐藏目录保存 validation_report.md/json
• 若校验失败，终端会直接给出首批错误摘要与 validation_report.md 路径
• 编译输出 budget.pdf

如校验失败，先修 budget_spec.json 再重新运行脚本，直到通过。

交付前人工复核

交付前必须至少复核这些点：

• 预算口径是否说清楚：申请总额 vs 直接费用
• 设备/测试/差旅/劳务是否真的与研究任务一一对应
• 是否出现“写得很满但没有证据”的句子
• 是否存在“金额能对上，但逻辑对不上”的隐性漏洞
• 是否存在“应该写无，却被硬凑了一段”的编造痕迹

默认采用以下结构化策略：

• 总述从严：先交代预算遵循政策相符性、目标相关性、经济合理性。

• 逐项落地：每节至少讲清“用途 + 测算 + 必要性 + 依据”。

• 少说空话：不要写“为保证项目顺利开展”“具有重要意义”这类无信息量句子，除非后面紧跟具体任务与支出。

• 金额服务任务：说明书不是“财务散文”，每一段都要能回到研究方案。

• 宁缺毋滥：缺材料时，先保守、先追问、先明确边界；不要补脑。

• skills/nsfc-budget/references/info_form.md

• skills/nsfc-budget/references/budget-writing-rules.md

• skills/nsfc-budget/scripts/init_budget_run.py

• skills/nsfc-budget/scripts/render_budget_project.py

• skills/nsfc-budget/models/01/.template.yaml

输出

最终输出必须同时包含：

• <workdir>/<output_dirname>/：完整 LaTeX 项目
• <workdir>/<output_dirname>/budget.pdf

中间过程保留在：

• <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/{yyyy-mm-dd-hh-mm}/

输出管理

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

校验

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

失败与恢复

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

约束

• 所有中间文件只能放在 <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/。
• 不要把草稿、日志、计划、截图、临时 JSON、编译中间文件散落到工作目录其它位置。
• 最终可见交付物只放在 <workdir>/<output_dirname>/（默认值见 config.yaml:defaults.output_dirname）。
• template_id、output_dirname、.template.yaml 里的 section_files/latex_entry/pdf_name 都必须是相对安全路径；不得包含绝对路径、. / .. 越界段。
• output_dirname 不得指向工作目录根路径，也不得与隐藏工作区 <workdir>/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/nsfc-budget/ 重叠。

公共硬约束

• 任务需要落盘时，使用唯一的 ./.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 和上方流程所声明的范围；不将未验证的信息伪装成确定结论。