认真你就输了，都是拉人头赚邀请码的 200 元钱的，空手套白狼，比真做事来钱快多了

以前不是，现在嘛，互相敌对，测试干开发，开发干测试，成了竞争关系。

我们现在也没有量化出价值，所以我们没免费的 AI 用。目前也在摸索着，自费 tokens 我不提倡，所以一直是自己偷偷用。但是会告诉领导，有无限 token 且能拿到开发源码，可以干很多事情。
目前能摸索的也有限：
测试左移：我们没有需求评审、用例评审、技术评审流程，测试左移只能到编码阶段，只要拿到开发源码，隐藏风险和潜在崩溃问题可以在编码阶段开始排除，测试阶段压力会小一些；
性能测试分析以及性能调优：以前只出报告，分析的也不那么准确，现在用 AI 能准确分析原因和期望调优方向；
项目知识库、工业、工程施工规范 RAG：当时喂了几个 G 的数据，包含工业工程施工规范的相关专业知识。写工业软件、工程施工相关的测试用例时会首先找这些专业知识，然后生成实际施工、运行需要的测试场景，还能提供给项目实施团队验收用例；
业务场景的接口自动化：只跑业务流转相关的接口，在回归阶段挺好用；
各种提效工具：结合自身公司痛点针对性的做的一些工具，用着还行、且自费不多，所以公网部署了一版，其他人在用着，目前公司 4 个测试，文档生成类调用数据有 100 多次，文档转换类调用有 70 多次，SQL 生成类调用有 40 多次；
提效工具这个是目前唯一落地了的（维护便宜、免费用且确实省时间），以前人工时总是会占 2 天左右的测试时间去写各种文档、材料，现在在前置条件满足的情况下 20~30 分钟搞定，现在同样的任务排期，测试可以多 2 天摸鱼时间。

观点一致的，会与不会 AI 不是裁员硬性指标，但是用错了 AI 与完全拒绝 AI 结果一样会被裁，还是要把 AI 正确的放在解决公司的问题上，能解决公司看得见的问题，能带来领导看得见的效率提升，怎么会裁你，裁了不就裁到大动脉了？很多说 AI 无用论的，估计大部分都是用来写文档、写用例、写平台。这完全是用杀猪刀杀蚊子蟑螂呀

站在效率的视角下，用 AI 的干的多比拒绝 AI，干得少的人要干的长久这个是没毛病的，飞哥毕竟经历过。大厂需要的就是要这种胡乱折腾的人，保不准哪天真出了一个精品，可以要到很多钱。但拒绝用 AI 顶多算是裁员次要原因，常见的裁员原因 AI 不是主因，顶多算次要原因，把 AI 跟裁员强绑定属于是公司不负责任的甩锅，裁员无非这么几个原因：
第一个原因：这个部门长期赚不到钱还烧钱最厉害，首先被连锅端，跟技术不技术无关，最很的都是整个部门一起干掉。
第二个原因：这个部门不算很重要，增量到了瓶颈，留下最重要的几个人维护就行，这个时候就符合飞哥的这篇文章的说法，一个人能干 5 个人的事的，那就留下来了。
第三个原因：别的部门都在裁，你们部门不得跟着裁几个，免得被说领导不一碗水端平，这个时候跟领导关系处不好的，就上了裁员名单，技术再好不捧领导这些全没用。
第四个原因：招你进来了，薪资要的高，但是具备的专业度、领域深度实在是不符合这个薪资区间的该有能力，如果有合适的，就换了，免得带来更大损失。不会用技术解决实际业务中的问题，只能干那种基础的写测试用例、写工具、搞自动化平台等等，那花这么高的价格请你来做啥？
第五个原因：中小公司最常见。不是很赚钱，只够养活公司和养家糊口，那些薪资高的成本部门，员工该砍还是要砍，负责核心项目的人，是稳的。跟领导关系相处的好的人，他也稳，裁员时，领导会让他负责核心项目，并且指导他提高技术能力。其他的都是可以砍的目标。
裁员优先级：本职工作能力差 > 跟领导相处不行 > 薪资高 > 技术好&&能力强 > 薪资低 > 跟领导关系相处的好 > 关系户。
我提交过的裁员名单是第一个原因，我自己上过的名单是第五个原因，我现在这个公司其他被裁的人是：第二个和第三个原因。
个人觉得：
拥抱 AI 是可以让我早点干完活下班、被裁可以优先找到工作、可以利用 AI 赚点额外收入，而不是拥抱 AI 我就能不被裁。
裁员不会考虑会不会用 AI，只会考虑能不能用 AI 真正解决领导焦头烂额的问题、用 AI 能不能给公司省钱的问题，如果用 AI 造成成本支出高了，成本高出的部分没带来额外的收入，要么不报销 AI 使用费用（我们就是 AI 钱用了，结果没给公司带来实质性收益），要么 AI+ 到业务本身。

不要看 BOSS，BOSS 上销售都能月薪 15K~20，看脉脉、猎聘、去爱企查上看看各个嵌入式公司的薪资水平

感觉 AI 赋能测试发展下去，最理想的模式还是 AI 基于需求文档生成功能用例，人再基于已有的功能用例上补充面向经验的用例：例如怎么测试这个功能是否是符合客户的要求？用户可能会怎么使用？是否遵守同类软件的用户使用习惯？有没有其他需要补充的非功能用例？然后交给 AI 去执行基于需求文档生成的功能用例，人工进行面向经验的探索性测试和补充用例的测试。
目前我司开发的 AIcoding 各不相同。
编程习惯好、能力强的开发，都会拉上产品过一遍产品的需求文档，使用 AIcoding 前，都会准备好对接后的功能交互图、函数命名规则、各个方法的注释、技术文档、甚至还有功能实现的代码样例，然后交给 AI 去照葫芦画瓢，产出的代码就很好，问题也没多到离谱、功能实现度 65% 以上，产出还快。
编程习惯差且水货开发，直接把需求文档、功能交互图直接就扔给 AIcoding 去生成项目了，也不问下需求文档有哪些功能、思考下他要怎么实现，产出的代码功能实现度 50% 不到，很多不需要的功能都没有移除，问题较之前多了 3 倍，产出是快了，但是测试阶段、改 BUG、补功能、删功能入口的时间比功能实现时间至少多 2 倍。

自动生成用例没啥难的，好的基座模型 + 质量高的需求文档 + 质量还行的源码 + 业务知识库 + 历史测试用例 + 测试用例设计规范提示词即可。

说的好像 agent 测开 35 不被裁一样，越是热门赛道年龄越大越不利。