我一般就看关注的人的内容，其它随缘

换赛道的话，建议换个新行业，或者说风口行业，老人新人都得重新积累经验的这类，这样才容易进入，且能再干很多年。比如 AI 行业、机器人行业这些

软件测试这个算是个很成熟的行业了，而且受 AI 冲击很厉害，你现在进入会很难，而且就算进来了，也未必能干很长久（非个人能力，主要是整个行业的变化）。

之前做运营的话，不妨可以看看，有没有啥运营能力 + 现在 AI 能力，能产生更大收益的事情？比如结合 AI 做自媒体运营这类？现在很流行的新岗位 FDE，本质也是把 AI 能力结合到某个行业/岗位里赋能，产生价值，获得收入。

有变化，我司在逐步 QA 转 RD 序列了

我用起来，大模型对于计算类的确实不是强项，很容易捏造数据。

日常涉及量化数据的，我都会让 ai 要生成脚本计算。不过近期看豆包之类的涉及统计的，思考过程就会自动通过写代码来统计，而不是自己去想。

另外，也可以 skill 里通过多个子 agent 配合干活来解决（比如一个干活，一个检查）。trae 之类的貌似支持 skill 里有多个子 agent，支持多个子 agent 上下文不共享来解决前面说的给同一个 agent 检查，会结合前面上下文引起幻觉的问题。

学习了，点赞！

无人的我们现在还在尝试。成熟的还是 AI 辅助研发写代码、AI 辅助测试写用例和执行用例。

1、你这个本质是怎么触发的问题。可以弄个提测单之类的东西，让开发提测时提交，里面把所有需要的信息带上就好了。如果禅道里本身有配置状态这类信息的话，也可以通过推进到测试状态来触发，然后推进的时候要求填提测分支。至于说要打开 cursor 输入指令这个，你可以看看一些 CLI 命令行工具，比如 claude cli，这样你通过代码就可以调用，或者弄个 skill 给 AI 自己去调用。

2、这个找到合适的 skill 来做。后端接口其实 AI 能读到源码基本就可以生成，前端的话可以试试基于 PRD 或者设计稿来生成（前端的没试过，纯思路）

3、测试环境隔离这个听着是基建要做的，和 AI 没啥关系吧？一般会通过泳道标识 + 流量隔离来做。数据准备自动化，这个要看具体场景了，不过如果不复杂，可以直接在你的测试用例里把这些步骤带上，就不用特别处理了。

提个建议：专业技能要和后面的工作经历相匹配。如果没法匹配的，或者自己自评觉得其实不算很强的，不大建议写，或者在末尾补充，但不要放到简历开头最显眼位置。

简历不是写得越多越好，而是越匹配越好。比如你这里写的第 9 点大模型/Agent 评估体系，如果后面工作经历里没有具体项目体现，或者确实没有实际在项目落过地，不建议写到这么显眼的位置。

这种一般两个路径

一个是反推提升 PRD 质量，把这些涉及的历史能力也说清楚。不过比较难，毕竟增加产品工作量，且对产品来说价值不大。
一个是建立知识库，让 AI 生成用例时，也通过 RAG 到知识库查看相关的知识（历史 PRD、历史用例等），进行补充完善。这个主要难点在于知识库的及时维护和召回内容准确度。

是的，这些点提效都很明显。我们现在用例编写基本都是 AI 先生成，然后再人肉 review 调整，甚至调整也是借助 AI 去批量调整，而不是直接上手改。

测试执行很多时候涉及具体环境、上下游等，以及过程中可能有些需求变更、操作体验啥的前期用例没法覆盖的，暂时还没有很完善的方案。

不过如果是研发自测程度的测试执行，现在其实已经能做得很不错了。我自己写一些平台功能，让 AI 生成技术方案同时生成对应的测试用例和去执行用例，确认代码可跑通且逻辑结果符合预期，都做得挺不错的。