字节还是舍得给钱，经典互联网模式，早期干啥都是不计成本先圈流量用户

后面我发个 spec coding 的分享

测开现在算是一条不归路，在 AI 下代码技能和熟练度逐渐变得不关键，关键是发现问题的经验、落实执行力、架构设计能力，在业务方向会越来越有优势。

毕竟以后 AI 把研发需求都卷完了，研发就该来卷测试工具了，测开是 100% 被研发卷到的。

建议还是找业务方向为主，面试时可以把搞过测开方向为优势去切入。

我其实更想看第三个命题【命题三：源于 “生产者” 的质变——用 AI 编写的软件系统如何测试】

这类垃圾邮件很早很早以前就有了，真可谓海量捞鱼

如果要用户体验好，肯定得和目标系统耦合在一起，不一定是什么前端，可能就直接是后端把 ai 整合在一起调用了。

【这整个搭建过程复杂吗？一个人再通过 AI 大概多久能完成呢？】这个问题太 case by case 了，没法回答

写简历要点其实不是极繁，而是极简（前面很多网友都是一样的反馈 “太长看不下去”）。
如果不得不凑字数，也要凑些有价值的能聊清楚的内容，不然就自己给面试的时候挖坑了。

不是的，在某个 AI 聊天框上的问答模式显然没法满足，体验割裂的同时也没有上下文一说。都是通过 api_key 调模型接口的。然后固定好提示词，以及一些业务资产的输入。

是的是的，一看就是有真实践的哥们。

确实除了业务知识库，业务的一切资产也是尽量精简一些喂给 AI，包括业务代码、业务配置、业务文档等。

这里面比较蛋疼的是，往往很多东西都跟公司内部平台绑定，很多概念性的东旭需要让 AI 先知道；另外发展快的业务用起来确实极差，目前相对更适合迭代成熟，需求偏向在原有功能上改的类型（而不是起全新功能的需求）

测试分析和测试用例做绝对没错，但是很需要足够的知识库和上下文，不能让 AI 太发散，范围要约束好（第一个坑就是上来就让 AI 对通用需求提供通用用例，应该是具体某方向的需求提供某些具体维度用例）。我们内部也有实践，虽然也是效果很差，但我判断是提示语设定的 AI 工作目标太发散 & 业务知识库匮乏的原因。这些短板慢慢补上去之后，肯定会越来越好。