无人的我们现在还在尝试。成熟的还是 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 生成技术方案同时生成对应的测试用例和去执行用例，确认代码可跑通且逻辑结果符合预期，都做得挺不错的。

比如功能测试上，因为代码都是确定性的东西，所以直接通过 步骤 - 预期结果 ，就能验证是否 ok

而 AI 则是概率性的事情，类似的内容可能换个说法，AI 的理解就会有很大偏差，人肉去测试成本很高。需要通过足量的评测集覆盖尽可能多的典型的场景 + 离线评测保障基础能力达标 + 线上持续监控优化 badcase。

我们目前基于公司基建，主要在 AI 用例生成 和 AI 用例执行 两方面实践提效，当然现阶段都没法完全自动化，AI 生成一版后还是需要人工确认和按需调整，但通过 AI 辅助确实已经很大幅度提升了效率了。

其次，如果业务有涉及 AI，最好去接触下 AI 评测，这块我觉着未来会变得很普遍。AI 评测模式上和功能测试还是有挺大差异的。

最后，比较认可 4 楼的观点，按照现在 AI 的发展速度，很快研发团队就不需要那么多人了，QA 也是类似。想办法让自己能独立创造价值，可能前途更光明一些。

恭喜当爸爸！

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

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

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

这么写才能写到简历里。