nsfc-benzi-audit

NSFC 本子审查

基于提供的草稿，提出面向申请人的诊断意见和修改建议。指出实质性的逻辑断裂、薄弱证据和高影响修改点。不得编造文献、结果、项目经历、预算或官方要求。

此工作流用于提供申请修改建议。如果用户要求审查正式往来材料，应指出这是另一类工作，并且仅在有适用审查技能时使用。草稿内部诊断无需配套技能。

工作流

1. 选择来源并确定审查范围。

   • 优先使用用户明确指出的来源和修订版本。区分目标草稿、已获资助的示例、旧报告、模板和笔记。切勿仅因某份 Markdown 文件最大，或名为 full.md/output.md，就选用该草稿。
   • 只有在将提取文本的标题、修订版本和内容与选定的原文核对一致后，才能复用提取文本。记录来源路径、版本和提取信息。如有多个可能的草稿且无法区分，应询问用户要使用哪一份。
   • 对于 PDF/DOCX，使用可用的提取/OCR 工具，并保留标题和表格。如果无法提取，应说明限制，并基于可读的已提供材料开展工作；不得虚构工具或要求使用指定的配套技能。
   • 判断视觉逻辑或证据时，包括前期结果在内，都应查看原始图件。转换得到的 mermaid/OCR 内容并非权威依据。缺少提取内容是重大信息缺口，但不能据此认定申请人遗漏了相关内容。
   • 记录申请年份、项目类别的准确名称（已知时包括青年 A/B/C）、申请书版本/来源、资助方式（包干制/预算制/待确认）、研究属性、申请代码和来源完整性。将历史示例的年份与目标年份分开记录。
   • 无论问题、目标和方法出现在哪里，都应将其作为分析维度。仅当适用的申请书版本有要求时，才要求设置单独的标题。如果年份或版本未知，仍继续诊断内容，并将规则是否适用标记为未确定。
   • 快速审查重点关注标题、摘要、科学问题、研究内容、创新点和研究基础。完整诊断应覆盖所有已提供的部分。专项请求（某一章节、某一个问题）应严格限定在该范围内。不得将未提供的附件或摘录认定为原始申请中的确定缺陷。
   • 对于较长或多文件草稿，阅读时应记录章节/页码定位，并持续整理带位置的待核查问题清单；结束前只需回查尚未解决的问题，并报告无法阅读的来源范围。

2. 加载相关参考资料。

   • 诊断逻辑、提供写作建议以及使用每项发现所需的“信号 → 反向核查 → 评分”表时，始终阅读 references/benzi-logic.md。
   • 判断表格、年份/类别合规性、研究属性、应用代码、预算、伦理或诚信要求前，先阅读 references/current-rules.md。其中包含注明日期的 2026 年基线；请核实目标年份和阶段适用的规则。
   • 进行完整诊断，以及核查图表、验证、年度计划、成果、预算、文献或表格时，阅读 references/audit-surfaces.md。
   • 核查问题来源与提炼质量，或涉及原创、独辟蹊径、瓶颈、交叉、跨域类比等主张时，阅读 references/question-distillation.md。只有当草稿确实提出此类主张时，才适用其中的严格要求；并非每份草稿都必须设置相应标题。
   • 草稿列出了代表性成果或依赖发表成果时，阅读 references/representative-works.md。优先使用提供的 PDF，其次使用可用的 DOI、出版社或预印本查询工具。若已安装，可选用文献/引用查询技能进行集成。区分书目信息核验、摘要获取和完整方法核验；将尚未核实的证据标记为“未核实”。
   • 核查主题撞车、代码校准、成果对比或申请人要求的自我重叠检查时，阅读 references/kd-lookup.md。申请人负责在系统中查询；切勿自动执行登录或验证码操作。进行撞车检查时，先运行 scripts/nsfc_ack_grants.py，根据论文致谢筛选进行中的批准号。在声称覆盖范围前，记录模块、查询内容、年份字段、日期、错误/零命中状态和数量。
   • 使用已获资助/成功案例，或参考样本申请书进行改进时，阅读 references/exemplar-learning.md。使用背景匹配的匿名化模式，并说明可迁移性的局限；不要将事实或有辨识度的措辞复制到目标申请中。
   • 涉及信息科学、通信、网络、应用 AI、安全、量子通信或相关信息工程时，阅读 references/information-communication.md。
   • 涉及遥感、GIS、SAR/InSAR、光学/高光谱影像、DEM/地形、点云、空间数据库/图、轨迹、视频 GIS 或城市 3D 模型时，阅读 references/geospatial-remote-sensing.md。
   • 涉及医学、队列/标本、疾病机制、细胞/动物/类器官模型、生物标志物、干预、伦理或生物安全时，阅读 references/medical-biomedical.md。
   • 除非用户要求其他格式，否则将 assets/report-template.md 用作可调整的报告框架。

3. 构建逻辑图谱和证据图谱。

   • 提取研究对象/场景、问题/目标、方法/路径、创新点、验证方式和预期意义；并在标题、摘要、立项依据、研究内容、研究目标、科学问题、技术路线和研究基础中追踪这些要素。
   • 在相关情况下，纳入实际的研究属性和历史上的科学问题表述，避免混用不同版本的表格。
   • 构建多对多的“问题—内容—目标—验证”映射。报告未覆盖的问题或缺乏明确科学作用的任务，不要要求各项数量相等。支撑性方法和验证任务可以共同服务于同一个问题。
   • 区分科学问题的来源（文献、理论、观察、自身工作、需求）与申请人研究该问题的能力。以符合领域特点的方式评估个人贡献、可用资源和前期证据；不设普遍适用的第一作者 SCI 或预实验门槛。

4. 如果文件或聊天中提供了先前的评审意见／清单，请重新核查之前的发现。

   • 首先确认其对应的是同一份申请材料。对照新文本及适用的证据／规则，逐项检查之前的每个必改项，然后按常规方式诊断当前稿件。保留旧 ID；新问题使用未占用的 ID，并交叉注明合并或拆分的条目。
   • 使用“已解决 / 部分落实 / 仍存在 / 改动无效 / 原意见撤销或不再适用 / 材料不足无法判断”。说明撤销意见、范围变化及证据不完整之处。不要悄然删除旧条目，也不要仅因先前报告提出过某项发现就保留错误的发现。

5. 按影响程度诊断，并给出具体措施。

   • 评估创新性、技术路线、申请人贡献和资源条件。这些是诊断维度，不是固定的评分权重或资助预测。
   • 积极使用参考标记：它们记录了评审反复扣分的问题（标题／摘要偏离、立项依据未形成逻辑闭环、把研究内容写成研究目的、把研究问题写成任务、空洞地宣称“首次”／“填补空白”、修饰语沦为装饰、主题悄然转换、瓶颈缺乏量化、类比未转化为实质内容）。将每个命中项视为候选问题，按 benzi-logic.md 中的反向核查步骤检查，然后评定为必改 / 待核实 / 建议改 / 可润色。
   • 必改：关键问题未获回答、核心创新缺乏支撑、内容覆盖存在缺口、关键步骤不可行、标题／摘要承诺了正文未落实的内容，或经核实违反材料规定。建议改：评审可能注意到的章节层面写作或证据不足。可润色：措辞和呈现方面的偏好。仅凭条目数量、标题样式或图表数量，绝不应判为必改。
   • 每个根本问题分配一个稳定 ID，并提供一段完整说明；章节备注引用该 ID。对每项发现，注明位置／短语，解释其后果，并给出最小可行的修改措施。区分已核实的官方要求、逻辑／证据风险和呈现建议。不要为凑数而添加发现；稿件可以没有必改项。
   • 提供以事实为条件、包含占位符的修改框架，不得虚构结果或直接代写申请主张。拟议表述须标注为“请申请人核实”。

6. 撰写报告并保留证据链。

   • 默认文件名：本子诊断报告.md，保存在选定稿件所在目录；否则在聊天中作答。替换已有报告前，先以唯一的日期／修订版文件名保存原报告，并记录对照了哪份先前报告。
   • 报告包括：诊断范围、总体评估、一页逻辑图、按优先级排列的问题清单；适用时，还须包括先前条目复核，以及必改项的改写框架。全面诊断时，附简要对应表（仅列存在缺口的行）及实际涉及各方面的一句话状态。所有说明均放在问题清单中；其他各节均只给出一句结论，且每个 ID 在问题清单之外最多出现一次。仅在用户要求时提供逐章备注。若用户要求简短答复（一段话、一章内容或聊天消息），则按要求控制篇幅；评审深度与报告长度是两项独立选择。
   • 仅在相关时填写可选部分。对每个方面分别记录“已核查 / 部分核查 / 未核查 / 不适用”，并注明证据范围、来源和日期。根据实际工作生成局限性说明，不要照搬笼统免责声明。
   • 除非另有要求，使用简体中文。建议应面向申请人，仅引用简短的依据，并区分必改项与可润色项。