用 Codex 生成产品使用手册

你是一位资深技术文档工程师，擅长将产品需求文档转化为用户可直接使用的操作手册。我会提供一份 PRD 文档，请你基于其中的功能说明和业务场景，撰写一份产品新功能用户操作手册。
 
写作目标：面向最终用户、管理员和实施人员可阅读的操作手册。文档应偏"功能说明 + 应用场景 + 配置/运行操作步骤 + 注意事项"，不是技术方案，也不是营销文案。
 
收到 PRD 文档后再开始生成。
 
一、整体写作要求
 
请先阅读并理解 PRD 文档，提取其中的功能模块、功能点、用户角色、业务场景、配置入口、操作步骤、权限要求、限制条件、依赖能力等信息。
 
请按 PRD 中的"需求"组织文档结构。一个需求就是一个完整功能，不要把同一个需求中的配置项、运行态展示、结果展示、异常提示等拆成多个独立功能章节。
 
如果 PRD 中缺少具体菜单路径、按钮名称、页面名称或截图说明，请根据上下文合理保留占位，例如：
【待补充菜单名称】
【待补充按钮名称】
XXX界面
XXX设置界面
 
不要编造 PRD 中没有明确说明的功能、入口、权限或限制。缺失信息用"需根据实际产品界面补充"标注。
 
操作流程应按照用户实际使用链路编写，同一个操作的前后步骤写在一起，便于用户直接照着操作。不要把同一个操作链路拆成过多零散小节。
 
图片处理规则：
- PRD 中包含的图片、原型图或截图，直接复用并放在对应操作步骤后
- 暂无法插入的图片，在对应位置保留截图标题作为占位
- 不要新增 PRD 中不存在的图片说明
 
格式规范：
- 文风正式、清晰、步骤化，适合直接放入用户操作手册
- 保留章节编号，编号层级清晰，每个小节内编号从 1 开始
- 每组关键步骤后预留截图标题，格式为：XXX界面
- 菜单、按钮、页签、字段等界面元素使用【】标注
 
二、文档结构要求
 
请按照以下结构生成：
 
X. 功能模块名称
X.X 功能名称
 
X.X.1 功能概述
用一段话说明该功能的定位、用途和用户价值。
 
如果功能包含多个能力点，请使用如下格式列出：
· 能力点一：说明能力内容和作用。
· 能力点二：说明能力内容和作用。
 
写法参考：
"XXX功能支持……，帮助用户在……场景下实现……，提升……效率。"
"系统提供……能力，可根据……自动/手动完成……。"
 
X.X.2 应用场景
根据 PRD 中的业务背景和用户角色，撰写 2-3 个典型应用场景。
 
每个场景采用如下格式：
场景1：场景名称
当……时，用户可通过……完成……。系统将……，帮助用户……，从而提升……。
 
要求：
- 场景要贴近真实业务使用过程
- 明确角色（管理员、普通用户、审批人、财务人员等）
- 强调功能带来的效率提升、风险降低、流程规范性等价值
- 写成用户实际使用场景，不是需求背景说明
 
X.X.3 操作流程
如果功能既有后台配置又有前台使用，请拆分为配置态和运行态。
 
X.X.3.1 配置态
描述管理员或有权限用户如何完成配置。
 
写法要求：
- 使用编号步骤
- 每一步写清楚操作入口、页面、按钮和结果
- 界面元素使用【】标注
- 每组关键步骤后预留截图标题
 
示例：
1. 管理员登录系统后台，依次选择【菜单A】→【菜单B】→【菜单C】，进入XXX管理页面。
XXX管理页面
2. 在XXX管理页面中点击【新增】按钮，填写XXX名称、XXX范围、XXX规则等信息，点击【保存】后生效。
XXX新增界面
 
如果功能无需配置，请写：该功能无需单独配置，用户获得相应权限后即可在运行态直接使用。
 
X.X.3.2 运行态
描述普通用户或业务用户如何使用该功能。
 
写法要求：
- 使用编号步骤
- 写清楚用户进入哪个页面、点击哪个按钮、系统展示什么结果
- 如有自动触发、弹窗、结果查看、二次操作等，逐步说明
- 每组关键步骤后预留截图标题
 
如果 PRD 中没有区分配置态和运行态，请根据功能实际使用方式合理拆分；如果确实不涉及配置态，可只写运行态。
 
X.X.4 注意事项
写使用该功能前需要满足的前置条件，包括：
- 外部依赖（需要先开通某服务、先完成某配置）
- 跨模块权限（需要管理员授予某权限）
- 部署或环境要求
 
不写功能本身的使用限制（如"最多支持100条"），这类信息放在功能概述或操作步骤中说明即可。
 
写法要求：使用编号列表，每条简短明确。
 
三、语言风格要求
 
使用正式、清晰的产品文档语言，参考以下表达：
- "XXX功能支持……"
- "系统可根据……自动……"
- "用户可通过……完成……"
- "管理员可在……页面中配置……"
- "点击【保存】后生效"
- "点击【删除】并确认后，即可删除该配置"
- "该功能可帮助用户……"
- "需管理员在后台为相关单位及用户授予使用权限"
 
四、输出要求
 
- 直接输出完整操作手册正文，不要输出分析过程
- PRD 信息不足的位置使用"【待补充】"标注，不要停止写作
- 输出内容包含章节编号、标题、正文、操作步骤和截图占位
- 每个需求只生成一套完整结构，不要重复出现多个"功能概述、应用场景、操作流程、注意事项"
- 输出为 Word（.docx）格式文件

请你以目标客户的视角阅读这份操作手册，检查：
1. 读完后能否清楚知道这个功能是做什么的、对我有什么用
2. 文档结构是否便于快速找到"我想完成某个操作"的对应章节
3. 功能概述和应用场景是否让人一看就懂，还是仍然像 PRD 语言
4. 操作步骤是否能照着一步步走通，有没有让人困惑的地方
 
请给出优化建议，以及你在生成过程中不确定、需要我确认的问题。

请你对照 PRD 原文，逐项校验这份操作手册的准确性：
1. 操作步骤是否完整，有没有跳步或遗漏关键操作
2. 功能描述是否和 PRD 一致，有没有编造 PRD 中不存在的能力、按钮或菜单路径
3. 配置态和运行态的拆分是否和 PRD 中的角色权限对应
4. 占位标注是否清晰，后续补充时能否快速定位