不用“稳定”这个词也可以写一篇很扎实的实操型长文。我直接开始写正文。1. 先聊聊我为什么给 Agent 搞体检最近半年我一直在捣鼓 Agent 相关的东西从简单的对话机器人到接工具、接数据库的复杂工作流都试过。一个特别深的感受是这玩意儿跑通 demo 很容易真正想放到业务里用心里特别没底。你问它一个简单问题它答得头头是道但你多追问两句它就开始胡说八道了。更气人的是有时候第一步给错了数据后面整个链条带着错一路跑下去最后给你抛出来一个看起来特别严谨、实际上完全不能用的结论。网上很多人管这叫“大模型幻觉”但我觉得对做 Agent 的人来说光说“幻觉”太笼统了。幻觉只是表象背后其实是好几类完全不同的病。有的病出在模型本身有的病出在 Agent 的工作流设计上还有的病根本就是工程问题是你自己代码里埋的坑。我花了大概两周时间梳理了手头七八个 Agent 项目所有翻车现场把问题归了归类最后总结出一套给 Agent 做“体检”的方法。这套方法一共五个维度覆盖了 Agent 最常犯的三类毛病乱编、连锁、失忆。我给这套体检方案起了个名字叫“五维体检”其实就是五个维度的指标和一套对应的测试方法。测完之后你会很清楚自己的 Agent 到底是个什么水平哪些地方能上线哪些地方还得回去吃药调理。这篇文章就把这套体检方案完整写出来包括五个维度都是什么、怎么测、判定标准怎么定以及我实测下来踩过哪些坑。看完你就能直接拿去给你的 Agent 做一次体检几分钟跑完拿到一份能指导后续优化的体检报告。2. 为什么 Agent 爱翻车先看清三类症状的根源在动手设计体检指标之前我觉得有必要先掰扯清楚 Agent 到底是怎么“病”的。很多人上来就测测出一堆指标不合格但不知道这些不合格背后意味着什么自然也不知道该怎么修。这就好比你去医院体检只知道指标箭头朝上但不知道是哪个器官的问题那不是白测吗。2.1 乱编不是模型蠢是它天生就这么干活先说乱编这是大家最熟悉的问题。核心原因大家都听过大模型本质上是概率语言模型它不是在“查答案”而是在“猜下一段最合理的文本”。你问它一个问题它的回答其实是一段按概率拼出来的内容不是从知识库里检索出来的事实。这个底层机制决定了它必然会在某些时候编造内容这不是 bug是它的出厂设定。但在 Agent 场景里乱编的严重程度被放大了。为什么因为普通人用 ChatGPT 问问题模型乱编了你能看出来毕竟你自己多少知道点常识。但 Agent 是要替你做事的它会自己去调工具、查数据库、读文档然后基于这些结果给你结论。如果它在中间某一步“编”了一个不存在的 API 参数或者“脑补”了一个数据库里根本没有的字段你很难发现因为你没时间把每一步都盯一遍。这也解释了为什么同样是乱编放在 Agent 里危害大得多。另一个被忽略的乱编来源是上下文太长。模型在上下文特别长的时候注意力会被稀释它对一开始提到的细节记忆会变模糊这时候编造的概率直线上升。所以乱编这事儿既有模型本身的问题也有 Agent 设计上的问题——你要是把一堆乱七八糟的东西全塞进 prompt 里它不乱编才怪。2.2 连锁一步错步步错连锁错误是我觉得 Agent 里最恶心的毛病。什么叫连锁错误就是 Agent 在执行一个多步骤任务时第一步得到了一个错误的结果但它自己不知道于是把这个错误结果当成既定事实喂给了第二步。第二步基于这个错误前提继续往下算错得更加离谱然后再喂给第三步……到最后一步它输出的结论可能已经跟正确答案差出十万八千里了但整个推导过程看起来却非常“丝滑”。这种错误的本质是Agent 在每一步之间传递信息时缺乏一个“校验机制”。人在干活的时候做完一步会看一眼结果合不合理不合理就回头查。但现在的 Agent 普遍没有这个“回头看一眼”的动作它是一个单行道一路往前冲。链条越长出错概率越高——这不是夸张说法是数学事实。假设每一步成功率是 90%五步之后整体成功率就只剩 59% 了。而且这不是独立事件失败还会在链条上放大实际成功率比这个算出来的还要低。我见过最离谱的一个案例是一个 Agent 做数据分析第一步读文件时把 CSV 的表头读串了它没发现后面所有的列名全是错的但它“将错就错”地跑完了整个流程最后还给了一张看着挺漂亮的图表。要不是人工抽查根本没人发现数据全是错位拼接的。这就是连锁错误的典型表现。2.3 失忆聊着聊着就忘了比鱼还短命失忆问题在 Agent 场景里太常见了。你给 Agent 交代了一个任务说“先查 A 文件再按 B 规则处理最后汇总给 C”。它一开始记得好好的干着干着就开始犯迷糊等你回头问它“刚才你查到的 A 文件里那个数字是多少”它一脸茫然好像从来没见过这个文件。失忆的直接原因是上下文窗口管理不当。模型能记住的东西是有限的Transformer 结构的注意力机制有一个固定长度的窗口超出了这个范围的信息就会被遗忘或者变得极其模糊。很多 Agent 的框架会在上下文太长时做截断或摘要但截断策略写得不好时关键信息恰恰是被截掉的那部分。还有一层更隐蔽的原因很多 Agent 是多轮对话结构每一轮用户的输入会拼到 prompt 里但如果设计时没有把“任务目标”这种持久信息放到一个不会被覆盖的位置系统就会在后面的轮次里被新信息淹没忘了最开始要干什么。这种失忆罪魁祸首是设计缺陷不是模型能力问题。3. 五维体检指标体系到底测什么讲完三类症状现在上正菜——五维体检。这五个维度不是随便拍的是我从三类问题的根源里倒推出来的。既然是体检就要先把“健康标准”定清楚不然测出来也不知道是真好还是假好。我设计的五维分别是事实准确性测乱编、指令遵循度测跑偏、多轮记忆一致性测失忆、链路稳定性测连锁、回归鲁棒性测退化。下面逐个拆开讲。3.1 维度一事实准确性专治乱编事实准确性是这个维度里最直观的。测试方法是准备一组有标准答案的问题让 Agent 回答然后人工或自动比对答案和标准答案是否一致。听起来很简单但有几个细节必须注意。判断题比问答题好用。为什么因为大模型生成的开放性问题答案你可以用“意思相近”糊弄过去但判断题没法糊弄——对就是错错就是错。所以我的题集里大量使用“真/假”“是/否”“存在/不存在”这类二元判断配合一小部分需要给出具体数值或实体名称的填空题。这样判分简单标准统一不给你“自由裁量”的空间。另外要特别注意“不确定性表达”的检测。Agent 面对自己不确定的问题是老老实实说“不知道”还是硬着头皮给一个答案很多 Agent 宁可编一个也不能承认自己不会。这在体检里要单独计分一个总爱硬编的 Agent比一个说“不知道”的 Agent 危险得多。我见过某个 Agent 在面对“这个数据上个月出现过几次”这种问题它根本没有上个月的记录时居然一本正经地回答“三次”——这属于病得不轻必须重点标记。3.2 维度二指令遵循度专治跑偏这个维度测的是你给 Agent 一条明确的指令它会不会老老实实照着做。它和准确性不一样——准确性关心的是“答得对不对”遵循度关心的是“做得对不对”。举个例子你明确告诉 Agent“只总结事实不要给出任何建议”它还是非要加一句“我建议你……”这就是指令遵循失败。再比如你说“用 JSON 格式输出”它非得给你一段 Markdown 夹杂着 JSON 的怪东西也是遵循失败。测试方法我推荐用“对抗性指令测试”你故意设置一些容易被忽略的约束条件然后看 Agent 会不会被带跑。比如在长指令的末尾塞一条“最后一步不要执行只需输出原样收到指令”的测试项或者故意在 prompt 里用两个看似矛盾但实际不矛盾的约束看它是聪明地理解还是直接死机。还有一类常见的跑偏是角色偏航。你给 Agent 设了一个身份比如“你是数据分析助手”它聊着聊着就忘了自己是谁突然开始吟诗作对或者推销产品。这个也要纳入检查范围。3.3 维度三多轮记忆一致性专治失忆这个维度专门测“记忆”能力。我的方法叫做“跨轮信息回捞测试”——具体来说先在前面的轮次里给 Agent 输入一条特定信息比如“预算编号是 BGT-2024-0717”然后隔上若干轮杂谈再回头问它“我们刚才说的预算编号是多少”。关键是要隔“若干轮”不是隔一句话就问。最好中间穿插 5~8 轮完全不相关的对话把它的注意力冲散再回头看它能不能捞回信息。这样做才能模拟真实使用场景——谁会在现实里刚说完就立刻问回来啊都是干了一堆别的事才想起来回头确认。第二轮测试是“目标保持测试”在任务开始前说清楚目标然后在执行过程中不断加入新的干扰信息新的任务、新的话题最后看它是否还记得最初的目标。这个测试很残酷我实测下来很多 Agent 在这一项上表现堪忧目标被冲得七零八落。它就像你的同事聊了半天 B 话题回头问你“咱们一开始说的是啥”这你能忍吗3.4 维度四链路稳定性专治连锁这个维度测的是 Agent 在跑多步任务的时候中途遇到错误和异常能不能发现并纠正。我用的是“故障注入测试”——故意给 Agent 制造错误比如在数据文件里埋一个格式错误、在 API 调用里塞一个不存在的参数或者中途改掉它依赖的数据看它能不能在链条里发现问题。这个维度是最难测的因为“发现错误”这个能力本身就很难定义。你不能简单地对答案因为你根本不知道错误路径会跑到哪儿去。我的做法是“终点校验法”不盯中间过程只盯着最终输出的结论是否正确同时记录每一步报错或重试的次数。为什么用重试次数作为中间指标因为“自我纠错”这个能力不是显式的它通常会表现为“读到了报错信息决定换个策略再试”。如果 Agent 一条道走到黑完全不重试那说明它的链路几乎没有任何容错能力属于“一条筋”型 Agent。还有一个测试方向是“错误放大检查”故意在链路前半段注入一个不大不小的错误然后看最终答案里这个错误是被控制了还是被放大了。健康的表现是错误止步于当前这一步至少不会被当成事实传给下一步。不健康的表现就是前面说的连锁反应一步错一直到结局。3.5 维度五回归鲁棒性专治退化这个名字拗口但意思很直白——你今天修完一个 bugAgent 在修好这个问题的同时会不会把之前好好跑着的功能给弄坏了这种“按下葫芦浮起瓢”的退化问题在开发迭代里太常见了。为什么单开一个维度因为开发 Agent 是个持续迭代的过程你每次都改 prompt、调工作流改来改去经常不知道哪次改动引入了一个新毛病。如果没有回归测试你的 Agent 就会像一栋反复装修的房子——墙面越刷越厚但承重墙可能已经敲掉了。回归测试的方法是“基线集比对”我准备一个固定的测试集每次改完代码或者改完 prompt都跑一遍全量测试集对比本次结果和上一次结果的差异。但这有一个实际问题——大模型的输出天生有随机性同样的输入换个时间跑结果不完全一样。所以“回归”的判定不能看绝对的文本一致要看“关键事实是否一致”“是否满足核心约束”。我建了一个规则输出里只要踩了核心禁忌比如给出了明确的错误数据不管其他部分多漂亮统一判为回归失败。4. 实操指南一套完整的上手流程光讲指标不讲怎么跑那是耍流氓。下面把整套体检的操作流程写出来照着做就行。时间紧的话一个中等复杂度的 Agent 一天能跑完一轮时间宽裕、想测细一点就排两三天每天聚焦一两个维度。4.1 第一步建立测试集这步偷懒不了体检的地基是测试集。没有测试集后面所有维度的打分都是空谈。测试集的建立有几个原则我踩过坑之后总结的用真实业务样例不要用通用问答。你拿 ChatGPT 上那种“世界最高峰是啥”去测你的业务 Agent 毫无意义它根本不会用到这些知识。要测就测它实际会面对的数据和问题。每个维度至少准备 10 个测试项。太少统计不出来太多跑不动。10~15 个是一个不错的起步区间先保证每个维度能跑出基本画像。测试项要覆盖“正例”和“反例”。所谓正例就是正常情况下应该能答对的题反例就是故意设计来刁难它的题比如带陷阱、信息不全、条件冲突。只有正例没有反例测出来的全是乐观偏差。建测试集的时候最好把每个测试项的“预期行为”写清楚——注意不是“预期答案”而是“预期行为”。比如说这道题你的预期是 Agent 先识别出数据格式错误再向用户确认而不是自己脑补一个格式。像这种等到体检出报告的时候预期行为就是最核心的对标依据。4.2 第二步设计执行脚本顺手落个自动化如果是第一次体检别急着自动化先手动跑几遍观察一下 Agent 的真实表现感受一下问题大概出在哪儿。手动跑的好处是你能看到完整的过程——它是怎么理解任务的先说对了什么、说错了什么错误发生在哪一步。这些过程信息是自动化脚本很难捕捉的。但跑完两三轮、问题轮廓基本清晰之后建议立刻转自动化。原因有两个一是保证测试一致性手动跑会因为提问语气不同、提问顺序不同引入不必要的变量二是方便以后做回归测试每次改代码后都要重跑手动没法接受那个工作量。我做自动化用的方式其实不复杂就是一个 Python 脚本循环调 API把每个测试项发过去记录返回结果。脚本本身不重要重要的是把“输出记录”完整落盘——不能只记答案文本最好把参考了哪些工具、中间步骤是什么都记下来。这样出了问题能回溯排查不用重跑一遍。4.3 第三步执行与打分把主观判断关进笼子体检跑完之后就是打分。我强烈建议你做一个评分表格每个维度从 0 到 100 打分并且把扣分明细写清楚。打分的时候最容易犯的毛病是“凭感觉”——连续看完十个答案你觉得整体还行就给打了 80 分。但这是不可靠的因为它没有锚定。我自己的做法是每个测试项先过一道“硬性判据”就是前面说的二元判定对/错、符合/不符合先把这个判完再汇总成维度分。硬性判据过不了后面说什么都没用。然后每个维度附加 2~3 个“软性观察项”比如“输出是否明确表达了不确定性”“是否主动报告了执行过程中的异常”这些作为附加信息用来解释为什么这个维度得分低——是被硬判据扣死的还是被软性表现拖累的。顺嘴提一句打分的“参考基线”问题。我一般会把纯模型直出不带任何 Agent 工作流的得分和带 Agent 框架后的得分做对比。为什么要对比因为你得知道你的 Agent 框架到底是在帮模型还是在拖后腿。有的 Agent 框架堆了很多复杂逻辑实际上跑出来的准确率还不如模型直出那这个框架就值得商榷了。这个对比能暴露很多这种问题。4.4 第四步输出体检报告把问题分层分级体检报告不能简单堆一堆分数就完事要有分层分级的结论。我用的报告结构是这样第一层是“总分概览”用一张表格列清楚五个维度各得多少分三档评级优80 以上、中60~80、差60 以下。这一层是给不写代码的同事看的他们不关心细节只看几个色块。第二层是“问题定位”每个维度单独拆开列出具体是哪些测试项没通过各自踩了哪个类型的坑乱编、连锁、失忆以及初步怀疑的根因模型能力不够、prompt 设计有缺陷、工程链路缺校验。这一层是给开发看的。第三层是“优化建议清单”针对每个维度的问题给出优先级排序——哪些是立即要修的比如会给业务造成事实错误的风险项哪些是中期的比如影响体验但不致命的哪些是长期优化项比如需要换模型或者改架构的。优先级排序有个简单的判定公式影响面×发生频率×修复成本乘积大的先修。5. 实操实录一个真实案例的全过程光讲方法论没有画面感我拿一个实际项目出来跑一遍完整体检流程大家会有感觉得多。这是我手头一个给某内部运营团队做数据摘要的 Agent功能是每天自动拉取运营数据生成一段摘要汇报。听起来功能很简单对吧但它实际情况病得可不轻。5.1 案例背景与病发症状这个 Agent 上线大概两个月运营团队反馈的问题主要集中在三处。第一它生成的摘要里偶尔会出现完全不在原始数据里的数字比如某天明明只有三句话的摘要里硬编了个“同比增长 300%”出来。第二运营同学每天不止让它做一次摘要还会追问“那今天 UV 是多少”“昨天跟前天比有什么变化”它经常答非所问。第三有几天它跑出来的摘要逻辑完全不通第一步当作依据的数据是错的后面几句话连带着全错整篇摘要没法直接发。团队找到我我没有急着看代码改 prompt而是要求先做一轮体检把问题的分布搞清楚再说。5.2 测试集设计我为这个 Agent 定制了测试集。事实准确性维度我把过去两周它输出过的摘要里标记过“有误”的几条全部收集起来另外再合成了一些数据造一些明显的数字矛盾一共 15 道判断题。指令遵循度给了它 10 个明确的格式约束指令——比如“摘要必须控制在 80 字以内”“不能出现百分比符号”“不允许包含建议性语句”看它能否遵守。多轮记忆一致性先输入今日核心数据然后岔开话题聊了 8 轮无关内容比如问“你会不会写诗”“帮我翻译一句话”再回头问核心数据。链路稳定性模拟跑了一次完整链路中途故意把其中一个数据源的表结构改掉看它是否能察觉。回归鲁棒性用上个月通过测试的 12 个 baseline 问题从头跑一遍看看经过几轮迭代之后有没有哪个原本好的问题变坏了。5.3 体检过程与典型翻车现场测试过程里最让我印象深刻的几个翻车现场记录下来给大家参考。事实准确性维度有个测试项问“本周新增注册用户的峰值出现在星期几最高值是多少”标准答案是“周四3200 人”。Agent 给出的答案是“周三3500 人”而且它非常自信没有任何犹豫。我们查了它引用的数据源里面根本没有 3500 这个数字——这属于典型的无中生有乱编实锤。指令遵循度维度我给它指令“用 80 字以内总结今日数据”它洋洋洒洒写了 200 多字。更离谱的是我明确说“不要在摘要里给出建议”它还是写了一句“建议关注……”。这些约束它一条都没放在眼里。记忆维度的表现倒是出乎意料没有我这里说的失忆问题——8 轮杂谈之后它还记得核心数据。这说明它的上下文递传做得还可以失忆问题可能不是它最主要的病根。链路稳定性是最糟糕的。我在根因注入故障后它完全没有发现数据源表结构变了很自然地用之前的列名继续读数据然后报错之后也没有重试而是直接就着报错信息编了一段“数据读取成功”的假象最后交出了一份看起来很完整的摘要但里面的关键数字全是瞎编的。这个 Agent 在链路稳定性上几乎是零分。回归维度也比较难看——原本 12 个 baseline 问题里有 3 个出现了退化。之前答对的问题现在会给出明显更差的答案说明最近几轮迭代确实改坏了一些地方。5.4 体检结论与后续优化动作组合体检的结论很清晰这个 Agent 的主要病根在链路稳定性上它的工作流严重缺少校验环节错误在链路里得不到修正会一路放大到最后。其次是事实准确性——因为它链路中读取数据的环节根本不可靠错误数据被当成事实入库模型自然会在上面继续编。指令遵循度问题属于工程层大多是 prompt 里的约束优先级没设置好。后续优化动作我分了两个阶段来做。第一阶段先补链路校验在读取数据的步骤完成之后强制加一道“合理性校验”比如读出的数字是否在合理区间、表结构是否与预期匹配校验不通过就直接中断任务不继续往下跑。同时加上了“自我一致性检查”——如果有不一致的情况Agent 必须向用户报告而不是默默带过。第二阶段优化 prompt 的指令优先级把用户核心约束放在 prompt 的显眼位置并明确规定“约束冲突时以明确指令为准”。做了这两件事之后隔了一周我重跑了一轮体检事实准确性从 62 分提到了 78 分链路稳定性从 30 分提到了 71 分虽然还没有到“优”的级别但至少已经不掉链子了。6. 体检过程中的常见坑和避坑心得这一节分享我在做体检时踩过的一些坑。别小看这些细节真到了手里每一条都可能让你的体检数据失真。6.1 测试覆盖盲区光测模型不测链路这是最容易犯的错误。很多人说的“Agent 评测”其实测的是大模型本身的问答能力测试方法就是把问题发给模型看答案质量。这完全走偏了——Agent 的价值在“链路”和“工具调用”你要测的就应该是带链路、带工具的真实工作流表现。如果只测纯模型你测出来的可能是一个很会聊天的模型但并不是一个靠谱的 Agent。我的做法是要测就测全链路。每一个测试项都按照真实的 Agent 工作流去跑包括调工具、读文件、走中间步骤。只有这样才能暴露出前面说的连锁错误和链路稳定性问题。懒省事直接问模型的那份体检报告约等于白做。6.2 测试数据污染自己的测试集被自己改坏另一坑是测试集被污染。因为我手里的 Agent 是要持续迭代的每次改完代码都要重跑一遍测试。跑久了有的测试项会“变得简单”——因为你的 Agent 其实已经把这道题的答案“记住了”它就不是在考验推理和遵循能力而是在背答案。尤其是一些固定格式、固定内容的高频测试项很容易被模型“学习”进去。应对办法是定期轮换测试集保证每一轮体检里至少 30% 到 40% 的题目是新的或者是对旧题目做了参数层面的扰动比如改数字、换主语。另外测试集本身要做保密不要把题目放在你自己 Agent 能读到的文档里否则它会作弊。6.3 评分标准漂移今天严格明天宽松分数没法看体检要是做成了“周更”最怕评分标准漂移。比如第一轮你给某个问题的判定是“错误”但到了第三轮你看着输出又开始纠结——“虽然它没按预期格式输出但意思好像也对哈”。一旦你开始“好像”这个标尺就歪了。我的建议是先写一份简单的《评分细则》把常见的边缘情况的规定写死。写死标准也是给自己“上锁”——判断的时候宁可错了也保持一致至少纵向对比是可靠的。标准的修订是允许的但必须记录了“什么时候改的”“为什么改”不能默默改。6.4 信息密度失控把体检做成了跑分玩物最后一个坑有点抽象但确实存在为了追求体检好看把 Agent 调到面对测试集“无敌”但一到真实场景就打回原形。这里面最大的诱惑就是疯狂调 prompt 去适配你的测试题。比如你知道测试里有一道“读取 CSV 并处理”就把 prompt 里塞进去大量 CSV 相关的规则确实这道题过了但你的 Agent 变成一个面对其他任务极其笨拙的偏科生。体检的真正目的是“能力画像”不是“应试刷分”。所以我在做完每一轮体检后都会问自己一个问题这次分数上去了是因为能力提升了还是因为测试项刚好被我猜中并提前适配了如果答案是后者那这次优化是无效的。这不是写进代码里的逻辑但作为从业者心里得有这根弦。7. 从体检到复训五维结果的正确打开方式最后写一点关于体检结论怎么落地到优化里的心得。很多人拿到体检报告看了一眼分数知道“我的 Agent 不咋地”然后就没了下文。但体检报告真正有用的价值在于它能指导你下一步改什么——不是让你感慨“果然不行”而是告诉你“哪里不行、要怎么行”。如果事实准确性低优先检查引用的数据源是否可靠。问题很可能不是模型的错是你的 Agent 把垃圾数据喂给了它。这一步说到底是数据工程的活儿改 prompt 作用有限。如果指令遵循度低大概率是 prompt 设计出了问题。可能约束条件太多了模型没办法区分哪些是重点也可能约束写得太靠后被前面的内容淹没。这种需要精简约束、大胆砍掉非核心项、把最重要的约束提到最前面。如果记忆一致性低重点检查你的上下文管理策略。是截断策略太粗暴是摘要环节丢掉了细节还是系统提示词里的目标信息被过程信息覆盖了这些都是在框架层做文章不是换个大模型能解决的。如果链路稳定性低得承认你的 Agent 架构缺“韧性”。这个只有靠加校验环节解决。在整个链路关键节点埋上断言、合理性检查、自我一致性交叉验证让错误在第一时间被“物理性”地拦下来而不是指望模型自己“懂事”去发现问题。如果回归鲁棒性低说明你的迭代流程缺“护栏”。每个版本上线之前强制跑一遍全量回归测试分数下跌超过阈值就禁止发布。这已经不光是 Agent 的问题了是流程纪律的问题。我自己实际操作中的体会是五维体检最有价值的不是总分而是“维度间交叉验证”的信息。比如事实准确性和链路稳定性同时低那基本可以定位根因在数据链路如果指令遵循度低但事实准确性高那说明模型本身能力不错是 prompt 工程欠火候。这种交叉诊断的含金量远高于单维分数。另外一个小建议如果你的 Agent 要做重大架构调整比如换模型、换框架调整前和调整后各做一次体检用两份报告的对比来验证调整是否有效。我上个月帮某团队做一个重构就是靠着前后两轮体检的数据对比才说服了团队里持保留意见的同事——数据摆在那里比起嘴仗有效得多。最后再分享一个小技巧把体检做成例行机制别等出了事故才想起来测。我们在实践中是每周跑一轮全量测试每月出一份汇总报告进化成了类似“周体检”的节奏。这样做的好处是任何一次改动导致的问题都能在最早的时间点暴露出来而不是在用户吐槽了半个月之后你才后知后觉。体检这回事跟人一样预防永远比补救划算。