# 操作手册结构

操作手册面向软著审核员，目标是说明软件用途、功能和基本操作。

常见内容范围：

1. 软件概述
2. 适用对象或使用场景
3. 运行环境
4. 进入软件或账号登录
5. 主要功能概览
6. 具体功能操作说明
7. 典型使用流程
8. 使用注意事项

以上只是内容范围，不是固定模板。生成时应根据项目业务、页面入口和功能关系自主组织章节，不要强制套用用户提供的范本文案或固定顺序。
具体章节结构应优先来自 `草稿/业务理解.json` 中模型写入的 `manual_sections`；如果该字段为空，才生成通用结构草稿并在自检记录中说明。

## 写作口径

- 使用通用、客观、简洁的中文。
- 不写面向终端用户的复杂教程。
- 每个章节必须有段落化说明，不能只写项目符号列表。
- 每个核心页面或功能模块必须写“模块用途 + 操作过程 + 系统反馈 + 截图预留”。
- 功能特点可以使用编号，但每个编号下至少写两句通顺说明，说明该功能解决什么业务问题以及用户如何感知结果。不同功能的说明要有差异，避免每条都使用相同句式。
- 操作手册语言要让审核员和普通读者能看懂，重点说明模块是做什么的、怎么操作、操作后看到什么。避免代码、框架、接口、状态管理、异步任务等技术化表达。
- “AI 味”主要表现为空泛、整齐、万能、没有项目现场感：例如每个模块都用同一种句式，反复写“提升效率、优化体验、提供支持”，使用“旨在、赋能、一站式、智能化、高效便捷、显著提升、强大能力、丰富功能”等口号，却没有说明当前项目的真实页面、真实对象、真实动作和真实反馈。发现这类内容时必须改写成朴素、具体、可回溯到项目证据的表达。
- 截图前必须先让用户在 Chrome DevTools MCP、Codex Computer Use、用户自行截图三种方式中选择；选择后检查对应能力是否可用。用户说现在不截图或先跳过截图时，记录为 `skip`，并在每个需要截图的位置保留正式 Word 中可见的截图预留文字。
- 不夸大不存在的功能。
- 功能名称和章节组织由模型根据项目证据判断；路由、页面、README、接口和组件命名只是证据来源，不是固定抽取规则。
- Markdown 草稿生成前由 agent 自行检查章节完整性、内容厚度、项目流程一致性和语言自然度，发现章节过薄、模块套话、AI 味、技术化表达或相邻模块含义混淆时先循环补写和修正；完整草稿生成后只向用户发起一次整体确认，再进入 Word 生成。
- 操作手册生成时必须同步输出 `操作手册自检记录.md/json`。记录中至少包含初稿生成、按项目流程扩写、去除制式表达和 AI 味三轮；如果第三轮仍发现问题，要继续自动修正并追加轮次记录。
- 操作手册必须基于已确认的业务理解写作。相近功能应结合项目真实业务分别说明各自的操作目的、用户动作和结果反馈，不能用同一段话替换不同模块。
- 禁止把测试项目中的行业、角色、流程、功能名称或示例文案写成通用规则；范本只能帮助理解软著手册需要“通顺、具体、能给审核员看懂”，不能作为固定内容来源。