研发效能/测试基础设施方向平时到底在解决什么问题？

消息提到，很多公司大规模用上 Coding Agent 以后，都开始遇到一个问题：代码写得越来越快，CI 快扛不住了。素材里还提到一个具体案例：Anthropic 工程师每季度交付的代码量是过去几年的 8 倍，其中 80% 由 Claude 完成；代码多了，测试数量涨了 10 倍，半年时间 CI 任务量增加了 25 倍。

这些数字属于该案例的公开说法，不能直接套到其他公司。但它指出的方向值得求职者注意：当写代码这一环变快，压力会转移到 Review、测试、构建、发布这些环节。研发效能和测试基础设施岗位要处理的，正是这类“上游提速、下游堵住”的问题。

这类岗位的日常不是写业务功能，而是让整条链路在代码变多之后仍然可控。具体工作可能包括：判断一次改动该跑哪些测试、维护测试环境与流水线、梳理测试技术、推动问题闭环。它需要你愿意长期和流程、工具、跨团队协作打交道，而不是只对某个业务模块感兴趣。

判断自己适不适合，可以问自己三个问题：看到重复的手工步骤，你是想绕过去还是想把它自动化；面对“测试太慢”这类模糊抱怨，你愿不愿意拆成可验证的环节；当你的工具被别的团队使用时，你能不能接受需求来自别人而不是自己。

面试这类团队时，怎么问清他们的真实工作方式？

素材里有一个细节很适合拿来设计提问：Anthropic 有一套服务，一边记录历史测试结果，一边判断这次改动应该跑哪些测试。这是两件事，记录端在每秒多个 CI 任务进来时会追不上。

面试时，与其问“你们用什么技术栈”，不如问这几个问题：

  • 你们怎么判断一次改动该跑哪些测试？是规则、历史数据，还是人工指定？
  • 记录测试结果和判断该跑什么，是同一个系统还是分开的？哪一端更容易成为瓶颈？
  • 当测试选择出错、漏跑了该跑的用例，责任怎么划分，谁来兜底？
  • 团队最近一次重做原有流程是什么时候，触发原因是什么？

这些问题能帮你判断：团队是在真正处理链路问题，还是只是把工具名字挂在招聘描述里。如果对方只能回答“我们很重视效率”，却说不清一次改动如何被验证，那这份工作可能和你的预期有差距。

如果团队正在经历类似变化，求职者该关注什么信号？

素材提到，补丁先后撑了 70 天、29 天、不到一天，最后重新设计整个服务。这个变化节奏说明：当上游代码量持续放大，原有方案可能很快失效，团队需要不断重算流程，而不是一次改造就结束。

对求职者来说，值得关注的信号不是“他们用了什么工具”，而是：团队是否在重算原有流程，是否有跨环节协作机制，出问题时是单点背锅还是共同定位。你可以问：最近半年，你们推翻过哪些原来的做法？谁提出来的？改完之后怎么验证有效？

需要提醒的是，素材没有说明 Anthropic 是否因此新增或调整了相关岗位与招聘要求，也没有说明其他公司是否会出现同样的量级变化。所以不要把“CI 压力变大”直接等同于“这类岗位一定扩招”。更稳妥的做法是：在面试中核实目标团队当前是否真的在处理这类问题，以及他们希望你进来先解决什么。

一个实际可做的小建议：挑一个你熟悉的项目，写下“如果代码量突然涨 10 倍，哪一步会先撑不住”，带着这个答案去面试，比背工具清单更能帮你判断自己和团队是否匹配。