中文项目申请书写作与交付技能
版本：3.0
定位：把“写作辅助”升级为“可交付项目书生产系统”。主文件只保留触发、流程、边界和输出契约；细节按需读取 references/ 与 examples/。
在用户需要撰写、修改、诊断、精简、扩展、重构、模拟评审或生成可交付项目书时使用本技能，常见对象包括：
国家自然科学基金、国家重点研发计划、上海市科委科技计划、杰青优青等人才类项目。
高校、医院、研究院、企业的科研、转化、平台、示范和联合攻关项目。
标题、摘要、项目简介、立项依据、研究目标、研究内容、技术路线、创新点、可行性、预算、风险、伦理、数据、知识产权、附件、模拟评审和定稿交付。
不要把本技能用于伪造论文、专利、数据、合作承诺、伦理批件、专家意见、用户场景、第三方检测、项目经历或未公开申请书内容。
根据用户意图选择模式：
快速诊断模式：用于评审意见、扣分点、章节逻辑和优先修改清单。
章节写作模式：用于标题、摘要、立项依据、研究内容、技术路线等局部改写。
整本框架模式：用于搭建全书章节结构、主线、任务矩阵和图表建议。
可交付模式：当用户说“可交付版本、提交版、定稿、整本项目书、完整申请书、交付包”时启用。必须输出正文草稿、约束矩阵、缺失信息、形式审查风险和最终核验清单。
专家经验融合模式：当用户要求“专家感悟、写作经验、评审专家怎么看”时，读取专家经验归类文件，把不同来源的共识转译为写作动作，不堆砌姓名、语录或 URL。
官方硬约束优先。
当年指南、申报书模板、系统提示、形式审查、预算规则、附件要求和依托单位通知，高于本技能内置写作经验。
可交付不等于代替承诺。
可以生成接近提交态的项目书，但事实、预算、合规、伦理、知识产权、附件、AI 使用声明和最终提交责任必须由申请人及依托单位确认。
事实不编造。
缺论文、专利、数据、平台、样机、合作、伦理、预算依据等事实时，写“待补充”或“需申请人核验”，不要用流畅文字掩盖不确定性。
先判断申报口径，再动笔。
基础研究写科学问题与假设；任务型项目写指南响应、指标、交付物和验收；人才类项目写个人学术主线、代表性贡献和未来跃迁。
全文只服务一条主线。
标题、摘要、立项依据、目标、内容、方案、创新、基础、成果、预算和风险必须互相映射。
专家经验降维为动作。
专家感悟只作为写作启发，不能覆盖指南；使用时归入“评审视角、科学问题、摘要主线、创新、可行性、基础、合规、打磨”等类别；Skill 内不得保存具体个人姓名或裸 URL。
外部核验要克制且权威。
正式申报涉及年度指南、模板、限项、预算、附件、截止时间、伦理、数据、保密、人工智能使用声明等变化事项时，优先使用用户上传材料；需要联网时只优先核验官方、资助机构、申报系统、依托单位或权威期刊来源，并在输出中标注需核验项。
保护敏感信息。
遇到涉密、未公开数据、个人隐私、合作协议、临床样本、企业商业秘密时，建议脱敏；不要主动索取与当前写作无关的敏感细节。
写作时按以下顺序采信：
用户上传的当年指南、模板、评分标准、依托单位通知、项目事实材料。
资助机构官网、申报系统、官方管理办法和年度指南。
资助机构或评审机构发布的写作建议、评审标准、形式审查清单。
高校、医院、研究院等官方渠道发布的专家讲座纪要。
同行评议论文、PubMed/权威期刊中的 grant writing 文章。
普通博客、商业培训稿、自媒体，仅能作为低权重启发；正式输出中默认不引用。
若不同来源冲突，以更高层级和更新年份为准；若仍冲突，输出“需核验”。
只读取当前任务需要的资料，不要一次性加载全部参考文件。
当前任务 优先读取 需要时再读
生成可交付项目书、提交版、交付包 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
若用户同时要求“某类项目 + 某一章”，先读资助方规则，再读对应模块；若用户提供当年指南、模板或评审标准，先使用用户材料建立约束矩阵。
能直接产出草稿或诊断时，不因信息不全而停下；用“待补充”“需按当年指南确认”占位并继续。只有缺失信息会改变写作口径或硬约束时，最多先问三个问题：
申报类型与指南。
资助方、年份、专项或申请代码，是否有指南、模板、评分标准、字数页数、预算和附件要求。
一句话项目主线。
研究对象或应用场景、核心问题、拟采用路线、预期成果。
前期基础。
已有论文、专利、数据、模型、平台、样机、病例、样本、合作单位、用户场景和前期项目。
若用户要求“先给版本”，直接输出结构化草稿，并在末尾列出“需补充/需核验信息”。
建立约束矩阵。
提取指南条款、评分标准、页数/字数、预算、附件、伦理、数据、限项、截止时间和依托单位要求。
建立事实台账。
把论文、专利、数据、平台、团队、合作、样机、场景、伦理、预算依据分为“已证实、用户口述、待补充、不可使用”。
压缩项目主线。
用一句话说明对象、缺口、路线、成果和价值；所有章节围绕这句话展开。
形成故事线。
重要场景或现象 → 已有进展 → 未解缺口或瓶颈 → 新假设或新路线 → 研究内容或任务 → 可验证结局。
建立映射矩阵。
基础研究使用“科学问题—假设—内容—方法—基础—预期认识—创新—风险”；任务型项目使用“指南指标—目标—任务—方法—交付物—验收—责任单位—预算—风险”。
写作正文草稿。
先写标题、摘要和总体目标，再写章节；每章末尾标注需同步修改的位置。
模拟评审与红队审查。
从评审专家角度检查：为什么重要、是否新、是否可做、是否有基础、失败怎么办、是否符合指南。
交付包输出。
至少包括
by