代理会写测试，但“会写”和“写得好”差在哪

消息提到，一项评测比较了26种提示条件，包括TDD、属性测试、形式化方法等，让编码代理实现Zstd，所有实现均用Rust。结果显示，没有任何条件大幅超越其他条件，而默认无额外指令的表现高于平均水平。作者还观察到，当要求代理使用特定测试技术或库时，代理往往只是把原本会写的测试放进另一种框架，或表面使用技术而未真正获得其价值。

这对求职者的启发是：代理能生成测试代码，但“会写”和“写得好”是两回事。假设同一个登录接口，一种做法是让代理生成“输入正确密码返回成功”的用例；另一种做法是让它覆盖空密码、超长输入、并发重复提交、错误次数锁定等边界。前者跑得通，后者才可能暴露真实缺陷。面试时，你可以用这类对比说明自己关注的是测试设计，而不只是测试数量。

TDD、属性测试这些技能，还值得投入吗

评测中，作者预注册的猜测之一是TDD会表现不佳，并称加入TDD条件正是因为预期它表现不好。最终这些技术被代理表面套用后，并未带来明显提升。但这恰恰说明，真正理解这些技术的人仍然稀缺。代理能把测试放进框架，却不一定知道该验证什么属性、该在哪里设断言、该用什么输入分布。

所以，把测试与验证作为长期技能方向仍然合理，但不要指望代理自动补齐。你可以先选一个方向深入，比如属性测试或变异测试，在自己的小项目里实际用一次，记录哪些缺陷是普通用例漏掉的。注意，原文未说明这些评测结果是否适用于其他编程语言或更大规模的项目，所以别把结论直接套到所有技术栈。

面试时怎么问清团队的测试实践

面试中了解团队测试流程，比背测试术语更有用。可以问：团队如何评审代理生成的测试？有没有测试质量门禁，比如覆盖率阈值或变异得分？代理在测试环节承担什么角色，是生成用例、补断言，还是只做回归？

这些问题能帮你判断团队是真正重视测试，还是把测试当走过场。如果对方只说“我们测试很全”，你可以追问一个具体场景：上次线上缺陷是怎么被测试漏掉的，后来补了什么用例。回答得越具体，说明流程越实在。

一个实际可做的小建议：下次用编码代理写代码时，先自己列出三个最可能出错的边界，再让代理生成测试，对比它漏了哪个。这个练习不需要额外工具，却能帮你在面试里讲出真实的测试判断。