工具切换支持手册面向已经完成切换的使用者，核心是把“谁在什么场景下做什么、去哪里找、找谁问、多久有回应”写清楚。编写时先锁定切换后的高频任务与常见卡点，再按任务场景组织章节，明确每类问题的入口、责任人和响应时限，最后用真实用户试读和上线后的问题回流持续修订。以下按内容框架、章节写法、角色分工、完整示例和完成检查五步展开。
要点总览（TL;DR）
- 支持手册面向已完成切换的使用者，先盘点切换后的高频任务与卡点，再按账号与权限、核心操作路径、历史数据查找、异常与回退求助、反馈渠道五类内容组织，按影响面和卡点频率排优先级。
- 章节按用户要完成的任务划分，单页统一使用适用角色、前置条件、操作步骤、预期结果、常见问题、求助入口六个字段，并配一张新旧工具名称对照表。
- 编写者、业务审阅人、支持响应人、手册维护人四类角色各有交付物和交接方式，评审节奏随切换阶段从每周逐步放宽到每月。
- 手册是否可用由真实用户试读判断，上线后按同一问题一周被问三次以上等条件触发修订，并定期识别过期页面。
手册先写什么：切换后用户最需要的五类内容
支持手册的内容起点是切换后用户的实际任务，产品功能目录只能作为参考。编写前先做一轮任务盘点：收集切换通知发出后一周内支持渠道收到的问题、切换培训中的提问记录、试点用户的操作反馈，把重复出现的问题归并成任务条目，再标注每条任务影响多少人、每天或每周发生几次。影响面大且卡点频率高的任务排在最前，低频且影响有限的内容放在后面或合并处理。
盘点结果通常可以归入五类内容，这五类构成手册的完整骨架：
| 内容类别 | 要回答的问题 | 典型条目 |
|---|---|---|
| 账号与权限 | 我怎么进入、能做什么、权限不够找谁 | 首次登录、密码与验证方式、角色权限差异、权限申请入口 |
| 核心操作路径 | 我日常最常做的几件事怎么做 | 新建与流转、常用查询、批量处理、导出与分享 |
| 历史数据查找 | 旧工具里的记录去哪了、怎么找 | 历史记录入口、检索方式、字段对应关系、找不到时的求助 |
| 异常与回退求助 | 出错时怎么办、能不能退回旧方式 | 常见报错处理、数据异常上报、临时回退的申请条件与流程 |
| 反馈渠道 | 有问题和建議往哪提、多久有回应 | 支持入口、值班时间、响应时限、问题升级路径 |
排序时把“影响面×卡点频率”作为统一口径：影响全员且每天发生的登录与权限问题必须放在第一章；只影响个别岗位的导出格式问题可以放到附录。每类内容先写最短可用版本，即能让人完成操作并知道找谁，再根据回流问题补充细节。完成标志是形成一份带优先级编号的内容清单，每条注明负责人和初稿截止时间，经业务审阅人确认后进入写作。
按任务场景组织章节：从目录到单页写法
章节划分以用户要完成的任务为单位，例如“提交一条新需求”“查找三个月前的历史记录”“申请临时回退”，每个任务一节。按功能模块划分会让用户先理解产品结构再找答案，切换初期用户对新产品结构不熟，按任务组织能让他们从自己的目的直接进入对应页面。目录层级控制在两层以内，一级是任务分组，二级是具体任务，单页标题用动词开头，写清对象和结果。
每个任务页使用同一套模板，保证不同编写者产出的页面结构一致、用户阅读路径一致：
- 适用角色：写明哪些岗位或权限的人会用到这一页，避免无关用户误读。
- 前置条件：进入操作前需要具备的账号、权限、数据或审批状态。
- 操作步骤：按顺序编号，每步一个动作，写清点击什么、填写什么、选择哪个选项。
- 预期结果：操作完成后用户应看到什么状态或页面，用于自我判断是否成功。
- 常见问题：列出该任务下最高频的两到三个卡点及处理办法。
- 求助入口：写明本任务出问题时的联系渠道、责任人和响应时限。
术语处理要单独约定。新旧工具名称并存是切换期的常态，手册应在开头放一张对照表，列出旧名称、新名称和一句话说明，正文统一使用新名称，首次出现时括注旧名称。同一概念在不同团队有不同叫法时，选定一个作为手册标准用语，其余叫法放入对照表，避免同一页面混用多个词。完成标志是目录通过业务审阅、单页模板定稿并完成两到三页试写，确认模板字段够用、不冗余。
角色与交付物：谁写、谁审、谁维护
手册写完无人维护，通常是因为职责没有落到具体人和具体交付物上。编写阶段至少区分四类角色，每类角色有明确产出和交接节点：
| 角色 | 职责 | 交付物 | 交接方式 |
|---|---|---|---|
| 编写者 | 按内容清单和模板撰写任务页，保证步骤可复现 | 任务页初稿、术语对照表 | 初稿提交业务审阅人，附上信息来源和未确认事项 |
| 业务审阅人 | 核对操作步骤与实际业务规则是否一致，确认权限和审批描述准确 | 审阅意见、签字确认的定稿 | 审阅意见回给编写者修改，定稿移交维护人 |
| 支持响应人 | 按手册中的求助入口接收问题，在承诺时限内回应，记录问题类型 | 问题记录、高频问题清单 | 每周把高频问题清单交给维护人，作为修订输入 |
| 手册维护人 | 管理版本、合并修订、发布更新通知、识别过期内容 | 版本记录、更新说明、过期内容处理记录 | 每次更新后通知支持响应人和业务审阅人 |
评审节奏与切换阶段匹配：上线前完成全部核心任务页的审阅；上线后第一个月每周评审一次新增和修订内容，第二个月起改为每两周一次，稳定后按月评审。每次评审只处理有明确输入的变化，例如支持响应人提交的高频问题、业务规则调整、新发现的术语歧义，避免为开会而开会。维护人负责在版本记录中写明改了什么、为什么改、影响哪些页面，让后续接手的人能追溯。完成标志是四类角色都落实到具体人名，评审日历排定，第一轮审阅意见闭环。
手册的编写、评审和版本维护本身是一组协作动作：内容清单对应待办事项，初稿和审阅意见对应文档状态流转，高频问题清单对应持续输入。使用 ONES 时，可以把任务页初稿作为文档关联到对应工作项，审阅意见在文档评论中留痕，支持响应人记录的问题按类型汇总为工作项进入修订队列，版本更新通过文档状态和更新说明体现。这样手册的每次修改都有来源、有责任人、有状态，维护人不必靠个人记忆追踪进度。
示例：一个“找不到历史需求记录”页面的完整写法
以下示例为演示情景，用于说明单页模板如何填写，具体入口名称和时限需按实际环境替换。
页面标题：查找切换前的历史需求记录
适用角色：产品经理、项目经理、需求提出人，以及需要查阅历史需求做复盘的分析人员。
前置条件：已开通新平台账号；具备历史数据查询权限，无权限者需先提交权限申请；知道要查找的需求大致时间范围或关键词。
操作步骤：
- 进入新平台的查询入口，选择“历史记录”范围，默认只查切换后的数据，需手动勾选包含切换前数据。
- 输入关键词，可使用需求标题、提出人或时间范围组合检索；旧编号与新编号不一致时，用旧编号在对照表中查到新编号再检索。
- 在结果列表中确认记录状态，切换前的已关闭需求显示为归档状态，可查看详情但不能直接编辑。
- 需要继续跟进的历史需求，使用“复制为新需求”功能重建，原记录保留作为追溯依据。
预期结果：结果列表出现目标记录，详情页可查看原始描述、处理记录和附件；复制后的新需求出现在当前项目中，与原记录建立关联。
常见问题：检索无结果时，先确认是否勾选包含切换前数据，再确认关键词是否与旧叫法一致，可查术语对照表；附件无法打开时，记录需求编号提交支持渠道，不要重复上传。
求助入口：数据查询类问题提交至支持渠道的“数据与记录”分类，工作日值班时间内响应时限为4小时；影响多人查询的批量问题，由支持响应人升级为高优先级并同步维护人。
这个示例体现了模板的用法：步骤写到可复现，预期结果让用户能自行判断成败，求助入口带分类和时限。其他任务页照此填写，保持字段完整、篇幅克制。
上线前试读与上线后修订：手册的完成检查
手册是否可用，用真实用户能否独立完成任务来判断。上线前组织试读，选取覆盖不同岗位和熟练度的用户，每人分配两到三个与其工作相关的任务，只给手册不给口头指导，观察他们能否找到页面、按步骤完成、在卡住时找到求助入口。记录卡住的位置和原因，作为修订依据。
上线前检查清单：
- 五类内容均有对应页面，核心任务页无缺项。
- 每个任务页六个模板字段填写完整，步骤可复现。
- 术语对照表覆盖新旧名称，正文用词统一。
- 每页求助入口写明渠道、责任人和响应时限。
- 试读用户能独立完成分配任务，卡点已修订或标注说明。
- 目录、版本记录和负责人信息齐全，发布渠道已通知到使用者。
上线后建立问题回流机制。支持响应人按周汇总问题类型，出现以下情况触发修订：同一问题一周内被问三次以上；用户按手册操作仍未完成；业务规则或权限设置发生变化；新旧名称对照出现遗漏。维护人根据触发条件安排修订，并在版本记录中注明来源。过期识别同样需要规则：页面引用的入口、审批流程或时限发生变化时，该页标记为待更新；连续两个月无人访问且无问题回流的页面，评估合并或下线。完成标志是检查清单逐项通过、回流机制开始运转、第一轮修订闭环，此后手册进入按节奏维护的状态。
常见问题
切换后用户问题很多，手册第一版应该先写哪些页面？
先写影响全员且每天发生的任务，通常是登录与权限、最常用的两三个操作路径、历史记录怎么查。把切换通知发出后一周内支持渠道的问题和培训提问记录归并成任务条目，标注影响人数和发生频率，按影响面乘卡点频率排序。低频、只影响个别岗位的内容先放附录或暂缓，等第一版上线后根据回流问题补充。
手册里的操作步骤写到什么颗粒度算够？
判断标准是试读用户只拿手册、没有口头指导也能独立完成。步骤按顺序编号，每步一个动作，写清点击什么、填写什么、选择哪个选项，并给出操作完成后的预期状态。涉及权限申请、审批或数据范围的，把前置条件写在步骤之前。步骤里出现新旧名称混用时，统一用新名称并在首次出现处括注旧名称，其余叫法放进术语对照表。
小团队人手有限，四类角色可以合并吗？
可以合并，但要保留职责边界。常见做法是编写者同时承担维护人，业务审阅人由熟悉业务规则的人兼任，支持响应人由日常接问题的人担任。合并后仍需保证审阅不是编写者自己签字，求助入口有明确的接收人，版本记录有人更新。角色合并的风险是修订输入没人汇总，建议至少保留每周一次的高频问题清单交接。
上线后发现手册某页写错了，怎么处理才不引起混乱？
先由维护人判断影响范围：只影响个别用户的操作描述，直接修订并在版本记录中注明改动和原因；涉及入口、审批流程或时限变化的，修订后通知支持响应人和业务审阅人，并在发布渠道说明。修订期间该页可标注“待更新”，避免用户按旧内容操作。若同一问题反复出现，说明页面结构或术语有问题，应回到单页模板层面调整，而不只是改文字。
手册稳定运行后还需要定期评审吗？
需要，但频率可以降低。切换后第一个月每周评审，第二个月起每两周一次，稳定后按月评审。评审只处理有明确输入的变化，例如支持响应人提交的高频问题、业务规则调整、新发现的术语歧义。同时定期检查过期内容：页面引用的入口、审批流程或时限发生变化时标记待更新；连续两个月无人访问且无问题回流的页面，评估合并或下线。
