official-doc-ch04-rd-content

name	official-doc-ch04-rd-content
description	第四章“项目研发内容”section skill。仅在 /official-doc-write 的 ch04-rd-content 中使用。采用参数化 task_id，确保每个研发任务都能映射到技术路线。不执行外部调研。
allowed-tools	Read Write Edit Bash

项目研发内容（ch04-rd-content）

必须配合 official-doc-section-common 使用。

写作对象为 ### 3. 项目研发内容。

写作目的

说明项目研究或建设什么、如何拆分任务、每项任务形成什么输出。完整实施路线属于 ch04-technical-route，本 section 不重复展开。

必须遵守的逻辑

按以下顺序展开：

建设范围或应用范围 -> 研发内容总述 -> 任务分解 -> 子任务展开 -> 任务衔接表 -> 与预期成果和技术路线的接口

每项任务必须包含：

任务目标 -> 任务输入 -> 关键技术或工程动作 -> 任务输出 -> 对应问题/指标 -> 验证方式 -> 与其他任务关系

模板化写法

本 section 应像模板第四章“项目研发内容”一样，采用“总述 + 任务分项 + 任务关系”的写法。任务分项可以使用正文内的“任务一：...”作为段首，但不得使用 ####、##### 等 Markdown 深层标题。

推荐句式：

本项目围绕...目标，设置...项研发任务。各研发任务分别面向...，并通过...形成完整技术链条。

任务一：...。本任务面向...问题，重点开展...工作。其输入为...，主要技术动作包括...，输出为...，并为...提供支撑。

任务二：...。...

任务三：...。...

结尾必须写清：

上述研发任务之间形成...关系，任务一输出...，任务二承接...，任务三集成...，共同支撑后续技术路线和预期成果。

标题层级要求：

• 正式正文中不得出现 #### 任务一、##### （一） 等四级或五级 Markdown 标题。
• 如需分层，用自然段段首“任务一：”“第一，”“第二，”表达。
• 图4-2 应放在研发内容总述之后、任务分项展开之前。

参数化任务规则

• 任务名称和数量以 framework.md 为准。
• 如果框架没有给出任务名称，使用 任务一：待补充，不得自行发明领域任务名。
• 每项任务必须在交接说明中映射到稳定 task_id。
• 每个 task_id 后续必须有同主题 tech_route_id。
• 正式正文不得暴露 task_id、pain_id、output_id、indicator_id、validation_id，只使用可读的任务名、问题名、成果名和验证描述。

深度和字数

如果没有更强要求，硬性最低字数为 4500 中文字符，目标为 5000-7000 中文字符。

每项核心任务必须写清：

• 任务目标和边界
• 任务输入
• 关键技术或工程动作
• 中间输出
• 最终输出
• 对应问题
• 对应目标或指标
• 验证方式
• 与前后任务的依赖关系

任务衔接表只能在正文充分展开之后使用，不能替代任务说明。

输出要求

• 不写孤立任务标题。
• 不重复完整技术路线。
• 不编造责任单位、验收指标或交付数量。
• 输入信息足够时，建议加入任务衔接表。