项目启动时大家都同意“先做简单版”，执行中却不断出现“这个也顺便加上”。问题不一定是有人故意扩大要求，而是简单版没有共同边界。范围说明既要写做什么，也要写这次不做什么。本文用虚构的社团招新准备为例，讨论协作方法，不涉及合同解释或对外服务承诺。
用交付结果界定本次任务
不要只写“支持招新”。可以说明本次准备一份经过确认的活动介绍和报名说明，并明确谁使用、在什么场景下使用。交付结果越具体，越容易判断新要求是否属于当前范围。实际的时间和资源限制应由团队提供，材料不充分时标为待确认，不用常见项目的经验数字填空。
排除项说明原因与去向
例如本次不制作长期社群运营方案，原因是当前目标只覆盖招新前的信息准备。排除不等于永远不要，而是说明它不在本轮交付内。可以记录后续由谁评估或在什么节点重看，但不要随意承诺下一轮一定完成。没有安排时就如实说明，不把暂不处理包装成已经排期。
用边界问题测试理解
虚构场景中，新增报名资格说明可能属于介绍材料的必要内容，而增加报名后的长期互动机制可能超出本次目标。判断不能只看工作量大小，也要看它服务哪项交付。边界模糊时，先记录问题和影响，由有决定权的角色确认，不能因为一句“很快就能做”直接变成必须完成。
把依赖条件写在范围旁
准备介绍需要已经确认的活动安排，若核心时间或资格规则仍未知，应明确它会影响哪些输出。不要把输入未定造成的返工全部归为执行慢。前提变化后，检查原范围是否仍能支持目标，再决定删减、调整或另开讨论；排除项也不能在条件改变后被机械地永久保留。
变更时记录取舍而非只加任务
确认新增内容后，说明为何纳入、影响什么，以及哪些安排需要同步调整。若资源不变，不应默认所有旧要求仍按原计划实现。决定暂不纳入，也保留理由与重看条件，减少同一问题反复从头争论。记录应与实际决定一致，不能为了维持材料整齐而隐去尚未确认的分歧。
在交付前按范围逐项核对
检查必需内容是否齐全、排除项是否被误解、待确认问题是否已有去向。建议请未参与讨论的同事读一次，用自己的话说明本次承诺是什么；若答案与负责人不一致，就继续修正。本文配图为方法示意，不是产品界面。范围写清，不是为了拒绝所有变化，而是让每个变化都能被看见并作出有依据的选择。