Skill: drjzhou/zh-project-proposal-writing (version 1.0.1)

--- name: zh-project-proposal-writing description: Use when the user needs to draft, revise, diagnose, shorten, expand, structure, finalize, or produce a deliverable Chinese project/grant proposal（中文项目申请书、基金申请书、科技计划申报书、可交付项目书）, especially NSFC/国家自然科学基金、国家重点研发计划、上海市科委、杰青优青等人才类项目；handles guide interpretation, constraints matrix, title, abstract, rationale, scientific question or technical bottleneck, objectives, tasks, methods, roadmap, innovation, feasibility, budget, risk, compliance, attachments, expert-wisdom synthesis, review-style scoring, and final delivery as a Word .docx document. --- # 中文项目申请书写作与交付技能 版本：3.1 定位：把“写作辅助”升级为“可交付项目书生产系统”。主文件只保留触发、流程、边界和输出契约；细节按需读取 `references/` 与 `examples/`。 ## 1. 使用范围 在用户需要撰写、修改、诊断、精简、扩展、重构、模拟评审或生成可交付项目书时使用本技能，常见对象包括： - 国家自然科学基金、国家重点研发计划、上海市科委科技计划、杰青优青等人才类项目。 - 高校、医院、研究院、企业的科研、转化、平台、示范和联合攻关项目。 - 标题、摘要、项目简介、立项依据、研究目标、研究内容、技术路线、创新点、可行性、预算、风险、伦理、数据、知识产权、附件、模拟评审和定稿交付。 不要把本技能用于伪造论文、专利、数据、合作承诺、伦理批件、专家意见、用户场景、第三方检测、项目经历或未公开申请书内容。 ## 2. 工作模式 根据用户意图选择模式： - **快速诊断模式**：用于评审意见、扣分点、章节逻辑和优先修改清单。 - **章节写作模式**：用于标题、摘要、立项依据、研究内容、技术路线等局部改写。 - **整本框架模式**：用于搭建全书章节结构、主线、任务矩阵和图表建议。 - **可交付模式**：当用户说“可交付版本、提交版、定稿、整本项目书、完整申请书、交付包”时启用。最终交付物必须是 Word `.docx` 文档，文档内必须包含正文草稿、约束矩阵、事实台账或缺失事实清单、章节映射矩阵、形式审查/附件/合规清单、红队审查和最终核验清单。 - **专家经验融合模式**：当用户要求“专家感悟、写作经验、评审专家怎么看”时，读取专家经验归类文件，把不同来源的共识转译为写作动作，不堆砌姓名、语录或 URL。 ## 3. 核心原则 1. **官方硬约束优先。** 当年指南、申报书模板、系统提示、形式审查、预算规则、附件要求和依托单位通知，高于本技能内置写作经验。 2. **可交付不等于代替承诺。** 可以生成接近提交态的项目书，但事实、预算、合规、伦理、知识产权、附件、AI 使用声明和最终提交责任必须由申请人及依托单位确认。 3. **事实不编造。** 缺论文、专利、数据、平台、样机、合作、伦理、预算依据等事实时，写“待补充”或“需申请人核验”，不要用流畅文字掩盖不确定性。 4. **先判断申报口径，再动笔。** 基础研究写科学问题与假设；任务型项目写指南响应、指标、交付物和验收；人才类项目写个人学术主线、代表性贡献和未来跃迁。 5. **全文只服务一条主线。** 标题、摘要、立项依据、目标、内容、方案、创新、基础、成果、预算和风险必须互相映射。 6. **专家经验降维为动作。** 专家感悟只作为写作启发，不能覆盖指南；使用时归入“评审视角、科学问题、摘要主线、创新、可行性、基础、合规、打磨”等类别；Skill 内不得保存具体个人姓名或裸 URL。 7. **外部核验要克制且权威。** 正式申报涉及年度指南、模板、限项、预算、附件、截止时间、伦理、数据、保密、人工智能使用声明等变化事项时，优先使用用户上传材料；需要联网时只优先核验官方、资助机构、申报系统、依托单位或权威期刊来源，并在输出中标注需核验项。 8. **保护敏感信息。** 遇到涉密、未公开数据、个人隐私、合作协议、临床样本、企业商业秘密时，建议脱敏；不要主动索取与当前写作无关的敏感细节。 ## 4. 来源与证据分级 写作时按以下顺序采信： 1. 用户上传的当年指南、模板、评分标准、依托单位通知、项目事实材料。 2. 资助机构官网、申报系统、官方管理办法和年度指南。 3. 资助机构或评审机构发布的写作建议、评审标准、形式审查清单。 4. 高校、医院、研究院等官方渠道发布的专家讲座纪要。 5. 同行评议论文、PubMed/权威期刊中的 grant writing 文章。 6. 普通博客、商业培训稿、自媒体，仅能作为低权重启发；正式输出中默认不引用。 若不同来源冲突，以更高层级和更新年份为准；若仍冲突，输出“需核验”。 ## 5. 按需读取规则 只读取当前任务需要的资料，不要一次性加载全部参考文件。 | 当前任务 | 优先读取 | 需要时再读 | |---|---|---| | 生成可交付项目书、提交版、交付包 | [deliverable_proposal_workflow](references/deliverable_proposal_workflow.md) | [templates_checklists](references/templates_checklists.md), [funder_rules](references/funder_rules.md) | | 搜集/使用专家写作感悟 | [expert_wisdom_synthesis](references/expert_wisdom_synthesis.md) | [writing_logic_consensus](references/writing_logic_consensus.md) | | 判断某类项目怎么写、解读申报口径 | [funder_rules](references/funder_rules.md) | [knowledge_boundaries](references/knowledge_boundaries.md) | | 写标题、摘要、项目简介、故事线 | [title_abstract_story](references/title_abstract_story.md) | [expert_wisdom_synthesis](references/expert_wisdom_synthesis.md) | | 写或改某一章 | [module_writing_guide](references/module_writing_guide.md) | [funder_rules](references/funder_rules.md) | | 做评审式诊断、评分、自检 | [templates_checklists](references/templates_checklists.md) | [expert_wisdom_synthesis](references/expert_wisdom_synthesis.md) | | 需要领域共识、评审视角、写作逻辑 | [writing_logic_consensus](references/writing_logic_consensus.md) | [module_writing_guide](references/module_writing_guide.md) | | 需要确认资料来源、公开样例边界、是否应核验最新信息 | [knowledge_boundaries](references/knowledge_boundaries.md) | [funder_rules](references/funder_rules.md) | | 需要学习输出格式或少样例 | [proposal_skill_examples](examples/proposal_skill_examples.md) | [deliverable_proposal_examples](examples/deliverable_proposal_examples.md) | 若用户同时要求“某类项目 + 某一章”，先读资助方规则，再读对应模块；若用户提供当年指南、模板或评审标准，先使用用户材料建立约束矩阵。 ## 6. 信息不足时如何处理 能直接产出草稿或诊断时，不因信息不全而停下；用“待补充”“需按当年指南确认”占位并继续。只有缺失信息会改变写作口径或硬约束时，最多先问三个问题： 1. **申报类型与指南。** 资助方、年份、专项或申请代码，是否有指南、模板、评分标准、字数页数、预算和附件要求。 2. **一句话项目主线。** 研究对象或应用场景、核心问题、拟采用路线、预期成果。 3. **前期基础。** 已有论文、专利、数据、模型、平台、样机、病例、样本、合作单位、用户场景和前期项目。 若用户要求“先给版本”，直接输出结构化草稿，并在末尾列出“需补充/需核验信息”。 ## 7. 可交付工作流 1. **建立约束矩阵。** 提取指南条款、评分标准、页数/字数、预算、附件、伦理、数据、限项、截止时间和依托单位要求。 2. **建立事实台账。** 把论文、专利、数据、平台、团队、合作、样机、场景、伦理、预算依据分为“已证实、用户口述、待补充、不可使用”。 3. **压缩项目主线。** 用一句话说明对象、缺口、路线、成果和价值；所有章节围绕这句话展开。 4. **形成故事线。** 重要场景或现象 → 已有进展 → 未解缺口或瓶颈 → 新假设或新路线 → 研究内容或任务 → 可验证结局。 5. **建立映射矩阵。** 基础研究使用“科学问题—假设—内容—方法—基础—预期认识—创新—风险”；任务型项目使用“指南指标—目标—任务—方法—交付物—验收—责任单位—预算—风险”。 6. **写作正文草稿。** 先写标题、摘要和总体目标，再写章节；每章末尾标注需同步修改的位置。 7. **模拟评审与红队审查。** 从评审专家角度检查：为什么重要、是否新、是否可做、是否有基础、失败怎么办、是否符合指南。 8. **生成 Word 交付文档。** 最终产出 `.docx` 文件；若用户提供申报模板，优先按模板结构和样式写入；若未提供模板，生成结构清晰的 Word 文档，把正文草稿、约束矩阵、事实台账/缺失事实清单、章节映射矩阵、形式审查清单、附件清单、预算/验收风险、红队审查和最终核验清单放入同一文档的正文或附录。 ## 8. 不同项目的一句话公式 ### 国家自然科学基金 针对【领域/对象】中【尚未解决的科学问题】，本项目基于【前期发现/理论依据】提出【科学假设】，采用【关键模型/方法/体系】，阐明/揭示/建立【机制/规律/理论/方法】，为【学科发展/应用基础】提供【新认识/新依据/新工具】。 ### 国家重点研发计划、上海市科委与应用示范类项目 面向【国家/上海/产业/民生/行业场景】中的【关键瓶颈】，本项目拟通过【核心技术路线/组织方式】，突破【关键技术/共性问题】，形成【标志性成果/产品/平台/标准/示范】，达到【指南考核指标】，支撑【战略目标/产业升级/社会效益】。 ### 杰青优青等人才类项目 申请人围绕【长期学术主线】持续解决【核心科学问题】，已在【代表性贡献】方面形成【可识别学术影响】，未来拟以【新问题/新方法/新平台】实现【学术跃迁】，带动【团队/平台/领域】发展。 ## 9. 输出契约 根据用户任务选择一种或多种输出，优先给用户可直接使用的结果。进入可交付模式后，不要只在聊天中输出 Markdown；必须创建并交付 Word `.docx` 文件。聊天回复只简要说明文件路径、版本状态和仍需核验事项。 | 任务 | 推荐输出 | |---|---| | 解读指南 | 约束矩阵、指标覆盖矩阵、形式审查风险、建议章节结构、待核验清单 | | 生成标题 | 6–10 个标题；说明优点、风险、适用口径；推荐首选标题 | | 改摘要或项目简介 | 一句话主线、六句故事线、问题诊断表、2–3 个改写版本、需同步修改的正文位置 | | 写整本框架 | 章节结构、逻辑递进、核心矩阵、图表建议、缺失信息清单 | | 生成可交付项目书 | Word `.docx` 文档；文档内含正文草稿、章节映射矩阵、约束响应矩阵、事实台账/缺失事实清单、附件/预算/合规清单、红队意见、最终核验清单 | | 改某一章 | 逻辑断点、评审疑问、修改策略、可替换文本、需同步修改章节 | | 模拟评审 | 指南匹配、问题价值、主线、创新、可行性、基础、成果、预算、合规、可读性评分；优先修改清单 | | 定稿前自检 | 硬约束核验表、一分钟复述、证据闭环、全文一致性、合规闭环、风险整改建议 | | 专家感悟归类 | 来源分级、主题归类、共识/分歧、可执行写作动作、适用项目类型、低可信来源剔除说明 | ## 10. 摘要快速规则 详细规则见 [title_abstract_story](references/title_abstract_story.md)。专家经验归类见 [expert_wisdom_synthesis](references/expert_wisdom_synthesis.md)。 - **国家自然科学基金摘要**：重要性 → 已知进展 → 未解缺口 → 前期基础与假设 → 研究内容和方法 → 验证方式 → 预期认识和意义。 - **科技部与上海项目简介**：需求场景、关键瓶颈、总目标、任务组织、核心路线、交付成果、验证方式、团队和场景基础、合规价值。 - **人才类摘要**：长期主线 → 代表性贡献 → 前沿缺口 → 未来计划 → 预期引领作用。 - **摘要硬伤**：开头空泛、背景过长、缩写堆砌、问题不具体、没有前期基础、只列方法、只承诺论文专利、滥用“首次”“领先”“突破”。 ## 11. 定稿前质量闸门 - **指南匹配**：每个目标、任务、成果、指标都能对应指南、模板或评分标准。 - **一分钟复述**：大同行读完标题和摘要后，能复述问题、缺口、路线、价值和可验证结局。 - **证据闭环**：每个主要目标都有方法、前期基础、交付物、验证方式和风险替代方案。 - **全文一致**：标题、摘要、目标、内容、路线、创新、基础、成果、预算和图表讲的是同一件事。 - **指标可验收**：任务型项目的指标有阈值、测试条件、评价方法、责任主体和验收材料。 - **专家经验已落地**：评审视角、科学问题、可读性、创新、可行性、基础和合规建议已转化为具体文本或修改动作。 - **交付完整性**：最终 `.docx` 文件已生成，正文、图表建议、附件、预算依据、风险方案、待补充项、版本记录和核验清单齐全。 - **合规闭环**：限项、资格、伦理、数据、知识产权、安全、保密、合作协议、附件、人工智能使用声明均已处理或标为待核验。 ## 12. 回复风格 使用清晰、专业、可直接粘贴进申请书的中文。诊断优先用表格，正式文本用完整段落。不要按个人姓名罗列写作建议，不输出裸 URL；应把经验整合为“摘要逻辑、故事线、创新性、可行性、评审沟通”等写作动作。若使用外部资料，说明来源层级和需核验事项；若无法确认，明确写“未核验”或“需按当年官方指南确认”。

path: AGENTS.md
content: # Agent instructions for maintaining this Skill

Use `SKILL.md` as the canonical instruction file for the project-application writing and delivery skill. Keep the main file concise and place detailed, task-specific guidance in `references/` or `examples/`.

## Maintenance rules

- Do not hard-code annual grant rules, deadlines, budgets, eligibility requirements, page limits, attachment formats, or submission-system details into `SKILL.md`; keep them as items requiring official verification.
- Preserve the source hierarchy: user-uploaded current guide/template > funder official rules > official review/writing guidance > university or research-institute expert lecture notes > peer-reviewed grant-writing articles > low-weight blogs or commercial training materials.
- When adding expert insights, classify them by writing problem, not by celebrity authority. Do not store specific person names or raw URLs anywhere in the Skill. Required categories include reviewer communication, project type fit, scientific question or technical bottleneck, abstract/storyline, innovation, feasibility, team/environment, impact/metrics, compliance, and revision workflow.
- Keep file paths ASCII where possible for portability across shell/container environments.
- When adding examples, use fictional placeholders and avoid copying unpublished proposal text or real confidential applications.
- Preserve the no-fabrication rule for papers, patents, data, ethics approvals, collaborations, budgets, reviewer comments, user scenarios, third-party tests, and institutional commitments.
- Deliverable-mode outputs must be packaged as a Word `.docx` document and include at least: proposal draft, constraints matrix, fact ledger or missing-facts list, chapter mapping matrix, compliance/attachment checklist, red-team review, and final verification list.
- If a user asks for a polished "final" version while facts are incomplete, continue drafting with clearly marked placeholders such as `待补充` and `需申请人核验`; do not fill gaps with invented facts.
- Do not store external raw URLs or specific person names in any Skill file. Use source tiers and generic source categories instead.
- After edits, check that `SKILL.md` still has YAML front matter with `name` and `description`, and that all referenced files exist.


path: README.md
content: # zh-project-proposal-writing

中文项目申请书写作与交付 Skill。主文件为 `SKILL.md`，参考资料在 `references/`，少样例在 `examples/`。

本版本把 Skill 从“写作辅助”升级为“可交付项目书生产系统”，可用于生成整本项目书 Word 文档，文档内包含正文草稿、约束响应矩阵、事实台账、附件/预算/合规清单、红队评审意见和最终核验清单。

## 安装

```bash
npx skills add ECNU-ICALK/zh-project-proposal-writing-skill
```

## 结构

- `SKILL.md`：触发条件、工作模式、来源分级、可交付工作流、输出契约和质量闸门。
- `AGENTS.md`：维护本 Skill 时的 agent 指令。
- `references/deliverable_proposal_workflow.md`：整本项目书可交付生产流程、版本推进、矩阵模板、红队问题库和交付包格式。
- `references/expert_wisdom_synthesis.md`：无姓名、无 URL 的可靠来源经验归类、主题共识和可执行写作动作。
- `references/funder_rules.md`：不同资助方/项目类型的写作口径。
- `references/title_abstract_story.md`：标题、摘要、项目简介和故事线写作规则。
- `references/module_writing_guide.md`：立项依据、目标、内容、路线、创新、可行性等章节写作手册。
- `references/templates_checklists.md`：诊断、模拟评审、自检、提示词和清单模板。
- `references/knowledge_boundaries.md`：公开资料、用户材料、不可编造事实和核验边界。
- `references/writing_logic_consensus.md`：项目书通用写作逻辑与评审视角。
- `examples/proposal_skill_examples.md`：常规任务少样例。
- `examples/deliverable_proposal_examples.md`：可交付项目书、专家经验融合和定稿前红队少样例。

## 推荐使用方式

1. 先上传当年指南、申报模板、评分标准、已有项目素材和依托单位通知。
2. 让 Skill 先建立“约束矩阵”和“事实台账”，再写标题、摘要和正文。
3. 整本项目书建议按 V0–V5 推进：约束盘点 → 主线骨架 → 正文草稿 → 模拟评审 → 定稿润色 → Word 交付文档。
4. 专家经验只作为写作动作和检查清单，不能替代当年官方指南和依托单位要求。

## 合规提醒

正式申报前必须由申请人、财务、伦理/数据、知识产权、科研管理部门和合作单位按职责核验。本 Skill 不生成未核实事实，不替代合规审查，不保证立项或中标。


path: examples/deliverable_proposal_examples.md
content: # 可交付项目书与专家经验融合示例

本文件提供少样例，帮助 agent 在“整本项目书交付、专家经验归类、定稿红队”场景中稳定输出。示例中的项目事实均为占位符，不可直接当作真实申请材料。

## 示例 1：生成可交付项目书草案

用户请求：
> 我准备申报 2026 年某市科技计划，方向是智能制造场景下的质量检测平台。请先给一版可交付项目书。

推荐动作：
1. 先读取用户上传的指南和模板；若未提供，则按 `references/deliverable_proposal_workflow.md` 输出 V0/V1/V2 组合版本。
2. 建立“指南约束响应矩阵”和“事实台账”。
3. 生成一句话主线和六句故事线。
4. 生成正文草稿；缺少事实用“待补充/需核验”。
5. 将正文、矩阵、红队意见、附件清单、预算/验收风险和最终核验清单写入 Word `.docx` 文档。
6. 聊天回复只给文件路径、版本状态和需核验事项摘要。

推荐 Word 文档骨架：

```text
# 项目书可交付草案

## A. 版本说明
- 项目类型：
- 依据材料：
- 当前限制：未提供正式指南/预算规则/附件模板，以下为可迭代草案。

## B. 一句话主线
【应用场景】中存在【关键瓶颈】，本项目拟通过【核心技术路线】，形成【平台/产品/标准/示范】，达到【指标】，支撑【产业/社会价值】。

## C. 指南约束响应矩阵
| 指南条款 | 章节响应 | 当前状态 | 风险 | 处理动作 |
|---|---|---|---|---|
| 待补充 | 总体目标/任务/成果 | 待核验 | 可能偏离指南 | 上传指南后重建矩阵 |

## D. 正文草稿
按用户模板或通用章节输出。

## E. 红队意见
| 风险 | 影响 | 修改动作 |
|---|---|---|
| 指标未给阈值 | 验收风险 | 补充测试条件、阈值、第三方检测方式 |

## F. 待补充与最终核验清单
- 当年指南、模板、评分标准。
- 预算上限、科目规则、附件要求。
- 伦理、数据、知识产权、合作协议。
```

## 示例 2：把专家感悟融入摘要修改

用户请求：
> 帮我按照权威专家经验把这个国自然摘要改得更像能打动评审。

推荐动作：
1. 读取 `references/expert_wisdom_synthesis.md` 和 `references/title_abstract_story.md`。
2. 不按专家姓名逐条罗列，而是按主题输出“专家经验 → 摘要修改动作”。
3. 给一句话主线、六句故事线、摘要诊断表和改写版本。

推荐输出骨架：

| 专家经验主题 | 当前摘要问题 | 修改动作 |
|---|---|---|
| 评审视角 | 第一段背景过长 | 第一句直接写对象、问题和缺口 |
| 科学问题 | 方法多，问题弱 | 用“仍不清楚的是……”凝练科学问题 |
| 可行性 | 前期基础没进入摘要 | 加入一条已验证前期发现，标明待核验 |

## 示例 3：定稿前红队审查

用户请求：
> 这是我们准备提交的申请书，请做最后一轮红队审查。

推荐动作：
1. 读取 `references/templates_checklists.md` 和 `references/deliverable_proposal_workflow.md`。
2. 不只润色语言，必须检查硬约束、事实、预算、附件、伦理、数据、知识产权和全文一致性。
3. 输出“致命风险/高优先级/中优先级/低优先级”。

推荐输出骨架：

| 优先级 | 风险 | 证据位置 | 可能后果 | 立即动作 |
|---|---|---|---|---|
| 致命 | 附件承诺未见证明 | 合作单位章节 | 形式审查或可信度风险 | 补合作证明或删除承诺 |
| 高 | 指标不可验收 | 总目标/任务3 | 评审认为不可执行 | 增加阈值、测试条件、验收材料 |

## 示例 4：从 V2 正文推进到 V5 交付包

用户请求：
> 草稿已经有了，帮我整理成可以给科技处和财务预审的交付包。

推荐动作：
1. 输出 Word `.docx` 交付文档，其中正文以外还包括：约束矩阵、事实台账、预算/验收核验表、附件/合规清单、红队意见、版本记录。
2. 对财务、伦理、科技处、合作单位分别列核验事项。
3. 保留未核验项，不把占位符伪装成终稿事实。

推荐 Word 文档骨架：

```text
# 预审交付包

## 1. 科技处核验
- 限项与资格：待核验
- 指南方向匹配：待核验
- 附件和签章：待核验

## 2. 财务核验
- 经费上限：待核验
- 设备费依据：待补充报价
- 外协/测试费：需合同或测算说明

## 3. 伦理与数据核验
- 样本/数据来源：待补充授权
- 伦理批件：待补充
- 数据安全与开放共享：按当年指南确认
```


path: examples/proposal_skill_examples.md
content: # 项目申请书 Skill 使用示例

本文件提供少样例，帮助 agent 在相似任务中稳定选择输出格式。不要照搬示例内容；应替换为用户项目事实。

## 示例 1：修改国家自然科学基金摘要

用户请求：
> 帮我把这个国自然摘要改得更有科学问题意识。

推荐动作：
1. 读取 `references/title_abstract_story.md`；如需判断基金口径，再读 `references/funder_rules.md`。
2. 输出“一句话主线”。
3. 输出“六句故事线”。
4. 用表格诊断摘要问题：背景、缺口、假设、方法、基础、预期认识。
5. 给 2 个改写版本：稳健版和强化科学问题版。
6. 末尾列“待补充事实/需核验信息”。

推荐输出骨架：

| 维度 | 当前问题 | 修改动作 |
|---|---|---|
| 科学问题 | 待填 | 写清“仍未知的是……” |
| 科学假设 | 待填 | 用前期发现推出假设 |
| 方法与验证 | 待填 | 写对象、模型、关键指标和判断标准 |

## 示例 2：解读科技部国家重点研发计划指南

用户请求：
> 这是指南方向，帮我判断申请书怎么写。

推荐动作：
1. 先读取用户提供的指南文本，再读 `references/funder_rules.md`。
2. 建立“指南条款—申请书章节—响应内容—风险—待核验”矩阵。
3. 输出任务分解、交付物、验收指标、责任单位、预算映射建议。
4. 标出不能凭经验确定的年度硬约束。

推荐输出骨架：

| 指南要求 | 申请书响应位置 | 应写内容 | 风险 | 待核验 |
|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 |

## 示例 3：重写上海市科委项目立项依据

用户请求：
> 这段背景太像论文综述，帮我改成上海科委项目口径。

推荐动作：
1. 读取 `references/funder_rules.md` 与 `references/module_writing_guide.md`。
2. 先诊断是否缺少上海相关性、场景、用户、验收成果和合作基础。
3. 重新组织为“本市需求—当前瓶颈—已有基础—项目路线—上海示范价值”。
4. 缺少具体单位、场景、数据或自筹时用“待补充”。

## 示例 4：模拟评审

用户请求：
> 按评审专家视角给这份申请书打分。

推荐动作：
1. 读取 `references/templates_checklists.md`；如需写作逻辑，再读 `references/writing_logic_consensus.md`。
2. 分维度评分，不只给总分。
3. 每个扣分点给“评审疑问—扣分原因—修改动作”。
4. 给 3–5 项最高优先级修改建议。

推荐输出骨架：

| 维度 | 分数 | 评审疑问 | 修改动作 |
|---|---:|---|---|
| 指南匹配 | 待填 | 待填 | 待填 |
| 主线清晰度 | 待填 | 待填 | 待填 |
| 创新性 | 待填 | 待填 | 待填 |
| 可行性 | 待填 | 待填 | 待填 |


path: references/deliverable_proposal_workflow.md
content: # 可交付项目书生产工作流

本文件用于把项目申请书从“局部润色”推进到“可交付版本”。可交付版本不是保证立项，也不是替申请人作最终承诺；它指：文本结构完整、事实来源可追踪、指南响应可核验、风险项清楚、申请人和依托单位可以据此进入最终提交审查。

## 1. 可交付版本的定义

一份可交付项目书至少满足以下条件：

1. **有明确资助方口径**：知道是基础研究、任务攻关、应用示范、平台建设、人才项目还是联合攻关。
2. **有约束矩阵**：指南条款、评分标准、页数/字数、预算、附件、伦理、数据、知识产权、限项、截止时间均已映射到章节。
3. **有事实台账**：每项成果、数据、专利、论文、平台、团队、合作、样机、场景、伦理批件、预算依据都有来源状态。
4. **有一条主线**：标题、摘要、立项依据、目标、内容、路线、创新、基础、成果、预算和风险讲的是同一件事。
5. **有可验证结局**：基础研究能说清预期认识/机制/规律/方法；任务型项目能说清指标、交付物、测试条件和验收材料。
6. **有红队审查**：从评审专家角度提出扣分风险，并完成至少一轮文本修复。
7. **有最终核验清单**：明确哪些内容已确认，哪些必须由申请人、财务、伦理、科技处或合作单位核验。
8. **有 Word 交付文档**：最终成果必须落成 `.docx` 文件；聊天文本只用于说明版本、路径和核验风险。

## 2. 交付包结构

建议交付时生成一个 Word `.docx` 文档，文件名优先使用 `proposal-deliverable-vX.docx` 或用户指定名称。若用户提供申报书模板，应优先按模板章节、标题层级和表格要求写入；若未提供模板，应使用清晰标题、表格和附录组织内容。若用户只需要正文，也要生成 `.docx`，并把矩阵和清单放在正文后附录或“预审材料”章节。

```text
proposal-deliverable-vX.docx
├── 版本说明与依据材料
├── 一句话主线与故事线
├── 申请书正文草稿
├── 指南约束与响应矩阵
├── 章节映射矩阵
├── 事实台账或缺失事实清单
├── 预算与验收指标核验表
├── 附件与合规清单
├── 红队评审与修改记录
└── 待补充与最终提交核验清单
```

不要把 Markdown 作为可交付模式的最终形态。可以先用 Markdown 草拟内容，但结束前必须写入 Word `.docx`。只有在运行环境无法生成文档时，才说明阻塞原因，并保留结构化草稿作为临时稿。

## 3. 初始信息采集表

不因信息不全而停下，但在可交付模式下应建立以下台账。

| 类别 | 必填信息 | 可暂缺但需标注 |
|---|---|---|
| 申报约束 | 资助方、项目类型、年份、指南、模板、截止时间、页数/字数、评分标准 | 限项、预算规则、附件格式、依托单位内审时间 |
| 项目主线 | 研究对象/应用场景、核心问题/瓶颈、拟采用路线、预期成果 | 竞争方案、国内外进展、关键参考文献 |
| 前期基础 | 论文、专利、数据、模型、样机、平台、样本、病例、前期项目 | 未发表数据、合作场景证明、第三方检测 |
| 团队与组织 | 负责人、骨干、合作单位、分工、管理机制 | 外协价格、合作协议、场景承诺 |
| 合规 | 伦理、数据、知识产权、安全、保密、AI 使用声明 | 伦理批件号、数据授权、保密审批 |
| 预算/指标 | 经费总额、分项预算、设备/材料/测试/劳务依据、考核指标 | 报价单、测试条件、验收材料 |

## 4. 事实来源标记

对每个关键事实使用四级标记：

- **已证实**：用户上传材料、公开官网、正式证书、论文/专利数据库、依托单位文件可支持。
- **用户口述**：用户提供但尚无文件证据；可以写入草稿，但需标注“需申请人确认”。
- **待补充**：缺少具体数字、名称、时间、证据或附件；草稿中用占位符。
- **不可使用**：未经授权的第三方材料、未公开申请书内容、无法核实的荣誉/指标/承诺、可能涉密信息。

正文中不要保留“不可使用”内容；可以把它列入风险清单。

## 5. 约束矩阵模板

| 指南/评分条款 | 对应章节 | 必须响应的关键词 | 当前文本状态 | 风险 | 处理动作 |
|---|---|---|---|---|---|
| 例：需说明关键科学问题 | 立项依据、研究目标 | 科学问题、机制、假设 | 已有但不够聚焦 | 评审认为只是技术路线 | 用一句话重写科学问题，并同步摘要 |
| 例：需提供验收指标 | 总体目标、任务、成果 | 指标、阈值、测试条件 | 待补充 | 指标不可验收 | 增加指标表和测试方法 |

使用规则：每条指南约束至少对应一个章节；每个目标和任务至少对应一条约束或评分标准。

## 6. 章节映射矩阵模板

### 基础研究型

| 科学问题 | 假设 | 研究内容 | 方法/模型 | 前期基础 | 预期认识 | 创新点 | 风险替代 |
|---|---|---|---|---|---|---|---|
| 待填 | 待填 | 内容1 | 方法1 | 数据/论文/模型 | 机制/规律 | 新对象/新方法/新理论 | 替代模型/替代样本 |

### 任务攻关型

| 指南指标 | 总目标 | 任务 | 技术路线 | 交付物 | 验收方式 | 责任单位 | 预算依据 | 风险替代 |
|---|---|---|---|---|---|---|---|---|
| 待填 | 待填 | 任务1 | 路线1 | 样机/平台/标准 | 测试条件 | 单位A | 材料/测试/劳务 | 备用方案 |

## 7. 版本推进流程

### V0：约束与素材盘点

输出：信息采集表、约束矩阵、事实台账、缺失信息清单。  
质量标准：知道“不能写什么、必须写什么、还缺什么”。

### V1：主线与骨架

输出：一句话主线、六句故事线、章节结构、核心矩阵、标题备选、摘要骨架。  
质量标准：大同行能在一分钟内复述项目要解决的问题、为什么重要、怎么解决、结果如何验证。

### V2：完整正文草稿

输出：可粘贴正文草稿，包括标题、摘要、立项依据、目标、内容、路线、创新、基础、成果、风险、预算说明等。  
质量标准：所有章节都有文本，不因为缺信息而空白；缺信息用占位符和待核验项标出。

### V3：模拟评审与红队审查

输出：评分表、扣分点、致命风险、优先修改清单、需同步调整章节。  
质量标准：每个扣分点都能转化成具体改写动作或补充材料。

### V4：定稿润色

输出：替换后的正文、图表标题、摘要终稿、标题终稿、形式审查清单。  
质量标准：逻辑一致、措辞克制、无明显空泛形容词、无不实承诺、无未解释缩写。

### V5：Word 交付文档

输出：一个 `.docx` 文件，内含正文草稿 + 约束矩阵 + 事实台账 + 附件/预算/合规清单 + 红队审查 + 最终核验清单。  
质量标准：申请人可以据此让财务、伦理、科技处、合作单位分别核验；文件可用 Word 打开并继续修订。

## 8. 可交付正文的章节要求

### 标题

- 应包含对象、问题/瓶颈、关键路线或预期机制中的 2–3 个要素。
- 避免只写技术名词堆叠，也避免“重大意义”“创新研究”等空泛词。
- 对任务型项目，标题尽量体现场景或交付；对基础研究，标题尽量体现科学问题或机制。

### 摘要/项目简介

- 第一段不要长背景，尽快交代问题和缺口。
- 必须出现研究对象、核心问题、路线/方法、预期结论或交付物、价值。
- 不能只列“采用 A、B、C 方法”；要说明这些方法如何共同回答问题。
- 对任务型项目，应出现指标、场景、示范或验收逻辑。

### 立项依据

- 从“大背景”进入“具体缺口”，最后落到“本项目的科学问题/技术瓶颈”。
- 国内外进展不是文献堆砌，而是证明“为什么现有方案还不够”。
- 每一节末尾最好有小结句，把评审带回项目主线。

### 研究目标与研究内容

- 目标是要达到的认识、机制、方法或指标；内容是为了达到目标要做的工作。
- 每个研究内容对应一个目标、一个方法组合、一个预期结果和一个风险替代。
- 避免目标、内容、创新、成果重复堆写。

### 技术路线/研究方案

- 按“输入—步骤—关键方法—输出—验证”写。
- 每个关键步骤说明为什么选该方法、如何控制变量、如何判断成功。
- 对高风险环节给出替代方法或阶段性止损方案。

### 创新点

- 创新点不是“首次、领先、突破”的形容词，而是“相对谁，改变了什么，带来什么新能力/新认识”。
- 每条创新点都应能回到科学问题或指南指标。
- 不确定的新颖性用“拟建立、拟揭示、拟形成”而不是绝对化断言。

### 可行性与前期基础

- 用前期数据、论文、专利、平台、团队分工、样本/场景、合作条件支撑。
- 每个主要任务至少有一个基础证据；没有证据时标注“待补充前期数据”。
- 不要把团队成员简历堆成可行性；要说明为什么这些能力足以完成本项目。

### 预算与验收

- 预算要能回到任务、方法、材料、测试、设备、劳务和交付物。
- 任务型项目的指标需要阈值、测试条件、评价方法、责任主体和验收材料。
- 不知道预算规则时，只写预算逻辑，不写具体合规判断。

## 9. 红队评审问题库

写完 V2 后，至少用以下问题审查：

1. 评审能否在标题和摘要中看出“为什么非做不可”？
2. 项目解决的是科学问题、技术瓶颈，还是只是方法清单？
3. 国内外进展是否真正证明了缺口，而不是泛泛综述？
4. 研究目标是否过多、过散或不可验证？
5. 研究内容之间是否有逻辑依赖？若一个失败，是否全盘失败？
6. 创新点是否有对照对象和具体增量？
7. 前期基础是否支撑每个关键任务？
8. 技术路线是否写清输入、输出、验证和失败替代？
9. 指标是否可测、可验收、可归责？
10. 预算是否与任务匹配，是否可能被认为不合理？
11. 附件、伦理、数据、知识产权、合作协议是否齐全？
12. 全文术语是否一致，缩写是否首次解释？
13. 是否存在“待补充”留在最终交付正文中而未列入核验清单？
14. 是否存在夸大、不可证实或容易被形式审查否决的表述？

## 10. Word 最终交付格式模板

以下结构应写入 `.docx` 文件，而不是只作为聊天中的 Markdown 输出。

```text
# 项目书可交付版本

## A. 版本说明
- 项目类型：
- 资助方/年度：
- 当前版本：Vx
- 依据材料：
- 尚需申请人确认：

## B. 一句话主线
【对象】中存在【问题/瓶颈】，本项目基于【前期基础/假设】，通过【路线】，形成【认识/技术/产品/平台/标准】，支撑【学术/应用/社会价值】。

## C. 指南约束响应矩阵
见表。

## D. 申请书正文草稿
按申报模板输出。

## E. 红队评审意见
- 致命风险：
- 高优先级修改：
- 中优先级修改：

## F. 附件与合规清单
见表。

## G. 待补充与最终核验清单
见表。
```

## 11. 交付时的措辞边界

- 可以写：“基于申请人提供的材料，形成以下可交付草稿。”
- 可以写：“以下内容需申请人按当年指南和依托单位要求核验。”
- 不要写：“保证可提交、保证中标、已完成合规审查。”
- 不要替申请人承诺未核实事项，如合作单位盖章、伦理批件、样本数量、预算报价、第三方检测、用户场景等。


path: references/expert_wisdom_synthesis.md
content: # 权威来源写作经验归类：无姓名、无 URL 版本

本文件用于“专家经验融合模式”。它不是来源书目，也不保存具体个人姓名或裸 URL；只保留来自可靠来源、能够转化为项目申请书写作动作的共识。若用户要求核验具体来源，应在当前会话中使用用户提供材料或联网核验，而不是把姓名和链接写入 Skill。

## 1. 使用边界

- 本文件用于提升写作质量、模拟评审视角和建立检查清单。
- 本文件不能替代当年指南、申报系统、模板、预算规则、附件要求、伦理规则和依托单位通知。
- 对单一来源、无法交叉验证、带商业宣传色彩或缺少官方发布背景的观点，不写入本文件。
- 输出时不要说“某专家认为”；应说“从可靠来源归纳出的写作动作是……”。
- 不生成或暗示未经核实的项目事实、论文、专利、数据、合作、预算、伦理批件或专家评价。

## 2. 来源可靠性分级

| 级别 | 来源类型 | 可用于什么 | 使用限制 |
|---|---|---|---|
| S0 | 用户上传的当年指南、模板、评分标准、依托单位通知和项目事实材料 | 确定硬约束、章节结构、页数、预算、附件、资格和实际项目事实 | 优先级最高；若与内置经验冲突，以 S0 为准 |
| S1 | 资助机构、申报系统或官方管理办法 | 确定正式规则、评审维度、诚信、伦理、预算和提交要求 | 只采用可核验的正式规则；年份变化项必须重新确认 |
| S2 | 资助机构或评审机构发布的写作建议、评审说明和形式审查清单 | 理解评审逻辑、常见扣分点、摘要/目标/影响力写法 | 属于指导意见，不替代当年具体指南 |
| S3 | 高校、医院、研究院等官方渠道发布的专家讲座纪要或科研管理培训材料 | 提炼评审沟通、科学问题凝练、立项依据组织、可行性和打磨经验 | 只采纳多来源一致的原则；不写姓名、不写链接、不当作硬规则 |
| S4 | 同行评议论文或权威数据库收录的 grant-writing 文章 | 补充国际通行写作规律、预评审、具体目标页、影响力和可行性表达 | 需要转译为中文项目申请书语境 |
| S5 | 普通博客、商业培训稿、自媒体、未公开课件 | 原则上不写入 Skill | 如用户主动提供，只作为低权重启发并标注未核验 |

## 3. 可靠性筛选规则

只有同时满足以下条件的经验才写入本文件：

1. 能被 S1/S2 来源支持，或在多个 S3/S4 来源中反复出现。
2. 能转化为具体写作动作，而不是空泛口号。
3. 不依赖单个人的身份背书。
4. 不要求保存具体姓名、单位、网址或未公开材料。
5. 不与当年指南、模板、伦理、诚信和依托单位要求冲突。

## 4. 主题一：评审视角与信息传递

### 经验融合

项目书首先是写给评审看的，不是写给作者自己的研究笔记。高质量申请书应让不同专业深度的评审在短时间内看懂：项目为什么重要、核心问题是什么、为什么现在能做、怎么判断做成、失败风险如何处理。

### 写作动作

1. 标题、摘要和总目标先回答“研究对象、关键缺口、核心路线、预期认识或交付成果”。
2. 每章段首尽量先给结论，再给依据；避免评审读完一页才知道重点。
3. 减少背景铺陈，把篇幅留给缺口、假设、方法、验证和可行性。
4. 对跨学科项目，术语首次出现时给出清晰解释，并保持全文一致。
5. 定稿前做“一分钟复述”：非本细分方向的大同行能否复述项目主线。

### 适用项目

所有项目，尤其适合竞争激烈、跨学科、评审时间有限、摘要权重较高的项目。

## 5. 主题二：资助口径与项目类型匹配

### 经验融合

不同项目类型对“好申请书”的定义不同。基础研究类项目更看重科学问题、科学假设、机制认识和学术贡献；任务型科技计划更看重指南响应、指标、交付物、组织实施和验收；人才类项目同时评价申请人的学术主线、代表性贡献、独立性、未来潜力和研究环境。

### 写作动作

1. 写作前先判断项目类型：基础研究、任务攻关、平台建设、示范应用、人才项目或企业联合项目。
2. 基础研究避免产品化口号，重点写“未知是什么、假设是什么、如何验证”。
3. 任务型项目避免只讲论文意义，重点写“指标、成果、场景、用户、验收和组织实施”。
4. 人才类项目避免罗列成果，重点写长期主线、独立贡献、学术辨识度和未来跃迁。
5. 每类项目都要建立“评分维度—章节内容—证据材料”的映射表。

### 适用项目

国家自然科学基金、国家重点研发计划、地方科技计划、人才项目、企业联合攻关、平台和示范类项目。

## 6. 主题三：科学问题、技术瓶颈与选题凝练

### 经验融合

可靠来源反复强调：申请书的灵魂不是方法堆砌，而是清晰、有限、可研究、可验证的问题。基础研究要凝练科学问题；应用项目要凝练技术瓶颈或场景瓶颈；任务型项目还要说明瓶颈为什么会影响指标、交付和应用。

### 写作动作

1. 用一句话写清“已有研究已经解决什么，仍未解决什么”。
2. 科学问题不要写成研究任务，例如“构建模型”不是科学问题，背后的机制、规律或因果关系才是问题。
3. 技术瓶颈不要写成设备清单，要写清现有技术在哪个场景、哪个指标、哪个边界条件下失效。
4. 问题数量控制在 1–3 个，并与研究内容一一对应。
5. 如果缺少直接前期证据，不要强行拔高为重大突破，应降低表述强度并标注待补充证据。

### 适用项目

基础研究、应用基础研究、重点研发、地方科技计划和企业联合攻关项目。

## 7. 主题四：标题、摘要与故事线

### 经验融合

标题和摘要是评审形成第一判断的入口。高质量摘要不是背景综述，也不是方法清单，而是压缩后的完整论证：重要性、缺口、假设或路线、研究内容、验证方式、预期认识或交付价值。

### 写作动作

1. 标题尽量包含研究对象、核心问题或机制/瓶颈，不只堆方法名。
2. 摘要第一句给出对象和问题，避免从宏大背景起笔。
3. 摘要中至少出现一次明确缺口，例如“仍不清楚”“尚缺乏”“现有方法难以”。
4. 摘要要写验证方式，而不只是“开展研究”。
5. 摘要结尾要说明预期贡献：基础研究写新认识、新机制、新方法；任务型项目写成果、指标、场景和价值。

### 推荐六句故事线

1. 重要场景或科学背景中存在一个具体问题。
2. 现有研究或技术已经取得进展，但仍有关键缺口。
3. 申请人的前期基础提示了新的假设或路线。
4. 本项目拟围绕 1–3 个问题展开递进研究或任务。
5. 通过明确方法、模型、数据、实验、验证或示范来判断结果。
6. 预期形成可识别的新认识、新方法、关键技术、平台、标准或示范价值。

### 适用项目

所有项目，尤其适合摘要、项目简介、预申请、项目概述和人才项目的代表性主线表述。

## 8. 主题五：创新性与原创性表达

### 经验融合

创新不是形容词堆砌，而是相对现有研究或现有技术的清楚差异。可靠来源普遍强调，创新要能说明“相对于谁新、新在哪里、为什么这个新法能解决原问题、如何验证它确实带来增益”。

### 写作动作

1. 每个创新点都写成“现有做法—不足—本项目新做法—预期增益”。
2. 避免单独使用“首次、国际领先、突破性”等无法证明的表述。
3. 基础研究创新可写新假设、新机制、新模型、新理论、新方法或新证据链。
4. 应用项目创新可写场景组合、关键指标提升、系统集成、标准化验证、工程化路径或示范模式。
5. 高风险原创项目要同时写“为什么值得冒险”和“失败后仍能产生什么知识或可用成果”。

### 适用项目

所有项目；对原创探索、青年/面上基金、人才项目和重点攻关项目尤其重要。

## 9. 主题六：研究方案、可行性与风险替代

### 经验融合

优秀项目书要让评审相信“问题重要，并且申请人能做成”。可行性来自前期数据、方法掌握、平台条件、团队分工、合作资源、样本或场景可得性，以及风险替代路径，而不是来自空泛的团队介绍。

### 写作动作

1. 每个研究内容写清：输入材料/数据 → 方法步骤 → 输出结果 → 验证标准。
2. 每个关键方法说明为什么适合当前问题，而不是只列方法名称。
3. 每个高风险环节给出替代方案，例如替代模型、替代样本、替代算法、替代测试路径。
4. 前期基础按研究任务分组，说明“已有证据支撑哪个任务”。
5. 控制目标数量，避免任务过散、指标过多、周期和预算无法支撑。

### 适用项目

所有项目；对青年项目、重点研发、地方科技计划、应用示范和企业联合攻关项目尤其关键。

## 10. 主题七：前期基础、团队与研究环境

### 经验融合

评审不仅看想法，也看申请人和团队是否处在“能完成这件事”的位置。可信的前期基础应与研究内容直接相连，团队介绍应对应任务分工，研究环境应说明资源如何支撑项目完成。

### 写作动作

1. 把前期基础按研究内容或任务分组，而不是按年份罗列。
2. 对每项基础写清“已有证据—支撑什么—还缺什么”。
3. 团队分工写到角色和接口：谁负责模型、实验、算法、样本、场景、转化、管理。
4. 合作单位只写可核实的资源和角色，不替合作方承诺未确认内容。
5. 人才类项目突出申请人的独立贡献、持续主线和未来发展空间。

### 适用项目

人才类项目、青年/面上基金、重点研发、平台建设、示范项目和跨单位联合项目。

## 11. 主题八：指标、影响与验收逻辑

### 经验融合

任务型项目不只要意义重大，还要能交付和验收。高质量申请书应把目标、任务、指标、交付物、验收方式、责任单位和预算形成闭环。基础研究也应说明预期认识、学术价值和可能影响，而不应只写论文数量。

### 写作动作

1. 每个指标写清阈值、测试条件、评价方法、责任主体和验收材料。
2. 每个交付物对应任务、预算和验收证据。
3. 影响写作从直接产出、受益主体、应用场景、推广路径和社会/产业价值展开。
4. 不把“发表论文、申请专利”当作任务型项目的唯一成果。
5. 地方科技计划和应用示范项目要加入本地场景、用户需求、示范路径和转化条件。

### 适用项目

国家重点研发计划、地方科技计划、企业联合攻关、平台建设、示范项目和转化类项目。

## 12. 主题九：形式审查、伦理、数据与科研诚信

### 经验融合

很多申请不是败在想法，而是败在形式审查、附件、伦理、预算、数据、安全、知识产权、资格和诚信。可交付版本必须把合规作为独立交付物，而不是只润色正文。

### 写作动作

1. 用当年指南、模板和依托单位通知制作形式审查表。
2. 涉及人类受试者、临床样本、动物实验、遗传资源、数据采集、算法数据、隐私或安全时，标注伦理和数据合规要求。
3. 合作单位、用户场景、第三方测试、样本来源、知识产权只写已确认内容。
4. 参考文献、成果、专利、奖励和前期项目必须可核验，避免虚假、夸大或错误归属。
5. 定稿前检查人工智能辅助使用声明是否符合资助方和依托单位要求。

### 适用项目

所有正式申报项目。

## 13. 主题十：反复打磨、预评审与版本管理

### 经验融合

可靠来源普遍建议尽早开始、先写核心页、让不同背景的人预读，并进行多轮版本迭代。可交付项目书应保留版本记录，说明每轮修改解决了什么问题，还剩哪些风险。

### 写作动作

1. V1 阶段先让预读者看标题、摘要、目标和科学问题，不急于全文润色。
2. V2 阶段让方法或工程专家看路线、数据、样本、指标和可行性。
3. V3 阶段让大同行看可读性、主线和创新性。
4. V4 阶段让科研管理、财务、伦理、数据或知识产权人员看形式、预算、附件和合规。
5. 每轮修改保留“改了什么—为什么改—还缺什么”的记录。

### 适用项目

所有项目；对截止期紧张、跨单位、跨学科、任务型和预算复杂项目尤其重要。

## 14. 专家经验共识表

| 主题 | 稳定共识 | 可执行动作 | 主要来源层级 |
|---|---|---|---|
| 评审视角 | 申请书要先服务评审理解 | 段首结论、摘要压缩、主线复述 | S1/S2/S3/S4 |
| 项目类型 | 不同资助类型不能套同一模板 | 先建资助口径矩阵 | S0/S1/S2/S3 |
| 科学问题 | 方法不是问题，问题要有限可验证 | 写“已知—未知—为什么重要” | S1/S2/S3/S4 |
| 摘要故事线 | 摘要是压缩论证，不是综述 | 用六句故事线改写 | S2/S3/S4 |
| 创新性 | 创新要有比较对象和验证方式 | 写“现有不足—新法—增益” | S1/S2/S3/S4 |
| 可行性 | 前期基础要支撑具体任务 | 建立任务—基础—风险表 | S2/S3/S4 |
| 指标与影响 | 任务型项目必须可交付可验收 | 指标写阈值、条件、材料 | S0/S1/S2 |
| 合规诚信 | 形式、伦理、数据、附件会影响提交 | 做定稿合规清单 | S0/S1/S2 |
| 版本打磨 | 好申请书来自多轮预评审 | 建立 V1–V5 版本记录 | S2/S3/S4 |

## 15. 低质量写法清单

- 背景宏大，但没有具体问题。
- 题目只有方法，没有对象、问题或场景。
- 摘要前半篇都是行业意义，后半篇只列方法。
- 创新点全是“首次、领先、突破”，没有比较对象和验证方式。
- 研究内容像工作包清单，目标像口号。
- 技术路线图好看，但文字没有输入、输出和验证标准。
- 前期基础只堆论文和成果，不说明支撑哪个任务。
- 指标没有阈值、测试条件、评价方法或责任主体。
- 预算和任务脱节。
- 合作、伦理、样本、数据、知识产权没有证据。
- 全文术语不一致，同一概念多种叫法。
- 最终文本仍保留“待补充”，但没有核验清单。

## 16. 使用本文件时的输出建议

当用户要求“专家感悟归类总结”时，建议输出：

1. 来源可靠性分级说明，但不列具体人名和 URL。
2. 按主题归类的共识表。
3. 每个主题下的可执行写作动作。
4. 对中国项目申请书的转译规则。
5. 哪些内容只作为启发，哪些必须以当年官方指南和用户材料为准。

不要输出长篇专家语录；不要假装阅读过未公开讲义或培训课件；不要用个人名望替代对申请书文本的实际修改。


path: references/funder_rules.md
content: # 资助方规则：科技部、上海市科委、国家自然科学基金与人才类项目

本文件用于判断不同资助方的写作口径、审查重点、常见风险和章节结构。通用写作经验优先使用本文件及其他内置资料；正式提交前必须核验当年官方指南、模板、预算、附件和系统提示。

## 目录

1. 资料权重与更新规则
2. 科技部国家重点研发计划
3. 上海市科委科技计划
4. 国家自然科学基金
5. 杰青优青等人才类项目
6. 三类核心矩阵
7. 资助方合规风险清单

---

## 1. 资料权重与更新规则

### 1.1 必须核验最新版本的事项

以下事项每年或每批次可能变化，不能只依赖本技能内置资料：

- 年度指南、申报通知、申请书模板、在线系统字段。
- 支持范围、禁止方向、指南方向、申请代码、项目类别。
- 申请资格、依托单位要求、年龄职称要求、在研项目限项、参与人限项。
- 评审方式、答辩方式、预申报与正式申报关系、是否需要现场考察。
- 正文字数页数、图表格式、上传材料、盖章签字和附件清单。
- 预算方式、包干制或预算制、自筹资金、设备费、外协费、测试化验加工费等科目限制。
- 科技伦理、人类遗传资源、生物安全、实验动物、科学数据汇交、知识产权、保密、合作协议。
- 人工智能辅助写作声明、代表作规则、申请人贡献说明。

### 1.2 权威顺序

1. 当年官方指南、申报书模板和系统提示。
2. 官方管理办法、预算规则、申报问答、形式审查要求。
3. 依托单位科研管理部门发布的通知和解释。
4. 归纳后的评审写作逻辑。
5. 公开样例和低权重经验材料。

若低层级建议与高层级规则冲突，以高层级规则为准。

---

## 2. 科技部国家重点研发计划

### 2.1 主导写作身份

科技部国家重点研发计划通常不是“个人想做的研究”，而是“完成国家任务的组织实施方案”。写作时要体现任务导向、目标导向、指标导向、集成验证和项目组织能力。

关键词：国家需求、指南指标、关键瓶颈、任务分解、牵头协调、联合攻关、系统集成、示范应用、验收指标、预算匹配、成果交付。

### 2.2 核心策略

- 先读指南，再写申请书；先建指标覆盖矩阵，再写正文。
- 每一条指南指标都要落到目标、任务、方法、交付物、验证方式、责任单位和预算。
- 任务分解要服务最终集成成果，避免多个单位各写一段、拼成项目。
- 技术路线要写清样品流、数据流、平台流、算法流、设备流、系统集成流和验证流。
- 多单位项目要写牵头协调、接口管理、质量控制、阶段考核、风险上报和数据知识产权管理。
- 预算必须对应任务必要性、测算依据和交付成果，尤其是设备、测试、材料、外协和示范费用。
- 预申报与正式申报要一致，正式申报可以细化，但不能削弱承诺指标或删去核心内容。

### 2.3 推荐结构

1. 项目定位与指南响应。
2. 国家或行业需求与关键瓶颈。
3. 总体目标和量化考核指标。
4. 任务分解、课题分解和接口关系。
5. 技术路线、集成路线和验证路线。
6. 创新点和关键突破。
7. 组织实施与项目管理。
8. 里程碑和阶段考核。
9. 预期成果、示范应用、标准、数据和知识产权。
10. 风险识别和替代方案。
11. 经费预算和自筹资金。
12. 伦理、安全、数据、保密、合作协议和附件。

### 2.4 评审常见疑问与修正

| 评审疑问 | 为什么扣分 | 修正动作 |
|---|---|---|
| 只是复制指南目标 | 看不出怎么完成 | 建立目标—任务—方法—交付物—验收矩阵 |
| 联合单位很多但接口弱 | 像拼盘，不像项目 | 增加接口图、共享里程碑、集成交付物 |
| 指标模糊 | 后期无法验收 | 写阈值、条件、测试方法和第三方验证 |
| 企业或用户只是挂名 | 转化和示范不可信 | 写清数据、样品、场地、测试、标准化和应用角色 |
| 预算与任务脱节 | 财务和形式审查风险高 | 每项大额经费对应任务、方法、成果和测算依据 |
| 风险写成口号 | 管理能力不足 | 写预警阈值、替代路线、责任人和触发条件 |

---

## 3. 上海市科委科技计划

### 3.1 主导写作身份

上海市科委项目应写成“上海场景下可实施、可管理、可验收的科技项目”。重点不是简单说明项目在上海做，而是说明项目为什么服务上海战略、产业链、临床需求、城市治理、绿色低碳、人工智能、生物医药、先进制造、平台建设或民生场景。

关键词：上海相关性、本市需求、应用场景、合同验收、任务书、示范应用、自筹资金、合作协议、科学数据、科技伦理、知识产权、科研诚信。

### 3.2 核心策略

- 明确说明“为什么是上海需要”，不要只写“依托单位位于上海”。
- 把成果写成可纳入合同或任务书的验收内容。
- 合作单位要写任务、经费、自筹、数据样品场地贡献、知识产权和成果分享。
- 若延续已有项目，要写继承关系、差异、非重复资助和新增价值。
- 涉及伦理、数据、样本、临床、城市运行或企业场景时，正文、附件和承诺必须一致。

### 3.3 上海相关性段落模板

本项目面向上海【产业/临床/城市治理/绿色低碳/公共服务/前沿科学平台】中的【具体需求】，当前存在【技术瓶颈或服务短板】，制约【本市重点领域发展或场景应用】。依托【单位平台、合作企业、医院、园区、示范场景】的【数据、样本、设备、用户或应用条件】，项目拟形成【成果】，并在【上海具体场景】开展验证，为【上海战略任务或产业链环节】提供支撑。

### 3.4 常见评审疑问与修正

| 评审疑问 | 修正动作 |
|---|---|
| 上海相关性弱 | 增加本市需求、场景、用户、产业链或平台定位 |
| 成果无法验收 | 把论文专利之外的成果写成指标、测试、应用或交付物 |
| 合作协议与正文不一致 | 同步任务、经费、知识产权、数据和成果归属 |
| 自筹资金不可信 | 说明来源、用途、到账计划和对应任务 |
| 数据或伦理风险未处理 | 写数据来源、授权、脱敏、伦理审批和安全措施 |

---

## 4. 国家自然科学基金

### 4.1 主导写作身份

国家自然科学基金申请书应写成“围绕重要科学问题的研究计划”。核心不是要做多少实验，也不是开发产品，而是提出清晰科学问题、形成合理假设、设计可验证方案，并产出新机制、新规律、新理论、新方法或新认识。

关键词：科学问题、学术价值、创新性、研究内容、研究方案、前期基础、申请人能力、可行性、预期科学贡献。

### 4.2 核心策略

- 从领域重要现象或理论矛盾出发，逐步推出未解科学问题。
- 摘要和立项依据要让大同行看懂，方案和基础要让小同行信服。
- 研究内容一般控制在三到四项，形成递进关系，不要堆实验。
- 研究方案要写关键模型、样本、方法、变量、对照、评价指标和统计或验证逻辑。
- 创新性要在与已有研究比较后形成，不要只说“首次、领先、突破”。
- 前期基础只放能直接支撑假设、方法和可行性的证据。
- 预期结果要区分“科学认识”和“成果形式”：论文专利不是科学问题的答案。

### 4.3 国家自然科学基金逻辑链

| 节点 | 应回答的问题 | 常放位置 |
|---|---|---|
| 重要现象 | 为什么这个问题值得研究 | 摘要、立项依据开头 |
| 已有进展 | 别人已经知道什么 | 立项依据 |
| 关键缺口 | 仍不知道什么，争议在哪里 | 立项依据、科学问题 |
| 科学假设 | 你认为背后的机制或规律是什么 | 摘要、目标、内容 |
| 研究内容 | 用哪几步验证假设 | 研究内容 |
| 研究方案 | 具体怎么做，如何判断成功 | 研究方案 |
| 前期基础 | 为什么你能做成 | 工作基础、可行性 |
| 预期认识 | 做完后能新增什么学术认知 | 摘要、预期结果、创新 |

### 4.4 常见评审疑问与修正

| 评审疑问 | 修正动作 |
|---|---|
| 科学问题不清 | 用一句话写“仍未知的是……” |
| 立项依据像综述 | 每段末尾写“因此，本项目需要解决……” |
| 研究内容像实验清单 | 改为“内容一解决什么问题、验证什么假设” |
| 方法先进但问题普通 | 让方法服务科学问题，不把工具当创新 |
| 创新点空泛 | 写“相对已有研究，本项目的新视角/新机制/新方法是……” |
| 前期基础堆成果 | 只保留与本项目直接相关的发现、数据和能力 |

---

## 5. 杰青优青等人才类项目

### 5.1 主导写作身份

人才类项目不是普通项目书的放大版，而是“个人学术主线、代表性贡献和未来跃迁”的综合展示。评审既看研究计划，也看申请人是否已经形成独立学术方向、是否有代表性贡献、是否具备继续引领的潜力。

### 5.2 推荐故事线

1. 申请人长期围绕什么学术主线。
2. 过去解决了哪些关键问题，形成哪些代表性贡献。
3. 这些贡献在领域中为什么有识别度。
4. 当前前沿还有什么更高层次问题没有解决。
5. 未来五年准备如何跃迁。
6. 团队、平台和学科方向将如何受益。

### 5.3 常见硬伤

不要写成成果清单。要把论文、专利、奖项、项目、平台和学生培养转化为一条主线：

> 长期关注的问题 → 代表性发现或技术 → 对领域认知或应用的改变 → 未解决的新前沿 → 未来要形成的引领方向。

### 5.4 人才类摘要特别要求

- 第一层写“人”：申请人的长期主线和已形成的贡献。
- 第二层写“问题”：未来要解决的前沿缺口。
- 第三层写“计划”：拟开展的研究内容和平台建设。
- 第四层写“影响”：学术引领、团队建设、学科平台或国家地方需求贡献。

---

## 6. 三类核心矩阵

### 6.1 指南指标覆盖矩阵

适用于科技部、上海、应用示范、企业项目。任何空格都代表高风险。

| 指南要求 | 对应目标 | 对应任务 | 方法路线 | 交付成果 | 验收方式 | 责任单位 | 预算支撑 | 风险与替代 |
|---|---|---|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |

### 6.2 科学逻辑矩阵

适用于国家自然科学基金和基础研究项目。

| 科学问题 | 科学假设 | 研究内容 | 关键方法 | 前期基础 | 预期认识 | 创新点 | 风险控制 |
|---|---|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |

### 6.3 故事评审矩阵

| 故事节点 | 申请书位置 | 当前表达 | 评审风险 | 修改动作 |
|---|---|---|---|---|
| 为什么重要 | 标题、摘要、立项依据 | 待填 | 待填 | 待填 |
| 缺口或冲突 | 摘要、立项依据 | 待填 | 待填 | 待填 |
| 新假设或新路线 | 摘要、目标 | 待填 | 待填 | 待填 |
| 行动计划 | 内容、任务 | 待填 | 待填 | 待填 |
| 为什么是我们 | 基础、团队 | 待填 | 待填 | 待填 |
| 可验证结局 | 成果、指标 | 待填 | 待填 | 待填 |

---

## 7. 资助方合规风险清单

### 7.1 科技部国家重点研发计划

- 联合申报协议：任务、指标、经费、知识产权、签章和日期。
- 相关单位和人员科研诚信承诺。
- 企业资质、用户场景证明或示范承诺。
- 自筹或配套资金证明。
- 科技伦理、生物安全、人类遗传资源、实验动物、数据汇交、安全审查。
- 预申报和正式申报的一致性。
- 经费测算与任务、设备、测试和外协的一致性。

### 7.2 上海市科委

- 在线提交和依托单位审核时间。
- 上海注册、实施、场景和成果转化相关性。
- 在研项目限项和项目负责人资格。
- 不含涉密或敏感内容。
- 科技伦理和科技安全审查。
- 科学数据记录和汇交。
- 合作协议、知识产权归属、收益分配、自筹资金。
- 回避评审相关信息和不当承诺材料。

### 7.3 国家自然科学基金

- 当年项目指南和学部补充说明。
- 正确申请代码、研究属性和项目类别。
- 申请资格、限项和参与限制。
- 主要参与人简历、在线确认和同意。
- 代表性成果的署名、贡献和全文附件要求。
- 伦理敏感内容审查。
- 不含涉密或不宜公开内容。
- 人工智能辅助内容需由申请人核验，并按当年规则声明或标注。


path: references/knowledge_boundaries.md
content: # 内置资料库：官方口径、写作逻辑与公开样例使用规则

本文件说明本技能已经内置哪些稳定资料结论，以及何时仍需核验最新官方信息。使用时优先调用本文件中的资料卡，不再为普通写作经验临时搜索网页。

## 目录

1. 使用原则
2. 什么时候不需要另查网页
3. 什么时候必须核验最新资料
4. 来源可信度分级
5. 官方口径资料卡
6. 写作逻辑共识资料卡
7. 国际通用写作原则资料卡
8. 公开样例使用规则
9. 禁止生成的内容
10. 维护规则

---

## 1. 使用原则

本文件不是链接清单，而是可执行写作知识库。使用时直接转化为诊断、改写、结构设计、评分清单和一致性检查。

本技能不按具体个人姓名呈现经验。领域认可经验已经整合为“摘要逻辑、故事线、立项依据、创新性、可行性、评审沟通”等写作共识。除非用户明确要求溯源核验，否则不输出个人名录和个人观点对照表。

## 2. 什么时候不需要另查网页

以下任务优先使用本技能内置资料：

- 解释申请书主要模块和模块逻辑。
- 修改标题、摘要、立项依据、目标、内容、技术路线、创新、可行性、预算、风险、合规等章节。
- 整合领域认可写作经验和评审视角。
- 设计项目故事线。
- 生成通用模板、矩阵和清单。
- 对用户提供的文本做评审式诊断。

## 3. 什么时候必须核验最新资料

以下任务不能只依赖内置资料：

- 用户要正式提交某一年、某批次、某指南方向申请。
- 涉及限项、年龄、职称、单位资格、预算科目、附件、模板、截止时间、在线系统字段。
- 涉及伦理、人类遗传资源、生物安全、科学数据、保密、人工智能使用声明等可能变化的要求。
- 用户要求可点击来源或逐条核验权威材料。

处理方式：优先让用户上传当年指南和模板；工具允许时只查官方、资助机构、依托单位或权威期刊材料，不用论坛和培训帖替代。

## 4. 来源可信度分级

| 等级 | 来源 | 用途 |
|---|---|---|
| 一级 | 当年官方指南、模板、系统提示、管理办法、预算规则、权威期刊文章 | 决定硬性要求、结构、预算、附件、合规 |
| 二级 | 领域认可专家公开辅导、获资助者经验、评审经验、官方机构发布的写作材料 | 优化摘要、故事线、创新、可读性、常见硬伤 |
| 三级 | 匿名论坛、商业培训、无法核验来源 | 只能提示常见问题，不能作为权威依据 |

## 5. 官方口径资料卡

### 5.1 科技部国家重点研发计划

核心口径：国家任务导向、指南指标覆盖、联合攻关、任务分解、系统集成、成果交付、示范验证、预算匹配。

转化动作：建立“指南原文—目标—任务—方法—交付物—验收—责任单位—预算”矩阵；摘要中写需求、瓶颈、总目标、任务组织、交付物、验证和价值；技术路线中写接口和集成节点。

### 5.2 上海市科委科技计划

核心口径：上海场景、本市需求、合同验收、示范应用、数据与伦理、知识产权、合作协议、自筹资金。

转化动作：立项依据单列上海相关性；目标写可考核指标；实施方案写用户、场景、示范和数据汇交；附件同步合作、自筹、伦理、知识产权和无涉密承诺。

### 5.3 国家自然科学基金

核心口径：科学问题、学术价值、创新性、研究方案、前期基础、申请人能力。

转化动作：建立“科学问题—假设—内容—方法—基础—预期认识—创新—风险”矩阵；摘要使用六到七句结构；研究内容按确认、解析、验证递进；预期结果写机制、规律、模型、方法或新认识。

### 5.4 人才类项目

核心口径：个人学术主线、代表性贡献、独立性、未来跃迁、团队平台带动。

转化动作：先写“长期主线—代表性贡献—未解前沿—未来跃迁”；代表作按主线贡献排序；摘要体现个人贡献和未来引领，不写成普通项目简介。

## 6. 写作逻辑共识资料卡

### 6.1 大同行可理解，小同行能信服

核心结论：题目和摘要要让非窄领域评审理解问题价值、缺口和路线；方案和基础要让小同行相信专业性和可行性。

写作动作：摘要前两句减少缩写，先讲问题价值；方案中写清对象、变量、模型、对照、指标和验证；研究现状客观比较代表性工作。

### 6.2 三个基本追问

核心结论：申请书必须持续回答“为什么重要、为什么可行、为什么由申请人或团队承担”。

写作动作：立项依据回答重要性；方案和风险回答可行性；前期基础、平台、团队和场景条件回答承担能力。

### 6.3 创新性与聚焦

核心结论：创新是项目竞争力的核心，但创新必须聚焦，不能靠大题目、热门方法或宣传词支撑。

写作动作：题目收窄到明确对象、过程或瓶颈；创新点写比较对象、创新内容、解决问题和验证方式；删除没有证据的“首次、领先、突破”。

### 6.4 摘要最后压缩，但最先服务评审

核心结论：摘要应在目标、内容、方案和基础基本成型后再写，但它是评审最先阅读、最容易记住的部分。

写作动作：摘要覆盖问题提出、基本思路、核心内容、关键方法和主要意义；每一句对应正文一个核心模块；避免背景过长。

### 6.5 申请书是书面答辩

核心结论：申请书没有口头解释机会，必须在题目、摘要、立项依据和路线图中形成完整故事线。

写作动作：先写六句故事线；再让标题、摘要、目标、内容、方案、创新和基础全部围绕同一主线展开。

### 6.6 人才类项目要讲学术主线

核心结论：人才类项目不是成果清单，而是个人长期学术判断、代表性贡献和未来跃迁的完整故事。

写作动作：代表性成果按学术贡献排序；每项成果说明“提出了什么、建立了什么、推动了什么”；未来方向要承接过去并体现新高度。

## 7. 国际通用写作原则资料卡

国际资助机构写作原则仅作为通用评审逻辑参考，不替代中国资助方要求。

- 清楚表达研究意图与价值：标题、摘要和目标页必须让非窄领域评审理解。
- 项目摘要三要素：项目概览、知识或技术贡献、广泛影响。
- 八问压力测试：做什么、现状局限、新路线、受益者、风险、成本、周期、成功标准。

## 8. 公开样例使用规则

可以学习：结构、标题、摘要、任务分解、指标写法、路线图、前期基础选择、预算与任务对应。

不可照搬：他人原文、图表、未公开数据、前期基础、论文贡献、专利、合作单位、用户场景、商业模板和未经授权材料。

当用户提供样例时，输出：

| 项目 | 内容 |
|---|---|
| 样例来源类型 | 官方样例、公开摘要、用户上传文本、其他 |
| 可学习点 | 结构、标题、摘要、任务、指标、图表 |
| 不可照搬点 | 数据、原文、图表、未公开设计、他人基础 |
| 可迁移模板 | 抽象出的结构或句式 |
| 本项目适配 | 需要按用户项目重写的部分 |

## 9. 禁止生成的内容

- 未经核实的论文、专利、项目、奖项、平台、样机、数据。
- 伪造专家评价、用户承诺、第三方检测、伦理批件。
- 无法核实的“已获批项目就是这么写的”。
- 他人未公开申请书段落、图表和技术路线。
- 不符合当年指南的预算、附件和合规声明。
- 未经授权或不应公开的涉密、敏感材料。

## 10. 维护规则

- 本文件保留稳定写作原则，不替代当年官方指南。
- 新增资料必须转化为“来源类型、核心共识、写作动作、适用项目类型”，不按个人姓名建档。
- 无法核验的建议来源，应降为低权重经验。
- 正式申报最终以当年官方指南、系统模板和依托单位科研管理部门要求为准。

path: references/module_writing_guide.md
content: # 模块写作手册：逐章细化要求、模板与自检

本文件用于写作、诊断和改写申请书各模块。每个模块都按“目的—评审问题—写作结构—句式模板—常见错误—自检清单”处理。

## 目录

1. 使用方法
2. 通用模块写作法
3. 标题
4. 关键词
5. 摘要、项目简介
6. 立项依据、项目背景、需求分析
7. 国内外研究现状、技术现状
8. 科学问题、技术瓶颈
9. 研究目标、总体目标、考核指标
10. 研究内容、任务分解
11. 研究方案、技术路线、方法学
12. 创新点
13. 前期基础、研究基础、可行性
14. 团队、组织实施与协同机制
15. 进度安排、里程碑与验收
16. 预期成果、应用示范与成果转化
17. 经费预算与测算依据
18. 风险分析与替代方案
19. 伦理、数据、知识产权、安全与保密
20. 图表、路线图与附件
21. 全文一致性检查

---

## 1. 使用方法

处理用户文本时，先判断项目类型，再进入对应模块。不要只润色语言，要同时检查逻辑、指南匹配、评审疑问、证据支撑和合规风险。

标准输出顺序：

1. 模块定位。
2. 当前文本主要问题。
3. 评审可能疑问。
4. 改写策略。
5. 可替换文本。
6. 需要同步修改的其他章节。
7. 待补充信息。

## 2. 通用模块写作法

### 2.1 每个模块都要回答的六个问题

| 问题 | 对应要求 |
|---|---|
| 为什么写这一段 | 明确模块目的，不写无功能内容 |
| 评审会问什么 | 站在评审角度组织信息 |
| 与指南如何对应 | 任务、指标、范围、合规要可追溯 |
| 与主线如何对应 | 回到同一句科学问题或技术瓶颈 |
| 有什么证据支撑 | 前期数据、文献、平台、样机、场景、团队 |
| 成功如何判断 | 指标、验证、成果、里程碑或科学认识 |

### 2.2 通用段落公式

> 【背景或场景】说明为什么重要；【已有进展】说明别人做到哪里；【缺口或瓶颈】说明为什么还需要本项目；【本项目判断】说明新假设或新路线；【行动】说明拟做什么；【验证】说明如何判断；【价值】说明做成后贡献什么。

### 2.3 通用诊断清单

- 是否有明确对象、场景或问题。
- 是否能对应指南、申请代码或项目类别。
- 是否存在空泛口号。
- 是否过度承诺。
- 是否缺少前期证据。
- 是否与标题、摘要、目标和内容一致。
- 是否存在形式审查或合规风险。

---

## 3. 标题

### 3.1 目的

标题决定评审的第一印象和项目归类。好标题应让评审快速知道研究对象、核心问题、研究层级和成果方向。

### 3.2 评审问题

- 这个题目是否属于本项目类别支持范围？
- 题目是否聚焦到一个可完成的问题？
- 题目是否过度承诺？
- 题目是否与摘要、目标和研究内容一致？

### 3.3 写作结构

国家自然科学基金标题：对象 + 科学问题/机制/规律 + 研究。  
科技部和上海项目标题：场景/需求 + 关键技术/系统/平台 + 研发/示范/应用。  
人才类项目标题：学术主线 + 未来方向，必要时体现申请人长期贡献。

### 3.4 句式模板

- 【对象】中【关键过程】的【机制】研究。
- 【关键因素】调控【对象/过程】的【机制】。
- 面向【场景】的【关键技术】研发与示范。
- 【关键瓶颈】突破及【成果形态】构建。

### 3.5 常见错误

- 题目像口号，缺对象、问题和边界。
- 题目写得很大，研究内容很小。
- 把方法当题目主体，问题不清。
- 应用类项目题目没有场景和成果形态。
- 基础研究题目像产品开发。

### 3.6 自检清单

- 题目能否一句话解释给非窄领域专家？
- 题目中的每个关键词是否在正文中反复出现？
- 题目是否避免未经证实的“首创、领先、突破”？
- 题目是否符合指南长度和格式？

---

## 4. 关键词

### 4.1 目的

关键词用于体现研究对象、核心问题、方法、场景和评审匹配。关键词不是宣传词。

### 4.2 国家自然科学基金写法

建议包含：研究对象、科学问题、关键机制或过程、关键方法、学科方向。

示例结构：

> 【对象】；【机制/过程】；【关键变量】；【方法/模型】；【学科方向】。

### 4.3 科技部与上海项目写法

建议包含：场景、关键技术、成果形态、验证方式、应用领域。

示例结构：

> 【场景】；【关键技术】；【平台/装备/系统】；【示范验证】；【标准/数据/应用】。

### 4.4 常见错误

- 全是大词，没有具体对象。
- 全是方法，没有问题。
- 与申请代码或指南方向不一致。
- 关键词之间没有层级关系。

### 4.5 自检清单

- 是否覆盖对象、问题、方法和场景？
- 是否能帮助评审快速归类？
- 是否与标题和摘要一致？

---

## 5. 摘要、项目简介

### 5.1 目的

摘要是评审最先读、最容易记住、最能影响第一判断的模块。它不是背景介绍，也不是研究内容目录，而是项目故事的高度压缩。

### 5.2 评审问题

- 项目为什么重要？
- 现有研究或技术缺口是什么？
- 申请人的新假设或新路线是什么？
- 研究内容是否递进？
- 为什么这个团队能做？
- 结果能带来什么新认识、指标或成果？

### 5.3 国家自然科学基金摘要结构

1. 重要性：具体对象或现象的重要性。
2. 已有认识：已有研究发现了什么。
3. 缺口：仍未知什么或争议在哪里。
4. 假设：基于前期基础提出什么判断。
5. 内容：拟开展哪两到三项递进研究。
6. 方法：用什么模型、样本、方法或验证体系。
7. 意义：将形成什么新机制、新规律、新方法或新依据。

### 5.4 科技部与上海项目简介结构

1. 需求或场景。
2. 技术瓶颈或指标缺口。
3. 总体目标。
4. 任务组织。
5. 核心技术路线。
6. 交付成果。
7. 验证方式和验收指标。
8. 团队基础、场景基础和应用价值。

### 5.5 人才类摘要结构

1. 申请人长期学术主线。
2. 已有代表性贡献。
3. 当前前沿缺口。
4. 未来研究计划。
5. 学术引领和团队平台贡献。

### 5.6 常见错误

- 摘要前半都是宏观背景。
- 没有“但……”引出缺口。
- 没有前期基础或为什么是你。
- 研究内容只是名词堆砌。
- 结尾只写论文专利，不写科学或技术价值。
- 缩写、术语太多，大同行看不懂。

### 5.7 自检清单

- 摘要能否标注出每句话的功能？
- 是否包含问题、缺口、假设或路线、行动、验证和结局？
- 是否控制背景比例？
- 是否与目标、内容、方案和基础一致？

---

## 6. 立项依据、项目背景、需求分析

### 6.1 目的

立项依据要证明项目“值得资助”。它不是百科式综述，而是把已有进展、关键缺口和本项目必要性连成逻辑链。

### 6.2 评审问题

- 这个问题是否重要且真实存在？
- 已有研究或技术已经做到哪里？
- 为什么还没有解决？
- 本项目切入点是否自然、必要、聚焦？
- 与指南或资助方向是否匹配？

### 6.3 国家自然科学基金推荐结构

1. 领域现象或科学背景：说明重要性。
2. 已有研究进展：分层而非流水账。
3. 关键缺口或争议：指出仍未知内容。
4. 申请人前期发现：引出科学假设。
5. 本项目必要性：说明为何要由本项目解决。

### 6.4 科技部与上海项目推荐结构

1. 国家或上海战略需求。
2. 行业、临床、产业或城市治理场景痛点。
3. 现有技术或产品短板。
4. 指南指标与现实差距。
5. 本项目解决瓶颈的必要性和紧迫性。
6. 场景、用户、平台和团队条件。

### 6.5 文献和现状写法

- 按问题逻辑组织，不按年份流水账。
- 每段最后要回到缺口：“因此仍需解决……”
- 国内同行工作不能省略，也不能贬低式描述。
- 对他人成果要客观，避免夸大自己的唯一性。
- 应用类项目要比较技术路线、指标、成本、效率、适用场景和成熟度。

### 6.6 段落模板

【已有研究/技术】已经在【方面】取得进展，表明【已知结论】。然而，在【条件/对象/场景】下，【关键机制/技术瓶颈】仍未明确，导致【科学认识不足或应用受限】。申请人前期【发现/建立/获得】提示【新判断】，因此本项目拟聚焦【科学问题/关键瓶颈】开展研究。

### 6.7 常见错误

- 背景很宏大，缺少具体缺口。
- 综述像论文引言，和项目目标没有关系。
- 只说国外先进，国内空白，没有证据。
- 把指南原文直接复制，没有转成项目问题。
- 应用类项目没有量化现状差距。

### 6.8 自检清单

- 每段是否服务同一主线？
- 是否从已有进展自然推出缺口？
- 是否说明本项目为什么必要？
- 是否有文献、数据、场景或指南支撑？

---

## 7. 国内外研究现状、技术现状

### 7.1 目的

现状分析要证明申请人了解领域全貌，并能准确定位本项目差异。它不是文献数量展示，而是比较和判断。

### 7.2 推荐结构

1. 按研究问题或技术路线分组。
2. 每组说明代表性进展。
3. 比较优势和局限。
4. 提出本项目切入点。

### 7.3 基础研究比较表

| 方向 | 代表性进展 | 已解决问题 | 未解决问题 | 本项目切入点 |
|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 |

### 7.4 技术现状比较表

| 技术路线 | 性能或指标 | 优势 | 局限 | 适用场景 | 本项目改进 |
|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |

### 7.5 常见错误

- 只罗列文献，不比较。
- 只写国外，不写国内。
- 只讲别人的不足，不承认已有进展。
- 技术比较没有指标条件。
- 最后没有推出本项目路线。

### 7.6 自检清单

- 是否有分组逻辑？
- 是否写出“已有进展”和“剩余缺口”？
- 是否能支持创新点？

---

## 8. 科学问题、技术瓶颈

### 8.1 目的

科学问题或技术瓶颈是项目的发动机。没有清晰问题，后面的目标、内容、路线和创新都会散。

### 8.2 国家自然科学基金科学问题要求

好的科学问题应满足：

- 重要：解决后能推进领域认识。
- 未解：不是常规验证或重复研究。
- 聚焦：一个项目能够回答。
- 可验证：能通过设计的研究内容获得证据。
- 有基础：申请人已有证据支持切入。

### 8.3 科学问题句式

- 【对象】在【条件】下发生【现象】的【关键机制】是什么？
- 【因素】如何调控【过程】，并导致【结果】？
- 【已有理论】为何不能解释【新现象】，其背后【机制】是什么？
- 【前期发现】提示【假设】，但【关键环节】仍需验证。

### 8.4 科技部与上海技术瓶颈要求

好的技术瓶颈应满足：

- 与指南指标或场景痛点直接相关。
- 能被任务分解和技术路线解决。
- 有量化指标或验证条件。
- 不是泛泛说“效率低、成本高、稳定性差”，而要说明在哪个环节、什么条件、差多少。

### 8.5 技术瓶颈句式

现有【技术/系统/流程】在【场景/条件】下存在【具体瓶颈】，主要表现为【量化差距或现象】，其根本原因在于【机制、材料、算法、工艺、标准、数据或集成问题】，导致【应用限制】。本项目拟通过【新路线】突破该瓶颈。

### 8.6 常见错误

- 把研究内容当科学问题。
- 科学问题太大，项目无法回答。
- 技术瓶颈没有指标条件。
- 问题与前期基础不相关。
- 问题与指南不对应。

### 8.7 自检清单

- 能否用一句话说清核心问题？
- 问题是否出现在摘要、立项依据、目标和内容中？
- 每项研究内容是否回答该问题的一部分？

---

## 9. 研究目标、总体目标、考核指标

### 9.1 目的

目标规定项目完成后要回答什么问题、形成什么能力或达到什么指标。目标必须可判断，不能只写愿景。

### 9.2 目标层级

| 层级 | 内容 |
|---|---|
| 总体目标 | 项目完成后的核心科学认识或成果能力 |
| 分目标 | 支撑总体目标的三到五个子目标 |
| 指标 | 可量化、可验证、可验收的条件和阈值 |
| 成果 | 论文、专利、平台、样机、标准、数据、示范等形式 |

### 9.3 国家自然科学基金目标写法

- 总目标：阐明、揭示、建立、解析某机制或规律。
- 分目标：围绕假设递进展开。
- 不要把“发表论文”写成研究目标。

模板：

> 本项目拟阐明【科学问题】中【关键机制/规律】，重点实现以下目标：一是明确【环节一】；二是解析【环节二】；三是验证【机制/模型】并形成【新认识/方法】。

### 9.4 科技部与上海目标写法

- 总目标要对应指南目标和验收指标。
- 指标要写数值、条件、检测方法、时间节点和应用场景。
- 分目标要能映射到任务和预算。

模板：

> 项目拟突破【关键技术】，形成【成果形态】，在【场景】实现【指标一、二、三】，完成【示范/验证/标准/平台】，支撑【应用价值】。

### 9.5 指标类型

- 技术指标：精度、灵敏度、效率、稳定性、通量、能耗、寿命、成本等。
- 工程指标：样机数量、平台规模、数据量、示范点、测试条件。
- 成果指标：标准、软件、数据库、专利、论文、报告、人才培养。
- 应用指标：用户验证、场景部署、经济社会效益、服务对象。

### 9.6 常见错误

- 目标像口号，无法判断是否完成。
- 指标无测试条件。
- 分目标与研究内容不对应。
- 应用类项目没有验收语言。
- 基础研究项目目标过于工程化。

### 9.7 自检清单

- 每个目标是否有对应研究内容？
- 每个指标是否有测量方法和验收条件？
- 总目标是否与摘要和标题一致？

---

## 10. 研究内容、任务分解

### 10.1 目的

研究内容说明项目具体做什么。好的研究内容不是实验列表，而是解决核心问题的递进步骤。

### 10.2 推荐数量

- 国家自然科学基金：通常三到四项研究内容，形成递进。
- 科技部和上海项目：按指南和任务书要求设置课题或任务，数量服从组织实施需要。
- 人才类项目：围绕未来主线设置二到四个方向，体现跃迁。

### 10.3 每项内容四句结构

1. 本内容解决什么子问题。
2. 为什么这个子问题必要。
3. 采用什么方法或任务组织。
4. 预期得到什么证据、指标或成果。

### 10.4 国家自然科学基金递进模式

- 模式一：发现现象 → 解析机制 → 验证功能。
- 模式二：建立模型 → 揭示规律 → 干预验证。
- 模式三：识别关键因素 → 阐明通路 → 构建理论或方法。

模板：

> 内容一：明确【现象/关键因素】。通过【方法】，回答【子问题】，为后续【内容二】提供依据。  
> 内容二：解析【机制/关系】。围绕【假设】，采用【方法】，揭示【过程】。  
> 内容三：验证【模型/机制】。在【体系】中验证【机制】并评估【意义】。

### 10.5 科技部与上海任务递进模式

- 需求分析与指标体系。
- 关键技术研发。
- 系统或平台集成。
- 中试、示范、测试和标准化。

模板：

> 任务一：突破【关键技术一】，形成【模块/方法】。  
> 任务二：突破【关键技术二】，实现【功能/指标】。  
> 任务三：集成【系统/平台】，完成【验证】。  
> 任务四：在【场景】开展示范应用，形成【标准/报告/数据/产品】。

### 10.6 接口写法

任务型项目必须写任务接口：

| 上游任务 | 输出 | 下游任务 | 接口形式 | 时间节点 | 责任单位 |
|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |

### 10.7 常见错误

- 内容之间并列堆砌，没有递进。
- 每项内容都写得像方法清单。
- 任务与指南指标不对应。
- 多单位任务边界不清。
- 内容过多，超出周期和经费能力。

### 10.8 自检清单

- 每项内容是否回答一个子问题？
- 内容之间是否存在先后逻辑？
- 每项内容是否有方法、基础和预期输出？

---

## 11. 研究方案、技术路线、方法学

### 11.1 目的

研究方案回答“怎么做、为什么这样做、如何判断结果”。技术路线要让评审相信项目不是想法，而是可执行计划。

### 11.2 推荐结构

1. 总体思路。
2. 分内容或分任务方案。
3. 关键方法和关键参数。
4. 样本、模型、对象、对照和评价指标。
5. 数据分析、统计、质量控制或测试方法。
6. 技术路线图。
7. 难点、风险和替代方案。

### 11.3 需要写细的内容

- 样本来源、选择标准、数量依据和质量控制。
- 模型构建、实验条件、关键变量和对照。
- 算法、数据处理、训练验证、评价指标和可解释性。
- 设备、材料、工艺参数、测试标准和环境条件。
- 伦理、授权、脱敏、安全和数据管理。

### 11.4 国家自然科学基金方案要求

- 每项研究内容都要有可验证的实验或分析路径。
- 不只写“采用某技术”，还要写该技术如何回答科学问题。
- 对可能出现的阴性结果、样本不足、模型不稳定要有替代方案。

### 11.5 科技部与上海技术路线要求

- 路线图要体现从需求到产品、平台、系统或示范的完整链条。
- 写清任务接口、集成节点、测试节点和验收节点。
- 关键指标要对应测试条件和责任单位。

### 11.6 方法段落模板

为验证【假设/实现目标】，本项目将在【对象/场景】中采用【方法】，重点测定/构建/评估【关键变量或指标】。通过【对照/比较/验证体系】判断【机制/性能】，并采用【统计/测试/第三方验证】保证结果可靠。

### 11.7 常见错误

- 只列方法名，没有说明为什么用。
- 关键难点一笔带过。
- 缺少对照、质量控制和评价指标。
- 技术路线图只是流程图，没有输入输出和验证节点。
- 方案与目标和内容不对应。

### 11.8 自检清单

- 评审能否看出每项内容怎么完成？
- 是否写清关键条件和评价指标？
- 是否有替代方案？
- 路线图是否能独立讲清项目？

---

## 12. 创新点

### 12.1 目的

创新点回答“为什么本项目不是重复已有工作”。创新不能只靠形容词，而要靠比较、差异和可验证贡献。

### 12.2 创新点结构

每个创新点按四句写：

1. 现有研究或技术怎么做。
2. 其局限是什么。
3. 本项目新在哪里。
4. 该创新将解决什么问题，如何验证。

### 12.3 国家自然科学基金创新类型

- 新科学问题或新视角。
- 新机制或新规律。
- 新模型或新理论框架。
- 新方法用于回答未解问题。
- 新证据链打通关键环节。

### 12.4 科技部与上海创新类型

- 关键技术突破。
- 系统集成创新。
- 工艺、装备、平台或软件创新。
- 标准、场景、模式和验证体系创新。
- 成本、效率、精度、稳定性或可推广性提升。

### 12.5 句式模板

相较于已有【研究/技术】主要关注【现有路径】，本项目从【新视角/新机制/新路线】出发，提出【创新内容】，并通过【验证方式】证明其在【科学认识/技术指标/应用场景】中的价值。

### 12.6 常见错误

- 把使用新设备、新软件、新方法当创新。
- 只写“首次、原创、领先”，不写比较对象。
- 创新点与研究内容不对应。
- 创新太多，反而显得主线不聚焦。

### 12.7 自检清单

- 每个创新点是否有比较对象？
- 是否能被研究内容验证？
- 是否与标题和摘要的亮点一致？

---

## 13. 前期基础、研究基础、可行性

### 13.1 目的

前期基础回答“为什么是你，为什么能做成”。它不是成果清单，而是支撑本项目假设、方法、样本、平台和团队能力的证据链。

### 13.2 推荐结构

1. 与科学问题或技术瓶颈直接相关的前期发现。
2. 已建立的方法、模型、平台、样本、设备或场景。
3. 已发表成果、专利、软件、数据、标准或样机。
4. 团队分工和协同基础。
5. 依托单位条件和合作单位支持。

### 13.3 证据映射表

| 本项目目标或任务 | 所需能力 | 已有基础 | 证明材料 | 仍需补强 |
|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 |

### 13.4 可行性写法

- 科学可行性：假设有前期证据和文献支撑。
- 技术可行性：关键方法已建立或有替代路线。
- 组织可行性：团队分工清楚、合作接口明确。
- 条件可行性：平台、设备、样本、数据、场景可获得。
- 时间经费可行性：任务量与周期和预算匹配。

### 13.5 常见错误

- 堆论文和奖项，但与本项目无关。
- 没有前期数据支撑核心假设。
- 合作单位作用不具体。
- 可行性只写“团队经验丰富”。
- 没有说明关键资源如何获得。

### 13.6 自检清单

- 每条基础是否对应某个目标、内容或风险？
- 是否能回答“为什么是你”？
- 是否有直接证据，而不是泛泛资历？

---

## 14. 团队、组织实施与协同机制

### 14.1 目的

团队与组织实施要证明项目有人做、能协同、能管理、能交付。任务型项目尤其要强调项目管理和接口。

### 14.2 推荐结构

1. 项目负责人能力和相关贡献。
2. 核心成员分工。
3. 联合单位角色。
4. 协同机制和会议制度。
5. 数据、样品、平台、成果和知识产权管理。
6. 质量控制和风险上报机制。

### 14.3 分工表

| 成员或单位 | 角色 | 负责内容 | 关键能力 | 交付成果 |
|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 |

### 14.4 常见错误

- 名单很强，但分工不清。
- 合作单位只是挂名。
- 多单位项目没有接口和管理机制。
- 团队优势与项目任务无关。

### 14.5 自检清单

- 每个关键任务是否有人负责？
- 牵头单位如何协调？
- 数据、知识产权和成果归属是否清楚？

---

## 15. 进度安排、里程碑与验收

### 15.1 目的

进度安排证明项目在周期内能完成。里程碑不是时间表装饰，而是阶段性成果和风险控制节点。

### 15.2 推荐结构

1. 按年度或季度列出任务。
2. 每个阶段对应阶段成果。
3. 关键节点设置验收或评估指标。
4. 风险高的节点设置替代方案。

### 15.3 里程碑表

| 时间 | 主要任务 | 阶段成果 | 验证方式 | 风险预警 | 责任单位 |
|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |

### 15.4 常见错误

- 只有时间，没有成果。
- 第一年前期准备过长，后期任务过满。
- 多任务并行但资源不匹配。
- 里程碑与验收指标不一致。

### 15.5 自检清单

- 每个阶段是否有可检查输出？
- 时间安排是否与方法难度匹配？
- 风险节点是否有备选方案？

---

## 16. 预期成果、应用示范与成果转化

### 16.1 目的

成果模块回答项目完成后留下什么。基础研究要写新认识和学术贡献，任务型项目要写可验收成果和应用价值。

### 16.2 国家自然科学基金成果写法

- 新机制、新规律、新模型、新理论或新方法。
- 学术论文、数据资源、方法体系等成果形式。
- 对学科发展的贡献。

不要只写论文数量，应先写科学贡献，再写成果形式。

### 16.3 科技部与上海成果写法

- 产品、样机、装备、工艺、平台、软件、数据库、标准、报告、示范点。
- 技术指标和验收条件。
- 用户、场景、第三方测试或应用验证。
- 知识产权、标准化和转化路径。

### 16.4 成果表

| 成果类型 | 具体成果 | 对应任务 | 指标或验收方式 | 应用场景 | 责任单位 |
|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |

### 16.5 常见错误

- 基础研究只写论文专利。
- 应用项目成果不可验收。
- 成果与目标和任务不对应。
- 示范应用没有用户和场景。

### 16.6 自检清单

- 成果是否能对应每个目标？
- 是否有验收或评价方式？
- 是否与预算和进度一致？

---

## 17. 经费预算与测算依据

### 17.1 目的

预算说明要证明经费用得必要、合理、可测算，并与任务和成果一致。

### 17.2 写作原则

- 先按当年预算制度和依托单位要求执行。
- 每项大额支出都要对应任务、方法或交付成果。
- 设备、材料、测试、外协、会议、差旅、劳务等应说明必要性和测算依据。
- 自筹资金和配套资金要说明来源、用途和到位计划。
- 不确定科目必须标注“需按当年预算规则确认”。

### 17.3 预算任务映射表

| 经费科目 | 金额 | 对应任务 | 测算依据 | 必要性 | 成果或指标 |
|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |

### 17.4 常见错误

- 预算与任务脱节。
- 大额设备没有必要性。
- 测试和外协没有说明内容和依据。
- 劳务、差旅、会议与任务周期不匹配。
- 自筹资金没有来源和用途。

### 17.5 自检清单

- 每项经费是否有任务对应？
- 是否符合当年预算规则？
- 金额是否有测算逻辑？
- 是否与合作协议和附件一致？

---

## 18. 风险分析与替代方案

### 18.1 目的

风险模块不是形式化表态，而是证明申请人知道难点、能监控、能调整。

### 18.2 风险类型

- 科学风险：假设不成立、关键机制不明显、样本异质性大。
- 技术风险：方法不稳定、指标达不到、集成失败、算法泛化不足。
- 资源风险：样本、数据、设备、场景或合作条件不足。
- 进度风险：关键节点延迟。
- 合规风险：伦理、数据、知识产权、安全和保密。
- 管理风险：多单位协同不足。

### 18.3 风险表

| 风险 | 发生环节 | 影响 | 预警指标 | 替代方案 | 责任人 |
|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |

### 18.4 替代方案写法

若【关键方法/任务】在【条件】下未达到【指标】，将采用【替代方法】，并通过【验证方式】判断是否满足【最低可接受标准】，以保证【目标或交付成果】不受根本影响。

### 18.5 常见错误

- 只写“加强管理、及时沟通”。
- 风险与关键难点不对应。
- 没有预警指标。
- 替代方案不可执行。

### 18.6 自检清单

- 是否覆盖最可能被评审质疑的难点？
- 是否有触发条件和替代路线？
- 风险控制是否影响预算和进度？

---

## 19. 伦理、数据、知识产权、安全与保密

### 19.1 目的

合规模块保护项目通过形式审查和后续实施。此类内容必须以当年官方要求和依托单位规定为准。

### 19.2 科技伦理

涉及人体、临床、样本、隐私、动物实验、遗传资源、生物安全、人工智能决策等内容时，需要说明：

- 伦理审批状态或计划。
- 知情同意、样本来源和使用范围。
- 数据脱敏、最小化使用和访问控制。
- 风险受益评估。
- 责任主体和审批材料。

### 19.3 科学数据

说明数据来源、采集、存储、质量控制、共享或汇交、脱敏、安全和长期管理。应用类项目要说明数据如何支撑验证和成果交付。

### 19.4 知识产权

联合项目要写清知识产权归属、成果转化、许可、收益分配和背景知识产权边界。正文、合作协议和附件必须一致。

### 19.5 安全与保密

不得在申请书中写入涉密或不宜公开内容。若涉及敏感场景、网络安全、重大装备、特殊数据等，按指南和单位要求处理。

### 19.6 人工智能辅助写作

人工智能可用于草稿、结构、诊断和润色，但申请人必须核验事实、文献、数据和表达，并按当年资助方要求进行声明或标注。不得提交未经核验的生成内容。

### 19.7 自检清单

- 是否涉及伦理或安全敏感内容？
- 是否已准备审批或说明材料？
- 数据来源和权限是否清楚？
- 合作协议与正文是否一致？
- 是否需要人工智能使用声明？

---

## 20. 图表、路线图与附件

### 20.1 目的

图表帮助评审快速理解结构、递进、接口、指标和证据。附件支撑真实性和合规性。

### 20.2 推荐图表

- 项目故事线图：背景、缺口、路线、成果。
- 科学问题逻辑图：问题、假设、内容、方法、预期认识。
- 技术路线图：输入、关键技术、集成、验证、输出。
- 任务接口图：各单位和任务之间的输入输出。
- 指标覆盖表：指南指标到任务和验收。
- 前期基础映射表：基础到目标和方法。
- 风险替代路线表。

### 20.3 图表要求

- 图题本身要能说明图的功能。
- 图中要有输入、处理、输出和验证节点。
- 不要把复杂流程堆成看不清的装饰图。
- 图表内容要与正文一致。

### 20.4 附件清单

| 附件 | 适用情况 | 需核验事项 |
|---|---|---|
| 合作协议 | 联合申报 | 任务、经费、知识产权、签章日期 |
| 伦理批件或说明 | 人体、动物、样本、隐私等 | 审批主体、范围、有效期 |
| 自筹证明 | 需要配套资金 | 来源、金额、用途、到位计划 |
| 用户或场景证明 | 示范应用 | 场地、数据、测试、用户角色 |
| 知识产权材料 | 专利、软件、背景技术 | 权属、许可、转化安排 |
| 代表性成果 | 基金和人才类 | 署名、贡献、全文或证明材料 |

### 20.5 常见错误

- 图表漂亮但没有信息。
- 图表和正文不一致。
- 附件承诺与预算或任务冲突。
- 忘记形式审查要求的签章和日期。

---

## 21. 全文一致性检查

### 21.1 一条主线检查

把全文压缩成一句话。如果标题、摘要、目标、内容、方案、创新、基础和成果不能回到这句话，说明主线散。

### 21.2 十项一致性

| 检查项 | 通过标准 |
|---|---|
| 标题与摘要 | 摘要完整解释标题 |
| 摘要与目标 | 摘要中的承诺都出现在目标中 |
| 目标与内容 | 每个目标有对应内容 |
| 内容与方案 | 每项内容有执行方案 |
| 方案与基础 | 关键方法有前期基础 |
| 创新与内容 | 创新点能被内容验证 |
| 成果与目标 | 成果能证明目标完成 |
| 预算与任务 | 经费支撑具体任务 |
| 风险与难点 | 风险覆盖关键质疑点 |
| 附件与正文 | 承诺、经费、任务和知识产权一致 |

### 21.3 最终自检

- 评审能否在一分钟内复述项目？
- 是否有一个最强亮点？
- 是否解决指南或科学问题的核心，而不是边缘问题？
- 是否有足够前期基础支撑高风险部分？
- 是否所有硬性要求都已核验？


path: references/templates_checklists.md
content: # 模板清单：矩阵、评分表、自检表与可复用提示词

本文件用于快速输出结构化结果。使用时根据用户任务复制对应模板，并用用户项目信息替换“待填”。

## 目录

1. 指南解读模板
2. 一句话主线与故事线模板
3. 标题生成模板
4. 摘要改写模板
5. 整本申请书框架模板
6. 核心矩阵
7. 评分表
8. 自检清单
9. 评审意见回复模板
10. 可复用提示词
11. 模块精修输出模板
12. 每模块写作自检总表

---

## 1. 指南解读模板

| 指南条款 | 申请书需要响应的内容 | 对应章节 | 当前材料状态 | 风险等级 | 修改动作 |
|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 高/中/低 | 待填 |

输出时补充：

- 项目是否落入支持范围。
- 可能的形式审查风险。
- 必须响应的指标。
- 必须准备的附件。
- 当前最缺的信息。

## 2. 一句话主线与故事线模板

### 2.1 国家自然科学基金一句话

针对【对象】中的【科学问题】，本项目基于【前期发现】提出【科学假设】，采用【方法体系】阐明【机制/规律】，为【学科或应用基础】提供【新认识】。

### 2.2 科技部与上海一句话

面向【场景】中的【瓶颈】，本项目通过【核心路线】突破【关键技术】，形成【成果】，达到【指标】，支撑【价值】。

### 2.3 人才类一句话

申请人围绕【学术主线】形成了【代表性贡献】，未来拟解决【前沿问题】，实现【学术跃迁】，带动【团队和领域】发展。

### 2.4 六句故事线

1. 【场景/现象】具有重要意义。
2. 已有研究或技术已经实现【进展】。
3. 但【缺口/瓶颈】仍未解决。
4. 本项目基于【前期基础】提出【假设/路线】。
5. 将开展【内容/任务一、二、三】。
6. 预期形成【新认识/成果/指标/示范】，支撑【价值】。

## 3. 标题生成模板

| 标题 | 类型 | 优点 | 风险 | 适用场景 | 推荐程度 |
|---|---|---|---|---|---|
| 待填 | 稳健/创新/应用/人才 | 待填 | 待填 | 待填 | 高/中/低 |

输出后给出：

- 首选标题。
- 为什么选择它。
- 若指南更偏基础或应用，如何微调。

## 4. 摘要改写模板

### 4.1 诊断表

| 维度 | 当前问题 | 评审风险 | 修改动作 |
|---|---|---|---|
| 问题价值 | 待填 | 待填 | 待填 |
| 缺口 | 待填 | 待填 | 待填 |
| 假设或路线 | 待填 | 待填 | 待填 |
| 研究内容 | 待填 | 待填 | 待填 |
| 可行性 | 待填 | 待填 | 待填 |
| 预期价值 | 待填 | 待填 | 待填 |
| 可读性 | 待填 | 待填 | 待填 |

### 4.2 国家自然科学基金摘要骨架

【对象/现象】在【领域】中具有重要意义，但其【机制/规律】仍未明确。已有研究提示【进展】，然而【缺口/争议】尚未解决。申请人前期发现【证据】，据此提出【假设】。本项目拟围绕【科学问题】，开展【内容一】、【内容二】和【内容三】，并结合【方法/模型/验证】阐明【机制】。预期将揭示【新认识】，为【学科/应用基础】提供【依据】。

### 4.3 科技部与上海项目简介骨架

面向【需求/场景】，现有【技术/系统】存在【瓶颈】，制约【应用】。本项目拟突破【关键技术】，构建【成果形态】，通过【任务一、二、三】实现【总体目标】。项目将在【场景】开展【测试/示范/验证】，达到【量化指标】，形成【平台/产品/标准/数据/示范】等成果，支撑【国家/上海/行业价值】。

### 4.4 人才类摘要骨架

申请人长期围绕【学术主线】开展研究，在【代表性方向】取得【核心贡献】，形成了【学术影响】。当前【前沿问题】仍缺乏【关键认识/方法】。未来拟聚焦【新问题】，通过【研究计划】实现【学术跃迁】，并带动【团队/平台/领域】发展。

## 5. 整本申请书框架模板

### 5.1 通用框架

1. 项目名称。
2. 摘要或项目简介。
3. 立项依据或需求分析。
4. 国内外研究现状或技术现状。
5. 科学问题或关键瓶颈。
6. 目标和指标。
7. 研究内容或任务分解。
8. 研究方案或技术路线。
9. 创新点。
10. 前期基础和可行性。
11. 团队和组织实施。
12. 进度与里程碑。
13. 预期成果和应用。
14. 预算说明。
15. 风险与替代方案。
16. 伦理、数据、知识产权、安全和附件。

### 5.2 国家自然科学基金精简框架

1. 立项依据与科学问题。
2. 研究目标。
3. 研究内容。
4. 研究方案与可行性。
5. 特色与创新。
6. 年度计划与预期结果。
7. 研究基础与工作条件。

### 5.3 科技部与上海任务型框架

1. 指南响应和项目定位。
2. 需求与瓶颈分析。
3. 总体目标和考核指标。
4. 任务分解和接口。
5. 技术路线和集成验证。
6. 创新与关键突破。
7. 组织实施和管理。
8. 进度、里程碑和验收。
9. 成果、示范、标准和转化。
10. 预算、风险、合规和附件。

## 6. 核心矩阵

### 6.1 指标覆盖矩阵

| 指南指标 | 总体目标 | 任务 | 方法 | 交付物 | 验收方式 | 责任单位 | 预算 | 风险 |
|---|---|---|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |

### 6.2 科学逻辑矩阵

| 科学问题 | 假设 | 内容 | 方法 | 基础 | 预期认识 | 创新 | 风险 |
|---|---|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |

### 6.3 基础到任务矩阵

| 前期基础 | 支撑目标 | 支撑方法 | 证明材料 | 仍需补强 |
|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 |

### 6.4 预算到任务矩阵

| 经费科目 | 金额 | 对应任务 | 测算依据 | 交付成果 | 风险 |
|---|---|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 | 待填 | 待填 |

### 6.5 附件清单矩阵

| 附件 | 是否需要 | 当前状态 | 风险 | 处理动作 |
|---|---|---|---|---|
| 合作协议 | 待填 | 待填 | 待填 | 待填 |
| 伦理批件或说明 | 待填 | 待填 | 待填 | 待填 |
| 自筹证明 | 待填 | 待填 | 待填 | 待填 |
| 用户或场景证明 | 待填 | 待填 | 待填 | 待填 |
| 知识产权材料 | 待填 | 待填 | 待填 | 待填 |
| 代表性成果 | 待填 | 待填 | 待填 | 待填 |

## 7. 评分表

| 维度 | 分值 | 评分问题 | 得分 | 主要扣分点 | 修改建议 |
|---|---:|---|---:|---|---|
| 指南匹配 | 10 | 是否对准指南和项目类别 | 待填 | 待填 | 待填 |
| 问题价值 | 10 | 问题是否重要且具体 | 待填 | 待填 | 待填 |
| 故事主线 | 10 | 是否有清楚因果链 | 待填 | 待填 | 待填 |
| 创新性 | 15 | 是否有比较后的真实创新 | 待填 | 待填 | 待填 |
| 研究方案 | 15 | 方法是否合理可执行 | 待填 | 待填 | 待填 |
| 前期基础 | 10 | 证据是否支撑关键假设或路线 | 待填 | 待填 | 待填 |
| 成果指标 | 10 | 是否可验证可验收 | 待填 | 待填 | 待填 |
| 团队组织 | 5 | 分工和协同是否可信 | 待填 | 待填 | 待填 |
| 预算风险 | 5 | 经费是否合理匹配 | 待填 | 待填 | 待填 |
| 合规附件 | 5 | 是否存在形式审查风险 | 待填 | 待填 | 待填 |
| 可读性 | 5 | 大同行是否能快速理解 | 待填 | 待填 | 待填 |

## 8. 自检清单

### 8.1 形式审查清单

- 是否使用当年模板。
- 是否符合字数页数和格式。
- 是否满足申请资格和限项。
- 是否选择正确项目类别和代码。
- 是否准备全部附件。
- 是否完成签章、日期、承诺和在线确认。
- 是否处理伦理、数据、安全、保密和人工智能使用声明。

### 8.2 内容质量清单

- 标题是否聚焦。
- 摘要是否讲完整故事。
- 立项依据是否推出缺口。
- 目标是否可判断。
- 内容是否递进。
- 方案是否具体。
- 创新是否有比较对象。
- 基础是否直接支撑项目。
- 成果是否可验证。
- 风险是否有替代方案。

### 8.3 科技部与上海清单

- 是否逐条覆盖指南指标。
- 是否写清任务接口和集成验证。
- 是否有场景、用户或示范条件。
- 是否有可验收成果。
- 是否说明合作单位任务和知识产权。
- 是否预算对应任务。

### 8.4 国家自然科学基金清单

- 科学问题是否明确。
- 假设是否有前期依据。
- 内容是否围绕假设递进。
- 方案是否写清关键方法和验证。
- 创新是否不是单纯方法新。
- 前期基础是否服务本项目。
- 预期结果是否写科学认识。

## 9. 评审意见回复模板

针对“【评审意见】”，申请书已在【章节】进行修改：一是补充【证据/说明】，明确【问题】；二是调整【目标/内容/方案】，使其与【指南/科学问题】一致；三是增加【风险控制/验证方式/附件】，提高项目可行性。修改后，项目主线由【原主线】进一步聚焦为【新主线】。

## 10. 可复用提示词

### 10.1 解读指南

请基于我提供的指南和项目想法，生成指南约束矩阵、指标覆盖矩阵、形式审查风险、建议申请书结构和待补充信息。请优先判断项目是否对口，并标出高风险条款。

### 10.2 生成标题

请根据以下项目主线和申报类型，生成十个中文标题，分别给出稳健型、创新型、评审友好型和应用交付型版本。每个标题说明优点、风险和适用条件，并推荐一个首选标题。

### 10.3 改写摘要

请按专家评审视角改写以下摘要。先给一句话主线和六句故事线，再诊断当前摘要的问题，最后给出稳健版、创新版和评审友好版。缺少事实请标“待补充”，不要编造。

### 10.4 诊断故事线

请检查以下申请书是否讲清楚“为什么重要、缺口在哪里、为什么是我们、怎么做、怎么验证、结果有什么价值”。请输出故事线诊断表、主线重构建议和需要同步修改的章节。

### 10.5 改立项依据

请将以下立项依据从“综述式写法”改为“评审式论证”：按背景、已有进展、关键缺口、前期发现、本项目必要性组织，并指出每段应补充的证据。

### 10.6 改技术路线

请诊断以下技术路线是否能支撑目标和指标。请补充输入、关键方法、输出、验证、风险和替代方案，并指出图表应如何重画。

### 10.7 科技部与上海指标覆盖

请把以下指南指标逐条映射到目标、任务、方法、交付物、验收方式、责任单位和预算。任何无法覆盖的指标请标为高风险。

### 10.8 国家自然科学基金精修

请按国家自然科学基金口径重构以下内容，突出科学问题、科学假设、研究内容递进、研究方案可行性、创新点和前期基础。请删除产品化、口号化和无关成果堆砌。

## 11. 模块精修输出模板

### 11.1 模块诊断

| 问题 | 位置 | 评审风险 | 修改建议 |
|---|---|---|---|
| 待填 | 待填 | 待填 | 待填 |

### 11.2 改写策略

- 主线如何收束。
- 哪些信息前移。
- 哪些证据补充。
- 哪些表述降调或删除。
- 哪些章节需要同步。

### 11.3 可替换文本

提供可直接粘贴的中文段落；缺失事实用“待补充”。

### 11.4 需要同步修改

| 章节 | 需要同步内容 |
|---|---|
| 标题 | 待填 |
| 摘要 | 待填 |
| 目标 | 待填 |
| 内容 | 待填 |
| 方案 | 待填 |
| 创新 | 待填 |
| 基础 | 待填 |
| 成果 | 待填 |

## 12. 每模块写作自检总表

| 模块 | 必须回答 | 常见硬伤 |
|---|---|---|
| 标题 | 研究什么、解决什么 | 大而空、方法堆砌 |
| 关键词 | 如何归类和匹配 | 全是大词或方法词 |
| 摘要 | 完整故事是什么 | 背景泛泛、无缺口 |
| 立项依据 | 为什么值得做 | 综述化、没有问题 |
| 现状 | 别人做到哪里 | 罗列文献、不比较 |
| 科学问题/瓶颈 | 核心卡点是什么 | 问题太大或不可验证 |
| 目标指标 | 完成后判断什么 | 口号化、不可验收 |
| 内容任务 | 做哪几件事 | 并列堆砌、不递进 |
| 方案路线 | 怎么做和怎么验证 | 方法名堆砌、缺对照 |
| 创新 | 新在哪里 | 没有比较对象 |
| 基础可行性 | 为什么能做 | 堆成果、无直接证据 |
| 团队组织 | 谁负责什么 | 挂名、接口不清 |
| 进度里程碑 | 何时完成什么 | 有时间无成果 |
| 成果转化 | 留下什么 | 只写论文专利 |
| 预算 | 钱为什么合理 | 与任务脱节 |
| 风险 | 出问题怎么办 | 口号化无替代 |
| 合规附件 | 能否过审 | 伦理、数据、签章遗漏 |

## 13. 可交付版本终检清单

用于整本项目书进入提交前审查。若任一关键项无法确认，不要在正文中伪装为已完成，应列入“最终核验清单”。

| 终检维度 | 必查问题 | 通过标准 | 未通过处理 |
|---|---|---|---|
| 指南匹配 | 是否逐条响应指南和评分标准 | 有约束响应矩阵 | 补矩阵并重排章节 |
| 事实证据 | 论文、专利、数据、平台、合作是否可核验 | 有事实台账 | 删除或标待核验 |
| 主线一致 | 标题、摘要、目标、内容、创新、基础是否讲同一问题 | 一句话主线可贯穿全文 | 先改摘要和目标，再回改各章 |
| 可验证性 | 目标和指标是否可验证/可验收 | 有阈值、条件、方法、材料 | 补验收或评价方案 |
| 可行性 | 每项任务是否有基础、资源和风险替代 | 任务—基础—风险闭环 | 补前期基础或缩小目标 |
| 预算 | 预算是否对应任务、材料、测试、设备、劳务和交付物 | 有预算依据和必要性说明 | 请财务核验后改写 |
| 附件 | 合作、伦理、数据、知识产权、承诺函是否齐全 | 附件清单完整 | 标为提交前必补 |
| 语言格式 | 缩写、术语、图表、页码、引用是否一致 | 形式审查无明显风险 | 最后一轮格式审校 |
| Word 交付 | 是否已经生成 `.docx` 文件，且正文、矩阵、清单、红队和核验项均在文档内 | 可用 Word 打开并继续修订 | 生成或重建 Word 文档，不以聊天 Markdown 作为最终交付 |


path: references/title_abstract_story.md
content: # 标题、摘要与故事线写法

本文件用于生成或修改项目标题、关键词、摘要、项目简介和故事线。核心原则：摘要不是正文缩写，而是评审在最短时间内理解项目价值、缺口、路线、可行性和结果的入口。

## 目录

1. 申请书里的“讲故事”是什么意思
2. 一句话项目主线
3. 标题写法
4. 关键词写法
5. 国家自然科学基金四百字摘要
6. 科技部与上海项目简介
7. 人才类项目摘要
8. 故事线结构
9. 大同行与小同行双层可读性
10. 摘要和故事线诊断

---

## 1. 申请书里的“讲故事”是什么意思

项目申请书的故事不是文学修辞，而是因果链：

> 重要场景或现象 → 已有进展 → 未解缺口或冲突 → 你的假设或新路线 → 研究内容或任务 → 前期证据和可行性 → 验证方式 → 预期价值。

好故事能让评审回答以下问题：

- 为什么这个问题现在值得资助？
- 现有研究或现有技术到底卡在哪里？
- 申请人的假设或路线新在哪里，为什么可信？
- 具体要做哪几件事，顺序是什么，彼此怎样递进？
- 怎样判断项目成功？
- 为什么是这个团队能做成？

## 2. 一句话项目主线

写标题和摘要之前必须先写一句话主线。

### 2.1 国家自然科学基金公式

针对【领域/对象】中【尚未解决的科学问题】，本项目基于【前期发现/理论依据】提出【科学假设】，采用【关键模型/方法/体系】，阐明/揭示/建立【机制/规律/理论/方法】，为【学科发展/应用基础】提供【新认识/新依据/新工具】。

### 2.2 科技部与上海项目公式

面向【国家/上海/产业/民生/行业场景】中的【关键瓶颈】，本项目拟通过【核心技术路线/组织方式】，突破【关键技术/共性问题】，形成【标志性成果/产品/平台/标准/示范】，达到【指南考核指标】，支撑【战略目标/产业升级/社会效益】。

### 2.3 人才类项目公式

申请人围绕【长期学术主线】持续解决【核心科学问题】，已在【代表性贡献】方面形成【可识别学术影响】，未来拟以【新问题/新方法/新平台】实现【学术跃迁】，带动【团队/平台/领域】发展。

## 3. 标题写法

### 3.1 标题的作用

标题要同时完成五件事：准确、简洁、对口、可记忆、与实际内容一致。标题不是口号，也不是关键词堆砌。

### 3.2 通用要求

- 标题应包含研究对象、核心问题或瓶颈、主要机制/路线/成果中的关键部分。
- 避免“大题小做”：题目很宏大，内容只解决局部问题。
- 避免“方法堆砌”：只写多组学、人工智能、模型、平台，却看不出研究问题。
- 避免无证据的“国际领先、国内首创、重大突破、填补空白”。
- 国家自然科学基金标题不要写成产品开发；科技部和上海应用类标题不要写成纯论文题。
- 若指南对题目长度有限制，以指南为准；无明确限制时，尽量短、准、稳。

### 3.3 国家自然科学基金标题公式

适用于机制、规律、理论和方法类基础研究。

1. 【对象】中【机制/过程】的【科学问题】研究。
2. 【关键因素】调控【对象/过程】的【机制】及其【意义】。
3. 基于【前期发现/新视角】的【科学问题】研究。
4. 【对象】发生/演化/响应【现象】的【机制】。

细节：

- 题目中心应是科学目标，不是常规工具。
- 题目不必把所有方法写进去，只保留能体现新视角的关键词。
- 题目中的因果关系、对象范围和研究层级要与正文一致。

### 3.4 科技部与上海项目标题公式

适用于技术攻关、示范应用、平台建设和任务交付。

1. 【场景/行业】中【关键技术】研发与示范。
2. 面向【需求】的【系统/平台/装备/工艺】关键技术及应用。
3. 【核心瓶颈】突破与【成果形态】构建。
4. 【上海/国家重点场景】下【技术体系】研发及验证。

细节：

- 题目要能看出交付成果或应用场景。
- 若指南要求“示范、应用、平台、标准、装备”，标题中应适度体现。
- 标题不要只写“机理研究”，除非指南明确支持基础研究。

### 3.5 标题评价表

| 维度 | 通过标准 | 风险信号 |
|---|---|---|
| 对口 | 能对应指南或项目类别 | 像另一个项目类别 |
| 聚焦 | 对象、问题和范围清楚 | 过大、过宽、过泛 |
| 价值 | 能看出科学或应用价值 | 只有方法名 |
| 可信 | 与内容和基础匹配 | 承诺过度 |
| 可记忆 | 有一个清晰亮点 | 词多但没有重心 |

## 4. 关键词写法

### 4.1 国家自然科学基金关键词

关键词一般服务于同行检索和评审匹配，应覆盖：

1. 研究对象。
2. 核心科学问题或机制。
3. 关键过程或变量。
4. 关键方法或模型。
5. 学科方向或应用基础场景。

避免：

- 全是大词，如“创新、发展、机制、应用”。
- 全是方法，如“测序、建模、仿真、深度学习”。
- 与申请代码或正文主线不一致。

### 4.2 科技部与上海关键词

关键词应覆盖：

1. 指南方向或场景。
2. 关键技术。
3. 成果形态。
4. 应用或示范对象。
5. 验证或标准化方向。

避免只写宏观政策词，而不写具体技术和成果。

## 5. 国家自然科学基金四百字摘要

### 5.1 摘要定位

摘要是评审最先读、会议评审最容易引用、申请人最需要反复打磨的部分。摘要应高度浓缩回答：为什么、缺什么、凭什么、做什么、怎么做、得到什么、有什么意义。

### 5.2 六到七句结构

推荐默认使用六到七个功能句，每句话都承担明确任务。

1. **重要性句**：说明研究对象或现象的重要性，避免空泛大背景。
2. **已知进展句**：说明已有研究已经认识到什么。
3. **缺口冲突句**：指出仍未知、争议或关键障碍。
4. **假设基础句**：基于前期发现或理论依据提出核心假设。
5. **研究内容句**：概括两到三项研究内容或递进任务。
6. **方法验证句**：说明关键模型、方法、样本、实验或验证逻辑。
7. **预期意义句**：说明将形成的新机制、新规律、新方法、新理论或新依据。

### 5.3 紧凑模板

【对象/现象】在【领域/疾病/系统/过程】中具有重要意义，但其【关键机制/规律】仍未明确。已有研究提示【已知进展】，然而【核心缺口/矛盾】尚未解决。申请人前期发现【关键证据】，据此提出【科学假设】。本项目拟围绕【科学问题】，开展【内容一】、【内容二】和【内容三】，并结合【关键方法/模型/验证体系】阐明【机制/规律】。预期将揭示【预期认识】，为【学科发展/应用基础】提供【新依据/新策略/新工具】。

### 5.4 四要素摘要

当字数更紧时，可压缩为四块：

1. 科学问题如何提出。
2. 基本思路或核心假设是什么。
3. 核心研究内容和关键方法是什么。
4. 主要意义是什么。

### 5.5 摘要语言规则

- 第一层给大同行看：少缩写、少黑话、先讲问题价值。
- 第二层给小同行看：准确写出对象、机制、变量、模型和验证。
- 背景不要超过全文四分之一。
- “拟”“将”可以使用，但不要连续堆砌。
- 不要在摘要里放太多文献引用和技术细节。
- 不要把成果写成“发表论文、申请专利”就结束，要写科学或技术贡献。
- 使用“首次、原创、领先、突破”前必须有充分依据，否则改成更稳健的表述。

## 6. 科技部与上海项目简介

### 6.1 八要素

1. 需求或场景：国家、上海、产业、临床、城市、民生或平台需求。
2. 瓶颈：现有技术、产品、流程、标准或应用的关键短板。
3. 总目标：项目完成后要形成什么能力或成果。
4. 任务组织：几项任务如何递进和集成。
5. 核心路线：关键技术、方法、系统或平台。
6. 交付成果：产品、装备、平台、标准、软件、数据集、示范、报告等。
7. 验证方式：第三方测试、真实场景验证、示范应用、对照评估、验收指标。
8. 基础与价值：团队基础、场景条件、合作单位、经济社会或战略价值。

### 6.2 模板

面向【需求/场景】，现有【技术/产品/平台/流程】存在【关键瓶颈】，制约【应用或发展】。本项目拟构建【总体方案】，突破【关键技术一、二、三】，形成【成果形态】，并在【场景/单位/示范点】开展【验证方式】。项目将达到【量化指标】，形成【标准/平台/产品/数据/示范】等成果，支撑【国家/上海/行业/民生价值】。

### 6.3 与国家自然科学基金摘要的区别

| 维度 | 国家自然科学基金 | 科技部与上海项目 |
|---|---|---|
| 核心问题 | 未解科学问题 | 指南任务或应用瓶颈 |
| 结果形态 | 新机制、新规律、新理论、新方法 | 产品、平台、工艺、标准、示范、指标 |
| 可行性证据 | 前期发现、模型、方法、论文 | 场景、用户、样机、平台、团队、合作 |
| 成功判断 | 假设是否被验证、认识是否更新 | 指标是否达到、成果是否验收、场景是否验证 |

## 7. 人才类项目摘要

### 7.1 五段结构

1. 申请人长期学术主线。
2. 已形成的代表性贡献。
3. 当前领域前沿缺口。
4. 未来研究计划和关键创新。
5. 预期学术引领、团队建设和平台贡献。

### 7.2 模板

申请人长期围绕【学术主线】开展研究，在【代表性方向】取得【核心贡献】，推动了【领域认识/技术方法/应用基础】。当前【前沿问题】仍缺乏【关键认识/方法/体系】。未来拟聚焦【新科学问题或新方向】，通过【研究内容和方法】形成【预期突破】，进一步建立【学术体系/技术平台/团队方向】，为【领域发展/国家需求/地方战略】提供支撑。

## 8. 故事线结构

### 8.1 六句故事线

1. 这个领域或场景出现了一个重要问题。
2. 现有研究或技术已经解决了一部分。
3. 但还存在一个关键缺口或瓶颈。
4. 我们基于前期发现提出一个新假设或新路线。
5. 项目将用几项递进内容或任务验证并实现它。
6. 成功后将形成可检验的新认识或可交付成果。

### 8.2 七节点故事模型

| 节点 | 写作功能 | 常见位置 |
|---|---|---|
| 场景 | 为什么重要 | 摘要开头、立项依据 |
| 冲突 | 为什么已有方法不够 | 研究现状、瓶颈分析 |
| 原因 | 卡点背后的机制或技术短板 | 科学问题、需求分析 |
| 转折 | 你的新假设、新路线或新平台 | 摘要、目标、创新 |
| 行动 | 几项内容或任务怎样递进 | 研究内容、任务分解 |
| 验证 | 怎样证明成功 | 方案、指标、里程碑 |
| 结局 | 对学科、产业、上海或人才发展的贡献 | 预期成果、意义 |

### 8.3 八问压力测试

适合任务型、工程型、转化型项目。

1. 你要做什么？
2. 现在别人怎么做，局限是什么？
3. 你的新路线是什么，为什么可能成功？
4. 谁会受益，为什么重要？
5. 主要风险是什么？
6. 需要多少资源和经费？
7. 周期和里程碑是什么？
8. 中期和最终如何判断成功？

### 8.4 开头钩子类型

| 类型 | 适用场景 | 写法 |
|---|---|---|
| 重大现象 | 基础研究 | “【现象】是【领域】中的关键过程，但其【机制】尚不清楚。” |
| 临床或民生痛点 | 医学、公共服务 | “【疾病/问题】造成【影响】，现有【手段】难以解决【瓶颈】。” |
| 产业瓶颈 | 科技部、上海、企业 | “【产业链环节】受制于【关键技术】，导致【成本/效率/质量/安全】受限。” |
| 理论矛盾 | 基础学科 | “已有研究对【问题】存在【相反解释】，核心原因在于【缺口】。” |
| 上海场景 | 上海市科委 | “上海在【场景】中具有【条件】，但仍面临【短板】。” |

## 9. 大同行与小同行双层可读性

### 9.1 大同行层

大同行不一定熟悉窄领域细节，但能判断问题价值、逻辑和可信度。因此标题、摘要、立项依据开头要做到：

- 少用未解释缩写。
- 先说问题价值，再说技术细节。
- 明确指出“仍不知道什么”或“卡在哪里”。
- 让项目主线能被复述。

### 9.2 小同行层

小同行会检查准确性和可行性。因此方案、现状、创新和基础要做到：

- 文献和现有技术比较客观。
- 核心变量、模型、样本、对照、算法、指标、测试条件写清楚。
- 难点不回避，给出替代方案。
- 前期数据能直接支撑假设或路线。

## 10. 摘要和故事线诊断

### 10.1 失败类型

| 失败类型 | 表现 | 修改方向 |
|---|---|---|
| 空背景 | 开头都是国家需求或领域重要性 | 换成具体对象、现象或瓶颈 |
| 无缺口 | 没有说明仍未知或卡点 | 加一句“但……” |
| 无假设 | 只写要做什么，不写为什么这样做 | 加前期发现和核心判断 |
| 无递进 | 内容并列堆砌 | 改成确认、解析、验证或研发、集成、示范 |
| 无可行性 | 没有说明为什么能做 | 加前期数据、平台、样本、团队或场景 |
| 无结局 | 最后只写论文专利 | 改成新认识、指标、平台、示范或决策价值 |

### 10.2 快速自检

- 摘要每句话是否有功能？
- 是否出现具体研究对象或应用场景？
- 是否出现明确缺口或瓶颈？
- 是否有前期基础或理论依据？
- 是否有两到三项核心内容或任务？
- 是否说明如何验证？
- 是否写出科学、技术、产业、上海或人才价值？

### 10.3 改写输出格式

处理用户摘要时，按以下格式输出：

1. 一句话主线。
2. 六句故事线。
3. 问题诊断表。
4. 稳健版摘要。
5. 创新版摘要。
6. 评审友好版摘要。
7. 仍需用户补充的信息。


path: references/writing_logic_consensus.md
content: # 写作逻辑共识库：摘要、故事线与评审视角

本文件把领域认可专家经验、基金评审经验、权威写作材料和公开样例中的共同观点整合为写作逻辑。使用时不要按个人姓名罗列建议，也不要写“某某专家说”。应直接转化为诊断、改写、结构设计和自检动作。

## 目录

1. 使用原则
2. 来源权重与使用边界
3. 顶层共识：申请书首先是评审沟通文本
4. 摘要共识：把项目压缩成可复述的故事梗概
5. 故事线共识：用因果链替代材料堆砌
6. 标题共识：短、准、稳、有识别点
7. 立项依据共识：从重要性自然推出缺口
8. 科学问题或技术瓶颈共识：必须尖锐、可验证、可承接
9. 目标与指标共识：目标要聚焦，指标要能验收
10. 研究内容与技术路线共识：内容回答做什么，路线回答怎么做
11. 创新性共识：有比较对象、有新意、有验证方式
12. 可行性与前期基础共识：证明为什么做得成、为什么由你做
13. 人才类项目共识：把成果串成学术主线
14. 任务型项目共识：把指南任务转成指标闭环
15. 评审阅读共识：同时服务大同行和小同行
16. 常见硬伤与修正动作
17. 写作动作矩阵
18. 摘要和故事线改写流程

---

## 1. 使用原则

本库只保留稳定、可迁移的写作逻辑，不保留个人姓名、个人语录和孤立观点。执行任务时应做到：

- 按写作问题归类，而不是按“谁说的”归类。
- 把经验转成动作，例如“摘要前两句降术语、先讲问题价值”。
- 不输出来源名录，除非用户明确要求核验来源。
- 不把经验当成硬性规则；当年指南、模板、系统要求和单位科研管理要求优先。
- 不编造专家评价、评审意见或“已获资助案例”。

## 2. 来源权重与使用边界

| 等级 | 来源类型 | 在技能中的用途 | 使用边界 |
|---|---|---|---|
| 一级 | 当年官方指南、申报模板、系统提示、管理办法、预算规则、权威期刊写作文章 | 决定硬性要求、结构、预算、附件、合规 | 必须以最新版本为准 |
| 二级 | 领域公认专家公开辅导、获资助者经验、评审经验、官方机构发布的写作材料 | 优化摘要、故事线、创新性、可行性、可读性 | 只抽象为共识，不按个人名录呈现 |
| 三级 | 公开样例、模板、经验帖、商业培训资料 | 发现常见问题、学习结构 | 不能作为权威依据，不能照搬原文 |

## 3. 顶层共识：申请书首先是评审沟通文本

项目申请书不是论文综述，也不是实验计划流水账，而是一次书面答辩。它必须在有限阅读时间内回答六个问题：

1. 这个问题为什么重要？
2. 现有研究或技术到底缺什么？
3. 申请人的核心判断、假设或路线是什么？
4. 准备做哪几件事，彼此怎样递进？
5. 凭什么相信能做成？
6. 做成后对学科、任务、产业、地方或人才发展有什么价值？

写作动作：

- 每一章开头都回扣同一句主线，不让评审重新猜项目方向。
- 重要信息前置：题目、摘要、第一页、路线图、创新点和基础优先打磨。
- 所有材料都要服务主线；不服务主线的论文、项目、平台、合作和方法应删减。
- 不把申请书写成“我会很多方法”，而要写成“我用这些方法解决这个关键问题”。

## 4. 摘要共识：把项目压缩成可复述的故事梗概

摘要是评审最先读、最容易记住、会议讨论时最容易被引用的部分。摘要不是正文缩写，而是项目故事梗概。

### 4.1 摘要必须回答的七件事

1. **重要性**：研究对象、场景或问题为什么值得资助。
2. **已有进展**：别人已经知道或做到什么。
3. **关键缺口**：仍不知道什么、争议在哪里、瓶颈卡在哪里。
4. **核心判断**：你的假设、新路线或关键思路是什么。
5. **前期依据**：为什么这个判断不是凭空提出。
6. **研究行动**：准备做哪两到三件递进的事。
7. **预期结局**：将形成什么新认识、技术、平台、标准、指标或示范。

### 4.2 六到七句摘要骨架

适用于国家自然科学基金、基础研究和应用基础研究：

1. 【对象/现象】在【领域/过程/疾病/系统】中具有重要意义。
2. 已有研究表明【已知进展】，但【关键机制/规律/关系】仍不清楚。
3. 这一缺口限制了【学科认识/技术发展/应用基础】。
4. 基于【前期发现/理论依据/初步数据】，本项目提出【核心假设】。
5. 项目拟围绕【科学问题】，开展【内容一】、【内容二】和【内容三】。
6. 通过【关键模型/方法/样本/验证体系】，阐明/揭示/建立【机制/规律/方法】。
7. 预期形成【新认识/新依据/新工具】，为【领域发展/应用基础】提供支撑。

### 4.3 四块摘要骨架

适用于字数更紧或用户只提供少量信息时：

- 第一块：科学问题或应用瓶颈如何提出。
- 第二块：基本思路或核心假设是什么。
- 第三块：核心研究内容和关键方法是什么。
- 第四块：预期意义和可检验结果是什么。

### 4.4 任务型项目摘要骨架

适用于科技部、地方科技计划、企业联合攻关和转化项目：

1. 面向【国家/地方/产业/临床/民生/城市治理】需求，现有【系统/产品/流程/技术】存在【瓶颈】。
2. 该瓶颈导致【效率、成本、质量、安全、可靠性、可及性或标准化】受限。
3. 项目拟构建【总体方案】，突破【关键技术一、二、三】。
4. 通过【任务组织、系统集成、示范应用或第三方验证】，形成【成果形态】。
5. 项目将达到【量化指标】并完成【交付物/示范点/标准/平台】。
6. 预期支撑【战略目标、产业升级、上海场景、民生改善或行业规范】。

### 4.5 摘要语言规则

- 开头不要写空泛大背景，直接进入具体对象、场景或现象。
- 少用缩写和窄领域黑话；必要术语首次出现时用通俗表达带一下。
- “缺口句”必须有力度，通常用“但、然而、仍不清楚、尚缺乏、难以支撑”。
- 前期基础只放最能支撑假设或路线的一条，不堆成果清单。
- 研究内容一般写两到三项，超过三项容易失焦。
- 结尾不要只写论文、专利，要写科学认识、关键技术、平台能力、标准或示范价值。
- 谨慎使用“首次、原创、领先、突破、填补空白”。没有证据时改成稳健表述。

## 5. 故事线共识：用因果链替代材料堆砌

好的申请书都有一条可复述的因果链：

> 重要场景或现象 → 已有进展 → 未解缺口或瓶颈 → 新假设或新路线 → 递进任务 → 验证方式 → 可检验结局。

### 5.1 六句故事线

1. 这个领域或场景有一个重要问题。
2. 现有研究或技术已经解决了一部分。
3. 但还有一个关键缺口、矛盾或瓶颈。
4. 本项目基于前期证据提出一个新假设或新路线。
5. 项目将通过几项递进内容或任务验证并实现它。
6. 成功后将形成可检验的新认识、技术能力或示范成果。

### 5.2 七节点故事模型

| 节点 | 写作功能 | 对应章节 |
|---|---|---|
| 场景 | 为什么重要 | 标题、摘要、立项依据开头 |
| 冲突 | 现有研究或技术为什么不够 | 国内外现状、需求分析 |
| 原因 | 卡点背后的机制或技术短板 | 科学问题、技术瓶颈 |
| 转折 | 你的新假设、新路线、新平台 | 摘要、目标、创新点 |
| 行动 | 几项内容或任务如何递进 | 研究内容、任务分解 |
| 验证 | 如何证明成功 | 研究方案、指标、里程碑 |
| 结局 | 成功后贡献什么 | 预期成果、效益、意义 |

### 5.3 讲故事的禁忌

- 只讲重要性，没有冲突。
- 只列方法，没有假设或路线判断。
- 只列任务，没有递进关系。
- 只写愿景，没有验证指标。
- 前期基础很多，但没有一条直接支撑主线。

## 6. 标题共识：短、准、稳、有识别点

标题是评审的第一印象，也是摘要和全文主线的压缩版。

标题应包含三类信息中的两类以上：

1. 研究对象或应用场景。
2. 核心科学问题、机制、瓶颈或关键技术。
3. 预期建立的机制、方法、系统、平台、标准或示范。

写作动作：

- 基础研究标题以对象、过程、机制或科学问题为中心。
- 任务型项目标题以场景、关键技术、成果形态或示范为中心。
- 人才类标题或主题要能体现长期学术主线。
- 删掉无证据的宣传词，如“国际领先、国内首创、重大突破”。
- 标题中不要堆太多技术名词；技术名词只保留最能体现新视角的一个。

## 7. 立项依据共识：从重要性自然推出缺口

立项依据的核心任务不是显示知道很多文献，而是让评审相信：这个问题重要、未解决、值得现在做，并且申请人的切入点合理。

推荐结构：

1. 具体场景、现象或学科问题。
2. 已有研究或技术取得的关键进展。
3. 仍存在的未解机制、争议、技术瓶颈或场景短板。
4. 缺口造成的后果。
5. 申请人的前期发现、独特资源或新视角。
6. 自然推出本项目的科学问题、假设或技术路线。

写作动作：

- 每一小节末尾用一句话收束到本项目。
- 文献综述按问题逻辑组织，不按年份流水账组织。
- 国内外代表性工作都要客观呈现，不刻意回避同行工作。
- 缺口不能只是“研究较少”，要说明“为什么现有方法解决不了”。

## 8. 科学问题或技术瓶颈共识：必须尖锐、可验证、可承接

科学问题或技术瓶颈是申请书的“冲突中心”。如果它不清楚，后面的目标、内容、方案和创新都会松散。

### 8.1 科学问题写法

一个好的科学问题通常具备：

- 对象明确：研究谁、哪一类过程、哪一个层级。
- 关系明确：机制、规律、因果、调控、演化、响应或耦合关系是什么。
- 未解明确：未知点、争议点或矛盾点是什么。
- 可研究：有模型、样本、方法、数据或理论路径可以推进。
- 可承接：能自然分解为两到三项研究内容。

模板：

> 本项目拟解决的核心科学问题是：【对象/过程】中【关键因素】如何通过【机制/关系】影响【结果/功能】，以及这一过程在【条件/场景】下如何被验证。

### 8.2 技术瓶颈写法

一个好的技术瓶颈通常具备：

- 场景明确：在哪个应用、行业、临床、城市或平台场景中发生。
- 短板明确：性能、成本、稳定性、标准化、集成、规模化、可及性、安全性等哪一项卡住。
- 原因明确：卡点不是笼统“不成熟”，而是由哪些技术环节造成。
- 指标明确：用什么指标判断瓶颈被突破。
- 交付明确：突破后形成什么成果。

模板：

> 当前【场景】中【现有方案】难以满足【指标/需求】，关键原因在于【瓶颈一】、【瓶颈二】和【瓶颈三】。本项目拟通过【路线】实现【指标提升/能力形成】。

## 9. 目标与指标共识：目标要聚焦，指标要能验收

目标是项目完成后的状态，内容是为实现目标要做的工作。二者不能混写。

写作动作：

- 总目标只写一个核心结果，不写多个并列愿景。
- 分目标对应研究内容或任务，不要凭空增加。
- 基础研究目标写“阐明、揭示、建立、解析、验证”。
- 任务型目标写“突破、形成、构建、完成、达到、示范”。
- 指标要有单位、阈值、测试条件、评价方法或验收依据。
- 不能承诺无法验证的宏大社会效益。

## 10. 研究内容与技术路线共识：内容回答做什么，路线回答怎么做

### 10.1 研究内容

研究内容应是解决科学问题或技术瓶颈的工作包，不是方法清单。

推荐递进方式：

- 基础研究：发现/确认 → 机制解析 → 功能验证。
- 方法研究：原理建立 → 方法构建 → 场景验证。
- 工程任务：关键技术突破 → 系统集成 → 示范应用。
- 上海项目：本地场景需求 → 技术实现 → 示范验收。

### 10.2 研究方案或技术路线

研究方案要回答每项内容如何执行：对象、方法、变量、对照、指标、数据、判断标准和替代方案。

写作动作：

- 对每个内容写“为什么做、做什么、怎么做、如何判断成败”。
- 最难、最关键、最容易被质疑的环节要讲细。
- 路线图要展示递进关系、输入输出和验证节点。
- 不把常规方法写成创新，但要把关键方法的适配性和验证写清楚。

## 11. 创新性共识：有比较对象、有新意、有验证方式

创新性不是形容词，而是比较后的差异。一个创新点至少回答四件事：

1. 相比什么已有认识、方法、技术或路线？
2. 新在哪里？是对象、机制、理论、方法、体系、集成还是场景？
3. 解决什么关键问题？
4. 如何验证这个新意成立？

写作动作：

- 创新点一般写二到三条，少而硬。
- 每条创新点用“已有局限—本项目新意—验证方式—预期贡献”结构。
- 不把先进仪器、热门算法、多组学、大数据、平台建设本身写成创新。
- 应用类项目可以写技术集成、标准体系、场景验证和应用模式创新，但要有指标支撑。

## 12. 可行性与前期基础共识：证明为什么做得成、为什么由你做

可行性不是自我表扬，而是证据链。前期基础要回答：申请人是否已经具备关键条件，能否支撑本项目最难的部分。

可行性证据包括：

- 前期发现、初步数据、预实验结果。
- 已建立模型、方法、平台、样本、数据库、样机或工艺。
- 与本项目直接相关的论文、专利、软件著作权、标准、成果转化或场景验证。
- 团队分工、合作单位、用户场景、伦理和数据条件。
- 风险识别和替代路线。

写作动作：

- 按“支撑哪个目标或任务”排列基础，而不是按时间或成果等级排列。
- 每条基础后写一句“因此可支撑本项目的……”。
- 对短板不回避，用风险和替代方案补齐。
- 不堆与项目无关的高水平成果。

## 13. 人才类项目共识：把成果串成学术主线

人才类项目不是普通项目书，也不是个人履历汇编。它要呈现申请人的独立学术判断、代表性贡献和未来跃迁。

推荐故事线：

> 长期学术主线 → 关键科学问题 → 代表性贡献 → 领域影响 → 当前前沿缺口 → 未来研究跃迁 → 团队和平台带动。

写作动作：

- 代表作按学术主线排序，不只按期刊、年份或影响因子排序。
- 每项代表性成果说明“提出了什么问题、建立了什么方法、改变了什么认识”。
- 未来计划要承接已有贡献，但不能只是原方向延长线。
- 个人贡献要写清楚，避免把团队成果写成个人独立贡献。

## 14. 任务型项目共识：把指南任务转成指标闭环

科技部、地方科技计划、企业联合攻关等任务型项目，核心不是“想研究什么”，而是“如何完成任务并可验收”。

写作动作：

- 建立“指南要求—项目目标—任务—技术路线—交付物—指标—验证—预算—责任单位”矩阵。
- 每个任务都有输入、输出、责任主体、里程碑和验收指标。
- 摘要和目标中不要漏掉示范、集成、标准、平台、应用场景和用户验证。
- 预算与任务匹配，不能出现高预算但无对应工作包。
- 合作单位职责要具体，不能只写“提供支持”。

## 15. 评审阅读共识：同时服务大同行和小同行

### 15.1 大同行可复述

大同行不一定熟悉窄领域细节，但能判断问题价值、逻辑和可信度。标题、摘要和立项依据开头要做到：

- 少缩写、少黑话。
- 先讲问题价值，再讲技术细节。
- 明确指出缺口或瓶颈。
- 让项目主线能被一分钟复述。

### 15.2 小同行能信服

小同行会检查专业准确性和方案可执行性。研究现状、方案、创新和基础要做到：

- 代表性文献或技术比较客观。
- 核心变量、模型、样本、对照、算法、指标、测试条件写清楚。
- 关键难点不回避，有替代方案。
- 前期数据能直接支撑假设或路线。

## 16. 常见硬伤与修正动作

| 硬伤 | 表现 | 修正动作 |
|---|---|---|
| 主题过大 | 题目宏大，内容分散 | 缩小对象、范围、机制或场景 |
| 摘要空泛 | 大背景多，缺口和行动少 | 改成六到七句功能摘要 |
| 缺口不尖锐 | 只说研究少、技术不足 | 写清为什么现有方法解决不了 |
| 内容并列堆砌 | 三四项内容互不递进 | 改成确认—解析—验证或研发—集成—示范 |
| 创新像口号 | “首次、领先、突破”但无比较 | 写比较对象、新意和验证方式 |
| 基础堆成果 | 高水平成果多但无关 | 按目标或任务重排，只留直接证据 |
| 路线不可信 | 关键难点一句带过 | 单列难点、风险、替代路线和判断标准 |
| 指标不可验收 | 没有单位、阈值或测试条件 | 加量化指标和验证方式 |
| 预算与任务脱节 | 买设备、劳务、测试没有任务对应 | 建立任务—经费—依据矩阵 |
| 合规缺口 | 伦理、数据、知识产权、保密漏写 | 单列合规清单并按指南核验 |

## 17. 写作动作矩阵

| 共识类别 | 写作动作 | 适用模块 |
|---|---|---|
| 重要性先行 | 开头用具体对象、场景或现象，不用空泛政策词 | 标题、摘要、立项依据 |
| 缺口要尖锐 | 用“但/然而/仍不清楚/难以满足”写出冲突 | 摘要、现状、科学问题 |
| 主线要聚焦 | 每章回扣同一句科学问题或瓶颈 | 全文 |
| 难点要讲透 | 对最难路径写验证、风险和替代方案 | 方案、路线、风险 |
| 创新要可比较 | 每条创新写“相比什么—新在哪里—如何验证” | 创新点 |
| 基础要支撑 | 每条基础对应一个目标、任务或关键方法 | 前期基础、可行性 |
| 指标要可验收 | 写单位、阈值、测试条件和验收方式 | 目标、成果、里程碑 |
| 评审要能复述 | 摘要完成后做一分钟复述测试 | 标题、摘要、第一页 |
| 材料要一致 | 标题、摘要、目标、内容、路线、成果、预算互相映射 | 定稿检查 |

## 18. 摘要和故事线改写流程

处理用户摘要或项目简介时，按以下流程：

1. 抽取一句话主线：对象、缺口、路线、价值。
2. 判断项目类型：科学问题型、任务指标型、地方场景型、人才主线型或通用型。
3. 写六句故事线：重要性、进展、缺口、假设/路线、行动、结局。
4. 建诊断表：背景、缺口、前期基础、内容、方法、验证、意义、语言。
5. 给出改写版：稳健版、评审友好版、强化创新版。
6. 标出仍需补充的信息：数据、指标、前期发现、场景、团队、合规或指南条款。

输出时不写具体专家姓名，不按个人观点分段，而是按上述写作逻辑整合。

Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)