老K走的那天，工位收拾得干干净净，连那盆养了两年的绿萝都没带走。茶水间有人小声说了一句"终于清净了"，我端着杯子，没接话。
三周。从AI测试工具上线到唯一的AI工程师离职，正好三周。
我是测试组的老人了，在这个团队待了六年多，见过人来人往，但这次不一样。我想把这件事写下来，不是要评判谁对谁错，只是觉得，有些东西值得我们做技术的人想一想。
01 老K来了
老K是CTO亲自挖来的，听说之前在阿里做AI测试平台。来的时候意气风发，GitHub上那个AI测试框架有800多颗星——说实话，我至今没搞明白星星多到底意味着什么，但在领导眼里，这大概就是实力的证明。
第一次组会，老K给我们展示了他的demo。
"传统的手工测试效率太低，重复劳动太多了，"他站在投影幕布前，手指在键盘上敲了几下，"我这套方案，可以把回归测试的效率提升至少3倍。"
屏幕上，AI Agent正在自动生成测试用例、自动执行、自动分析结果。界面上那些花花绿绿的图表，说实话，我没完全看懂，但CTO的眼睛是亮的。
"老K以后负责AI测试体系建设，"CTO拍了拍他的肩膀，"大家多配合。"
台下没人说话。我余光扫了一眼小张——他在组里干了四年，手工测试做得最细，Bug检出率一直排第一——他低着头刷手机，表情看不清楚。
02 第一天就出事了
老K第一天正式工作，就要求所有人把自己维护的测试用例库交上来，"我需要训练模型。"
群里安静了整整一个上午，没人回应。最后还是组长出来打了个圆场："大家整理一下，下午统一发给老K。"
小张在工位上嘟囔了一句："我这几千条用例都是踩坑踩出来的，凭什么说交就交。"声音不大，但足够让周围的人听见。
更大的问题出在第三天。
老K在群里发了一份《AI测试执行规范》，要求所有的Bug报告必须按照他定义的格式录入，否则系统无法识别。
"以后大家提Bug，描述里必须包含'预期结果'和'实际结果'的对比字段，优先级用P0-P3标注，环境信息要按模板填写。"
群里炸了。
"我们一直用的JIRA模板，为什么又要改？"
"这不是增加工作量吗？"
"格式不对AI就不认，那是人给AI打工还是AI给人打工？"
老K回复了一条："这套格式是为了让AI能准确理解问题，短期会增加一点成本，但长期来看——"
"长期？我们现在天天加班还忙不过来，哪有时间给AI整理格式。"小张直接怼了回去。
群里安静了。老K没有再回复。
03 信任，一开始就没有建立
后面的发展，其实是可以预见的。
老K写的自动化脚本，大家不愿意用。他说"让AI先跑一轮，人工只需要回归异常用例就行"，但小张他们还是全量手工跑一遍，"万一AI漏测了呢？谁负责？"
老K做的智能缺陷预测，建议"高风险模块优先测试"，但测试组认为"它推荐的区域和我们经验判断的不一样，不放心"。
有一次我路过老K工位，看见他对着屏幕发呆。屏幕上是一份测试用例覆盖率报告，数字不太好看。他大概也感觉到了，那串数字背后，不只是技术问题。
真正撕破脸是第二周的事。
老K在会上说，AI模型分析了过去一年的Bug数据，发现某个模块的缺陷率异常高，建议对这个模块的负责人进行"重点关注"。
那个模块是小张负责的。
小张当场就站起来了："你一个来了不到半个月的人，拿个机器跑出来的数据说我做得不好？你知道那个模块为什么Bug多吗？那是历史遗留的老代码，需求天天变，我顶着压力扛了一年多，你懂什么？"
会议室安静得能听到空调的声音。
老K张了张嘴，想解释，但最终什么都没说。
04 技术逻辑 vs. 人情逻辑
站在老K的角度，他其实没做错什么。
他是被请来解决"测试效率低下"这个问题的。他带着技术方案来，满脑子都是准确率、召回率、覆盖率这些指标。在他的逻辑里，流程不规范就改流程，数据不标准就定标准，人员能力跟不上就培训——一切都可以被算法优化。
但他忽略了一件事：这个团队不是由算法组成的，是由活生生的人组成的。
这些人在这里干了五年、八年，他们有自己熟悉的工作习惯，有靠经验积累起来的"隐性知识"，有彼此之间心照不宣的默契。更重要的是，他们对自己的工作有感情——那些被说成"低效"的手工测试，是他们一遍一遍跑出来的；那些被要求"格式化"的测试用例，是他们踩过的坑、背过的锅换来的。
老K要改变这一切，又没给足够的时间让大家理解和接受——甚至没有真正让大家感觉"被理解"——冲突就不可避免。
这本来是个变革管理的经典命题。但我觉得，对老K来说，更根本的问题在于：我们这一行，往往太相信技术的逻辑，而低估了人的逻辑。技术思维是线性的、可量化的、可优化的——问题是，人不是。
05 最后一根稻草
第三周，周五。老K提了离职。
听HR说，离职面谈的时候，他只说了一句："我可能不太适合这里。"
没有抱怨，没有指责。就那一句话。
那天晚上，我一个人留在办公室加班。路过老K的工位，已经空了。显示器没了，键盘没了，那盆绿萝也没了。我忽然想起第一天他来的时候，带了六包挂耳咖啡放在抽屉里，笑呵呵地说"以后加班用得着"。
六包咖啡，一包都没喝完。
06 我学到的一些事
老K走了，AI测试工具还在运行，但没人主动去维护了。偶尔有人用一下，更多的时候，它像个摆设。CTO最近没再过问这个事——估计在琢磨下一个"降本增效"的办法。
我不是想讲一个"谁对谁错"的故事。我只是觉得，如果我们真心想让AI改变软件测试这个行业，有些事可能需要重新想一想。
第一，技术落地的起点，往往是组织问题，而不是技术问题。 很多人觉得引入AI的难点在于算法够不够先进、模型够不够准，但实际最大的难点往往很简单：一个七八年的老团队，为什么要在意一个刚来的人说"你的工作可以被替代"？——这个问题，靠技术解决不了。你得先回答它，再谈技术。
第二，变革需要翻译者，而不只是技术专家。 老K缺一个帮他"翻译"的人——把"训练模型需要数据"翻译成"大家一起构建团队的知识资产"，把"AI优先推荐高风险区域"翻译成"让AI先帮你探探路，你来做最终判断"。同样的话，换一种说法，味道完全不同。这个人可以是HR，可以是团队里资深的老人，也可以是老K自己——如果他意识到这个角色需要扮演的话。
第三，不要动了别人的奶酪，却只画了一张大饼。 老K其实挺冤的，降本增效是领导定的调子，但在一线同事听来，降的本就是他们的经验积累，增的效意味着他们可能被优化。谁都清楚，工具只是第一步，下一步就是裁人——哪怕你嘴上不说，大家也都明白。如果你想让团队接纳新东西，可能得先让大家明白：这对"我"有什么好处？"我"的角色会变成什么？而不是只对领导说有效。
第四，谦逊不是软弱，是策略。 后来我想，如果老K来的第一周没有立刻推规范、上流程，而是先请大家吃顿饭，坐下来聊一聊，听听大家平时最头疼的是什么——那结果可能完全不一样。不是说技术上要妥协，而是在做事的方式上，可以更聪明一点。
第五，一线技术人最需要的，往往不是"被优化"，而是"被看见"。 小张为什么反应那么大？不全是因为AI威胁到了他的工作。更深的原因是，他在这个模块上死磕了一年多，需求变来变去他扛着，历史债务他顶着，结果新人带着工具来了，拿数据说"这里有问题"——他感受到的不是技术挑战，是过去所有的付出被否定了。很多时候你推不动一件事，不是你的逻辑不对，而是你没有接住对方的情绪。
07
写到最后，想说一句可能不太中听的话。
这年头，降本增效是大趋势，AI确实能帮测试团队解决不少重复劳动的问题。但是——
工具替代的是动作，替代不了信任；优化的是流程，优化不了人心。
下次再有机会引入AI工具，我希望有人能先花两周，不是让算法跑起来，而是让人坐下来。
那六包挂耳咖啡的味道，我至今不知道。但我知道，有些东西比咖啡更苦。
（本文来自一位不愿具名的测试团队老员工的投稿，以第一人称整理发布。如果你也在经历技术变革中的阵痛，欢迎在评论区聊聊。）
关于我们
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
