先立基线：现状盘点与核对范围
谈欧博平台之前，先把“现在是什么样”写清楚，否则后面的核对都会漂移。基线阶段的目标不是选方案，而是把可观察的现状固定下来，作为后续每个阶段的比对参照。
- 列出当前在用工具与流程节点，标注每个节点的负责人。
- 记录现有操作的输入与输出，确认哪些环节已有书面说明。
- 标出近期反复出现的操作痛点，只写现象，不写猜测原因。
- 明确本次核对范围：哪些环节纳入，哪些明确不纳入。
- 确认参与核对的人员名单与各自可决策的边界。
基线阶段的退出条件：范围、人员、现状描述三项都有书面记录，且参与方对“不纳入项”没有异议。未达成则不要进入下一阶段。
第一阶段：把需求与约束写成可核对条目
这一阶段把模糊的期望转成能逐条打勾的条目。目标是把“想要更好用”这类表述，拆成可观察、可验证的具体要求。
- 每条需求写成一句可判断真假的陈述，避免形容词堆叠。
- 区分硬约束与偏好项，硬约束不满足即淘汰。
- 为每条需求标注验证方式：看文档、现场演示还是小范围试用。
- 记录需求来源，避免口头转述造成偏差。
- 对相互冲突的需求标注优先级，而不是全部保留。
- 先完成硬约束清单，再讨论偏好项。
- 硬约束确认后再进入候选方案收集。
- 候选方案收集完毕后才安排验证。
退出条件：需求条目数量稳定、每条都有验证方式、硬约束与偏好项已分开。此时才具备进入场景验证的前提。
第二阶段：把候选方案放进真实场景验证
验证阶段围绕欧博平台的实际使用场景展开，重点是观察操作路径是否顺畅、异常情况是否有明确处理方式，而不是比较功能数量。
- 选取一个有代表性的日常场景，完整走一遍操作流程。
- 记录每一步的输入来源与输出结果，标注卡点位置。
- 检查异常输入时的提示信息是否可理解、可追溯。
- 确认操作记录是否留存，便于事后复盘。
- 核对权限划分是否与基线阶段的人员边界一致。
退出条件：场景走查记录完整、卡点有明确结论（可接受或不可接受）、异常处理方式已书面确认。结论存疑的条目退回需求阶段重新表述。 欧博平台实用指南
第三阶段：小范围试运行并固化操作规范
试运行阶段的目标是把验证过的路径变成可重复执行的规范，同时暴露验证阶段未覆盖的情况。
- 限定试运行范围与时长，避免无限期扩大。
- 为试运行设定观察指标，只记录可观察现象，不做推测性结论。
- 把验证阶段确认的操作步骤写成简明操作说明。
- 记录试运行中出现的新问题，标注是否影响原有结论。
- 明确回退方式：出现何种情况时停止试运行并恢复原流程。
退出条件：操作说明可被未参与验证的人独立执行、新问题已分类处理、回退方式已确认可用。
评审关口与交接：谁能签字、交什么材料
每个阶段之间设一个评审关口，关口的作用是防止问题被带入下一阶段。交接材料应能支撑他人独立复核。
- 关口一：基线记录与范围说明是否齐全。
- 关口二：需求条目是否全部具备验证方式。
- 关口三：场景验证结论是否逐条有依据。
- 关口四：试运行记录与操作说明是否配套。
- 交接包：现状记录、需求清单、验证记录、操作说明、回退方式。
交接完成后，由接手方按清单逐项核对，发现缺项即退回上一阶段补齐。整条阶段路线的价值在于每一步都有可核对的产出，而不是一次性的结论。