范围不是用来争的，是一起来选的
一句话总结
把范围判定规则和前提台账固化成文件，面对新的请求，就可以不回答“不行”，而是回答“那么要去掉什么”。
为什么需要它
启动第一周定下的范围，从第二周开始就会渗漏。渗漏的地方总是差不多：物流团队在 Slack 上发来“就这一点”，经营支持团队在会议结束时补一句“顺便把那个也做了”，而我们当场找不到拒绝的依据。协议文本在抽屉里，翻开来看，这个请求是否属于那句话，也含糊不清。
第二个地方是前提。在启动会上听到“夜间批处理只在 02:00 到 04:00 之间运行”，就以此为前提安排了维护窗口。三周后才发现这个前提是错的，而那时，日程和变更计划已经建立在它上面了。前提如果只存在于会议纪要里，就没有人会再去确认。
第三个地方是回答的方式。对范围之外的请求回答“那不在范围内”，对话就结束了，关系也受到损害。站在客户的立场，他是因为需要才问的，而我们是来帮忙的人。
工作原理
三者用同一种办法来解决：把判断从人的脑子里移到文件里。
范围规则写成有顺序的列表。每条规则写明条件、结果（范围内或范围外）和理由，把一个请求从上往下逐条过一遍，先匹配的规则获胜。顺序就是优先级，所以窄的规则放在上面，宽的规则放在下面。把“涉及个人信息的工作属于范围外”放在最上面，它就会先于下面的“仓库系统的工作属于范围内”生效。
这里重要的是暂缓判断。没有被任何规则命中的请求，不是“范围外”，而是“尚不清楚”。如果把没被命中的自动推到范围外，规则的空隙就永远不会暴露。留作暂缓，这份列表就成了下一次会议的议题。
判定里要同时写明是哪条规则做出的决定。有了这一点，客户问“为什么这个不行”时，只需要出示一条规则；如果规则错了，改规则就行。这就成了修改文件而不是说服人的对话。
前提台账为每个前提写四项内容。
전제 "야간 배치는 02:00 부터 04:00 까지만 돈다"
깨지면 점검 창이 배치와 겹쳐 서비스가 멈춘다
확인법 crontab 과 최근 30일 실행 로그의 시작 시각을 견준다
확인일 2026-08-20 (유효 14일 → 2026-09-03 까지)
该代码块中的韩文依次说明：前提是“夜间批处理只在 02:00 到 04:00 之间运行”；如果被打破，维护窗口会与批处理重叠，导致服务中断；确认方法是把 crontab 与最近 30 天运行日志中的开始时间进行比较；确认日期为 2026-08-20，有效期 14 天，到 2026-09-03 为止。
这份台账的核心，是写下“被打破时什么会崩塌”。写一写就会发现，有的前提即使错了也没有任何影响，而有的前提上面却承载着整个计划。另外，要给确认加上有效期。客户环境在我们观察的同时也在变化，所以确认过一次的事情，不可能永远为真。过了有效期的前提，不是“错了”，而是“需要重新确认”。
在现场相遇的样子
第一，拿出置换表，而不是拒绝的话。如果范围外的请求需要 6 天，就这样回答：“加入这个需要 6 天。把目前约定的工作中这两项去掉就可以抵上。选哪一种？”客户得到的不是拒绝，而是选项，大多数情况下他自己会重新排定优先级。
拿出置换表时要遵守两点。建议去掉的那一组工作的天数合计，必须大于等于新请求的成本，而且从这一组中随便去掉任何一项，都会不够。如果建议去掉得很宽裕，客户会觉得我们想少干活。另外，必须做的工作（协议文本中明确写定的）不放进可置换的对象。
第二，不要隐藏暂缓判断的列表。暂缓有五条，就意味着规则有五处空隙，如实报告出来，客户会和我们一起补上。如果擅自把暂缓的推进范围内或范围外，这个决定就成了我们自己单独做出的。
第三，写明前提的负责人。如果写着“夜间批处理时间”的负责人是运维团队的 Choi 科长，重新确认时就不用发愁该问谁。没有负责人的前提，过了确认期限也没有人去确认。
第四，把规则和台账作为交付物交出去。合同结束时如果交出的只有报告，下一个人还会从同样的地方重新开始。规则文件和前提台账，可以直接成为下一份合同的起点。
实际工作中真正重要的事
- 先匹配的规则获胜。顺序就是优先级，所以窄的规则放在上面。
- 没被命中的不是范围外，而是暂缓。暂缓列表会显示规则的空隙。
- 前提要同时写明被打破时的后果、有效期和负责人。
- 对范围外的请求，用置换表来回答。建议去掉的那一组，挑选得既不多也不少。
下一项实验要做什么
拿到（虚构的）Taeseong 食品的启动资料包：25 条请求、10 项已约定的工作，以及协议文本中谈到范围的六行。把范围规则写成有顺序的文件，编写判定器，把请求分成范围内、范围外和暂缓。评分器会在每次以不同的规则和请求真实运行你的判定器，核对判定和依据规则，还会调换窄规则和宽规则的顺序，看优先级是否得到遵守。然后建立前提台账，并编写找出确认已过期的前提的工具。最后，针对新进来的范围外请求制作置换表，写成报告提交。