写代码也是测试的能力呀，写自动化代码，或者按需去生成一些测试脚本乃至一些造数平台，都是测试领域的。不见得都是开发

我是看到你前面提的是写代码，所以顺着问。我一般校招 ai 相关看 2 块，一块是有没有用 ai 去具体做某个事情，并有一些技巧沉淀；另一个块是有没有了解或者做过比较专业的 AI 评测（我们这里有基于应用场景的一些 AI 评测的需要）。不过不同岗位要求不一样，建议还是先去多面一下吧。

这里有具体实践案例么？比如用 ai 完成某个具体的模块/功能，并且在里面通过某些技巧让 AI 生成的效果更优之类的。

这么写才能写到简历里。

恭喜恭喜！

看着 AI 已经把你的问题总结得很好了，但不知道你自己是否认可？如果认可的话，建议可以先基于 AI 给的建议去优化下自己面试时回答问题的方式，显得更专业一些。不认可的话，可以补充更多信息说明。

另外，这个只是一场面试，一场不一定代表全部，不用为此就觉得焦虑受挫。建议多去面一下，每次面完做一下总结，总结自己表现好的点，以及需要改进的点。每次改进里面 1-2 点，持续迭代，熟练后你会越来越有自信。

如果有机会，强烈建议你去实习下，实际工作锻炼带来的能力提升，会比你 “系统学习” 来的更直接有效。

PS：不知道你现在对 AI 的了解如何，自己实际写代码等有没有用 AI？现在是 AI 的浪潮，有这方面经验或者比较深入的了解，会是个很大的加分项。

前提：既要做开发的工作，也要做产品的工作，公司给与一定的培养缓冲时间，并且开发的工作肯定会做适度调整

想问个问题：开发和产品的工作都要做，那最后打绩效的实线 Leader 是开发还是产品？

单纯从这个描述看，不像是真的让你长期往产品走，只是找个人能兼顾一定产品的活，减少人力缺口。毕竟真正要做好产品的工作，和业务、研发的沟通是少不了的，会非常占据时间。这个基础上还得兼顾开发的工作，两边都得做好，非常非常难。

最后可能变成两边都半桶水，产品部分只能做一些相对简单的工作，开发部分也只能作为非主力协助，没有了自己的核心竞争力。

个人判断是，如果本身有意愿长期转产品的，是个契机，借这个机会入门产品，然后再跳到其他纯产品岗，且自己可以以 “有开发经验” 来作为自己的一个亮点。
但如果没有想长期转产品的意愿，只是想多学技能，那不大建议，长期容易两边都没亮点业绩，评绩效产出啥的很尴尬。

第二种的话，尝鲜可以，要做到收益会比较难。

这里一般有 2 种做法：

• 第一种就是我前面提到的，生成自动化代码。但生成后的代码还需要人去调试修正，且还是得要有代码基础的。用 trae 之类的 AI 代码编辑器就可以做。

• 第二种是 AI 自主执行，相当于基于你给的一句话或一条用例，自行去尝试执行你的用例，并进行校验。这个今年 MTSC 有一些相关议题分享，需要做 3 个子 agent。
  一个基于应用地图（类似于知识库）做路径规划，把你的 新建工单 转换为 到 xx 页面点击 xx 按钮 ；
  一个做动作执行，操作浏览器/app，识别界面内容，找到要操作的控件进行操作。这块也许有现成的 MCP 工具可以直接使用。
  一个做实时纠正，发现找不到想要操作的控件时，自行想招去解决

个人建议，可以尝试第二种，做个 demo 让老板看看，交个差还是可以的。
但要提效，这个会很难，一个是不稳定（可能第一次跑成功，第二次失败，第三次又成功；而且可能因为自行扩展的检查点不够细致，可能有些 bug 会被放过）；一个是跑得慢（截图、AI 思考都需要时间，比人执行要慢不少）；还有一个是成本高（token 消耗如流水）。至少以现阶段的 AI 能力，个人觉得用外包会比用这个更香。

从一般的 AI 结合测试且产出会比较有保障的角度，有几个方向：
1、AI 基于需求文档生成测试用例
2、AI 基于测试用例，生成自动化测试代码

考虑到你们组内没代码基础，建议可以先尝试第一个，做 demo 尝试啥的比较容易，纯调整提示词就可以，你们也比较好辨别结果是否合适。不过要提高准确率啥的，得弄 RAG，并规范需求文档格式，否则 AI 很容易幻觉或者看不懂需求内容。

不知道你这个 “工具” 是用来干啥的，建议先和领导确认清楚？领导不一定知道具体工具怎么做，但应该至少能说明为啥要做这个工具。

有几个可能的方向，供参考：

1. 解决没有联动 app 打包后自动执行，研发没感觉。那用 jenkins 就好了，app 打包后触发脚本运行，并运行结束后自动发报告。界面想要好看，也可以自己弄个前端界面包一下，背后调用 jenkins api 来触发任务。

2. 解决现在用例数量增加后，每个用例都是面条代码难以维护问题。那可以看看 page object，代码里做一下封装。（但也看 roi，封装不好可能比面条代码还难维护）

3. 解决想让大部分测试人员去写自动化，但他们不会写代码的问题。这个工作量就比较大了，建议直接调研比较流行的开源 app 自动化平台，选一个内部落地和二次开发好了。

相比于自动生成，我觉着自动分析自动化失败原因，并能自行提交 MR 进行维护优化，这个用处更大。

自动化长期跑起来，维护和解决误报，这个才是日常投入最多的，尤其是 UI 自动化。

看着你这个报错不像是 python 自身报错，像是服务器 response 本身报错

你先抓个包，看看请求服务器的参数和你现在用脚本请求的参数，格式和内容是否一致？