official-doc-review

name	official-doc-review
description	新 official-doc-write 架构的 section 级复核 skill。逐个复核 project-workspace 下的 section 草稿，检查 section-plan、evidence-ledger、traceability-matrix、字数门槛、文风规则和装配条件。
allowed-tools	Read Write Edit Bash

小节复核规则（official-doc-review）

本 skill 只服务新的 /official-doc-write 架构。每次只复核一个 section：

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

不得使用旧工作流、旧章节提示词、旧写作规则、旧参考资料目录、旧装配目录、official-doc-research 或任何外部调研流程。

必读文件

复核前必须读取：

• project-workspace/<project-slug>/context/section-plan.md
• project-workspace/<project-slug>/context/evidence-ledger.md
• project-workspace/<project-slug>/context/traceability-matrix.md
• project-workspace/<project-slug>/context/artifact-plan.md
• project-workspace/<project-slug>/drafts/sections/<section-id>.md
• .claude/templates/full-research-project-artifact-blueprint.md

必要时同时读取：

• project-workspace/<project-slug>/inputs/framework.md
• project-workspace/<project-slug>/inputs/research-report.md
• project-workspace/<project-slug>/inputs/reference-supplement.md

输出位置

review 写入：

project-workspace/<project-slug>/reviews/<section-id>-review.md

review 文件必须包含且只能包含一种状态：

section_status: approved

或：

section_status: review_failed

只要仍有 Must Fix，就必须写 review_failed。

不得使用 status: approved、review_passed、复核通过 替代 section_status: approved。主入口和校验脚本只认 section_status: approved。

复核门禁

1. 范围

• 草稿只能包含目标 section。
• 标题必须匹配 section-plan.md 的 chapter_title / parent_heading / section_heading，并服从 .claude/templates/full-research-project-template.md。
• section 必须使用 section-plan.md 指定的 agent 和 section skill。
• 草稿不得包含过程说明、review 意见、提示词指令、测试标记或内部任务说明。
• 草稿不得包含 --- 元数据块、section_id:、skill:、evidence_used:、traceability:、task_binding:、char_count:、status: 等交接字段。
• 不得把父级标题和子级标题压扁，例如 ## （三）1. 国内发展现状、## （一）1. 建设目标、## （二）1. 技术路线。
• 第一章、第四章 section 草稿不得出现 ####、##### 或更深 Markdown 标题；核心章分层必须使用自然段句式，不使用技术报告式深层标题。
• 不得出现 ### 2.1、#### 3.3.1 等小数编号标题。
• 次要章节不得使用 ## 1 ...、## 2 ... 作为二级标题，必须使用 ## （一）...、## （二）...。
• 次要章节不得使用 ### （一）...。中文括号序号必须是二级标题 ## （一）...，三级标题必须是 ### 1. ...。
• 第五章、六章、八章不得新增模板外 （一）、（二） 小节标题；这三章以章级正文和表格为主体。
• 不得新增 小结 标题，除非模板规格明确要求。

2. 证据

• 正文判断必须能被 evidence-ledger.md 或三份输入支撑。
• 正文不得要求外部调研。
• 缺失事实只能保守处理或标记 待补充。
• 不得编造预算、周期、单位、团队、量化指标、验证条件、应用规模、成果数量等项目事实。

3. 内部编号

正式正文不得暴露内部编号，包括：

• FW-001、RR-001、RS-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 对问题的说明中。

4. 关联关系

必须核对 traceability-matrix.md。

典型 Must Fix：

• 第一章痛点没有对应第四章主要问题。
• 第四章主要问题没有回应第一章痛点。
• 研发任务没有同主题技术路线。
• 预期成果没有来源研发任务。
• 指标或验证方法没有绑定成果或任务。
• 应用推广、产业链安全、受控复用与任务、路线或成果脱节。
• 第五章工作包没有来源第四章研发任务。
• 第六章单位分工没有绑定工作包或任务。
• 第八章预算项没有任务、设备、人员、平台建设或管理活动来源。
• 第九章效益没有成果、应用推广或产业链价值来源。
• 第十章风险没有应对措施。
• section 依赖的矩阵行仍包含 blocks_assembly: Yes。

review 不得修改矩阵。矩阵不足时，section 复核不通过，并说明缺失关系。

5. 字数

以 section-plan.md 或 framework.md 中的字数要求为准。section 有最低字数时，必须达到最低字数；没有明确最低字数时，也要判断是否满足该 section 在章节中的深度责任。

章节或装配稿检查优先使用：

python scripts/count_chars.py <md-file>

默认硬门槛：

• 第一章最低 8000 中文字符。
• 第四章最低 22000 中文字符。
• ch04-rd-content 最低 4500 中文字符。
• ch04-technical-route 最低 7000 中文字符。

低于硬门槛不得通过。

6. 深度

第一章 section 应至少检查：

• 项目对象
• 政策或产业背景
• 具体问题或差距
• 对项目必要性的影响
• 与痛点、重大问题或产业链安全的关联

第四章 section 应至少检查：

• 问题来源或任务来源
• 技术或工程动作
• 输入输出关系
• 方法、架构、流程或机制
• 与成果、指标、验证、应用或受控复用的关系

ch04-rd-content 和 ch04-technical-route 必须是第四章中最厚的部分之一，不能只改写任务名称或罗列功能愿望。

7. 文风

正式正文应是连续公文段落。出现以下情况应判为 Must Fix：

• 用密集清单替代正文
• **技术描述**、**作用**、**子任务** 等加粗小标签
• 只有口号、没有对象、机制、输出和验证
• 机械过渡词堆叠
• 填补空白、填补...空白、唯一可行路径、国际先进水平、国际领先、国内领先、首创、首次提出 等强宣传或绝对化表述
• 显著提升、大幅提升、全面提升、形成...闭环、赋能、打造...平台、构建...体系 等口号化表达；确需表达提升效果时必须改为具体对象、建设动作、形成能力和支撑意义
• 中英文术语污染；第四章确需出现英文缩写、软件名或文件格式时，应以中文名称为主，英文括号说明一次，不得密集出现
• 不完整公式或复杂度残句

第一章、第四章必须额外检查模板句式和内容位置，出现以下情况应判为 Must Fix：

• ch01-background 以 DNV、Siemens Teamcenter、Nauticus、PLM 等国外工具、国外平台或国外应用成熟度开头，或主要篇幅写国外现状。
• ch01-domestic-status 写入国外厂商、国外产品或国外应用成熟度。
• ch01-foreign-status 写入国资委、招商局集团、商道平台、上海研究院等国内政策和主体内容，或把国内建设基础写成国外现状。
• ch01-pain-analysis 提前展开第四章的算法、接口、平台集成和验证路线。
• 第一章出现“技术能力闭环”“应用生态框架”“可复制推广的工程范式”“智能化应用格局”等抽象 AI 化表达，且没有落到具体对象、动作、能力和意义。
• ch04-major-issues 出现“来源于第一章痛点分析中的……”“对应 pain_01 / task_01”等后台映射式表述。
• ch04-major-issues 出现 问题一：……问题。、问题二：……问题。 这类重复问题句式。
• ch04-major-issues 出现“该问题主要由任务一予以承接”“该问题对应第一项研发任务”等后台关系说明，而不是正式公文的问题表现和建设方向。
• ch04-rd-content 用 #### 任务一、##### （一） 等标题组织任务，而不是用“任务一：……”自然段。
• ch04-technical-route 用 ##### （一）总体技术架构 等技术报告式标题，或只罗列任务名称而未写数据流、接口、验证和应用路线。
• 第四章预期成果、推广、联合研发、成果管理等 section 使用深层标题代替连续公文段落。

第二、三、五、六、七、八、九、十章必须额外检查模板结构，出现以下情况应判为 Must Fix：

• 第二章没有 ## （一）项目牵头单位情况、## （二）项目负责人基本情况、## （三）联合体单位情况，或缺少牵头单位八项固定三级标题。
• 第三章没有 ## （一）团队情况、## （二）团队实力和基础、## （三）软硬件支撑条件、## （四）以往业绩及承担相关项目情况、## （五）专业人员资质能力情况。
• 第五章出现 （一）任务设置原则、（二）工作包划分、（三）各工作包目标与内容 等自造小节，而不是章级正文和年度任务表。
• 第五章出现 ## 子课题一阶段任务说明、## 子课题二阶段任务说明、## 项目验证阶段任务说明、## 项目总结阶段任务说明 等阶段说明标题，而不是章级正文和年度任务表。
• 第六章出现 （一）联合体总体分工框架、（二）成员单位任务分工 等自造小节，而不是章级正文和联合体分工表。
• 第七章没有按模板的六个二级小节和对应三级制度项展开。
• 第八章拆成资金筹措方案、投资估算范围、费用科目明细等自造小节，或编造金额。
• 第九章没有按 经济效益分析、社会效益分析 展开，或编造销售收入、利润、回收期。
• 第十章没有按“技术、市场/应用、经营/组织、资金、法律合规与数据安全、政策”风险类别展开，或每类风险缺少“风险分析”和“基础条件/应对措施”。
• 第二章财务、股权、人员、设施、研发投入等模板项被空泛介绍替代，且未标注 待补充。
• 第三章没有形成“单位能力 -> 支撑研发任务 -> 保障项目实施”的句式关系。
• 第五章表格仍是工作包表，而不是“年度 | 年度任务 | 年度考核指标 | 重要任务的时间节点”的年度任务安排表。
• 第六章分工表删减了任务负责人、年度任务分解、年度考核指标与时间节点、投资额、承担任务占比等模板关键字段。
• 第九章表格出现 output_01、benefit_01、application_01 等内部 ID，或在缺少测算参数时使用“假设每型船……”推导收益。
• 第十章风险分析没有绑定第四章技术路线、第七章管理机制或第八章资金安排，只写通用风险模板。

检查完整 section 或装配稿时，优先运行：

powershell -ExecutionPolicy Bypass -File scripts/style_check.ps1 -FilePath <md-file>

如果 Result: FAIL 命中普通正文，必须列入 Must Fix。

若命中项属于 mixed_token_noise，按以下规则判断：

• 第一章、第二章、第三章、第五至第十章原则上不得密集出现英文词；能中文化的必须中文化。
• 第四章技术路线可以保留必要软件、标准、文件格式和算法缩写，但正文应先写中文术语，英文只作括号说明；同一段落不得连续堆叠英文缩写。
• 全文 mixed_token_noise 达到 5 处及以上时，视为正式公文语体不合格，最终装配不得批准。

8. 图表

必须核对 artifact-plan.md 中当前 section 或当前章节的图表行。

典型 Must Fix：

• required=Yes 的图表没有嵌入正文。
• type=图 的图表没有按 official-doc-figure 规则生成或回修。
• type=表 的图表没有按 official-doc-table 规则生成或回修。
• 图表位置或类型没有对应图表蓝图的 template_anchor、artifact_type 和写作位置。
• 图表没有使用正式编号，例如缺少 图4-1 或 表8-1。
• artifact-plan.md 中 type=图 但 artifact_id 以 表 开头，或 type=表 但 artifact_id 以 图 开头。
• 正文出现“表X-X ……图”或“图X-X ……表”等编号和标题含义不一致的图表。
• 表格没有表题，或表题没有放在表格前。
• Mermaid 或流程图没有正式图题。
• 图表内容与 traceability-matrix.md 的任务、成果、预算、效益、风险关系不一致。
• 图表中出现输入未提供的金额、数量、收益、单位、指标、责任主体等事实。
• 某章最终正文没有任何正式编号图或表。
• required_per_task 图表没有按每个研发任务分别展开。
• 第一章出现 图1-X。
• 正式表格暴露 task_01、risk_01、benefit_01 等内部编号。
• 图表或表格暴露 output_01、task_01、pain_01 等内部编号。

只有图表已经嵌入正文、内容有事实来源、编号与 artifact-plan.md 一致时，相关 section 才能通过。

9. 模板装配

装配章稿或最终稿时，必须额外检查固定标题树：

• 第一章必须包含 ## （三）国内外发展现状及前景，其下再放 ### 1. 国内发展现状、### 2. 国外发展与应用现状、### 3. 痛点分析、### 4. 发展前景。
• 第四章必须包含 ## （一）总体目标 和 ## （二）项目建设方案，其下再放对应 ### 1. 至 ### 5. 或 ### 4. 子标题。
• 任何章节文件出现 ## （三）1.、## （一）1.、## （二）1. 时，必须判为 review_failed。
• 运行 scripts/validate_project_workspace.ps1 -ProjectSlug <project-slug> 或 scripts/style_check.ps1 发现标题、风格门禁失败时，不得批准最终装配。

复核文件结构

使用以下结构：

# <section-id> review

section_status: approved

## 范围
- checked_files:
- assigned_agent:
- assigned_skill:

## 统计
- current_chinese_chars:
- minimum_chinese_chars:
- word_count_status:

## 已通过项
- ...

## 必修问题
- None

## 可优化问题
- ...

## 关联关系
- ...

## 图表
- ...

## 证据
- ...

## 装配门禁
- allowed_to_assemble: Yes

未通过时写：

section_status: review_failed

并写：

## 装配门禁
- allowed_to_assemble: No

每个 Must Fix 都要写清影响文件、问题、修复动作和通过条件。