范围说明书被反馈“边界不清”或“验收标准模糊”时，先别急着整体重写。这两类问题可以分开排查：边界问题看某条内容能否对具体工作项给出“做或不做”的判定，验收问题看能否用可观察结果判断“通过或不通过”。排查时把说明书条目拆成包含项、排除项、假设与依赖、验收条件四类字段，逐条追问判定依据和责任人；拿不出证据的记为缺陷假设，再用干系人确认、上游文件比对和样例试判三种证据排除或坐实，最后回填修订并设置复发检查点。
要点总览（TL;DR）
- 先分类再排查：问“该不该做”答不上来是边界问题，问“做成什么样算完成”答不上来是验收问题，两类缺陷的取证方式不同。
- 原因在取得证据前只作假设：边界条目用执行人员试判，依赖缺失用上游文件比对，验收缺陷用“谁来验、怎么验、什么算通过”三项检验，术语分歧用多方复述比对。
- 排查顺序按影响面排：先查影响验收与结算的条目，再查跨团队接口条目，最后处理内部表述问题。
- 涉及合同或已批准范围的修改只记录差异并提交变更流程，排查中不直接改口径；证据不足的条目标记待确认，不强行下结论。
- 修订后用真实工作项重新试判、请验收方复述通过条件，并把边界、假设、验收三类检查项固化进评审清单和阶段关口复核。
症状与范围：先分清边界问题还是验收问题
排查的第一步是把“这份说明书有问题”这类笼统反馈，转成能定位到具体条目的症状清单。边界问题和验收问题的表现不同，混在一起讨论容易各说各话。判断某一条属于哪类问题，可以用一个简单标准：问“这件事该不该做”时答不上来，是边界问题；问“做成什么样算完成”时答不上来，是验收问题。
边界不清的典型症状
- 包含项与排除项缺失：说明书只写了要交付什么，没有写明哪些相邻工作明确不做，导致执行中不断有人提出“这个是不是也该我们做”。
- 相邻系统或团队职责重叠：两个模块、两个团队对同一功能或同一份数据都有描述，接口处的归属没有写清。
- 交付物颗粒度不一致：同一份说明书里，有的条目细到单个报表字段，有的只写“提供相关支持”，粗细不一使边界无法对齐。
- 范围描述使用无指向的动词：如“配合”“协助”“必要时支持”，没有说明配合的对象、动作和产出。
验收标准模糊的典型症状
- 只有定性描述：“界面友好”“性能良好”“文档齐全”这类表述，不同人可以给出不同判断。
- 缺少判定方法：写了要达到的状态，但没写用什么方式验证，是演示、抽样检查还是对照清单逐项确认。
- 缺少判定人：没有写明由谁确认通过，出现争议时无人可作最终判断。
- 无通过阈值：涉及数量、比例、时间的条件没有给出具体数值或允许偏差。
需要区分“模糊”和“只是写得简略”。简略但可判定的条目，例如“提交一份含五个章节的测试报告”，虽然短，但通过条件清楚，不属于缺陷；模糊的条目即使写得很长，只要无法据此判断通过与否，就应列入排查。判断依据是能否写出可观察的通过条件，篇幅长短不作标准。
划定本次排查的范围
本次排查只覆盖范围说明书本身及其直接上游文件，例如立项文件、合同范围条款、需求文档中的范围约定。任务拆解是否合理、变更审批流程是否顺畅，属于另外的问题，不在本轮排查中展开，避免把范围缺陷和计划缺陷混为一谈。
每条症状都要记录出现位置：属于哪一条条目、对应说明书的哪一版、由谁提出。这份记录既是后续假设验证的输入，也是修订前后对比的依据。可以用下表整理：
| 症状描述 | 所属条目 | 疑似类型 | 提出人 | 说明书版本 |
|---|---|---|---|---|
| 未写明第三方接口由谁负责联调 | 3.2 系统集成 | 边界不清 | 开发负责人 | V1.2 |
| “响应速度满足业务需要” | 5.1 性能要求 | 验收模糊 | 测试负责人 | V1.2 |
| “提供上线支持”未说明支持内容 | 6.3 交付服务 | 边界不清 | 项目经理 | V1.1 |
原因假设与排除证据：四类字段逐条追问
症状清单整理出来后，下一步是针对每条症状提出原因假设，并为每个假设规定能排除或坐实的证据。原因在取得证据前只是假设，不能直接写进结论，否则修订可能改错地方。下面四类假设覆盖了范围说明书缺陷的常见成因，可以逐条对照使用。
假设一：边界条目缺失或表述笼统
证据要求：把该条目交给一位不参与编写的执行人员，请其判断某个具体工作项属于范围内还是范围外。如果能给出明确的是或否，并说明依据条目中的哪句话，假设排除；如果无法判定或需要额外解释才能判断，假设坐实。这个试判要用两到三个真实工作项分别测试，避免只测一个恰好能对上的例子。
假设二：假设条件与外部依赖未写明
证据要求：对照上游立项文件、合同范围条款或需求文档，检查说明书中依赖的外部条件是否有对应约定。例如说明书默认某接口由对方系统提供，但上游文件未作此约定，则该依赖属于未写明。找到上游文件中的对应条款即可坐实或排除，找不到对应约定时记为待验证，不直接认定任何一方有责任。
假设三：验收标准缺少判定方法与判定人
证据要求：尝试为每条验收标准写出“谁来验、怎么验、达到什么结果算通过”。三项都能写出的条目，假设排除；缺少其中任何一项的，假设坐实。这里要注意，判定方法必须可执行，例如“由测试负责人在验收环境执行清单中的十项检查，全部通过即为通过”，而不是“经确认满足要求”。
假设四：多方对同一术语理解不一致
证据要求：请业务方、开发方、验收方分别用自己的话复述同一术语的含义，记录差异。复述一致则假设排除；出现实质差异，例如“上线”一方理解为部署完成、另一方理解为业务方开始使用，则假设坐实，并记录差异点作为修订输入。
每条假设都要标注状态：已排除、待验证或已坐实，并写明支撑证据的来源。可以用下表维护：
| 假设 | 对应条目 | 所需证据 | 证据来源 | 状态 |
|---|---|---|---|---|
| 边界条目笼统 | 6.3 交付服务 | 执行人员试判结果 | 试判记录 | 已坐实 |
| 外部依赖未写明 | 3.2 系统集成 | 上游合同条款比对 | 合同附件二 | 待验证 |
| 验收缺判定人 | 5.1 性能要求 | 能否写出判定人与方法 | 条目原文 | 已坐实 |
| 术语理解不一致 | 4.1 上线 | 三方复述差异记录 | 访谈记录 | 已坐实 |
排查过程涉及多条假设、多个责任人和多轮确认，条目状态容易散落在邮件和聊天记录里。可以在 ONES 中把每条待查条目登记为工作项，指定确认责任人，将试判记录、上游文件比对结果和干系人复述差异作为附件或文档关联到对应条目，让“哪条已坐实、哪条还待验证”始终有统一出处，评审时按状态筛选即可推进。
排查顺序与处置动作：从条目到修订
假设清单可能很长，排查顺序按影响面安排，而不是按条目编号从头到尾。先查影响验收与结算的条目，这类缺陷会直接导致交付无法确认、款项无法结算；再查跨团队、跨系统的接口条目，这类缺陷影响面广且容易在执行中反复引发争议；最后处理内部表述问题，例如措辞不统一但不影响判定的条目。
取证动作
- 条目试判：选取真实工作项，请执行人员依据条目判断是否在范围内，记录判断结果和依据。
- 干系人复述比对：请关键干系人分别复述同一条目的含义，记录差异点。
- 上游文件逐项对照：把说明书中的范围条目与立项文件、合同、需求文档逐项比对，标记缺失、冲突和多余三类情况。
修订动作
取证完成后按缺陷类型修订：边界类条目补写排除项，把“配合相关工作”改写为具体的动作、对象和产出；依赖类条目补写假设条件与外部依赖，注明由谁提供、何时提供；验收类条目改写为可观察条件，写明判定方法、判定人和通过阈值；术语类问题在说明书中增加术语定义，统一各方用法。每条修订都记录原条目、问题类型和修订内容，形成可追溯的修订记录。
风险边界与停止点
修订前先确认条目是否属于已批准范围或合同约定内容。涉及合同条款或已批准范围的修改，排查中只记录差异并提交变更流程，不直接改动口径，避免排查动作本身变成未经授权的范围变更。对于无法取得任何证据的条目，标记为待确认并写明缺少哪类证据、由谁补充，不强行下结论。停止点设在“证据不足以支撑判断”处，而不是设在“看起来改完了”处。
验证与复发预防：确认修订真的可判定
修订完成不等于问题解决，还要验证修订后的说明书确实能支撑判定。验证用可复现的方式进行，避免只由修订者自己确认“已经清楚了”。
验证方法
- 试判验证：用修订后的条目对若干真实工作项重新试判，检查是否还出现无法判定或多人判断不一致的情况。试判样本应包含此前争议最大的条目。
- 验收方复述：请验收方按新标准复述通过条件，与修订文本比对。复述一致说明标准可传达；出现偏差说明表述仍有歧义，需要继续修改。
- 修订记录复核：逐条核对修订记录中的待确认项是否已闭环，未闭环的明确责任人和补充时限。
复发预防
把本次暴露的问题转化为检查项，固定到后续评审中。在范围说明书评审清单里加入三类必查项：边界类检查包含项与排除项是否成对出现、接口职责是否写明归属；假设类检查外部依赖是否有上游文件对应、由谁在何时提供；验收类检查每条标准是否具备判定方法、判定人和通过阈值。评审时逐项打勾，缺项不通过。
在阶段关口增加一次复核，确认排除项与假设条件是否仍然成立。项目推进中外部条件会变化，原先写明的依赖可能失效，原先排除的工作可能被重新提出。复核发现变化时同步更新说明书并走相应流程，让范围说明书保持与实际情况一致，而不是在立项后就不再维护。
这套检查清单和复核动作可以固化在 ONES 的评审流程中：将范围说明书作为文档纳入评审，评审清单作为检查项逐条确认，复核结论和修订记录关联到同一文档版本，后续阶段关口按清单再次核对。这样每次修订都有记录可查，复发检查也有固定入口，不必依赖个人记忆。
常见问题
范围说明书条目写得很简略，算不算验收标准模糊？
判断标准是能否写出可观察的通过条件，篇幅长短不作依据。例如“提交一份含五个章节的测试报告”虽然短，但章节数量、交付物形态都清楚，可以判定通过与否，属于简略但合格。反过来，一段很长的描述如果只写“满足业务需要”“达到行业水平”，无法据此判断通过与否，仍属于模糊。排查时对每条标准尝试写出判定方法、判定人和通过阈值，三项齐全即可排除模糊嫌疑。
排查中发现某条边界确实漏写了，能不能直接在说明书里补上？
先确认这条内容是否落在已批准范围或合同约定之内。属于原有范围内的表述澄清，可以在修订记录中写明原条目、问题类型和修订内容后直接完善；属于新增工作或改变已约定口径的，排查中只记录差异并提交变更流程，由变更审批决定是否纳入。把两者混在一起处理，容易让一次排查变成未经授权的范围扩张，后续验收和结算都会失去依据。
干系人对同一条目各执一词，怎么判断谁的理解是对的？
排查阶段的目标是记录差异，而非裁定对错。先请业务方、执行方、验收方分别复述同一条目的含义，把差异点写下来；再回到上游文件，例如立项文件、合同范围条款、需求文档，看原始约定如何表述。上游文件有明确约定的，以约定为准修订说明书；上游文件同样没有写清的，属于需要在变更或补充确认中解决的事项，标记为待确认并指定责任人，不凭职位高低或声音大小定结论。
修订后的说明书怎么确认真的可以判定，而不是修订者自己觉得清楚？
用两个可复现的动作检验。一是试判：拿修订后的条目对若干真实工作项重新判断属于范围内还是范围外，样本要包含此前争议最大的条目，看是否还出现无法判定或多人结论不一致。二是复述：请验收方按新标准用自己的话讲出通过条件，与修订文本比对，出现偏差说明表述仍有歧义。两项都通过，才能认为修订达到了可判定状态；修订记录中的待确认项也要逐条核对是否闭环。
项目进行到中途，原先写好的排除项和假设条件还适用吗？
需要在阶段关口安排一次复核，逐条确认排除项是否仍成立、假设条件与外部依赖是否仍然有效。项目推进中外部条件会变化，原先写明的依赖可能失效，原先排除的工作可能被重新提出。复核发现变化的，同步更新说明书并走相应流程，让文档与实际情况保持一致。把复核结论关联到同一文档版本，后续追溯时能看清每次变化的原因和时间点。
