做测试开发几年之后，我越来越觉得这个岗位的含义还是挺丰富的。同样是title测开的人 —— 有人做点点点、维护自动化用例；有人建设测试相关的基础设施；有人牵头某些指标的提升；有人就是开发团队的一员，在业务交付之外额外负责团队的质量建设。

刚毕业那会儿曾把测试开发和”写自动化脚本”划等号。自动化当然重要，但它只是结果的一部分，很多时候更关键的问题是：判断哪些风险值得被自动化覆盖，哪些链路需要前置拦截，哪些问题应该通过平台、工具、流程或者监控来降低重复成本。

质量保障不只是执行测试

过去做过一些质量体系、接口自动化、前端 E2E、数据对账、流量回放、Diff 测试之类的事情。

这些事情看起来方向不完全一样，但底层诉求差不多：尽量把质量保障从”人盯人”变成”机制和工具持续工作”。

当然，这件事也没那么理想化。工具如果离业务太远，很容易没人用；规则如果太重，也可能变成研发流程里的阻力。测试开发比较难的地方，可能就在于既要懂工程实现，又要理解业务交付节奏，还要接受很多方案只能做到阶段性有用。

我现在倾向于把测试开发理解成一种工程化、支撑型的角色：围绕质量、效率和风险，把一些重复的、不稳定的、靠经验兜底的事情，逐步变成可运行、可观察、可维护的系统。

进入下一段工作

最近一段时间，我完成了一次工作阶段的切换。

这次变化并不是在所有准备都做充分之后才发生的。回头看，有些地方可以更稳，比如提前整理作品和履历，提前看市场情况，或者采用更常见的”骑驴找马”策略。实际过程里，更多是先做出选择，再一边处理现实问题，一边重新判断自己的方向。

好在事情最后有了一个阶段性结果，也让我重新梳理了一些问题：自己接下来更想做什么，什么样的团队更适合自己，哪些成长是真正有价值的，哪些只是被业务节奏推着往前走。

目前看下来，我还是更偏向工程化、工具化、平台化的方向。比如质量平台、测试基础设施、AI Agent 评测、研发效率工具、数据质量保障。

这些方向不一定每个都很新，但都有一个共同点：并非单点解决一个问题，而是试图把某类问题变得更可控。

一些阶段性判断

AI时代工程师们人人自危，关于工作，我现在会更在意一些具体问题：通勤是否可接受，汇报线是否清楚，团队是否能正常沟通，岗位到底是在做基础设施，还是长期救火。

这不是说不看成长，也不是说只追求轻松，只是到这个阶段，我会更希望工作本身和个人状态能保持一个相对可持续的关系。

技术方向可以继续往前走，但最好不是靠长期透支来换。

至于进入职场三四年之后，应该如何看待离职、找工作的话题（也是过去几个月我亲身经历的过程），这里面还有不少细节可以单独写一篇。先按下不表，等之后再整理成一篇更完整的记录。

这些判断可能还会变。先记录一下，后面再回头看，也许能看出当时哪些想法是对的，哪些只是阶段性的感受。