放入 Word 初稿
把初稿放进 01 阶段目录，确认是本阶段要转换的文件。
预期 · 文件就位
00 / 先读这一页
先看自己处在哪一个阶段
这份说明书只解决一件事：你现在应该放什么文件、点哪个按钮、完成后看到什么。不要先研究系统，先找到自己的阶段目录。
你只需要做
把文件放进 01–05 阶段目录，用 Oxygen 打开阶段目录里的文件；在右侧 AI Positron 面板顶部打开 Actions，选 Review：执行当前阶段，然后看结果。
AI 负责
按阶段调用 Word 转换、评审稿生成、意见提取和回写；不替你批准，不替你判断技术事实。
你先看结果
01 看迁移报告；02 看评审 Word；03 看修订/批注数量；04/05 看状态和门禁。
本阶段动作预期结果阶段门禁
第一次读：00 → 01 → 02；执行时看：03；出问题看：05。Quality 是独立模块，不要混进 Review 状态。
00a / 术语
先认识几个词
| 词 | 在这里指什么 |
|---|---|
| 阶段目录 | 01–05 下对应的工作目录，文件放在这里才能被识别。 |
| 初稿 | 作者提交、准备转成结构化内容的 Word 文件。 |
| 评审稿 | 从结构化内容导出、交给研发修订和批注的 Word 文件。 |
| 修订 | 研发在 Word 中直接修改文字或格式留下的痕迹。 |
| 批注 | 研发在 Word 中提出的说明、问题或修改建议。 |
| 工作副本 | 回写后生成的内容副本，不是源文件。 |
| 状态文件 | 记录本次处理的修订数、批注数和回写结果。 |
| 待批准 | 内容已处理完，等待人工确认，不等于已发布。 |
| 检查点 | 每个阶段结束前必须满足的完成条件。 |
| 入口文件 | 一本手册的顶层 map，用来确定本次处理的范围。 |
| 标准 Word | 不需要企业模板和 Word 插件的通用输出样式。 |
| 企业模板 Word | 按企业模板、样式文件和本机环境生成的输出样式。 |
00b / OXYGEN 用户三分钟
如果你平时在 Oxygen 里做文档
不用学新工具。记住“我做什么、AI 做什么、我看什么”三件事即可。
你负责
- 在 01 放 Word 初稿；
- 在 02 选 root map 和 Word 样式；
- 在 03 放回带修订/批注的 Word；
- 在 04/05 确认合并、完成审批。
AI 负责
- 01 把 Word 转成结构化内容；
- 02 生成评审用 Word；
- 03 提取修订和批注，回写工作副本；
- 04/05 报告门禁和状态。
你在 Oxygen 里看
- 01：
MIGRATION-REPORT.md； - 02：
out/docx下的评审 Word； - 03：最新
review-*的state.json/result.json； - 04/05：门禁结果和批准状态。
你不需要
- 不需要选角色；
- 不需要记命令；
- 不需要手工对齐 XML；
- 不需要把 Quality 当成 Review 的一步。
01 / 时间轴
五个阶段，一条评审链
01提交 Word作者 DE
02生成评审稿作者 DE
03研发评审研发 RD
04合并基线文档工程
05审批批准人
02 / 阶段与角色
谁在什么时候做什么
横向是五个阶段，纵向是角色。空白格表示该角色在该阶段不介入；不要让所有人都参与每一步。
角色 / 阶段ROLE / STAGE
01提交 Word作者 DE
02生成评审稿作者 DE
03研发评审研发 RD
04合并基线文档工程
05审批批准人
作者 DE写初稿 / 选样式
选择 map 与 Word 样式
选 root map；明确选 A 标准 Word 或 B 企业模板 Word。
预期 · 选择明确，可生成
AI 执行器按阶段执行，不批准
转换 Word
按模板把 Word 转换成结构化内容；复杂表格/公式提示人工复核。
预期 · 结构化内容 + 迁移报告
生成评审 Word
按所选样式导出评审用 Word，带修订/批注入口。
预期 · 评审 Word
提取并回写
读取真实修订/批注，回写工作副本；不覆盖源文件。
预期 · 工作副本 + 状态
报告门禁
只报告合并和审批门禁；不代替批准，不声称已发布。
预期 · 门禁结果
研发 RD修订 / 批注
评审并放回
在 Word 中只做修订和批注；把带真实意见的文件放回 03。
预期 · 可提取的评审意见
文档工程合并 / 基线
核对合并条件
确认最新评审结果可核对；当前 Review 只报告合并门禁，不自动生成新基线。
预期 · 合并检查结果
批准人审批
确认审批条件
确认内容、版本和记录；当前 Review 只报告状态，不自动写审批记录。
预期 · 待批准状态（APPROVAL_READY）
门禁
G1 转换结构化内容生成
G2 评审稿Word 可打开
G3 意见确有修订/批注
G4 合并检查结果可核对
G5 审批待批准状态
横向滚动可查看全部阶段；移动端不压缩阶段列，保持角色与阶段的对应关系。
03 / 一步一步做
五步操作，每步只看结果
01 提交 Word 初稿
把 Word 放进 01_ProduceSampleDITA，在 Oxygen 中打开该目录里的文件；到右侧 AI Positron 面板顶部点 Actions → Review：执行当前阶段。
预期：生成结构化内容与
MIGRATION-REPORT.md；复杂表格/公式标记人工复核。02 生成评审用 Word
进入 02_DITAtoDocsforReview，选 root map；明确选择 A 标准 Word 或 B 企业模板 Word。
预期：
out/docx 下出现可评审 Word；样式与选择一致。03 研发评审
研发在 Word 中做修订/批注，把文件放回 03_DocsReviewed；点击 Review。
预期：最新
review-* 有 state.json / result.json，显示修订、批注和回写结果。04 核对合并条件
文档工程确认评审结果可核对；当前 Review 只报告合并门禁，不自动生成新基线，也不重做评审。
预期：合并检查结果可核对；没有 Git/批准记录时，不声称已合并或已发布。
05 确认审批条件
批准人确认内容、版本和记录；当前 Review 只报告状态，不自动写审批记录。
预期：出现
APPROVAL_READY 待批准状态；它不是审批记录，也不是已发布。04 / Word 样式选择
先选 A 或 B，具体怎么做
Word 样式由 10_REVIEW/config/word-profiles.json 管理。普通作者不需要改配置；只需在 02 阶段明确回答 A 或 B。B 由管理员先配好路径，否则预检会停。
A. 标准 Word（首次使用建议选这个）
使用配置里的 docx_standard。不需要 Word 插件，不需要企业模板；但仍要求本机的 DITA 构建程序和 Java 运行环境路径有效。输出通用 Word，样式和编号不保证与企业模板完全一致。
选择方法：在 02 阶段点击 Review，当它询问样式时选 A，或直接说“A 标准 Word”。
B. 企业模板 Word
使用配置里的 docx_ext。需要主题目录、模板文件、document.xsl、numbering.xsl、footnotes.xsl，以及本机 DITA 构建程序和 Java 环境。任何一项缺失都会失败。
选择方法：先由管理员确认上述路径存在；在 02 阶段选 B，或说“B 企业模板 Word”。不要猜路径，也不要用相近模板代替。
02 阶段的实际顺序
1. 打开 02_DITAtoDocsforReview 里的文件，点击 Review：执行当前阶段。
2. 选择本次手册的入口文件（root map）。
3. 当 Review 询问样式时，明确回答 A 或 B；不回答就停在预检。
4. A 直接生成；B 先检查 word-profiles.json 中的路径，缺项则停止。
5. 结果都在 02_DITAtoDocsforReview/out/docx；打开确认样式与选择一致。
当前 word-profiles.json 里的模板、主题和构建程序路径可能是开发机路径；换到高云机器后必须改成实际路径。模板字段是 template，当前配置指向一个 .docx 模板，不要按旧说明强行准备 .dotx；最终以配置和预检结果为准。
05 / 出问题时看哪里
先看阶段，再看文件
| 现象 | 通常原因 | 下一步 |
|---|---|---|
| 没有识别到阶段 | 打开的文件不在 01–05 阶段目录 | 打开阶段目录里的文件再点 Review |
| 找不到 Word / map | 文件没放进阶段目录，或放了多个 | 只保留本次要用的文件；多个时明确选一个 |
| 评审 Word 没有修订/批注 | 放回的是发布稿，不是评审稿 | 停止；不要用发布稿冒充评审稿 |
| 样式生成失败 | Word 样式模板/样式文件缺失 | 改选 A 标准 Word，或补齐 B 所需文件 |
| 04/05 没有结果 | 03 还没有成功生成最新评审结果 | 回到 03 完成评审；不要跳过 |
| 状态显示 APPROVAL_READY | 已到待批准，不是已发布 | 交给批准人；不要对外称已发布 |
06 / 边界
这些事不要做
Review 内
- 不要选角色；阶段决定角色；
- 不要跳过 03 直接做 04/05；
- 不要把发布稿当评审稿；
- 不要把工作副本当发布件；
- 没有 Git/批准记录时，不要声称合并/发布完成。
Review 外
- Quality 是独立模块，不进入 Review 状态；
- 不要为了“跑通”改验收标准；
- 不要生成脚本或手工改工具输出；
- 复杂表格/公式必须人工复核；
- 没有真实评审意见时，不进入下一阶段。
Review 的目标是“把评审意见可靠地带回内容”，不是“自动批准”。AI 可以执行，但不能替代作者、研发和批准人的判断。