Shopee工具放在链条哪个位置

工具是替代还是补位

先看一个具体的分界。把一段工作拆成几十个动作，其中重复的复制粘贴、格式调整、字段改名占了大头，这一段就适合让工具顶上去。反过来，如果这段工作的大部分时间花在比较、取舍、和供应商沟通上，工具只能把资料摆好，判断还得人来做。

很多团队上工具的初衷是省时间，结果上完之后时间没有省下来。原因通常是让工具去做判断这一部分。工具给的候选清单永远比实际能做的多，筛掉哪些、留下哪些，这个动作它做不了，最后还是要人对着清单再走一遍。

反过来也有另一种失误，是该用工具的段落一直在手工做。一家店铺每周花两天时间在几个页面之间抄数，一年下来就是将近一百天。这种纯粹的重复搬运，工具的可靠性通常比人更高，因为它不会因为第两百行而注意力下降。

还有一个容易被忽略的分界是差错成本。搬运出错要及时发现，工具搬运出错往往要过很久才暴露出来，因为它的错是成批的。所以让工具顶上去的段落，最好同时安排一个抽查动作，按比例抽几行核对，而不是等月底对账才发现。

补位和替代还有一个时间维度的差别。替代是长期的，上完之后这一段的工作方式就变了；补位往往是临时的，旺季人手不够的时候用一下，淡季还是回到手工。把这两种当同一件事处理，很容易在淡季留下一堆没人维护的工具。

实际判断的时候可以走三步。第一步把这一个月这一段的所有动作列出来，第二步给每个动作标上重复还是判断，第三步看两类的比例。重复占七成以上，这一段就适合让工具顶上去；两种大致对半，就只做补位。

标类的时候有一个技巧，看这个动作能不能写成一个不会引起争议的规则。能写成规则的，多数可以交给工具；写的时候需要加很多例外条件的，说明里面还有判断成分，暂时不要交出去，先把规则跑顺再说。

还有一个动作能帮上忙，就是记录交接次数。同一件事从一个人手里到另一个人手里，算一次交接。交接次数多的段落，工具补位的价值比替代更大，因为这类段落的痛点在于信息在传递中变形，不在于干活速度慢。

定下来之后要写一句结论，明确这一段是谁出结果。是工具直接出，还是工具出草稿人签字。这句话写下来，后面出问题的时候能立刻分清是规则没定好，还是执行的时候没按规则做，省掉很多来回。

最后要留一个回看的时间点，通常定在三个月后。到那时候看两件事：这段时间有没有出现规则之外的例外需要人工补，以及有没有人抱怨结果不对。两个都没有，说明这个位置摆对了。

有一个细节常被忽略：补位用的工具也要有自己的输出格式。很多人觉得既然是临时的、辅助的，随便给个截图或者聊天消息就可以了。结果过两个月要复盘，翻遍聊天记录也找不到当时那份数据，临时动作反而留下了长期的麻烦。

关于边界条件，有一类段落天然不适合用工具顶上去，就是那些一年只做几次、每次规则还不太一样的段落。比如换季时的品类调整，一年两次，每次的判断依据都有变化。这种段落做工具化的投入，摊到每次使用上都很大。

记录方法上建议给每个工具建一行台账：服务的环节、上线的日期、输出给谁、字段清单放在哪、退出条件是什么。这一行信息写下来只要几分钟，但半年后有人问这个工具是干嘛的，不用再靠回忆。

台账还有一个用处，就是排查断点的时候可以直接拿来看。两个相邻环节的工具，如果一方的输出字段和另一方的输入字段在台账上没有对应，那基本可以确定中间有一段是手工接的。这只用看表，不用真的跑一遍流程。

还有一个案例值得说。一家店铺在旺季前上了三个工具，旺季过完就停了两个，只留了对齐汇总那一个。他们后来复盘说，留下的那个之所以能留，是因为它的输出是别的段落都在用的底表，另外两个的输出只有自己看。

工具的位置由输出的去向决定，不由功能清单决定

每个环节对应哪类工具

选品判断这一段适合的工具是候选整理类。它的作用是把各个来源的候选品拉到一张表里，补上规格编号和基本属性，去掉重复的行。它不该替你做留与不留的决定，只负责让候选池是干净、完整、可比较的。

关键词这一段适合词表管理类。一段话里可能出现几十个变体，词序颠倒、单复数、同义替换。这类工具的价值在于把变体归到一起，标出哪些是主词、哪些是长尾，以及每个词挂在哪个品上。归堆是机械动作，归堆之后定主次才是判断。

竞品监控这一段适合采集与提醒类。它的作用是按固定频率把对手的价格、主图、促销状态记下来，有变化的时候提醒你。这一段的关键不在采集能力，而在提醒的阈值，变化多大才值得叫人来看，这个阈值定不好会天天被噪音打扰。

数据取数这一段适合对齐汇总类。几个后台的数口径不同，这一段要做的是把时间点固定、把范围写清，输出一张同口径的底表。它的输出质量决定了后面诊断能不能做，底表口径不清，后面的结论都建立在流沙上。

诊断排查这一段适合标注与分类类。把异常项按类型归堆，标上影响范围，剩下的归因和取舍还是人来做。回到选品这一段则适合待办收口类，把上一圈得出的结论变成带责任人和时间的下一步动作。

给每个环节选工具的时候，先做一件事：把这一段要交出的输出写成一行字段清单。字段清单出来之后，再去看哪些工具能产出这些字段，而不是先选工具再看它有什么。顺序反了，最后总要迁就工具的能力去改流程。

字段清单通常控制在十项以内，太多了说明这一段还没理清。清单里要有一列专门记录来源，标明这一项是从哪来的、多久更新一次。来源不清的字段，后面出了口径问题会很难追。

写完清单之后做一次反向检查：拿下游要用的字段来对一遍，看有没有上游没产出、下游又在用的。这种缺口是最常见的断点来源，通常补起来不难，难的是没人意识到它是缺的。

还有一个动作是给每个字段标上必需和可选。下游的校验只需要盯必需项，全都要对会拖慢速度。多数情况下，必需项能对上，这一段就算接上了；可选项缺一两个，可以边走边补。

选完之后建议先跑一段人工对照期。同一件事，工具做一遍、手工做一遍，比两周。不一致的地方逐条记下来，看清是工具的规则没设好，还是手工的习惯没写下来。这段时间花得值，能省掉后面反复返工。

有一个容易搞混的细节：选品那一段的工具和竞品监控那一段的工具，输出看起来很像，都是品和对手的信息。区别在于前者是收窄，输出的是留下来的少数品；后者是展开，输出的是一个持续变动的观察面。把这两种输出混在一张表里，下游会分不清哪个是要做的。

关于边界，有一种情况是工具的输出里带着一点判断色彩，比如它会给候选品打一个分。这时候要留一个动作：把打分依据也一起输出。只有分数没有依据，下游既无法验证也没法在自己场景里调整，最后往往整个分数都不用了。

记录方法上，建议在每个环节的输出表里保留一列备注，用来写这一行是怎么来的。备注不用长，写清是哪次取数、按什么范围筛的就行。这一列在排查的时候价值很高，因为很多争议其实只差一条来源信息。

还有一个细节是版本标注。同一张输出表，口径改过之后最好换个文件名或者加一个日期后缀。同名覆盖是排查中最麻烦的情况之一，因为旧的数字再也找不回来，无法对比口径改动前后的差异。

有一家团队的做法是把每个环节的输出统一加上三列：生成时间、口径版本、生成人。成本几乎为零，但任何时候拿到一份表，都能立刻知道它是谁、在什么时候、按哪一版口径做的。这三列解决了很多扯不清的问题。

越是重复搬运的段落，工具补位价值越高，越是需要判断的段落越低

放在哪个位置最值

位置值不值，可以用一个简单的算法判断。先估算这段工作每个月花多少小时，再估算上了工具之后能省下多少，然后减去工具本身要花的配置、维护和数据核对时间。省下的时间大于后面这三项之和，这个位置才值得放。

还有一个判断角度是看这段的产出能不能被下游直接用。同样花十天做一个自动化，一个的产出下游拿来就用，另一个的产出下游还要重新录一遍，前者的位置价值明显更高。输出被直接接上的那一段，应该排在优先做的位置。

从经验看，价值最高的位置通常在两段的交界处，而不是某一段的内部。交界处是手工搬运最集中的地方，也是口径最容易走样的地方。把工具摆在这里，一次能同时改善上游的输出质量和下游的输入质量。

有一家店铺的做法值得参考。他们不在整条链上铺工具，只在两个地方放了东西：一个是几个后台的对齐汇总，另一个是候选品的整理。其余四段全靠手工加表格，全年下来效率反而比铺满工具的时候更高。

位置判断还有一个时间前提。当业务量还小的时候，很多段落的搬运量本来就不大，这时候上工具的收益很难覆盖维护成本。通常要到搬运量稳定并且能预测的时候，工具的位置价值才会真正显现出来。

排序的时候可以用一个打分表。四列：每月节省的小时数、下游能不能直接用、配置和维护要花多久、出错后影响的环节数。前两项是收益，后两项是成本与风险。算完把段落按分数从高到低排，先做分数最高的那一段。

打分表不需要很精确，粗估就够用。很多人卡在这一步是想把每个数字都算准，结果半个月过去了还没动手。粗估的意义在于排出顺序，不在于算出结论，顺序排对了，这个表就已经起作用了。

排完顺序之后，建议一次只推进一段。同时推三段看起来快，出了问题是三处一起查，反而更慢。一段跑通之后再动下一段，中间那点等待时间，换来的是问题范围始终是可控的。

推进的过程中要做一次中间验收，时点可以定在配置完成之后、正式启用之前。验收的内容是把上游的旧输出和新输出对齐比一遍，看差异在哪、是否都能解释。解释不了的差异先解决，再正式切换。

切换之后还要安排一个观察期。观察期里两套并行跑，手工那套不要立刻停。并行期通常两到四周，等到连续几期结果一致，再把手工那套停掉，这样即使工具出了问题也有退路。

有一个细节是关于小批量的。当某一段每月的量只有几十条记录时，工具化的收益往往还不明显，这时候更好的做法是用公式和模板先把这一段标准化。等到量涨到几百上千条，同样的模板可以平移给工具，前面的功夫不会白费。

边界条件是人员变动。一段工作如果长期只有一个人做，流程其实藏在他自己的习惯里，这时候上工具要谨慎，因为很可能把个人习惯固化成了团队规则。比较稳的做法是先让第二个人按现有流程做一遍，看有多少地方需要问人。

记录方法上，可以给每个推进中的段落建一条时间线：什么时候定的字段、什么时候配置完、什么时候开始并行、什么时候切换。这条线在复盘时很有用，能看出从决定到真正用起来花了多久，帮助下次估算得更准。

还有一个容易忽略的细节：并行期的数据要比对到能解释的程度。只是看到两个数差不多就切换，往往会把一个小差异带进正式流程。差异要么被解释，要么被记录，两种情况都可以切换，唯独不能视而不见。

有一个案例是做多站点的团队。他们先在量最大的一个站点把两段之间的接口做通，然后把这套字段清单原样搬到其他站点，只在币种和时间口径上做了两处调整。搬过去的过程几乎没有重新设计，因为他们把可变的部分单独列了出来。

位置放错的后果

第一种后果是双份录入。工具出了结果，但格式和下游要的不一样，于是有人把结果抄一遍再往下走。这种状态下，工作量不是减少而是增加了，因为上游要维护工具，下游还是要手工录，中间多了一道谁也不负责的转换。

第二种后果是口径分叉。同一个指标在两段里各自算，一开始差得不多，几个月之后差距越来越大。等到发现的时候，已经很难判断是从哪一天开始分叉的。这种问题的排查成本，通常远高于当初把字段对齐的成本。

第三种后果是工具变成孤岛。摆的位置不对，它的输出没有人接，慢慢就没人打开了。奇怪的是这类工具通常不会被删掉，因为它是花了钱或花了时间做的，于是继续占着预算和注意，成为一段谁也不看的数字。

第四种后果最隐蔽，是把判断也一起交出去。有些工具会直接给出一个推荐结果，看起来很方便。用久了之后，团队慢慢就不再自己判断了，等到工具的推荐不符合实际，也没有人能立刻说出为什么不对。

这四种后果有一个共同的起因：上工具的时候只谈了它能做什么，没谈它交给谁、以什么格式交。补上这一步其实不复杂，把输出的字段列一遍，写清下游拿它做什么，位置对不对立刻就能看出来。

发现位置放错，最快的办法是追一次全流程。挑一个具体的品，从选品那一段开始，一直追到回到选品，把每一步的交接都记下来。记完之后把交接次数数一遍，次数明显偏多的那几处，就是位置放错的地方。

追流程的时候要带上时间。每一步记录开始和结束的时刻，间隔特别长的两处之间通常有手工等待。等待可能是人在忙，也可能是数据还没出来，两者对应的问题不一样，要分开记。

找到问题之后，处理顺序建议是先把转换动作固定下来，再考虑改工具。也就是说，先写清上游出什么、下游要什么，中间用哪几列对上，哪怕这一步暂时还是手工做。接口定下来之后再换工具，才不会换了还是接不上。

如果发现是口径分叉，处理的动作是先定一个基准，再往回改。选那个被下游用得多的一方作为基准，另一方往它靠。改的时候把历史数据也标一下，说明从哪一天起口径变了，避免以后有人拿旧数来比。

如果发现是工具成了孤岛，先别急着停。先问一句：它的输出真的没人需要，还是有人需要但拿不到。前者是收拾，后者是接口没做通，处理方式完全不同。这一步问清楚，能避免把有用的东西一起清掉。

有一个细节值得留意：位置放错往往不会立刻出问题，而是在业务量上来之后才暴露。量小的时候手工抄一遍还承受得住，量涨到几倍之后，那一段就变成了整条链最堵的地方。这也是为什么建议在量还没涨起来之前先把接口写清。

边界条件是换人。同一套错的位置，老员工做了一年，靠记忆弥补了很多字段缺口；新人接手之后，缺口就全部显出来了。交接的时候暴露出的一堆问题，通常不是新人不会，而是接口本来就没有定义。

记录方法上，建议把每次发现的位置问题写进一份问题清单，写清表现、原因、处理方式和是否已解决。清单积累到十几条之后，会明显看出规律，多数问题集中在同一两处交界上，处理那两处就等于处理了大半。

还有一个细节是关于孤岛工具的处置时机。如果判断它确实没用了，停掉的时候顺手看一下它占用的时间预算有没有被别的地方更大，比如某个一直没人做过的手工核对。把资源挪过去，比单纯停掉更有价值。

有一个案例可以说明追流程的作用。一家店铺长期觉得效率低但说不上哪里低，追了一遍全流程之后发现，光是商品规格编号在三个环节被重新录了三遍。修掉这一处之后，他们没有上任何新工具，整体节奏就明显快了。

工具之间的数据怎么流通

流通的最小单位是字段，不是文件。很多人以为把表格导出成通用格式就算能流通了，实际上只要字段名对不上，下游还是要手工认一遍。真正能流通的状态是，上游表的某一列，下游拿到之后知道该放进哪一格。

字段对齐通常要处理三类问题。一类是名称不同，同一个东西在两处叫两个名字；一类是颗粒度不同，一个是按天、一个是按周；一类是取值范围不同，一个是含税费价、一个是不含税价。三类里面颗粒度最难对齐，需要在中间加一层换算。

还有一个容易漏的是一致性的键。两段之间要靠某一列把记录对上，这一列多半是商品规格编号或者订单编号。如果上游在整理的时候把编号去掉、只留品名，下游就失去了对上的依据，只能靠人工猜。

时间戳也是流通中的常见麻烦。上游记的是动作发生的时间，下游记的是记录写入的时间，两者在不同步的时候会错开。约定一个统一的时间口径，并在表头注明，比在出问题之后再一项项回溯要省事得多。

最后一条是关于缺值的约定。上游某一格是空的，下游要能分清这是没有数据、还是不适用、还是没查到。这三种在业务上完全不同，但表格里都是一个空格。加上一个专门的标记，下游就不用每次都来问一遍。

要让数据真正流通，可以先定一份字段对照表。左边写上游的字段名，中间写它是什么意思、什么单位、什么时候更新，右边写下游把它放进哪一格。这张表不用长，十几行就能覆盖两段之间的全部来往。

对照表定完之后，做一次实测。拿上游最近一次真实输出，按对照表手工映射一遍，看能不能全部对上。对不上的地方有几种原因，趋势上多半集中在颗粒度和取值范围两项，这两项也是最需要写清处理规则的地方。

映射规则写下来之后，安排一个固定的检查动作。每次上游口径有变动，就把这张对照表拿出来过一遍，看有没有哪一项要跟着改。多数口径变动只影响一两行，逐行看一遍花不了多少时间。

还有一个动作是把流通关系画成一张简单的图。每个环节画一个方框，方框之间画箭头，箭头上写清传的是哪几个字段。图不用讲究排版，能让人一眼看出谁接谁就够了，这张图本身也是排查断点的入口。

图定下来之后放在团队能看到的地方，新来的人接手时先看这张图，比听人讲解快得多。图上的箭头如果出现某个字段在两个方向上传，说明这一段有来回，通常意味着接口定义得还不够清楚。

有一个细节是关于数值精度的。上游算出来的数带着好几位小数，下游直接用，汇总的时候尾差会累积。约定一个统一的小数位数，并且在汇总之前先按约定舍入，这种小问题就不会变成月底对不上账的大问题。

边界情况是同一个字段在两段里含义有细微差别。比如同样叫销量，上游算的是下单数，下游要的是完成数。这种差别在正常时候看不出来，遇到集中取消的时候就全都显出来了。发现之后应该改名，而不是靠口头提醒。

记录方法上，字段对照表本身要有版本和修改记录。改过哪一行、什么时候改的、为什么改，写在表下面几行就行。没有修改记录的对照表，过一段时间就没人敢动，因为不知道动了会影响到谁。

还有一个细节是空值和零的区别。零是一个有意义的结果，空是没有结果。上游把两者都写成零，下游在算平均值的时候就会把没发生的情况算进去。分开处理这两者，是一张底表能不能被信任的关键之一。

有一个案例是多来源汇总。一家店铺把几个后台的数对到一张表里，最开始的问题不是数不准，而是同一笔订单在两张来源表里各出现一次，汇总时被算了两次。后来他们加了一列来源标记，问题立刻变得可以检查了。

功能强的工具未必接得上，能不能接上取决于字段对不对得上

判断某环节该不该上工具

判断可以从四个问题开始。这段工作每周做几次？每次的动作重复度有多高？出错之后的发现要多久？这段的输出下游有人在等着用吗？四个问题的答案里，重复度和发现时间这两项最能说明问题，越高越该上。

有一类段落看起来很适合上工具，其实不适合，就是那些规则还在变的段落。规则一个月改两次，工具刚配好就要重配，维护成本比手工还高。通常要等到规则连续两三个月没有大改，才是上工具的合适时点。

反过来有一类段落看起来不适合，其实很值得，就是量不大但频率极高的动作。比如每天早上把几个数抄进一张表，动作只有五分钟，但一年三百多天。这类动作单次价值低，累计起来却很大，而且工具化之后几乎不需要维护。

判断的时候还要看这段的输出有没有人接。如果下游其实不需要这段的产出，那这段本身就该先考虑要不要保留，而不是考虑上什么工具。先把无用的段落砍掉，再谈工具，顺序颠倒会白花很多配置的功夫。

还有一条边界是合规与责任。涉及到对外承诺、价格变更、账务处理的段落，即使很适合工具化，也通常需要保留一个确认的动作。让工具做草稿，人做发布，这个分工在多数团队里都更稳妥。

把四个问题的答案写下来之后，还可以加一条实测动作：先手工跑一遍完整的替代流程。也就是说，用人工的方式模拟工具会做的事情，走一遍看看哪里会卡。这遍走下来，能发现很多只在纸面上看不到的问题。

实测的时候特意记录两类情况：一类是需要临时判断一下的地方，一类是数据对不上的地方。前者说明这一段还有判断成分，工具只能补位；后者说明字段口径还没理清，先理清再上工具，否则工具会把口径问题固化下来。

实测之后如果决定要上，先定一个最小范围。比如只处理某一类商品、只覆盖某一个站点，而不是全量铺开。范围小的好处是出问题影响有限，而且能在短时间里看到真实效果，比长时间的评估讨论更有说服力。

最小范围跑顺之后，再定扩大的条件。条件要具体，比如连续四期结果一致、异常解释率高于某个比例。条件写清楚之后，扩大就成了一个可以判断的动作，而不是一次拍脑袋的决定。

还有一步容易被省掉，就是给这一段留一个手工备用路径。工具停摆的时候，至少要知道怎么退回手工做，以及退回之后哪些结果会受影响。备用路径不用写得很细，写清第一步做什么就够了。

有一个细节是判断的参与者。这一段实际干活的人必须参与，因为很多隐性规则只有他知道。管理者看流程图往往看不出哪一步要临时判断，而干活的人一句话就能点出来。少了他，实测那一遍会把问题全部漏掉。

边界条件是当这一段的结果要被外部看到时，比如对客户展示或者作为结算依据。这类段落的判断标准要更严一点，除了自己内部能对上，还要能对客户解释得清。这种情况下，工具的输出最好保留一个可回溯的过程记录。

记录方法上，实测那几天的记录要留着。写清哪一步卡住了、卡了多久、后来怎么绕过去的。这些记录不需要整理得很漂亮，但它们是把判断依据具体化的唯一材料，比事后回忆可靠得多。

还有一个细节是要区分两种慢：一种是人手不够造成的等待，一种是规则不清造成的反复。前者上工具能解决，后者上工具只会把反复做得更快。判断的时候看到反复的次数多，就要先去把规则理清。

有一个案例是店铺在决定要不要把报价整理这一段工具化时，先手工做了三周。三周下来他们发现，真正费时间的不是整理，而是等上游确认一个参数。结论是这一段不该上工具，该做的是把确认动作提前。

摆对位置之后，省下来的不是操作时间，是找错的时间

工具的退出条件

退出条件要在上工具的时候就定，不是等到用不下去的时候再想。常见的有三条：数据源已经停用、输出连续几个月没有被下游使用、维护它的时间超过了它省下的时间。这三条都比较容易观测，不需要复杂的评估。

除了这三条，还有一条值得加上，就是它覆盖的环节已经不在了。业务调整之后，有些环节被合并或者取消，服务于那个环节的工具就失去了存在的理由。这类工具往往因为没人主动想起来而被留了很久。

退出的时候要注意数据的去向。工具里存着的历史记录，很可能还有参考价值，直接关掉会丢失。常见的做法是导出最后一份完整记录，标上停用日期，放到团队的共享位置，然后把账号和任务一并停掉。

有一个反直觉的经验：退出比上线更该有仪式感。上线的时候大家会讨论、会配置、会培训；退出的时候往往悄悄就停了，结果半年后有人还在用它出的旧数字做判断。把退出写进团队的动作清单，能避免这类麻烦。

还有一条边界情况是两个工具功能重叠。这时候不必急着停掉一个，可以先让其中一个转成只做抽查校对，跑一两个月，确认另一个的输出稳定之后再停。重叠期有成本，但比停错工具的风险小得多。

决定退出的时候，先做一次盘点。把在用的工具列成一张表，写上它服务的环节、最近的输出日期、下游还有谁在用、每月维护大概花多少时间。这张表做出来之后，该退的通常一眼就能看出来。

盘点的频率不用高，半年一次就够。频率太高会变成额外负担，频率太低又容易积累。半年一次的节奏，和多数团队的预算与规划周期也对得上，便于一起讨论。

退出时按顺序做三件事：先通知下游，再导出留档，最后停任务和账号。顺序不能颠倒，先停掉再通知，下游会在不知情的情况下拿到空数据，这种混乱比多留两周更麻烦。

通知的时候要写清两件事：什么时间停、停了之后下游从哪里拿。只说停不说到哪里去拿，等于把问题推给了下游。多数情况下可以指一个替代来源，或者在过渡期继续手工输出一段时间。

还有一条经验是退出之后留一个观察窗。停掉之后的一两个月里，留意有没有人来问原来的数据。有人问，说明还有需求没被替代，这时候要回头看看是不是退早了；没人问，这件事就可以结束。

有一个细节是退出的决定权。停在用的工具往往需要不只一个人的同意，因为它牵涉到别人的工作。建议把决定权放在使用这段输出的那一段手上，用的人说不需要了，就可以停，比由工具所属的人自己决定更贴近实际。

边界条件是两个环节合并之后留下的旧工具。合并之后，两个工具都在做类似的事，输出有重叠。这时候的处理顺序是先确认新流程下谁是正式来源，再把另一个转成抽查，跑一段时间后停掉，不要同时留着两个正式来源。

记录方法上，退出时留一份简短的说明：原来做什么、为什么停、数据放在哪、如果需要恢复该找谁。这张说明写一次可以用很久，也能避免半年后有人重新做一个功能一样的东西，把已经解决过的问题再走一遍。

还有一个细节是关于历史数据的可用期限。导出留档的时候顺手写清这份数据覆盖了哪个时间段、按哪一版口径生成。没有这两项，留档的数据在半年后基本没法用，因为不知道它和现在的口径能不能比。

有一个案例值得记下来。一家店铺清掉了四个长期没人用的工具，其中三个确实无用，还有一个其实有人每周在用，只是没人上报。这个漏掉的提醒了一件事：停之前最好在团队里公开一次清单，让人有机会说一句「这个还在用」。

常见问题（FAQ）