AutoTVM Python API算子调优：搜索空间、测量与记录命中

把一段矩阵乘法的计算图丢进 AutoTVM，让它自己去搜最优的 tiling 参数——我第一次做这件事的时候，以为跑个脚本就完事了，结果第一条日志等了四十多分钟才吐出来，而且日志里挑出的“最优配置”套回网络之后，居然一点加速都没有。查了两个晚上才定位到，问题既不在编译器也不在硬件，而是我调优时用的 target 字符串和部署时用的 target 字符串不一致，历史记录压根没匹配上，静默回退到了默认调度。这件事之后我对 AutoTVM 的 Python API 有了完全不同的认识：它不是几个函数调用，而是一套“搜索空间设计 + 测量可信度 + 记录绑定”的完整链路，任何一环松了，调出来的东西就是废的。

这篇东西想聊的就是这条链路上的实操细节。AutoTVM是深度学习编译器栈里负责算子级自动调优的模块，它通过Python API把算子模板、参数搜索空间、测量构建器和调优算法串起来，让一段张量计算在给定硬件上自动逼近较优的调度方案。适合谁看？如果你的模型在推理时有那么几个算子死死卡住端到端延迟，而你又不满足于手动拍一个 tiling 参数，那这套东西值得花时间吃透；如果你只是想跑通官方示例，那看文档就够了，下面这些内容更多是踩过坑之后总结出来的判断依据。我假设你已经能读懂 TE 的基本写法，对 schedule 里的 split、reorder、bind 不算陌生，剩下的部分我会把每一步的“为什么”讲清楚。

1. 先把 AutoTVM 到底调什么这件事讲透

1.1 手写调度参数为什么很难拍准

先说清楚被优化的对象。在 TE 这套体系里，一个算子的计算逻辑（compute）和它的执行方式（schedule）是分离的。计算逻辑定死了“算什么”，schedule 决定“怎么算”——数据怎么切块、循环怎么排序、哪些轴绑到哪个层级的并行维度上。同一段矩阵乘法，切块大小从 8 换到 64，实测算下来性能能差出三到五倍，这不是夸张，在访存密集型算子上非常常见。

难点在于这个映射关系不是单调的。tile 太小，循环开销和访存次数上去了；tile 太大，寄存器压力和缓存命中率崩了；某些形状下把归约轴拆成两段会更友好，换个形状就变成负担。更麻烦的是，这套关系和硬件参数是耦合的：缓存行大小、共享内存容量、向量化位宽、寄存器数量，任何一个变了，最优参数就跟着漂。我做过一次对比，同一份模板在两种不同架构的板子上各调 800 次，最后选出的 tile 组合几乎没有重叠。

人工拍参数的典型做法是凭经验给一组，然后拿 profiler 看瓶颈，改一版再测。一个问题改三轮，一轮二十分钟，效率极低，而且很容易陷在局部最优里出不来——你把 tile 从 16 调到 32，发现变快了，就继续往上调，但真正的最优点可能藏在“32 加上归约轴再拆一刀”这个组合里，你不主动去探索就永远看不到。AutoTVM 存在的意义就是把这种靠直觉的探索变成可枚举、可度量、可复现的搜索过程。

1.2 调度模板加配置空间，才是可搜索的前提

AutoTVM 的核心思路不复杂：把 schedule 的构造过程写成一个带参数的函数，把参数取值的组合定义成一个搜索空间，然后让调优器在空间里采样，每次采样都构建、运行、计时，最后把最好的那组参数记下来。三个角色缺一不可。

第一部分是调度模板，一个用@autotvm.template装饰的函数，它接收算子的形状和类型作为参数，内部根据传入的配置实体（ConfigEntity）动态生成 schedule。关键在于这个模板必须对“任意合法配置”都能构建成功，不能出现某个参数组合直接抛异常的情况，否则整个搜索空间的可信度就打折扣。

第二部分是配置空间，在模板里通过cfg.define_split、cfg.define_knob、cfg.define_reorder这些调用声明出来。这些声明不只是给调优器看的候选列表，它们同时决定了空间的大小和结构。define_split会自动枚举一个轴的所有合法因子拆分方式，define_knob则是显式给一组离散值。空间的大小直接决定调优成本，一个不小心就会从几百条膨胀到几十万条。

第三部分是代价模型和调优器，负责在空间里挑下一个要试的点。默认的调优器是 XGBoost，它根据已经测过的点训练一个回归模型，预测未测点的性能，然后挑预测值最好或者最不确定的点去实测。这个设计的意义在于，纯随机采样在空间大的时候收敛太慢，而模型引导能把有限的试验次数集中到有希望的区域。

1.3 什么情况下值得上，什么情况下纯属浪费

这一点我觉得比 API 用法更重要。AutoTVM 的单位成本不低：每条配置都要走一次完整编译加多次运行计时，单条从几百毫秒到几秒不等，一个几千条的空间跑一晚上很常见。所以先判断值不值得。

值得做的信号很明确。第一，这个算子在你的端到端耗时里占比够高，比如 top5 算子合计占了七成以上时间，那优化它们收益直接。第二，这个算子的调度空间确实大，卷积、矩阵乘、批量归一化这类访存和计算都重的算子都属于这一类。第三，你的目标硬件相对固定，调一次能用很久，摊销下来才划算。

不值得的情况同样明确。像 element-wise 加法、简单的 reshape、激活函数这类算子，调度空间基本没什么可挖的，手写一个向量化的 schedule 就到顶了，花几小时调优提升可能只有百分之三。还有一类是形状极度动态的场景，每个 batch size 或者序列长度都不同，那 workload 的 key 会爆炸，调优记录也难以复用，这时候更该考虑的是算子融合或者换执行后端，而不是死磕自动调优。我自己的经验线是：单算子调优后预期收益低于 5% 的，直接跳过；占端到端 10% 以上的，认真调。

2. 一条自动调优流水线的整体设计

2.1 五个核心对象各自管什么

用 Python API 搭流水线，本质上是在组装五个对象，理解它们的职责边界，后面所有问题都好定位。

Task是调优任务的载体，由模板名和一组参数实例化出来，它内部持有了配置空间。ConfigSpace是任务产出的搜索空间，可以打印出来看规模，也可以手动裁剪。Tuner是调优算法本体，负责“下一条试什么”。Builder负责把配置实例化成可执行的模块，本地构建就是调本地编译器。Runner负责把构建产物跑起来并计时，可以是本机，也可以是通过 RPC 连到远端设备。

这五者的关系是一条链：Tuner 问 ConfigSpace 要候选，交给 Builder 编译，Builder 的产物交给 Runner 测量，测量结果回流给 Tuner 更新模型。任何一环出问题，表现出来的现象都是“调优跑完了但没效果”或者“调优卡住不动”，而根因可能藏在完全不相干的地方。我遇到过 Runner 的 timeout 设得太小，导致一批本来正常的配置被标记为测量失败，Tuner 拿到一堆无效反馈，最后选出来的“最优”其实是矬子里拔将军。

measure_option就是把 Builder 和 Runner 打包在一起的那个配置项，写法上是一行，但它决定了整条流水线的吞吐和可信度，值得单独拿出来反复调。

2.2 搜索空间的设计取舍

空间设计是整件事里最考验经验的部分。新手常见的问题是空间开太大，觉得“搜索能力越强越好”，实际上调优器的采样效率是有限的，空间大一倍，收敛需要的试验次数可能多好几倍。

我的做法是先做一个“粗粒度版本”：只在最关键的维度上开搜索，比如矩阵乘只对 M、N 两个输出轴的 tile 做 split，K 轴固定不拆。跑一两百次看看最优配置大概落在什么量级，比如 tile 集中在 32 到 64 之间。然后基于这个信息做第二轮，把范围收窄，同时加入更细的维度，比如向量化、归约轴拆分、循环重排策略。这种两阶段的做法比一次性开大空间效率高得多，而且第一轮的结论本身就是有价值的信息。

还有一个必须注意的点：define_split生成的因子列表不是无限的，它默认会包含 1、2、4、8、16、32 这样的常见值，但不会包含所有整数因子。如果你的硬件对某个非 2 的幂次特别友好（某些架构上 3 或者 6 的对齐确实有优势），那就得用define_knob显式给值。反过来，如果确认某个轴只能取少数几个值，用define_knob限定比define_split全枚举要省得多。

2.3 调优器怎么选

三种调优器我用得比较多。GridSearchTuner是穷举，只在空间小（几百条以内）且你需要完整数据的时候用，好处是可复现、无随机性，坏处是慢，空间一大就没法用。RandomTuner是纯随机采样，作为基线很合适——调优效果如果连随机都不如，说明模板或者测量环节有 bug。XGBTuner是默认选择，模型引导的采样在空间超过一千条时优势明显，实测下来同样的试验次数，XGBTuner 找到的最优配置通常比随机好 10% 到 20%。

还有一个容易被忽略的选项是XGBTuner的loss_type参数。默认是"reg"，用回归预测绝对耗时；设成"rank"则改成排序学习，只关心相对好坏。我的经验是测量噪声大的场景（比如共享机器、有后台任务）用rank更稳，因为绝对耗时波动大，但相对排序相对可靠。

3. 核心 API 逐个拆开看，参数背后的取舍

3.1 模板定义里的版本差异

模板的写法在不同版本上有差异，这一点必须先确认，否则复制来的示例代码直接报错。较早的版本里，模板函数用te.create_schedule生成 schedule，返回(s, [A, B, C])这样的元组；较新的版本要求用te.create_prim_func把计算图先转成 PrimFunc，再基于它建 schedule，返回(sch, [func])。两种写法在语义上等价，但混用会出问题。

import tvm from tvm import te, autotvm @autotvm.template("tutorial/matmul_v1") def matmul_v1(N, L, M, dtype): A = te.placeholder((N, L), name="A", dtype=dtype) B = te.placeholder((L, M), name="B", dtype=dtype) k = te.reduce_axis((0, L), name="k") C = te.compute( (N, M), lambda i, j: te.sum(A[i, k] * B[k, j], axis=k), name="C", ) cfg = autotvm.get_config() s = te.create_schedule(C.op) y, x = s[C].op.axis # 输出轴分块，候选因子由 define_split 自动枚举 cfg.define_split("tile_y", y, num_outputs=2) cfg.define_split("tile_x", x, num_outputs=2) yo, yi = cfg["tile_y"].apply(s, C, y) xo, xi = cfg["tile_x"].apply(s, C, x) # 归约轴分块，只给固定几档，避免空间爆炸 cfg.define_knob("tile_k", [4, 8, 16, 32]) ko, ki = s[C].split(k, factor=cfg["tile_k"].val) s[C].reorder(yo, xo, ko, yi, ki, xi) s[C].vectorize(xi) return s, [A, B, C]

这里有几个细节值得抠。cfg.define_split的第二个参数传的是轴对象还是轴长度，版本之间不一样，报错信息通常是“期望 int 收到 IterVar”之类的，看到就改一下。cfg["tile_y"].apply(s, C, y)这一步是把配置里的拆分方案真正落到 schedule 上，它返回新的内外轴，顺序是外层在前、内层在后，写reorder的时候别搞反。

vectorize(xi)放在reorder之后是个习惯，因为向量化的对象必须是最内层循环，如果先向量化再重排，很容易把向量轴挪到非最内层，编译器会报错或者默默退化成标量。这一点我踩过，现象是调优日志里所有配置的耗时几乎一样，排查半天发现向量化全失效了。

3.2 构建器与运行器的组合，决定了测量的可信度

measure_option的写法看着简单，但里面每个参数都在影响“测出来的数准不准”。

measure_option = autotvm.measure_option( builder=autotvm.LocalBuilder(timeout=20, n_parallel=4), runner=autotvm.LocalRunner( number=10, repeat=3, timeout=30, min_repeat_ms=500, enable_cpu_cache_flush=False, ), )

number是单次测量里运行多少次取统计值，repeat是整个测量重复几轮，最终取各轮的中位数或最小值（由MeasureResult的聚合逻辑决定，默认偏向最小值，因为最小值对噪声更鲁棒）。min_repeat_ms是个很实用的参数：它是让测量持续到至少这么长时间，内部的number会自动放大到满足条件。这个设计是为了对付“单次运行只有几十微秒”的算子——计时器的分辨率不足以覆盖，测出来的数全是噪声。设成 500 毫秒，测量精度立刻上一个台阶。

timeout有两个，Builder 的和 Runner 的，含义不同。Builder 的超时是编译超时，某些复杂 schedule 编译能磨几十秒，设小了会误杀。Runner 的超时是运行超时，设小了同样误杀。两个都建议给足，宁可慢一点也不要拿到脏数据。n_parallel是本机并行构建进程数，设成 CPU 核数的一半左右比较稳，设太满会和测量进程抢资源，把计时搞脏。

enable_cpu_cache_flush只在 CPU 场景有意义，用来清 L2/L3 缓存避免跨轮次污染，如果你的算子是访存密集型的，建议打开。

3.3 TuningOptions 和试验预算的估算

tuner.tune调用里最容易被随意填的就是n_trial。填 1000 还是 5000，背后应该有账算。

粗算方式是：单条配置的成本 ≈ 构建时间 + 测量时间 × 重复轮数。以本机矩阵乘为例，构建大约 1.2 秒，测量在min_repeat_ms=500下每轮约 0.6 秒，repeat=3就是 1.8 秒，加起来约 3 秒一条。1000 条就是 50 分钟。这个估算不是精确值，但能让你在按下回车之前知道要等多久。

tuner = autotvm.tuner.XGBTuner(task, loss_type="rank") tuner.tune( n_trial=800, measure_option=measure_option, callbacks=[ autotvm.callback.log_to_file("matmul_v1.log"), autotvm.callback.progress_bar(800, prefix="[matmul] "), ], )

log_to_file这个 callback 必须加，而且要在第一次跑的时候就想清楚日志路径。AutoTVM 支持中断恢复：只要日志文件存在，重新跑的时候已经测过的配置会被读进来，不会重复测。这个机制救过我很多次，尤其是调优跑到一半机器被占、或者发现参数写错了但已经跑了两小时的情况。

提示：日志文件建议带上 workload 描述和目标硬件标识，比如matmul_1024x1024_intel.log。多个任务共用一个日志文件不是不行，但后面按 workload 匹配的时候排查成本会高很多。

3.4 记录结构：匹配是怎么发生的

调优产出的每一条记录包含三样关键信息：workload 字符串、target 字符串、config 实体加耗时。应用历史记录的时候，AutoTVM 拿当前任务的 workload 和 target 去日志里找完全匹配的条目，找到就用那组配置，找不到就静默回退到默认调度。

这个“静默”是万恶之源。它不报错、不警告，只是安静地用了默认参数，你在上层看到的就是“明明调过了，一点没变快”。排查手段是打开 dispatch 的调试输出，或者直接在应用前后打印当前配置。

import logging logging.getLogger("autotvm").setLevel(logging.DEBUG) logging.getLogger("autotvm").addHandler(logging.StreamHandler()) with autotvm.apply_history_best("matmul_v1.log"): with tvm.transform.PassContext(opt_level=3): lib = relay.build(net, target=target, params=params)

打开 DEBUG 之后，日志里会打印每条记录命中的情况，没命中的一眼就能看出来。我现在的习惯是首次跑通流程时一定开 DEBUG，确认命中率，再关掉。

workload 字符串是由模板名加参数拼出来的，参数顺序和类型必须和创建任务时完全一致。matmul_v1(1024, 1024, 1024, "float32")和matmul_v1(1024, 1024, 1024, "float32")看着一样，但如果一个是 Python int、一个是 numpy int64，拼出来的字符串可能不同。这类问题我在 relay 图抽取任务的时候遇到过，从计算图里抽出来的形状是tvm.tir.IntImm类型，和手写脚本里的原生 int 拼出来的 workload 不一致，导致记录全部不命中。解决办法是抽取后统一转成原生类型再建任务。

4. 一套完整可复现的调优流程

4.1 环境与版本对齐

动手之前先确认三件事。第一，编译器和 runtime 是同一套构建出来的，混用不同来源的库容易在测量阶段莫名其妙崩溃。第二，调优器依赖的第三方包装好了，XGBTuner 需要额外装 XGBoost，没装的话会直接报导入错误。第三，确认目标描述字符串的准确写法，这一点我建议直接打印出来。

import tvm target = tvm.target.Target("llvm -mcpu=skylake-avx512") print(target) print(target.keys)

把这行输出记下来，后面所有环节都用这同一个字符串，不要手打。target 的 keys（比如cpu、llvm）参与记录匹配，手动构造时少写一个 key 就会导致不命中。

4.2 参数计算：空间规模到底有多大

拿上面那个模板算一下空间规模。tile_y用define_split，输出轴长度 1024，默认因子列表大概包含 1 到 1024 之间的常见 2 的幂次，实际枚举出来的候选大约 8 到 10 组；tile_x同理；tile_k是 4 档。三者相乘，空间在 300 到 400 条左右。

这个规模用 GridSearchTuner 完全可以穷举，400 条 × 3 秒 = 20 分钟，拿到的是完整数据，后续分析最方便。但如果把归约轴也改成define_split、再引入define_reorder的多种策略，空间很容易冲到几万条，那就必须换 XGBTuner，并且把n_trial控制在 1500 以内，靠模型引导而不是穷举。

我一般的判断线是：空间 500 条以内用 GridSearch，500 到 3000 用 XGBTuner 配n_trial等于空间的三分之一到一半，超过 3000 就先砍空间，基本不会硬着头皮跑。

4.3 跑调优与中断恢复

正式跑之前，先做一次“冒烟测试”：把n_trial设成 5，跑一遍全流程，确认构建成功、测量有数、日志有内容、应用记录能命中。这五分钟的投入能避免你在跑了半小时之后发现日志是空的。

确认无误后正式启动。如果是长时间跑，建议放到tmux或者nohup里，不要挂在会断的会话上。

nohup python tune_matmul.py > tune.out 2>&1 & tail -f tune.out

进度条会实时刷新已完成的试验数和当前最优耗时，这个数字在前期下降很快，后期趋于平缓。什么时候该停？我的标准是看最近 100 次试验里有没有刷新最优值，连续 200 次没刷新，基本可以收手了，继续跑边际收益极低。

如果中途因为机器重启、被人抢占之类的原因中断了，直接重跑同一个脚本，日志里的记录会被自动加载，从断点继续。

# 重跑时不需要额外处理，log_to_file 指向同一个文件即可 tuner.tune(n_trial=800, measure_option=measure_option, callbacks=[autotvm.callback.log_to_file("matmul_v1.log")])

有一个细节要注意：AutoTVM 恢复时会读取日志里的所有记录，包括其他 workload 的记录，但只把匹配当前任务的拿来用。如果你改过模板的内部逻辑但模板名没变，旧记录会被错误地认为有效，跑出来的结论不可信。改模板就得换模板名或者换日志文件，这一点别偷懒。

4.4 结果落地：把配置真正用起来

调优只是过程，落地才是目的。应用历史记录有两种方式：一种是包在apply_history_best上下文里，适合整个编译流程一起走；另一种是显式取出最优配置，手动 instantiate 验证。

with autotvm.apply_history_best("matmul_v1.log"): with tvm.transform.PassContext(opt_level=3): with tvm.target.Target(target) as tgt: lib = relay.build(net, target=tgt, params=params) lib.export_library("optimized.so")

部署侧还有个更常见的需求：把调优产物做成一个独立的配置库，运行时不用带日志文件。做法是用tvm.autotvm.record遍历日志，把每条记录转成目标序列化格式导出。这样部署包里只有二进制，没有明文日志，体积也小。

验证落地效果最直接的办法是端到端计时对比。同一个网络、同一份输入，分别在有无apply_history_best的情况下跑 100 次取中位数。如果提升只有个位数百分比，别急着怀疑调优质量，先检查是不是命中了——前面说过，不命中也是这个表现。

5. 踩坑记录与排查速查

5.1 调优耗时远超预期

最典型的三个原因，我按出现频率排。

第一个是timeout设得太小导致大量配置被判定失败，失败之后调优器可能重试或者换采样策略，整体时间反而更长。判断方法是看日志里 error 记录的比例，超过 5% 就要查。

第二个是构建没有并行化。LocalBuilder的n_parallel默认值在不同版本上不完全一致，显式设成 4 到 8 通常能把整体吞吐提上去。但注意别超过物理核数的一半，不然和测量进程抢资源，测出来的数不可信。

第三个是空间里存在“编译地狱”配置，某些极端拆分组合会让编译器优化 pass 跑上几十秒甚至几分钟。这种情况用 Builder 的超时兜底，超时的配置直接丢弃，对最终结果影响不大——反正那些配置本来也不会是最优。

5.2 测量数据波动大，最优值不可信

测量噪声是三方面的叠加：机器本身有其他负载、缓存状态在不同轮次之间不一致、计时器分辨率不够。

第一个靠独占机器解决，实在不行就接受噪声，把调优器的loss_type改成rank，减弱绝对值的权重。第二个靠enable_cpu_cache_flush=True，代价是每轮测量多花点时间。第三个就是前面说的min_repeat_ms，把它设到 500 甚至 1000，代价是单条测量变慢，但数据质量提升明显。

还有一个隐性问题：GPU 场景下的计时必须处理同步。异步 kernel 启动之后计时器直接返回，测出来的数是启动开销而不是执行时间。AutoTVM 的 Runner 内部做了同步，但如果你自己写了自定义 Runner，这一步千万别漏。

5.3 记录不命中或者命中错误

前面提过 target 和 workload 两个匹配键。这里补充两个隐蔽情况。

一是同一个模板被不同参数实例化，参数里有浮点数。1.0和1拼出来的字符串不同，记录就对不上。形状参数统一用整型，别混。

二是批量调优多个算子时，所有记录写进同一个日志，应用的时候 workload 前缀相同但参数不同，可能出现前缀匹配的错觉。实际上 AutoTVM 要求完全匹配，不会误用，但排查时容易看错行。建议每个算子单独一个日志文件，命名带上形状信息。

注意：看到“调优没效果”先别改模板，90% 的情况是匹配或测量环节的问题。模板是最不容易错的部分，因为写错了通常直接编译失败，反而是最快能发现的。

5.4 从单算子到整网的抽取

单算子调通之后，下一步是整网。流程是从编译好的计算图里抽取算子任务，批量跑调优。这里有一个交接点必须注意：抽取出来的算子参数类型和手写脚本里的类型可能不同，前面提过 IntImm 的问题。

tasks = autotvm.task.extract_from_program( mod, target=target, params=params, ops=("conv2d", "dense", "batch_matmul"), ) for i, task in enumerate(tasks): print(i, task.name, task.args)

先把抽取结果打印出来看，确认 workload 字符串长什么样，再决定日志命名和后续匹配策略。这一步花十分钟，能省掉后面两小时的困惑。另外ops参数要按你实际模型里存在的算子类型给，给多了会抽出一堆你根本不关心的任务，白白增加调优时间。

6. 进阶玩法和工程化落地

6.1 多设备调优的组织方式

实际项目里目标硬件往往不止一种，比如服务端和边缘端各一套。这时候不建议把所有记录塞进一个日志，而是按设备分目录组织，每个目录下按算子分文件。应用时根据运行时探测到的设备类型加载对应目录，逻辑清晰，也方便做灰度。

如果目标设备不能直接在本地编译，可以用 RPC 的方式把构建产物传到远端运行计时。这种方式的好处是测量环境真实，坏处是链路长、稳定性差，建议加足够的重试和超时保护，否则一次网络抖动就会污染一批测量数据。

6.2 和自动调度器的关系

后来出现的 auto-scheduler 走的是另一条路：不要求人写调度模板，直接从计算图生成搜索空间，用更加重的代价模型搜索。它的优势是省人力，对新算子友好；劣势是调优成本高，对算力要求大，而且搜索出来的调度可读性差，出问题不好排查。

我的取舍是：核心算子、调用频繁、有成熟模板经验的，用 AutoTVM，可控性更好；新模型里冒出来的陌生算子、或者形状组合特别多的，用自动调度器先探个底，看能到什么水平，再决定值不值得手写模板精调。两者产出的记录格式有差异，别混着用。

6.3 把调优纳入日常构建

调优不应该是一次性动作。硬件驱动升级、编译器版本迭代、模型结构变化，都可能让之前的最优配置失效。合理的做法是把调优做成流水线里的一个定期任务，比如每周跑一次，对比新日志和旧日志的最优耗时，偏差超过阈值就更新配置库。

工程上要注意两点。一是调优任务和主构建解耦，调优失败不能阻塞主流程，用旧配置兜底。二是配置库要有版本号和回滚能力，新配置上线后如果端到端指标变差，能一键切回去。这两条不是技术难点，但少了任何一条，线上出问题的时候就会很被动。

最后分享一个我自己一直用的小习惯：每次调优结束，把最优配置连同当时的 target 字符串、编译器版本、试验次数、最优耗时一起写进一个小的元数据文件，跟日志放一起。半年后回头看，能立刻判断这份配置还有没有参考价值，比翻聊天记录靠谱得多。