需求定义：先写清使用边界
这份清单用于在接触任何候选方案之前，先把亿万28的使用边界写下来。审计现在做的原因很简单：需求没写清时，后续比较很容易变成参数对照，而不是围绕真实场景判断。清单只覆盖可观察、可复述的内容，不涉及任何供应商评价或结果承诺。 亿万28
- 用一句话写明主要用途，避免出现“通用”“全能”这类无法核对的说法。
- 列出实际参与使用的角色，以及每个角色最常执行的动作。
- 标注使用频率与时段，例如日常连续使用还是阶段性集中使用。
- 写下当前已知的硬约束，包括环境条件、既有流程衔接点。
- 确认哪些需求属于“没有就不能用”，哪些只是“有更好”。
必备项与加分项：分级核对
把需求分成两级再进入比较，能减少后面反复改口的成本。必备项是判断能否继续谈的门槛，加分项只影响排序，不影响是否入围。
- 必备项逐条写成可验证的陈述，而不是形容词。
- 加分项单独成组，避免与必备项混在同一张清单里。
- 为每条必备项标注核对方式：演示、文档阅读或现场试用。
- 记录候选方案在必备项上的缺口，不用“基本满足”含糊带过。
- 明确加分项的权重上限，防止次要差异压过门槛条件。
对照分组示例
- 门槛组：使用边界内的基础能力、与既有流程的衔接方式。
- 排序组：操作习惯匹配度、维护成本的可预期性。
- 观察组：需要更长时间使用才能判断的差异，先记录不下结论。
评估问题：向候选方案追问什么
提问的目的不是为难对方，而是让内部评估者拿到可以写进简报的事实。问题应围绕使用边界展开，避免泛泛而谈。
- 在写明的使用边界内，哪些能力是默认具备的，哪些需要额外配置？
- 出现异常时，使用方能看到哪些信号，如何判断是否需要回退？
- 与现有流程衔接需要改动哪些环节，改动由谁承担？
- 日常维护动作有哪些，频率和前置条件分别是什么？
- 哪些限制条件是方案本身固有的，短期不会改变？
取舍清单：哪些差异可以接受
取舍不是找完美方案，而是确认哪些差异在边界内可以接受。以下核对项用于把讨论从偏好拉回条件。
- 差异是否落在必备项之外，若落在门槛内则直接排除。
- 差异带来的额外操作是否超出使用角色的承受范围。
- 差异是否可以通过流程调整消化，而不是依赖方案改变。
- 差异在试用期内是否可观察，无法观察的先列入观察组。
- 把可接受取舍与不可接受取舍分别写清，留作后续复核依据。
建议框架：形成内部结论的下一步
清单核对完成后，用一份简短简报收口，便于其他人复核判断过程而不是只看结论。
- 整理需求边界与必备项清单，标注每条核对方式。
- 汇总候选方案在门槛组上的缺口，缺口未闭合的不进入排序。
- 记录加分项差异与可接受取舍，注明观察组待定项。
- 形成内部结论草案，写明依据与未决问题，进入下一轮复核。