替代外包的方式，你去看下孙高飞的文章吧，里面说的很清楚详细了。高飞测沙箱都不是手来操作了，也没有外包来测试，你可以从这个角度来思考下。

你也留个 bug 半夜 call 他

说说为什么字节现在还有 QA/外包吧：

1. 决策层应该是 100% 知道这个事实，但是希望无痛过渡，一刀切不可取。
2. 字节内部的大模型还不够，用国外模型确实能搞定，但是国外大模型成本较高（比招个外包差不了多少），也有数据安全风险。国内大模型比如 deepseek 预计还有不到半年的窗口期，半年以内 deepseek（豆包可能得一年）会成熟到可行。
3. 字节内部的代码权限屏障太硬，代码数量极其庞大，历史业务很多没落盘或者找不全了，boe 环境还有提升空间，历史包袱太重，都换成 AI 需要时间，需要人整理。
4. 纯 AI 后预计还有 10% 的核心用例（操作简单，UI 用例为主）还需要人来点，纯执行留极少部分人无伤大雅。

他给加班费吗？24 小时 on call？

you want,you can, you do,then nothing......

建议别裸奔，除非提前找到下架了

何必跟傻子计较呢，不鸟他就行了

跟开发搞好关系，想想办法干他一炮

AI 怎么替代外包的？展开讲讲

我这里是小公司，只有 2 个测试，每个项目的测试时间都很短，开发测试的时间占比大概是 1/10，但是老板在推 AI 测试，他们的想法很简单，写了测试用例，交给 AI 来执行就可以了，人来核对测试报告就可以了，但个人实现下来不现实。

实践下来发现，AI 是可以根据用例来执行测试的，UI 测试、接口测试都能进行。但是能发现的问题很局限，一些数据核对的用例执行效果比较好。但牵扯到一些业务逻辑或流程场景时就不行了，一个原因就是用例写的就是开放性的结果，不会写的很明确（比如会写有合适的错误提示信息，不会具体什么信息），还有一些就是页面报错或者接口 200 但结果错误的，这些也不能发现。有些甚至用例明确写了错误结果也出现了，AI 愣是识别不到，就很奇怪，不知道你们遇见过没。
而这些都需要人来介入进行调试才行。

个人对目前 AI 测试的理解是：AI 测试其实就是 AI 编写了一套自动化测试的脚本，手工调试测试结果或场景其实就是在使用 AI 来调试自动化测试脚本，底层还是使用自动化测试脚本来进行测试。

但对小公司、项目快速切换的情景下，基本就没什么项目积累，项目上线后很快就进入其他项目了，自动化这一套很难用。