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

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

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

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

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

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

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

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

再给一些建议，改完之后的版本，在简历中还是处于 “写得差” 的段位。

1. 专业技能就只体现技能，不要把工作数据收益混在里头（如第 6 点），显得很没逻辑
2. 第 1、2、3、4、5、8 这些点实话说，基本都是通识基础要求，单独写出来也没什么实质性内容，建议直接合并为一到两个点。比如我问，你白盒测试有什么技巧，或者就直接问你 Spring 框架的一些工程实现，能答得上来吗？

问题 & 建议

1. 开篇的专业技能非常震撼，极度啰嗦凑字数，有效信息极少 —— 写得长不是加分项，是减分项；同类项合并，每一个点控制在一行或一行出头，点控制在 10 个之内，最好 5 个内。【为什么是 10 个/5 个，为什么是一行，就是格式舒服与信息量的权衡，无科学依据】
2. 项目细节，也是极致体现 “极繁” 论述的风格 —— 显而易见大家懂的都懂的东西就不用写，写出来反而是凑字数嫌疑，显得没料。如【从 0 到 1 建设自动化测试体系并接入 CI 门禁：接口自动化覆盖元数据/发布/权限/数据元等……】，修改打样：

从 0 到 1 建设自动化与 CI 门禁：接口自动化 300+ 用例覆盖 xx% 核心功能，UI 自动化 30+ 用例覆盖 xx 核心链路；CI 接入自动化，回归周期 5 天->3 天，回归人力 10 人日->7 人日。

其他的，如此类推，是有技巧的。

1. 关键收益数据要通过格式凸显，不要和冗长的文字糅杂在一起，别人很难找
2. 太业务的细节，留到面试再聊，往简历上堆叠是总结能力欠缺或没料的表现
3. 行业通识的东西，就不要复杂化，大家都理解，别把面试官当傻子
4. 内容量不是关键，第一要义是让别人看简历觉得很舒服，一下子抓到要点，可以给你打上你想要的标签
5. 最后，无论是什么级别的人，简历最好控制在 2 页内（特殊 case 另说）

我们组的思路是在研发自测大背景下，帮助研发自测得更快更好。

1. 对于已有的用例，从不同类型的风险视角，评估哪些用例要留下，哪些可以去掉
2. 结合现有的各种自动化、监控报警、专项兜底，第 1 步中留下的用例，是不是还能进一步删减
3. 最后剩下的少量用例，是否除了执行本身外，还需要关联去建设自动化、监控报警、专项兜底等，给出执行和建设引导

上面是用例评估的，结合用例生成，自测留痕、bug 验证，就都闭环在一个质量平台下了，最后结论是 QA 自己把自己干掉

https://testerhome.com/topics/43564

非常的广告