原始征途多开出错之后，判断这次错属于哪一档，比马上动手更重要。能自己补的错，处理起来简单，当场收拾完继续走；必须停下的错，牵扯到代理IP线路或者分组这些共用资源，硬撑下去只会把影响面扩大。分档的判断标准有两条：影响范围有多大、能不能在当天恢复。
- 自己补
- 只影响单个窗口，当天能恢复到原样
- 先记下再看
- 影响面不明，需要观察一段时间才能判断
- 必须停下
- 牵扯到共用代理IP线路或分组，继续做会扩大影响
必须停下的那一档，判断依据是共用资源有没有被带进去。窗口是个号自己的事，线路和分组是几个人共用的，动到这一层，出错的代价会顺着共用关系传出去。所以凡是牵扯到代理IP线路、分组划分、共用配置这三样的错，都归到必须停下那一档。
停下之后做什么
先确认影响范围，把受影响的号列出来，再按分组逐个恢复。恢复的顺序从影响最小的分组开始，一个一个来，不等所有分组同时恢复。这样做的原因是同时恢复容易互相干扰，也会把注意力摊得太散。
自己补的那一档要不要记
记一句就够，不用展开。这类错频率高，每次都写一段，记录很快就没法看了。写清哪一天、什么动作、代理IP那边怎么恢复的，三个点。
先记下再看的那一档怎么跟
设一个明确的观察时点，比如第二天收尾时看一次。到了时点还没弄清，就把范围再放大一档，按必须停下处理。不定时点的话，这类错会一直悬在那里，既没处理也没放下。
分档会不会太麻烦
熟练之后是一个几秒钟的判断。两条标准各自看一眼，很快就有结论。真正花时间的是不分档、所有错都当成大事来处理的那套做法，一天下来光判断就耗掉不少精力。
分档标准要不要经常改
号群规模或者代理IP线路结构有明显变化时改一次，平时不动。标准频繁变动，判断反而会变慢，因为每次都要重新想一遍边界在哪。
分档的方向是把大部分错归到自己补那一档。如果发现每天都有好几个错落到必须停下那一档，说明问题多半落在动作次序或者线路分配上，跟出错本身关系不大，那是另一件事，值得单独花时间看。
分档分清了，处理动作就不容易乱。
跑一段时间之后，可以回头数一数三档各占多少。自己补那一档占绝大多数的，说明日常动作本身是稳的；必须停下那一档频繁出现的，才需要往流程上找原因。
