# 可交付项目书生产工作流

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

## 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. 交付时的措辞边界

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