| name | write-grant-proposal |
| description | Use when writing, revising, or reviewing Chinese grant proposals and technical application documents, including industry-university-research fund applications, NSFC-style proposals, enterprise challenge proposals, research contents, technical routes, innovation points, milestones, assessment indicators, expected deliverables, and scenario-specific technical narratives. |
写本子技能
适用：产学研基金申请书、自然科学基金申报书、企业揭榜方案、专项申报书、技术实施方案。
核心目标：把用户提供的申报指南、申请书模板、草稿、大纲和材料，转化为场景贴合、结构完整、指标可验收的正式申请书文本。写作时只使用从优秀申请书中抽象出的结构规律、论证规律和句法规律，不复用任何具体项目内容、项目名称、专有场景或原文表达。
强制执行流程
写本子必须按流程推进，不能拿到材料后直接写正文。每个本子的模板、章节顺序、字数限制、表格字段和评审关注点都可能不同，必须先解析模板，再决定写法。
- 读模板：提取章节结构、标题层级、填写要求、字数限制、表格字段、附件要求和不可改动内容。
- 读指南：提取研究方向、申报边界、考核指标、交付成果、时间周期、经费和限制条件。
- 定方法：根据模板和指南确定写作模式、技术主线、研究内容分解、方法命名规则和指标映射规则。
- 写大纲：先产出完整章节大纲，明确每一节写什么、对应哪个指南要求、需要哪些素材、是否有待补信息。
- 填内容：按冻结后的大纲逐节写作，先写骨架性章节，再写研究内容和技术路线，最后补指标、成果、进度和支撑条件。
- 全文自检：检查模板完整性、内容一致性、标题一致性、指标一致性、术语一致性、主语一致性、字数格式和脱敏安全。
- 修订收口：根据自检结果统一改标题、术语、方法名、指标、成果和交叉引用，形成可提交版本。
除非用户明确要求只写某一小节，否则每次承担完整本子写作或大段修订时，都要先给出“模板解析 + 方法体系 + 大纲”，再进入正文填充。
第0步：读取输入材料
在写任何内容之前，先读取用户提供的基础材料：
- 申报指南：提取课题方向编号、研究内容要求、考核指标、经费限制、软硬件限制、交付要求和格式约束。
- 申请书模板：确定各节标题名称、顺序、层级、字数限制和表格格式。不同模板节名可能不同，必须严格按模板来。
- 当前大纲或草稿：识别用户已有框架、技术主线、已有表述、缺口和冲突。
- 补充材料：读取用户提供的技术方案、团队基础、已有成果、数据来源、应用场景和验收条件。
材料读取原则：
- 先读申报指南和申请书模板，再读用户草稿，最后读补充材料。
- 模板和指南的章节名、指标、交付要求优先级最高；草稿内容必须服从指南和模板。
- 如用户提供了过往文本，只抽取其章节组织、标题命名、论证节奏、句法结构和指标组织方式，不迁移具体领域内容、项目名称、数据、机构信息或原文句子。
- 若材料不足以确定关键事实，不编造项目背景、指标阈值、团队成果或外部数据；用占位符标注待补信息。
模板解析必须输出：
- 章节清单：按模板原顺序列出一级、二级、三级标题。
- 填写要求：记录每节需要回答的问题、字数要求、表格字段和格式限制。
- 结构约束：标出不可删改的固定标题、必须保留的表格、附件或签章信息。
- 内容映射：标出每节对应指南中的哪个要求、哪个指标或哪个成果。
- 缺口清单：列出当前材料缺失的信息，避免后续正文凭空补写。
本步输出：课题核心要求摘要 + 模板章节结构表 + 指南要求映射表 + 现有草稿骨架 + 待补信息清单。
第0.5步：确定写作模式和方法体系
先判断本轮任务属于哪一类申请书，再选择章节重心和语气。然后根据指南与模板确定全文方法体系。不要把不同类型申请书的写法混在一起。
| 写作模式 | 适用场景 | 章节重心 | 语气要求 |
|---|
| 产学研/专项模式 | 高校产学研创新基金、专项申报、横向项目 | 需求分析、研究内容、技术路线、考核指标、预期成果 | 问题导向、工程可落地、指标可验收 |
| 自然科学基金/大项目模式 | 自然科学基金、联合基金、重点项目、重大项目 | 科学问题、研究目标、研究内容、关键技术、创新点、可行性 | 科学问题清楚、技术机制充分、创新性突出 |
| 企业揭榜/方案模式 | 揭榜挂帅、企业技术方案、平台申报 | 业务痛点、总体方案、实施路径、验收方法、交付物 | 场景强绑定、交付明确、风险可控 |
人称与主语规则：
- 概述、研究目标、创新点、预期成果等正式章节，可按模板使用"本项目""本课题""本研究"，但同一章节保持一致。
- 技术路线展开段可使用"我们"，用于增强方案推演感和执行感。
- 不要在同一段中频繁混用"本项目/本课题/本研究/我们/本文"。
方法体系必须先定后写：
- 总技术主线：用一句话说明全文围绕什么核心问题、采用什么总体路径、形成什么能力。
- 研究内容分解：确定研究内容的大项和子项数量，确保能覆盖指南要求。
- 方法命名规则：先统一方法名风格，避免正文中同一方法出现多个名称。
- 标题对应规则：确定哪些章节标题必须一一对应，例如研究内容标题与技术路线标题。
- 指标映射规则：确定每个研究内容对应哪些考核指标、预期成果和验证方法。
- 术语表：列出全文必须统一的关键术语、对象名称、系统名称、模型名称和成果名称。
本步输出：写作模式 + 章节重心 + 主语规则 + 总技术主线 + 研究内容分解表 + 方法命名表 + 指标映射表 + 术语表。
第0.8步：写大纲并冻结结构
正文填充前必须先写完整大纲。大纲不是目录复制，而是把模板章节、指南要求、方法体系和材料缺口组织成可执行写作蓝图。
大纲必须包含：
- 模板原始章节标题：保持模板标题、顺序和层级不变。
- 每节写作任务：说明该节要回答什么问题，承担什么论证功能。
- 核心内容要点：列出该节需要写入的技术点、场景点、指标点、成果点。
- 材料来源：标出该节依据指南、草稿、补充材料还是待补信息。
- 交叉关系：标出该节与研究内容、技术路线、指标、成果之间的对应关系。
- 风险提示：标出材料不足、逻辑未闭合、指标无来源、成果无对应等问题。
大纲冻结规则：
- 大纲确认后再填正文，正文不得擅自新增模板外章节。
- 如写作中发现方法体系或章节结构需要调整，先更新大纲和映射表，再改正文。
- 研究内容、技术路线、创新点、指标、预期成果之间的数量和名称必须在大纲阶段先对齐。
本步输出：完整章节大纲 + 每节写作要点 + 内容映射关系 + 待补/风险清单。
第1步：写概述/需求分析
本段任务：大背景 → 具体问题枚举 → 本课题方案 → 预期价值。
结构规律：
- 第一段先从领域趋势或应用需求切入，再缩小到具体场景中的关键矛盾。
- 第二段列出至少3个具体问题。问题必须来自场景，避免只写"数据质量不高""智能化不足""效率较低"等泛化表述。
- 第三段点出课题全称和核心方案，用一句话说明"用什么技术解决什么场景问题"。
- 第四段收束到预期价值，描述能力提升和应用支撑，不提前承诺量化指标。
写法模板：
[领域/场景]的[发展趋势/任务特征]对[现有方法/系统/流程]提出了更高要求，特别是在[关键环节]方面，[现有手段]难以满足[具体需求]。
其中，[核心痛点]尤为突出：
[问题1]，[具体表现]；
[问题2]，[具体表现]；
[问题3]，[具体表现]。
为克服上述不足，本课题——[课题全称]，提出了一套面向[应用场景]的[总体方案]。
其核心在于[一句话说清核心思路]。
本课题将[核心技术/方法]融入[业务流程/研究场景]，以实现[目标]。
通过本课题的研究，将构建[系统/方法/模型/平台]。
该成果能够有效解决[场景问题]，具备[能力1]、[能力2]和[能力3]。
写完后自查：
第2步：写研究目标
本段任务：总目标 → 逐条目标。每条目标必须回答"针对什么问题、提出什么方法、达到什么效果"。
结构规律：
- 总目标要承接概述中的核心痛点。
- 分目标数量通常与研究内容大项数量一致。
- 每个分目标用同一语法骨架，形成稳定的评审阅读节奏。
- 目标写"旨在达到的能力"，不写过细的算法流程。
写法模板：
本研究旨在[总目标]，针对现有方法在[不足1]、[不足2]和[不足3]方面的问题，分别提出以下研究目标：
1. 针对[不足1]的问题，提出[方法名]。
该方法旨在[具体目标]，以[作用/效果]。
2. 针对[不足2]的问题，提出[方法名]。
该方法旨在[具体目标]，以[作用/效果]。
3. 针对[不足3]的问题，提出[方法名]。
该方法旨在[具体目标]，以[作用/效果]。
写完后自查：
第3步：写研究内容
这是申请书最核心的一段。 先写总述，再逐项展开。每项严格按"针对 → 提出 → 通过 → 实现"四段式。
3.0 总述
针对[总问题1]、[总问题2]以及[总问题3]，提出了[总方法名/总体技术体系]。
该方法通过[技术路径A]实现[效果A]，
通过[技术路径B]实现[效果B]，
通过[技术路径C]实现[效果C]。
3.1 子项标准句式
针对[精确限定场景]中[具体对象]的[具体困难]，
提出了[方法全名]。
该方法通过[技术手段1：具体怎么做]、[技术手段2]和[技术手段3]，
实现了[效果1]、[效果2]和[效果3]。
高频动词表：
| 环节 | 动词 |
|---|
| 问题锚定 | 针对、面临、存在、缺乏、难以、制约 |
| 方法引出 | 提出、构建、设计、建立、引入、融合 |
| 手段展开 | 通过、利用、基于、结合、借助 |
| 效果收束 | 实现、形成、达到、提升、支撑、保障 |
写作规律：
- 子项开头必须锚定场景，不要直接从技术名词开始。
- "提出了"后面必须是完整方法名，优先使用"基于/面向/融合/结合"等结构。
- "通过"后面必须写具体技术动作，不能写"通过深入研究""通过系统分析"。
- 末尾必须有明确产出或能力，且为定性描述。
写完后自查：
3.2 标题命名铁律
研究内容标题 = 技术路线标题，一个字不差。
这是优秀申请书中非常稳定的组织规律：研究内容负责说明"研究什么"，技术路线负责说明"怎么做"，但二者的子项标题必须完全一致，以形成评审可追踪的对应关系。
标题命名公式：
基于[核心技术/理论/机制]的[场景+对象][动作]方法
| 组成部分 | 说明 | 示例 |
|---|
| 核心技术/理论/机制 | 支撑方法成立的技术来源或理论基础 | 多源数据融合、领域知识约束、动态关系建模、混合推理 |
| 场景+对象 | 本课题的业务场景、研究对象或操作对象 | 工业检测报告、遥感目标识别、医学文本质控、供应链风险事件 |
| 动作 | 方法、模型、技术、机制、体系 | 知识抽取方法、质量判定模型、关系建模方法、风险推理机制 |
反面示例：
- 不充分：
数据抽取方法。问题：缺少场景、对象和核心技术。
- 不充分：
质量判定方法。问题：缺少技术来源和对象限定。
- 更完整：
基于领域知识约束的工业检测报告关键指标抽取方法。
变体公式：
面向[场景/问题]的[技术名]方法融合[技术A]与[技术B]的[场景+对象]方法基于[机制]的[对象][动作]模型
第4步：写技术路线
技术路线分两层：总体技术路线 + 各研究内容技术路线。各研究内容技术路线必须与研究内容逐项对应。
4.0 总体技术路线
放在各研究内容技术路线之前，用一段说清整体链路。
写法模板：
本项目的总体技术方案聚焦于[核心目标]。
方案核心在于[核心A]、[核心B]以及[核心C]，旨在通过[技术手段]全面提升[能力]。
首先，方案强调[方面A]。针对[问题]，方案采用[方法]，通过[具体技术]实现[效果]。
在[方面B]方面，项目引入了[技术]，[做法]，[效果]。
在[方面C]环节，方案构建了[系统/方法/模型]，[做法]，[效果]。
总体而言，该技术方案通过[技术列表]的有机结合，全面提升了[能力]，为[对象/场景]提供了[价值]。
结构规律：
- 第一段写整体目标和核心组成。
- 第二段按技术链路展开，不要写成成果清单。
- 第三段收束到总体能力和应用价值。
4.1 各研究内容技术路线
每个子项 1200-1500 字，严格按 问题 → 算法流程 → 场景效果 → 总结 四段结构。
四段模板：
##### 4.1.X.X [技术路线全名（=研究内容名）]
[段1：问题，200-350字]
[场景]中[具体对象]的[具体困难]，用该场景中的真实对象、字段、流程或业务动作说明问题。
说明该问题导致的后果，例如人工处理成本、质量不可控、追溯困难、模型无法稳定应用、业务闭环无法形成等。
[段2：算法流程，550-800字]
针对上述问题，我们提出了[方法全名]。
用自然段叙述算法或技术过程，不使用"第一步/第二步/Step 1"等编号。
根据方法内在逻辑选择叙述节奏：
- 数据驱动型：从数据对象出发，逐项梳理字段、语义、关系和校验机制。
- 管线型：从输入端、处理层、约束层、输出端逐层说明。
- 层次型：从底层数据、中层模型、上层应用和反馈更新说明。
[段3：场景效果，250-400字]
在[场景]中，该方法[如何部署/使用]。
以[一个具体数据样例或业务样例]为例，说明输入经该方法处理后的输出结果，以及用户、系统或评审方如何使用该输出。
[段4：总结，120-200字]
收束方法的核心贡献和解决的痛点，只做定性描述，不出现百分比、准确率、数量等验收指标。
叙述节奏示例：
| 方法类型 | 叙述风格 |
|---|
| 数据驱动型 | "从...出发，逐项梳理...由于...方法通过...在...基础上引入...模型建立后进一步..." |
| 管线型 | "在输入端构建...送入模型后...但直接使用存在风险...为此引入...经过滤后还需..." |
| 层次型 | "核心思想是通过三层架构...底层是...中间层是...因此需要...上层是...搭建完成后真正挑战在于..." |
关键要求：
- 技术路线展开段优先用"我们"；概述类章节可用"本项目/本课题/本研究"，同一章节主语必须一致。
- 段2禁止用"第一步/第二阶段/Step 1"等编号。
- 段3必须有具体数据样例或业务样例，不能只有泛化场景描述。
- 段4收束为定性效果，不出现百分比、数量、阈值等指标。
- 不写任何指向既有私有文本、私有项目或技术出处的溯源标注。
- 四段总字数控制在 1200-1500 字。
4.2 关键技术展开写法
自然科学基金、大项目或技术机制要求较强的项目，关键技术可按 难点 + 特色方案 展开。
2.X [关键技术名]
[问题背景段落，说明面临的挑战]。
（1）难点：[具体技术难点描述，说明该领域为什么难、难在哪里、现有方法为什么不足]。
（2）特色：为应对上述难点，本研究设计了[方案]。
通过[技术A]和[技术B]，该框架能够[效果]。
并引入[技术C]，实现[效果]。
4.3 技术路线正文的场景贴合要求
技术路线正文必须绑定场景，不能写通用流程。
| 通用描述 | 场景贴合写法 |
|---|
| 将实体和关系组织为图谱模式 | 将具体业务对象、属性、流程节点和依据组织为可追溯的关系网络 |
| 利用规则进行校验 | 使用该行业的业务规则、质量约束、阈值范围或审核条件校验输出结果 |
| 设计增量更新机制 | 当新增记录、规则变化或业务状态变化时，定向更新受影响的数据、模型或判断链路 |
| 输出分析结果 | 输出与业务动作直接相关的判断、原因、风险等级、处置建议或证据链 |
写完后自查：
第5步：写创新点
本段任务：每条创新点 = 问题 + 方法 + 技术手段 + 效果。
简洁型模板：
（1）提出[方法全名]。
针对[具体问题]，构建[机制/模型]，结合[技术A]和[技术B]，形成[成果/能力]。
（2）提出[方法全名]。
针对[具体问题]，通过[做法]，实现[效果]。
展开型模板：
创新点N：提出[技术全名]。
针对[具体问题]，基于[核心技术/理论]，构建[体系/框架]，提出[方法/机制]，构建[模型]，以实现[目标]。
同时利用[辅助技术]，构建[辅助机制]，以实现[更大目标]。
写作规律：
- 创新点数量一般与研究内容大项对应。
- 创新点不能只是技术名词堆叠，必须说明相对现有方法的新意。
- 创新点只写创新机制和预期效果，不写完整技术路线。
写完后自查：
第6步：写进度安排
按项目执行期分3个阶段。阶段名称要体现工作推进逻辑，不要只写"第一阶段/第二阶段/第三阶段"。
### 阶段一：[名称]（时间：YYYY年MM月-YYYY年MM月）
主要任务：[3-4条]
阶段成果：[2-3项]
### 阶段二：[名称]（时间：YYYY年MM月-YYYY年MM月）
主要任务：[3-4条]
阶段成果：[3-5项]
### 阶段三：[名称]（时间：YYYY年MM月-YYYY年MM月）
主要任务：[3-4条]
阶段成果：[3-5项]
写作规律：
- 阶段一通常对应需求梳理、数据准备、理论模型或原型框架。
- 阶段二通常对应核心方法研发、系统集成、关键技术验证。
- 阶段三通常对应场景验证、优化完善、成果凝练和验收交付。
- 每个阶段成果必须能映射到预期成果或考核指标。
第7步：写技术指标/考核指标及验证方法
本段任务：把指南中的考核要求转成可验收的指标表。每项指标必须回答"验什么、怎么验、交付什么证据"。
7.1 指标分类
| 指标类别 | 适用内容 | 写法重点 |
|---|
| 算法性能指标 | 抽取、分类、匹配、推理、预测、排序等算法 | 指标名称、测试数据、对比基线、验收阈值 |
| 功能完整性指标 | 系统、平台、工具、原型软件 | 功能模块、输入输出、操作流程、异常处理 |
| 数据/知识产品指标 | 数据集、知识库、知识图谱、规则库 | 数据规模、字段范围、更新机制、质量校验 |
| 工程交付指标 | 软件著作权、专利、报告、样机、系统部署 | 交付物名称、数量、形式、验收证据 |
| 应用验证指标 | 示范场景、测试案例、业务闭环 | 场景样例、验证流程、用户或专家评审方式 |
7.2 写法模板
围绕[核心技术环节1]、[核心技术环节2]和[核心技术环节3]，项目考核指标按照[指标类别A]、[指标类别B]、[指标类别C]和[应用验证指标]进行设计，并通过[验证方法1]、[验证方法2]、[验证方法3]开展综合验收。
| 序号 | 指标类型 | 指标内容 | 验证方法 | 对应成果 |
|-----|---------|---------|---------|---------|
| 1 | 算法性能 | [具体指标及阈值] | [测试集/对比实验/人工复核] | [算法模型/测试报告] |
| 2 | 功能完整性 | [功能模块和能力边界] | [系统测试/场景演示] | [原型系统/用户手册] |
| 3 | 数据产品 | [数据规模、字段范围、质量要求] | [抽样检查/一致性校验] | [数据集/知识库] |
7.3 写作要求
- 指标必须来自申报指南或研究内容，不要凭空承诺。
- 指标阈值放在本节，不要塞进研究内容和技术路线的收束句。
- 每项指标必须有验证方法，不能只写"达到要求"。
- 每项指标必须映射到预期成果，避免成果和考核脱节。
- 如果指南已经给出固定指标，必须逐项覆盖；如果指南没有给出，则按研究内容主动设计可验收指标。
写完后自查：
第8步：写预期成果
分条列出，格式为"成果名 + 数量"：
- 发明专利申请[数量]项
- [数据/知识产品][数量]套
- [方法/模型][数量]套
- [软件/原型系统][数量]套
- 研究报告[数量]份
- 测试验证报告[数量]份
注意：成果必须与申报指南和第7步技术指标对齐，指南要求的每项指标都要有对应成果。
场景贴合度铁律
写出来的内容必须"换一个场景就不能直接用"。不是简单替换名词，而是让问题、方法、输入、输出和效果都嵌入该项目的真实业务或科研链条。
判定方法
读完每一句，问两个问题：
- 这句话描述的问题，换成另一个行业或学科是否仍然成立？如果成立，问题不够场景化，需要重写。
- 这个方法的输入、输出或中间步骤，换成另一个行业或学科是否照样运行？如果能运行，方法没有贴合场景，需要重写。
抽象示例
| 通用套话 | 场景贴合写法 |
|---|
| 通过智能模型自动识别实体属性 | 从具体业务文档中识别该场景独有的指标、对象、约束条件和判定依据 |
| 构建知识图谱实现关联查询 | 构建以业务对象、流程节点、判定依据和结果证据为核心的可追溯关系网络 |
| 输出分级结果 | 输出与业务处置直接相关的等级、原因、依据、风险解释和后续动作 |
| 利用规则进行校验 | 用该行业或学科的规则、阈值、流程约束和审核条件校验模型输出 |
| 结合领域知识约束 | 将专业规范、专家经验、术语体系和质量要求转化为模型可执行的约束 |
核心原则
- 问题必须来自场景：写具体对象在具体流程中的具体困难，不写泛化困难。
- 方法必须嵌入场景：写清输入是什么、怎样处理、输出给谁用、如何进入业务闭环。
- 效果必须服务场景：写对研究、管理、验证、生产、评审或决策有什么直接支撑。
字数控制铁律
- 研究内容：每个子项 150-220 字。
- 技术路线：每个子项四段合计 1200-1500 字。
- 概述/需求分析：按模板要求控制篇幅，避免把技术路线提前写进概述。
- 创新点：每条突出一个创新机制，不写成研究内容复述。
脱敏与开源安全规则
- 不保留任何具体过往项目名称、课题名称、单位名称、团队名称、人员姓名、标准号、客户名称、经费信息、内部文件名或机器路径。
- 不引用、复述或改写任何私有申请书原文段落。
- 不使用指向既有私有文本、私有项目、历史版本或内部资料的溯源表述。
- 可以保留从优秀文本中抽象出的写作规律，例如章节对应、标题一致、四段式技术路线、场景贴合、指标映射和主语一致。
- 示例必须使用通用占位符或跨领域抽象样例，避免暴露真实项目痕迹。
全局自检
流程完整性自检
全文一致性自检
章节质量自检
提交前自检
