2023年11月，一位做家居品类的卖家朋友在旺季前两周发现，主推款FBA可售库存只剩9天，而他自己的补货计划表上写的是“可支撑34天”。差额不是算错，是口径错了，他用的日均销量来自最近7天，而那7天刚好卡在站内Deal结束后的低谷期。数据是真实的，趋势判断却是失真的。
这件事让我重新思考一个问题：亚马逊库存管理里，真正难的不是“算”，而是“看”。算库存、算补货点、算安全库存，只要公式正确、参数完整，结果八九不离十；但趋势观察不一样，它面对的是波动、滞后、平台规则变化和人为干扰，任何一个环节观察错了，后面所有计算都在为一个错误的假设服务。
这篇内容我想讲的，是我自己在2022到2024年间、经手十余个亚马逊店铺的库存数据后，总结出的一条实施路径：库存管理软件要真正完成趋势观察，必须按“先统一口径、再建模判断、最后绑定动作”的顺序落地。反过来做，基本都会返工。
先把结论摆在前面，后面所有章节都在为这几条结论提供证据。
很多卖家在选型时最关心的是“有没有智能预测”“有没有AI补货”。但从我实际复盘的项目看，预测结果偏差的主要来源极少是模型本身，而是输入口径：日均销量取的是7天还是56天、是否剔除大促、退货是否回冲、在途库存是否计入可用、多站点库存是否合并。
这五项口径只要有一项没对齐，同一个SKU、同一天的数据，不同人算出来的“可售天数”能差出两倍以上。算法再先进，也救不了一个错误的输入。
7天口径适合看异常，30天口径适合看短期节奏，但两者都不足以支撑补货决策。原因很简单：亚马逊的销量波动天然带有周期性，工作日与周末、月初与月末、站内活动前后、竞品断货期的流量溢出，都会在短周期里制造出假趋势。
我现在的做法是主口径用滚动90天日均，同时把它按周切片做成一条曲线。曲线的作用不是用来算补货量，而是用来看“这90天里，趋势是在抬还是在压”。低于90天的窗口，我只用来触发预警，不用来下订单。
我看过太多后台做得非常漂亮的库存看板，折线图、饼图、热力图一应俱全，但运营每天早上刷一眼就关掉了。问题不在图，在于图上没有任何一条线告诉他“到这里了你就得动手”。
一个真正被使用的趋势观察体系，至少要给出三类阈值：可售天数低于多少进入紧急补货、高于多少进入清库预警、库龄超过多少天进入长期仓储费风险区。没有阈值的趋势图，本质上是在占屏幕。
我见过最常见的失败路径是：先买软件，再想指标，最后才去对齐口径。结果就是软件上线三个月，运营仍然在用Excel算补货，因为系统算出来的数“跟他们心里的数对不上”。
对不上不是系统的错，是没人定义过“什么叫做销量”。这个定义工作必须在实施之前完成，而且是业务方主导、系统方配合，不能反过来。
讲方法之前，我想先说三次具体的翻车。它们分别对应了库存趋势观察的三个典型陷阱，也是我后来搭建整套体系时反复回看的案例。
2021年第四季度，一个家居收纳类SKU，在10月中旬进入稳定上升期。当时我每天早上看后台的7天日均销量，数字很漂亮，一路抬高。我按这个口径推算了补货时间，觉得还有余量，就把下单节奏往后压了两周。
结果11月上旬站内活动结束后，销量回落，我又按新的7天口径重新计算，发现“可售天数”忽然从28天涨到41天，于是判断不用急。等到11月下旬真正的旺季流量涌进来，日均销量在五天内翻了三倍，那个SKU在12月3日断货，一直断到12月19日。
事后复盘，问题不在销量预测，而在于我用一个波动极大的短窗口，去支撑一个周期长达60天的补货决策。补货周期是60天，观察窗口却只有7天，观察窗口必须与决策周期匹配，这是最基础的一条原则，我当年却忽略了。
2022年，我接手一个服装类店铺。当时整体库存周转看起来还行，总库存在下降，但半年后长期仓储费账单出来，金额是预期的三倍。
拆开看才发现，问题出在结构上：整体库存在降，是因为几个快销SKU在快速清货；而同时有31%的库存是超过270天的老货，这些SKU的单量小、动销慢，被整体平均值掩盖掉了。
这就是典型的观察粒度问题。总库存周转天数是一个加权平均值，平均值天然会掩盖结构性问题。后来我把库龄分成0-90天、91-180天、181-270天、271-365天、365天以上五档，按档位看金额占比，才第一次看清真实的库存健康度。
2023年，同时管理五个亚马逊账号、三个站点，SKU总数从三百多涨到两千多。当时最大的痛苦不是库存算不准，而是根本来不及看。每个账号后台导一次报表，每个报表字段还不一样，光是把数据拼到一张表里，一周就要花掉两个工作日。
更麻烦的是，在途库存在ERP里、亚马逊库存在后台里、头程时效在货代的小程序里，三份数据永远对不齐。每次开补货会，一半时间都在争论“这个数字到底以谁为准”。
也就是从这一年开始，我意识到库存管理软件的价值，不在于它能不能预测，而在于它能不能把分散的数据源统一到一个口径下，让我一次看全、一次看准。这也是我后来接触“数跨境”这类工具的起点。
在讲正确路径之前，先拆误区。因为这五个误区，我在不同项目里反复见到，几乎每次实施失败都能对应到其中一条。
库存报表回答的是“现在有多少”，趋势观察回答的是“接下来会怎么走”。这两个问题的数据来源、时间窗口和更新频率都不一样。
报表可以是每天更新的快照，趋势观察必须是带时间轴和多口径对比的序列。用报表当趋势看，等于用一张照片判断车速。
亚马逊的很多品类有强季节性。如果只看最近30天，你会把“季节性上行”误判成“趋势爆发”，也会把“季节性下行”误判成“产品衰退”。
正确的做法是建立一个季节性基线：用过去两年同月份的数据，算出每个月的季节性指数（当月销量 ÷ 全年月均）。当观察值明显偏离基线时，才值得深入分析。偏离基线叫异常，偏离平均值只叫波动。
这是最容易被低估的一条。FBA可售库存只是库存的一部分，完整的可用量应该包括：FBA可售 + FBA在途（已发货未入库）+ 国内仓可发 + 生产在制 – 已占用（预售、B2B订单）。
更关键的是入库时效。2024年我观察到的样本数据显示，旺季期间从“货代签收”到“亚马逊可售”的平均时长，比淡季多出7到12天，个别仓库甚至超过20天。如果补货模型里没有这一段缓冲，断货几乎必然发生。
补货公式是有价值的，但它假设未来会重复过去。在遇到新品上架、竞品退出、平台政策变化、站外流量引入这类事件时，公式会失效。
我的做法是：公式给基准建议，人工做上下浮动，浮动超过30%必须写明理由。这样既保留了自动化的效率，也保留了人的判断。没有人工介入口的自动化，最后一定会被人绕过去。
亚马逊后台能告诉你发生了什么，但很难告诉你为什么。要理解趋势，至少需要三类数据交叉验证：平台销量数据、广告投放数据、外部需求信号（搜索热度、类目BSR变化、竞品动作）。
只靠平台销量数据做趋势判断，等于只看体温计判断病因。
讲完误区，进入方法。我把库存趋势观察拆成四层：数据层、指标层、判断层、动作层。每一层解决一个特定问题，缺一层，上面那层就不成立。
数据层要回答三个问题：数据源有哪些、更新频率是多少、以谁为准。这一层的工作看起来枯燥，但决定了后面三层的上限。
我在实操中会先建一张“口径字典”，把每个关键字段的定义写清楚。比如“日均销量”这个字段，我至少要写清四件事：统计窗口是几天、是否剔除大促、退货是否回冲、多站点是否合并。
这份字典的价值在于，当运营、供应链、财务三方对不上数的时候，可以拿着它逐条核对，而不是靠嗓门大小决定谁对。
我见过最夸张的库存看板有四十多个指标。结果是没人看。我的建议是控制在核心八个指标以内，并且让它们能互相验证。
下面这张表是我目前在用的指标体系，分为健康度、趋势、风险三类：
| 类别 | 指标 | 计算口径 | 观察频率 |
|---|---|---|---|
| 健康度 | 可售天数 | （FBA可售 + 可发货库存）÷ 滚动90天日均 | 每日 |
| 健康度 | 库存周转天数 | 平均库存成本 ÷ 日均销货成本 | 每周 |
| 健康度 | 动销率 | 近30天有销量SKU数 ÷ 在库SKU总数 | 每周 |
| 趋势 | 滚动90天销量斜率 | 90天销量的线性回归斜率 ÷ 均值 | 每周 |
| 趋势 | 季节性偏离度 | 本周实际销量 ÷ 去年同期 × 季节性指数 | 每周 |
| 风险 | 库龄结构占比 | 各库龄段库存金额 ÷ 总库存金额 | 每周 |
| 风险 | 冗余库存占比 | 可售天数 > 120天的SKU金额占比 | 每周 |
| 风险 | 断货风险SKU数 | 可售天数 < 补货周期 × 1.2 的SKU数 | 每日 |
这八个指标的设计逻辑是：健康度看现状，趋势看方向，风险看敞口。任何一次库存决策，都应该同时看到三类信息，而不是只盯着一个数字。
判断层是大多数卖家缺失的一环。数据有了，指标也有了，但从指标到结论之间缺少一套明确的推理规则，结果就是每次都要重新拍脑袋。
我用的判断规则大致是这样：先看趋势方向，再看趋势强度，最后看趋势的确定性。方向用滚动90天斜率判断，强度用斜率相对均值的比例判断，确定性用连续多少周保持同方向判断。
举个例子，斜率转正但只持续了一周，强度是均值的3%，这叫“噪声”；斜率转正持续了四周，强度是均值的18%，这才叫“趋势”。趋势不是单点的方向，而是一段时间内方向的稳定性。
动作层的核心是阈值化。我通常设置三级响应：绿色（正常）、黄色（观察）、红色（行动）。黄色通常不直接下单，而是加入本周重点复核清单；红色则直接触发补货或清库流程。
阈值不能拍脑袋定，要从历史数据里回算。具体的做法是：回看过去12个月，找出每次断货或滞销发生前两周，当时的指标处于什么水平，那个水平就是你的经验阈值起点。
讲完方法，说案例。2023年底我开始在一个多店铺矩阵项目里推进库存趋势观察的体系化，选用的工具是数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）。这一段我会把实施过程、遇到的问题和实际观察到的数据都写出来。
项目背景是5个亚马逊账号、3个站点、约2200个活跃SKU，此前完全靠人工导表。接数的目标很明确：把亚马逊后台、国内仓、在途货代三处数据统一到一个时间轴和一套口径上。
这一步的实际耗时比预想的长。接数本身不慢，慢的是口径确认。比如“在途库存”到底怎么算，团队的供应链同事认为是“已付货款未到仓”，运营认为是“已发货未上架”，两个口径差了两周的时间。
最后我们的处理方式是：在途库存拆成两段，一段是从供应商发货到国内仓（采购在途），一段是从国内仓发出到亚马逊可售（履约在途）。两段分别计时、分别计算，避免混在一起。这个拆分看起来只是多加了一个字段，但它让补货模型真正能反映不同环节的时效差异。
口径定完，接下来是把它固化成可复用的计算逻辑。这一步我习惯用一段明确的代码来定义，因为自然语言描述容易产生歧义，代码不会。
# 库存趋势观察核心口径：滚动90天日均销量（已剔除大促、已回冲退货）
import pandas as pd
WINDOW = 90
PROMO_EXCLUDE = True
RETURN_OFFSET = True
def rolling_daily_sales(sku_df):
df = sku_df.sort_values("date").copy()
有效销量 = 订单销量 – 退货回冲
df["net_sales"] = df["gross_sales"]
if RETURN_OFFSET:
df["net_sales"] = df["net_sales"] – df["return_qty"].fillna(0)
剔除大促期间的极端值，避免把活动爆发当成常态趋势
if PROMO_EXCLUDE:
df.loc[df["promo_flag"] == 1, "net_sales"] = pd.NA
滚动90天，按有效天数求均值（不能用固定90，否则有缺失的SKU会被低估）
roll_sum = df["net_sales"].rolling(WINDOW, min_periods=45).sum()
roll_cnt = df["net_sales"].rolling(WINDOW, min_periods=45).count()
df["rolling_daily_sales"] = (roll_sum / roll_cnt).round(2)
return df
这段逻辑里有两个细节值得展开。第一，滚动窗口的分母用的是有效天数，而不是固定90天。如果某个SKU在大促期间被剔除，它在这个窗口里的有效天数是少于90的，用固定90做分母会系统性低估销量。
第二，退货回冲必须做，但要注意时间差。退货发生在订单之后，如果按订单日期回冲，会污染历史窗口。我们的做法是按退货发生日期回冲，虽然会造成窗口内的轻微不匹配，但比按订单日期回冲更接近真实。
口径固化之后，趋势观察才有意义。我在系统里主要看两个信号：一是滚动90天销量的斜率，二是季节性偏离度。
斜率我不用绝对值，用相对值：斜率 ÷ 窗口均值。这样不同量级的SKU可以横向比较。在我这个项目里，相对斜率超过 ±5% 才算进入观察区，超过 ±15% 进入行动区。
季节性偏离度用的是过去两年的同月数据。这里有个坑：如果SKU上架不满两年，就没有完整的季节性基线。我的处理是先用类目均值做替代基线，等SKU积累了完整数据再替换。
这个项目从2023年12月启动，到2024年6月完成主要模块上线。下面是我记录的六个月前后对比数据，来自项目内部脱敏统计：
| 指标 | 实施前（2023.07-12） | 实施后（2024.01-06） | 变化幅度 |
|---|---|---|---|
| 断货SKU占比（按金额） | 11.8% | 3.4% | -71.2% |
| 冗余库存金额占比 | 24.6% | 13.2% | -46.3% |
| 库存周转天数 | 96天 | 67天 | -30.2% |
| 长期仓储费（月均） | 2.8万元 | 1.1万元 | -60.7% |
| 补货决策工时 | 9.4小时/周 | 2.6小时/周 | -72.3% |
| 因口径争议导致的会议延时 | 约4.2小时/周 | 约0.7小时/周 | -83.3% |
这里面我最看重的是最后一项。口径争议时间的下降幅度最大，也最能说明问题：趋势观察体系的真正收益，不只是库存变好，而是团队不再把时间浪费在争论数字上。
需要说明的是，这组数据是单一项目的样本观察，期间还叠加了运营策略调整和品类结构变化，不能完全归因于工具。但在同口径对比下，方向和幅度是清晰的。
为了把过程讲透，我用一个实际SKU做演示。这是一款厨房小工具，日均销量在2024年2月到4月之间出现了明显变化。
这个案例说明了两件事：一是阈值需要持续校准，不能一次定死；二是趋势观察的价值不只在于避免断货，还在于给补货留出选择运输方式的余地，而运输方式的选择直接决定毛利。
方法只有落到具体场景才有意义。我按店铺规模和数据复杂度，把卖家分成四类，分别给出行动建议。
这个阶段不建议上复杂系统。核心任务是建立口径意识，而不是工具升级。
这个阶段数据源开始分散，人力成本快速上升，是最需要工具介入的区间。
这个阶段的特点是需要跨站点协同，库存调拨的可能性大幅增加，趋势观察的复杂度显著上升。
铺货型的核心矛盾是SKU数量与人力不匹配，不可能做到每个SKU精细化。
任何实施路径都伴随取舍。这一节讲我做过的最难的四个取舍，以及我的判断依据。
追求精度意味着一层层校验，数据可信度提高，但更新变慢。追求速度意味着接受一定误差，但能及时反应。
我的判断逻辑是按SKU分层：头部SKU要精度，可以接受T+1甚至T+2的更新频率；中长尾SKU要速度，接受日内数据，误差容忍度放宽到±15%。
库存管理里没有全局最优解，只有分层最优解。用同一套精度标准要求所有SKU，结果一定是头部不够准、尾部成本过高。
自建的好处是口径完全可控、可以深度定制；坏处是维护成本高，尤其是接口变更时。采购的好处是上线快、维护由供应商承担；坏处是口径受限于产品设计。
我在2人以下的运营团队里倾向于采购，因为自建体系的隐性维护成本往往被严重低估。接口变更、字段调整、数据异常排查，这些工作每个月至少要吃掉三到五个人天。
全量覆盖看起来更安全，但实际执行中会导致资源摊薄。我的经验是：按贡献度倒推覆盖范围。通常20%的SKU贡献80%的销售额，把趋势观察做深在这20%上，收益远高于对全部SKU做浅层监控。
剩余80%的SKU用批量规则兜底，比如统一的安全库存天数和固定的补货周期，不做个性化建模。
自动化的诱惑很大，但我建议在补货这种直接影响现金流的动作上保留人工复核。不是因为不信任系统，而是因为系统不知道的事情太多，供应商临时涨价、竞品突然清仓、平台政策变化，这些都不会出现在历史数据里。
我的折中方案是：系统出建议，人工做确认，但确认有时间限制。超过24小时未确认的自动升级给上级，避免流程卡死。保留人工不等于放弃效率，关键是要给人工环节也设定时限。
最后把前面的内容收敛成一条可执行的实施路径。我把它分成四个阶段，每个阶段都有明确的完成标志。
这个阶段唯一的目标是把口径字典写出来。参与的应该是业务方和供应链，而不是IT。
完成标志：口径争议在一次会议内可解决，不需要反复拉群。
不要全量上线。选20到50个SKU做试点，覆盖头部、中部和尾部各若干。
完成标志：试点SKU的断货率和冗余率同时改善，且运营愿意主动使用。
试点验证通过后，按SKU分层逐步覆盖。头部SKU优先接入，尾部SKU最后接入。
完成标志：库存决策不再依赖个人经验，新任运营可在两周内上手。
体系上线不是终点。季节变化、品类调整、平台规则更新都会让阈值失效。
完成标志：库存管理从“靠人救火”变成“靠机制运行”，人的价值转移到规则设计和异常处理上。
体系建完之后，怎么验证它是否有效？我用三组对照来验证，避免自我感觉良好。
拿过去12个月的数据跑一遍，看每次断货或严重滞销发生前，系统是否在两周内发出过预警。召回率低于60%，说明阈值太宽松；预警次数超过SKU数的30%，说明太敏感。
这个测试的价值在于它不需要等待未来，用历史数据就能验证，成本极低。
推广期我会让新体系和原有方式并行一段时间，每周对比两边的建议单量。差异超过30%的SKU逐个人工核查，看看是哪边错了。
这个过程往往会暴露出一些老方法里长期存在的错误，比如某类SKU的安全库存被系统性设得太高。并行验证最意外的收获，常常是发现自己原来的做法一直是错的。
最终还是要看结果。我关注的六个指标是：断货SKU金额占比、冗余库存金额占比、库存周转天数、长期仓储费、动销率、补货决策工时。
这六个指标要一起看。只降断货但冗余上升，说明只是把风险从一端推到了另一端，不是真正的改善。
周复盘只看红色阈值事件，控制在30分钟内；月复盘看指标结构和库龄分布，1小时左右；季复盘看阈值是否仍然合理，要不要调整参数。
节奏分层的意义在于，避免把所有问题都堆到一次长会议上讨论，那样既耗时又容易跑题。
写到这里，我想把最核心的几个判断再收一遍。
第一，库存趋势观察的难点在口径，不在算法。我经手的项目里，没有一个是靠换算法解决的，全都是靠把口径定义清楚、把数据源对齐之后才出现改善。
第二，趋势观察必须绑定动作，否则就是装饰。一条不会触发任何行为的曲线，对库存健康没有任何贡献，只会消耗注意力。
第三，实施路径不能倒过来。先定口径、再接数据、再建指标、最后绑动作，这个顺序颠倒任何一步，都会有返工。我给自己的团队定的规矩是：口径文档没有签字，任何系统配置都不动手。
第四，工具的价值在于把重复劳动自动化，把人的时间释放到异常判断上。以数跨境这类工具为例，它最大的作用不是替你做决定，而是让你每周在库存上只花两三个小时，就能看清两千个SKU的方向。这是人做不到的，也是工具真正不可替代的地方。
如果你现在正在考虑推进这件事，我建议的下一步很具体：不要先看软件、不要先比价格，先花一周时间，把你自己团队里“日均销量”这四个字到底指什么，写成一段所有人都认可的定义。这段定义写不出来，后面所有投入都会打折。
如果这段定义能写出来，并且团队三方都签字确认，那么你已经完成了整个实施路径里最难的一步，剩下的都是工程问题。
我管着几个站点，后台报表一大堆数，每天看总库存和销售额感觉都在涨，结果月底一算账发现压了不少货。之前也试过看库存周转率，但跟财务算出来的完全对不上，不知道该信哪个数字。
先固定四个指标，每个指标配一个写死的口径：可售天数＝可用库存÷近14天日均销量，在途库存单独列，不并入可用；周转率＝近28天出库成本÷平均库存成本；断货影响＝断货SKU天数占比×该SKU近28天日均销售额，折算成损失金额；冗余占比＝库龄超90天的可售库存金额÷全部可售库存金额。
口径要写在表格旁边，谁改谁负责，否则你画的不是库存趋势图，而是口径变更图。判断趋势至少看连续8周的周度数据，单周波动没有决策价值；同比优先用去年同周而不是环比，因为平台有明显的季节性和大促节奏，环比很容易被活动前后挤压带偏。
老板让我上库存管理系统，我第一反应是先去选型，比了七八家，功能表看上去都差不多。真对接进来才发现SKU编码、仓库归属、在途口径全都没统一，数据进了系统就是一坨垃圾，还得回头推倒重做。
先用两周做一张手工看板，再谈工具。做法是从后台下载库存快照和已配送销售额报表，按SKU＋站点建一张表，手工把四个指标算出来，连续跑两周。这一步不是为了看数，是为了暴露口径冲突：FBA可用、FBA在途、FBA不可售、本地仓、在途采购分别算谁的库存，退货和移除算不算出库，促销赠品算不算销量。
理清之后再去选型，标准只剩三条：能不能按你的口径取数、能不能每天自动刷新、能不能按SKU追溯历史快照。工具解决的是频率和一致性问题，解决不了口径问题。顺序颠倒的话，系统上线三个月后还得推翻重来，浪费的是实施费和团队信任。
我同时管北美、欧洲、日本几个站点，后台更新时间不一样，欧洲报表要等到第二天才准。拿一周数据做趋势判断时数字总在跳，补货决定一直不敢下，怕下错了砸在手里。
核心是把决策时点和数据时点分开，并且固定用快照、不用实时查询。每天固定一个时间（比如北京时间上午10点）拉一次全站点快照，落库时带上时间戳，所有趋势比较只基于同一时点的快照序列。
销售额和库存数据本身存在回补，通常要24到72小时才稳定，所以最近三天的数字只做参考、不参与趋势判断，趋势窗口一律整体延后三天。多站点不要直接加总，先各自按当地货币和当地销量算指标，再按统一汇率和口径汇总，否则某个站点的汇率波动会污染整条趋势线。
如果某两周指标波幅超出历史正常区间，先查数据链路（漏采SKU、新站点接入、店铺授权过期），确认数据没问题再解读业务，这个顺序能挡掉大半误判。
上次我看到某款七天销量涨了三成，立刻追加采购，结果那是大促前的备货效应，两周后库存砸在手里。现在看到上涨信号我都很犹豫，不知道什么样的信号才值得真金白银动手。
先把信号分成结构性和事件性两类。结构性变化要同时满足三个条件：连续三周以上同方向、剔除大促和广告加投因素后仍然成立、搜索词报告里的自然位点击同步上升。只满足一条的按事件处理，不做采购决策。动作上用分级触发代替拍脑袋：可售天数低于14天且连续两周下降，走加急补货；14到30天且走势平稳，按常规节奏补；
超过60天且周转率连续三周下滑，进入清货流程，用降价、捆绑、站外渠道组合处理。每次决策都记录触发指标、当时数值和最终结果，三个月后回头复盘，把误判案例归类，通常你会发现八成误判来自把促销峰值和季节前备货当成了趋势。这份复盘记录本身，就是下一轮判断趋势时最值钱的依据。
读者评论
口径统一这条我很有感触，但90天滚动日均在季节性强的品类里也有滞后，旺季前容易错过拐点。实际用下来，可能还要叠加周同比和活动前后切片，不然趋势还是慢半拍。阈值也要按品类分，不能一套通用。
实施顺序我认同，但小团队最难的是没人长期维护口径字典。系统能统一数据源，却统一不了补货会上谁拍板。最后往往变成系统算一套、Excel算一套，根子还是流程和责任人没定清楚。
图表用11个店铺脱敏归一化，只能当参考。阶段四断货率2.1%、周转63天看着很理想，但不同类目和站点差异很大。我更想知道阈值设完后误报多不多，人工复核是否真能降到每周1.8小时，还是把工作量转到了调阈值上。