中文项目申请书写作与交付

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	templates_checklists, funder_rules
搜集/使用专家写作感悟	expert_wisdom_synthesis	writing_logic_consensus
判断某类项目怎么写、解读申报口径	funder_rules	knowledge_boundaries
写标题、摘要、项目简介、故事线	title_abstract_story	expert_wisdom_synthesis
写或改某一章	module_writing_guide	funder_rules
做评审式诊断、评分、自检	templates_checklists	expert_wisdom_synthesis
需要领域共识、评审视角、写作逻辑	writing_logic_consensus	module_writing_guide
需要确认资料来源、公开样例边界、是否应核验最新信息	knowledge_boundaries	funder_rules
需要学习输出格式或少样例	proposal_skill_examples	deliverable_proposal_examples

若用户同时要求“某类项目 + 某一章”，先读资助方规则，再读对应模块；若用户提供当年指南、模板或评审标准，先使用用户材料建立约束矩阵。

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。专家经验归类见 expert_wisdom_synthesis。

• 国家自然科学基金摘要：重要性 → 已知进展 → 未解缺口 → 前期基础与假设 → 研究内容和方法 → 验证方式 → 预期认识和意义。
• 科技部与上海项目简介：需求场景、关键瓶颈、总目标、任务组织、核心路线、交付成果、验证方式、团队和场景基础、合规价值。
• 人才类摘要：长期主线 → 代表性贡献 → 前沿缺口 → 未来计划 → 预期引领作用。
• 摘要硬伤：开头空泛、背景过长、缩写堆砌、问题不具体、没有前期基础、只列方法、只承诺论文专利、滥用“首次”“领先”“突破”。

11. 定稿前质量闸门

• 指南匹配：每个目标、任务、成果、指标都能对应指南、模板或评分标准。
• 一分钟复述：大同行读完标题和摘要后，能复述问题、缺口、路线、价值和可验证结局。
• 证据闭环：每个主要目标都有方法、前期基础、交付物、验证方式和风险替代方案。
• 全文一致：标题、摘要、目标、内容、路线、创新、基础、成果、预算和图表讲的是同一件事。
• 指标可验收：任务型项目的指标有阈值、测试条件、评价方法、责任主体和验收材料。
• 专家经验已落地：评审视角、科学问题、可读性、创新、可行性、基础和合规建议已转化为具体文本或修改动作。
• 交付完整性：最终 .docx 文件已生成，正文、图表建议、附件、预算依据、风险方案、待补充项、版本记录和核验清单齐全。
• 合规闭环：限项、资格、伦理、数据、知识产权、安全、保密、合作协议、附件、人工智能使用声明均已处理或标为待核验。

12. 回复风格

使用清晰、专业、可直接粘贴进申请书的中文。诊断优先用表格，正式文本用完整段落。不要按个人姓名罗列写作建议，不输出裸 URL；应把经验整合为“摘要逻辑、故事线、创新性、可行性、评审沟通”等写作动作。若使用外部资料，说明来源层级和需核验事项；若无法确认，明确写“未核验”或“需按当年官方指南确认”。