Agent Skills: NSFC 中英文摘要生成器

当用户明确要求"写/润色 NSFC 标书摘要""生成中文摘要和英文摘要""把中文摘要翻译成英文摘要"时使用。输出中文、英文两个版本(英文必须是中文的忠实翻译版),同时输出标题建议(1个推荐标题+5个候选标题及理由)。中文摘要默认≤400字符,英文摘要默认≤4000字符。输出方式:将结果写入工作目录下的 `NSFC-ABSTRACTS.md`。⚠️ 不适用:用户只想翻译一段与标书无关的通用文本(应直接翻译);用户只想写立项依据/研究内容/研究基础正文(应使用对应 nsfc 系列 skill)。

UncategorizedID: huangwb8/chineseresearchlatex/nsfc-abstract

Install this agent skill to your local

pnpm dlx add-skill https://github.com/huangwb8/ChineseResearchLaTeX/tree/HEAD/skills/nsfc-abstract

Skill Files

Browse the full folder contents for nsfc-abstract.

Download Skill

Loading file tree…

skills/nsfc-abstract/SKILL.md

Skill Metadata

Name
nsfc-abstract
Description
当用户明确要求"写/润色 NSFC 标书摘要""生成中文摘要和英文摘要""把中文摘要翻译成英文摘要"时使用。输出中文、英文两个版本(英文必须是中文的忠实翻译版),同时输出标题建议(1个推荐标题+5个候选标题及理由)。中文摘要默认≤400字符,英文摘要默认≤4000字符。输出方式:将结果写入工作目录下的 `NSFC-ABSTRACTS.md`。⚠️ 不适用:用户只想翻译一段与标书无关的通用文本(应直接翻译);用户只想写立项依据/研究内容/研究基础正文(应使用对应 nsfc 系列 skill)。

NSFC 中英文摘要生成器

输入(先要信息,缺啥就问啥)

优先让用户按信息表提供(见 skills/nsfc-abstract/references/info_form.md)。若用户只给了零散信息,先用 3-6 个问题补齐最关键缺口:

  • 你希望题目更偏“机制向 / 方法向 / 转化向 / 场景向”哪一类?(不确定可不选,默认给混合候选)
  • 研究对象/场景是什么?(疾病/材料/系统/任务)
  • 领域痛点与未解决的科学问题是什么?(一句话)
  • 你们的关键前期发现/预实验/数据点是什么?(1-2 条,可定量)
  • 拟验证的科学假说/核心判断是什么?(一句话)
  • 研究内容 3-4 点分别要做什么、用什么方法、得到什么可验证结果?
  • 预期科学意义/应用价值是什么?(避免空话)

流程

输入

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

执行步骤

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

目标:写出“评审一眼读懂”的五句式摘要,做到重要性、科学问题、可行性证据、研究内容、科学意义五个要素齐全;并输出与之一致的英文翻译。

篇幅比例原则:资深评审希望尽快看到申请人”进入正题”,背景铺垫过多是专业度不足的信号。各句目标占比如下(超出即压缩):

| 句子 | 功能 | 目标占比 | |------|------|---------| | ① 背景 | 入场券 | ≤ 15% | | ② 科学问题 | 定位缺口 | 15–20% | | ③ 前期研究 | 建立可信度 | 20–25% | | ④ 研究内容 | 主体 | 35–40% | | ⑤ 意义 | 闭环 | 10–15% |

  1. 重要性/背景(≤ 15%):严格 1 句,点明研究对象的重要性与核心瓶颈,不展开背景综述。
  2. 科学问题(15–20%):指出关键未知与当前不足(具体到机制/指标/因果链的缺口)。
  3. 可行性证据(前期研究)(20–25%):给出 1-2 条前期发现/预实验(尽量可定量),并顺势提出科学假说/核心判断。
  4. 研究内容(3-4 点)(35–40%):用动词开头,写清”做什么→怎么做→要验证什么/得到什么判据”(点数默认以 config.yaml:limits.content_points_min/max 为准);此句是摘要主体,应获得最多篇幅。
  5. 意义/价值(10–15%):总结预期贡献(科学机制 + 方法/策略/应用潜力),与第 2 句的问题形成闭环。

当用户明确要求“中文≤400字符/英文≤4000字符”等硬约束时,必须走闭环:先检测,再压缩,再检测,合格后再写入。

  1. 先生成一个“可读但可能超限”的初稿(五句式要素齐全)。
  2. 用确定性脚本检测(必须用 --json,让硬编码负责精确计数):
    • python3 skills/nsfc-abstract/scripts/validate_abstract.py - --json --diff --strict
    • 输入可通过 stdin(无需先写文件),或在写入 NSFC-ABSTRACTS.md 后对文件校验。
  3. 若超限:按“压缩优先级”执行压缩,再回到步骤 2,最多 3 轮。
  4. 连续 3 轮仍超限:停止自动压缩,向用户说明当前超限数(ZH/EN exceeded),并请用户选择:
    • 允许删减某些信息(哪些可删)
    • 放宽字数上限(修改 config.yaml)
    • 人工给出更短的关键信息摘要(例如只保留最关键 1 条证据 + 3 点研究内容)

压缩优先级(从上到下)

  • P0(必须保留):研究对象/关键科学问题缺口/定量证据(若有)/核心方法名称/预期贡献闭环
  • P1(优先精简):程度副词、形容词修饰、”我们将/本研究”主语、过程性描述、”通过/采用”等介词短语、并列重复表达
  • P2(优先删除):背景超出 15% 的部分(首先压缩)、空洞评价(无定量支撑的”显著/重要/领先”等)、重复句、与科学问题无关的背景扩展

如需确定性写入/校验,可使用脚本:

  • 写入:python3 skills/nsfc-abstract/scripts/write_abstracts_md.py <input> --strict
  • 校验:python3 skills/nsfc-abstract/scripts/validate_abstract.py NSFC-ABSTRACTS.md --json --diff --strict

输出

  • 必须同时给出中文与英文;英文是中文的忠实翻译(不扩写、不新增假设、不引入新结果)。
  • 中文摘要使用中文标点。
  • 引号硬约束(不可绕过):中文摘要中若需引号,唯一合法形式为中文弯引号 ” (U+201C)与 ” (U+201D)。以下形式一律禁止:ASCII 双引号 ”、全角引号 "、直角引号 「」 / 『』、单引号 ' / ',以及任何其他替代形式。
  • 中文摘要正文为纯文本:不得含有 Markdown 标记(**、*、_、# 等),用户会直接将正文 copy 到只支持纯文本的系统中。
  • 中文摘要数字不使用千分位逗号:写 1000,不要写 1,000 或 1,000。
  • 必须给出”主要研究领域”:放在英文摘要之后,一句话(汉字数 ≤ 25),精简表达核心研究方向,不得写成多条或列表。
  • 写入 NSFC-ABSTRACTS.md 时,中文摘要正文末尾与英文摘要分段标题之间不留空行。
  • 必须给出标题建议:遵循 skills/nsfc-abstract/references/title-rules.md 的”中标题目”结构偏好;至少包含:
    • 推荐标题:...(中文)
    • Recommended Title: ...(英文,紧跟推荐标题下一行)
    • 1) ... —— 理由:... / EN: ...(至少 5 条;数量以 config.yaml:title.title_candidates_default 为准;每条末尾附英文翻译)
  • 中文摘要:默认 ≤ 400 字符(含标点);推荐 5 句(以 config.yaml:limits.zh_recommended_sentences 为准),每句 1 个功能。
  • 英文摘要:≤ 4000 字符(含标点);语法正确、术语一致。
  • 不使用夸大/营销式表达(如“国际领先/填补空白/首创”),除非用户提供可核验依据且明确要求保留。
  • 不堆砌背景,不罗列方法学名词;每个方法名词必须服务于“要验证什么”。

按如下格式写入 NSFC-ABSTRACTS.md(标题文本以 config.yaml:output.zh_heading/en_heading 为准)。在末尾给出长度自检(字符数计数口径:把连续空白折叠为单个空格后计数,含标点):

# 标题建议
推荐标题:...
Recommended Title: ...
1) ... —— 理由:... / EN: ...
2) ... —— 理由:... / EN: ...
3) ... —— 理由:... / EN: ...
4) ... —— 理由:... / EN: ...
5) ... —— 理由:... / EN: ...

# 中文摘要
(正文)
# English Abstract
(translation)
# 主要研究领域
(一句话,≤ 25 个汉字)

### 输出管理

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

### 校验

- 中文摘要字符数:N/400
- 英文摘要字符数:M/4000

写入文件后,在对话中不要重复粘贴全文(除非用户明确要求),只需回报:

  • 写入的文件路径(默认 ./NSFC-ABSTRACTS.md)
  • 标题候选数量是否满足默认要求
  • 中文/英文字符数与是否超限

失败与恢复

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

约束

遵守以下公共约束,并执行本 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 和上方流程所声明的范围;不将未验证的信息伪装成确定结论。