official-doc-section-common

name	official-doc-section-common
description	新 project-workspace section 级写作架构的通用规则。所有核心章节和次要章节 section skill 都必须配合本规则使用。流程只消费 framework.md、research-report.md、reference-supplement.md，不执行外部调研。
allowed-tools	Read Write Edit Bash

小节写作通用规则（official-doc-section-common）

本文件是新 section 级架构的共享规则层。

输入来源

只有以下文件可以提供事实：

• project-workspace/<project-slug>/inputs/framework.md
• project-workspace/<project-slug>/inputs/research-report.md
• project-workspace/<project-slug>/inputs/reference-supplement.md
• project-workspace/<project-slug>/context/evidence-ledger.md
• project-workspace/<project-slug>/context/traceability-matrix.md
• project-workspace/<project-slug>/context/section-plan.md
• project-workspace/<project-slug>/context/artifact-plan.md

不得使用 official-doc-research。不得联网搜索。不得推断缺失的项目事实。

小节流程

每个 section 都按同一流程执行：

section skill 写作 -> section review -> 必要时 section revise -> section review -> approved

每个 section 写入：

project-workspace/<project-slug>/drafts/sections/<section-id>.md

section 草稿只能包含该 section 的正式正文，不得包含：

• --- 元数据块
• section_id:、skill:、evidence_used:、traceability:、task_binding:、char_count:、status: 等交接字段
• FW-001 等内部证据编号
• pain_01、major_issue_01、task_01、tech_route_01、output_01、indicator_01、validation_01、application_01 等内部矩阵编号
• unit_01、member_01、work_package_01、milestone_01、budget_item_01、benefit_01、risk_01、mitigation_01 等次要章节内部矩阵编号
• 过程说明
• review 意见
• 来源映射表
• 给下一个 agent 的指令
• 当前测试稿 等测试标记；除非该表述属于已接受的非阻断缺口策略

写作完成后的交接说明只能写在 agent 回复中，或由 review skill 写入 reviews/<section-id>-review.md。不得附加到 section 草稿末尾。

文风

• 使用正式中文公文语体。
• 优先使用完整自然段。
• 避免只有口号、没有对象和机制的表述。
• 第一章、第四章应尽量贴近模板的展开方式：先用总述段交代对象、背景和目的，再分层说明机制、路径、分工或边界，图表前后均需有承接段和解释段。
• 第四章不得写成产品方案说明书式的平铺罗列。每个 section 至少应体现“总述 -> 分项展开 -> 图表承接或关系收束”的模板式行文节奏。
• 禁用强宣传和绝对化表述。正式正文不得使用 填补空白、填补...空白、唯一可行路径、国际先进水平、国际领先、国内领先、首创、首次提出、显著提升、大幅提升、全面提升、形成...闭环 等写法；确有输入依据时也应改为稳健表述。
• 推荐替换口径：填补空白 改为 补齐能力短板 或 完善支撑能力；唯一可行路径 改为 更符合本项目需求的路径；国际先进水平 改为 与成熟工具仍有差距 或 对标成熟应用做法；显著/大幅提升 改为 有助于提升、进一步提升；闭环 改为 衔接关系、闭合管理链条 或直接写清输入、处理、输出、验证。
• 英文缩写和软件名只在确有输入依据且不可替代时使用，首次出现应以中文名称为主、英文括号说明；不得让 Word/PDF/Windows/Linux/Python/PCA/op2/DNV/RINA 等英文词密集污染正式公文语体。
• 除任务、成果、指标、表格等确实需要条目化的内容外，不用清单替代正文。
• 只有三份输入没有给出事实时，才使用 待补充。
• 如果 traceability-matrix.md 将某个缺口标为 blocks_assembly: Yes，该 section 可以进入草稿和 review，但不得通过 review 或装配。
• 不得写未经证据支撑的精确信息，包括日期、政策文号、比例、数量、单位名称、预算金额、人员、验证阈值、成果数量等。

标题层级

• section 草稿必须服从 .claude/templates/full-research-project-template.md 的标题树。
• 不得把父级标题和子级标题压扁，例如不得写 ## （三）1. 国内发展现状、## （一）1. 建设目标、## （二）1. 技术路线。
• 第一章、第四章是核心章，section 正文不得使用 ####、##### 或更深 Markdown 标题；需要分层时使用自然段开头的“第一，”“第二，”“任务一：”“成果一：”“在……方面”等模板化句式。
• 不得使用技术报告式小数标题，例如 ### 2.1、#### 3.3.1。
• 次要章节二级标题必须使用 ## （一）...、## （二）...，不得使用 ## 1 ...、## 2 ...。
• 次要章节不得使用 ### （一）...。凡是中文括号序号 （一）、（二） 均为二级标题，必须写作 ## （一）...；三级标题只能写作 ### 1. ...、### 2. ...。
• 第五章、第六章、第八章在模板中以章级正文和表格为主，原则上不新增 ## （一）... 或 ### （一）... 小节；除非 framework.md 明确给出模板外结构。
• 第五章不得新增 ## 子课题一阶段任务说明、## 子课题二阶段任务说明、## 项目验证阶段任务说明、## 项目总结阶段任务说明 等阶段说明标题。阶段、年度、子课题只能写入章级正文或年度任务安排表。
• 不得新增“## 小结”“### 小结”“### （五）小结”等模板外收束标题；需要收束时用自然段。
• 第四章技术内容需要分层时，正文内使用“重点工作方向一”“子任务一”“关键环节一”等中文表达，或使用普通段落，不新增小数编号标题。

第一章内容边界

第一章各 section 必须避免内容错位：

• ch01-background 写项目建设背景，重点是政策要求、产业场景、业务基础和建设必要性。不得以 DNV、Siemens Teamcenter、Nauticus、PLM 等国外工具和平台开头；这些内容属于国外发展与应用现状。
• ch01-domestic-status 写国内发展现状，重点是国内船舶行业、中央企业智能化、招商局集团和项目承担单位已有基础。不得写国外厂商、国外产品和国外应用成熟度。
• ch01-foreign-status 写国外发展与应用现状，重点是国外工具链、船级社规范校核、PLM/CAE/report automation 等成熟做法及其适配不足。不得写国资委、招商局集团、商道平台、上海研究院等国内政策和主体内容。
• ch01-pain-analysis 写痛点本身，不提前展开第四章技术路线。
• ch01-major-problems 写待解决重大问题，必须承接痛点并引出第四章建设任务，不得写成成果清单。

第四章内容边界

第四章各 section 必须避免内容错位：

• ch04-construction-goal 写目标，不展开任务细节和技术路线。
• ch04-major-issues 写建设方案要解决的主要问题，不重复第一章痛点原文，不提前写算法步骤。
• ch04-rd-content 写研发任务、输入、动作、输出和任务关系，不写成技术路线。
• ch04-technical-route 写路线、流程、数据流、接口、验证和工程应用，不写成研发任务清单。
• ch04-expected-outputs 写成果来源、成果形态、验证和应用关系，不重复研发任务。
• ch04-application-promotion 写内部试点、示范应用、推广路径和反馈机制，不写第九章效益测算。
• ch04-collaboration-mode 写产学研用协同基础、联合研发机制、任务接口和应用反馈，不替代第六章单位任务分工。
• ch04-open-source-strategy 写与模板对应的攻关成果开源策略，但必须服从保密和知识产权边界，不得编造开源比例、社区或对外发布承诺。
• ch04-major-issues 的正文只写问题表现、制约影响和建设方向，不得显式写“来源于第一章痛点分析中的……”，不得暴露 pain_01、major_issue_01、task_01 等后台映射。

核心章文风禁区

第一章、第四章不得出现以下写法：

• “来源于第一章痛点分析中的 pain_01”
• “对应 task_01 / output_01 / major_issue_01”
• “问题一：……问题。”这种重复问题句式
• “该问题主要由任务一予以承接”这类后台关系说明
• “技术能力闭环”“应用生态框架”“可复制推广的工程范式”“智能化应用格局”等抽象 AI 化表达
• “填补空白”“唯一可行路径”“国际先进水平”“显著提升”“大幅提升”“形成闭环”等强宣传或非模板化表达

应改为模板式公文表达：

当前……，主要表现为……。该问题制约了……，需要通过……形成……能力。

项目实施后，可在……方面发挥作用，为……提供支撑。

次要章节内容边界

第二、三、五、六、七、八、九、十章必须按 .claude/templates/full-research-project-template.md 的对应章节结构写作：

• 第二章按“项目牵头单位情况、项目负责人基本情况、联合体单位情况”展开，不得改写成泛泛单位简介。
• 第三章按“团队情况、团队实力和基础、软硬件支撑条件、以往业绩、专业人员资质能力”展开，不得写成宣传式团队介绍。
• 第五章按年度任务安排表写作，不得新增任务设置原则、工作包划分等模板外小节。
• 第五章不得使用 ## 子课题...阶段任务说明 作为标题；子课题和阶段信息应进入 表5-1 年度任务安排表 的“年度任务”“年度考核指标”“重要任务的时间节点”列。
• 第六章按联合体任务分工表写作，不得新增总体分工框架、成员单位任务分工等模板外小节。
• 第七章按项目管理模式、项目运行保障机制、人才团队及设备设施保障、成果运营管理、成员知识产权及权益分配、项目后期运营策略六部分展开。
• 第八章按商务口径和经费估算表写作，不得编造资金来源、金额和费用比例。
• 第九章按经济效益分析、社会效益分析展开，不得编造销售额、利润、回收期或市场占有率。
• 第十章按各类风险“风险分析 -> 基础条件/应对措施”展开，不得只列风险名称。

字数门禁

每个 section 都必须在 section-plan.md 中有 minimum_chars。这是硬门槛。

• 写作 agent 必须在允许的 section 结构内扩写到 minimum_chars。
• 扩写必须增加机制、输入、输出、验证方法、应用边界、数据流、接口关系、风险控制和证据支撑说明。
• 不得新增计划外标题凑字数。
• 不得用同一价值判断换说法重复扩写。
• section 交接说明必须报告当前中文字符数，以及是否达到 minimum_chars。

关联关系

正式正文应当可读，不暴露内部 ID；但写作逻辑必须能通过 traceability-matrix.md 回溯。

必要关系包括：

• 痛点分析 -> 主要问题
• 主要问题 -> 研发任务
• 研发任务 -> 技术路线
• 研发任务 -> 预期成果
• 成果 -> 验证与应用
• 安全保障、推广、平台集成、受控复用 -> 研发任务或成果
• 第五章任务设置 -> 第四章研发任务
• 第六章单位分工 -> 第五章工作包或第四章研发任务
• 第八章预算 -> 任务、设备、人员、平台建设或管理活动
• 第九章效益 -> 成果、应用推广或产业链价值
• 第十章风险 -> 应对措施

如果关系缺失，必须向主入口报告，不得自行静默发明矩阵行。

图表写作

图表是正式正文的一部分，由 artifact-plan.md 统一安排。

• 写作前必须检查当前 section 是否承担必需图表。
• type=图 的图表必须调用 official-doc-figure 生成或回修。
• type=表 的图表必须调用 official-doc-table 生成或回修。
• 必需图表必须按 .claude/templates/full-research-project-artifact-blueprint.md 的 template_anchor、artifact_type 和写作位置嵌入 section 正文，不能只在交接说明中提到。
• 图题必须以 图X-X 开头，表题必须以 表X-X 开头。
• 表格使用 Markdown 表格时，表题放在表格前一行。
• 关系图、任务分解图、技术路线图可以使用 Mermaid；代码块前必须有正式图题。
• 图表中的单位、金额、数量、比例、指标、责任主体和收益测算必须来自允许输入或矩阵关系。没有事实支撑时写 待补充。
• 图表用于压缩关系、任务、分工、预算、效益和风险信息，不得替代关键正文说明。
• required_per_task 图表必须按每个研发任务分别生成，不得用一个总图替代全部任务图。
• type=图 的 artifact_id 必须以 图X-X 开头；type=表 的 artifact_id 必须以 表X-X 开头。编号、类型、标题含义不一致时必须报告主入口修正 artifact-plan.md，不得自行生成。
• 标题含“组织架构图”“路线图”“流程图”“结构图”“关系图”的，一般应作为 图；标题含“清单”“表”“矩阵”“明细”“测算”的，一般应作为 表。若 artifact-plan.md 与该含义冲突，必须阻断。

小节复核最低通过条件

section 只有在 review 确认以下事项后才算完成：

• 标题和范围正确
• 证据来自允许输入
• 没有外部调研依赖
• 正文没有内部证据编号和矩阵编号
• 没有未绑定的关联判断
• 没有编造项目事实
• 没有阻断性 待补充
• 达到 minimum_chars
• artifact-plan.md 分配给该 section 的必需图表已经嵌入正文
• review 可写入 section_status: approved