最近工作中使用 AI 工具越来越多了，工作方式也就是这样潜移默化的改变的
除了提问、文档处理及流程使用大模型对话和内部工具接入的 MCP 和 Skill，测试执行上也发生了一些转变
说 AI 时代，如果没有来得及学习新技术就不用学了，因为技术一直在推陈出新，感觉也没啥问题，但是一些工具的使用，显而易见是必须掌握的
分两个部分说一下吧，一块是需求、设计、测分阶段，目前感觉来说，人还是最关键的，做主要的判断作用
大模型无法一下子将项目和自身融合的那么深，仍然需要人做判断，决定走向
开发难受
开发了解需要后进行设计，没有深入了解需求，进行设计实现，最后出来的东西有问题竟然无法解决
完全靠 AI 进行 vibe-coding 的产品无法使用，有问题无法修复，这里可能是开发没有工程化是使用 ai 编程工具，也可能是没有想好就进行了开发
开发新接收了这个需求，没有彻底了解系统架构，无法描述对应的问题点，让 AI 编程工具去工作
甚至可能因为错误的理解误导 AI，导致编码的内容实际是有问题的
最终是导致需求的延期，相关代码全部回滚
在当前情况下，以人为主体驱动的研发活动中，人依然需要对需求进行深入理解才能更好的使用 AI 工具，在很多关键节点进行判断
特别是一些比较复杂的场景，能够平价使用的 AI 模型并不能很好的解决问题，还是需要人进行引导
测试难受
测试在研发活动中也在使用 AI 工具，在需求分析、测试分析、测试执行阶段都有不同的场景
但和研发一样的困境，作为人你还是需要了解这个需求以及开发实现细节，不然无法对 AI 生成的内容进行判断
你需要指挥，对 AI 生成的内容进行评价，缺少的测试内容需要补充，冗余的测试内容需要精简
看了一些团队的分享，使用 AI 工具后，工作量并没有变少，而是转移了，到了其他部分需要投入大量的精力
当然 Agent 出来以后，以及出圈的 skill、mcp 确实给人的工作体验好了很多，但是解决 AI 犯的错也是我们必须要付出的代价
我今年才开始接触 agent 的 cli 工具，最开始使用的 claude code 和 qwen cli，当时体验的感觉就是，确实很牛逼，但是自己用起来感觉很无力
自己无法精准表达自己的意思，让 AI 去干活，但是也有 AI 模型没那么聪明的原因吧，哈哈
MCP 很早就出来了，之前也学习过，但是感觉就是很重，个人平时基本不会使用，这种 cs 的架构方式限制比较多
SKILL 很好的弥补了这些问题，比较轻量，渐进式批量也不会烧太多的 token
很多 agent 工具的特性也是这时候学习的，我感觉这个是 AI 时代必须去学习的，各家的编程 Agent 工具大同小异，互相抄过抄去，特别是 cc 之前源码泄露了
也有接触 codex app，代码审批的功能是开发比较心动的，以及多项目多对话界面管理挺不错
但是人对于多个任务的处理还是有点困难的，反正我开太多命令窗口玩不转，开三个窗口工作差不多了
之前是针对已有的自动化测试代码写了一些 skill 去生成代码和用例，但是整体流程是脱节的，生成的采纳率也不高，或多或少有问题
但已经比之前快很多了，对于单接口的测试用例生成已经很快了，但对于复杂组合接口的用例生成，还是需要我进行接口逻辑关系的说明
也是这一块最花时间的，也尝试如何用 AI 去提效，但最终还是需要自己去检查生成的测试代码，是否真正的验证到了功能
另一块是自己的工作和一些尝试
工程化的尝试
踩坑是必不可少的，去做使用一些东西，就是需要花费自己的时间去投入，从学习 agent 的产品特性，了解基础的使用
到一些新概念的接触、了解、接纳、使用，还是需要去实践、踩坑
之前了解了像 openspec，supperpower、spec-kit 这些插件，只是想到可以用到开发的研发过程中，但实际是通用的
拿 openspec 举例，之前了解以后没有去使用，感觉和测试没啥关系，但是实际尝试使用后发现，比直接去使用 skill 和大量自然语言以及文档描述
这些已经实现的工程化链路更有效，你可以继续开发生成你业务垂于的 skill，但工作的流程可以更加规范。
首先我们需要安装 openspec，在自己的项目 init 它
openspec init
init 命令行会让你选择对应的 agent 工具，我们选择 Claude code 即可，初始化成功以后当前项目目录就会多一个 openspec 目录记录你的提案
这些记录的提案会成为你项目的参考资料
然后 cc 启动，通过/opsx:explore 描述你的需求、目的，开始一个标准化的流程
这样你讨论的内容都会被记录下来，可以是你的想法，可以是 AI 的建议，最终目的是明确你的目标、任务、以及相关的细节
/opsx:explore xxx
当你觉得和 AI 讨论得差不多时，就可以生成一个提案了
/opsx:propose
AI 工具就开始工作，生产对应的 spec，自动根据任务复杂程度做拆分
你可以检查项目下 openspec 的具体提案内容，让 AI 进行优化修改，感觉没有问题就可以 apply 了
/opsx:apply
ai 开始安装这个提案开始工作，这时候可以去干其他事情了
完成后，我一般会自己去验收一下，或者在 propose 的时候就告诉它如何做验收
没有问题就可以执行 archive
/opsx:archive
归档这个提案
整体流程并不复杂，而且对比之前比较杂乱的方式一下就更清晰了，也能回归之前的提案，即使/new 了新的对话也无所谓
我最近的测试执行过程中就是这样测试和编写测试脚本的，整体工作体验比之前好很多
之前的工作中测试执行和编写自动化是割裂的，但现在感觉完全可以融合了，AI 干活我可以去进行一些探索性的测试
感觉自己的能力边界也扩展了不少
当还有很多类似的插件，supperpower 的工作流命令更多，这里就不废话了
spec-kit 还没来得及了解去使用，应该也是很不错的
说到这里大概就一些测试角度是使用 AI 的体验了，可能比较局限，希望对你有用
题外话
使用 AI 避免不了一个问题是大模型服务的调用，这个也分两块说，工作内和工作外
工作内，我们公司给的内部额度比较有限，opus 4.8、4.7、4.6，现在只让用 4.6 了，每天 1200 的额度，我基本都省着用，有时候有需求都是周六周日去，就是为了这 1200 的额度
还有是一些国内的大模型，GLM-5.1、Deepseek-v4-flash/pro、minmax 2.5、kimi-2.5/2.6 等，不同模型使用的倍率不同
目前只能说够用，需要按照你任务的复杂程度来看，没必要吕布骑狗，按需使用
工作外，我自己也在用 AI 工具，之前 meoo 出来的时候玩了一下，token 基本不够用，最亮眼的应该是一键发布到生产直接访问，后面发现很多内容做得太糙了，使用的技术栈还要被局限，就不咋玩了，主要自己没什么好的 idea，玩不出什么花。
qwen cli 有免费额度，是入门体验的不二人选；claude code+deepseek 也可以的，自己体验用 v4-flash 就可以了；我订购了 mimo 的 token plan，mimo-2.5 用起来也还行，最近他们发布了自己的 mimo code 代码编程工具，界面挺好看的，compose 模式默认带了 supperpower 的工作流，使用体验也还不错。
qwen3.7 在 meoo 上体验有 bug，不知道修复没
qcoder work 在 windows 上好卡，卸载了
trae 最早接触的也是最早卸载的，感觉界面太丑了
codebuddy 不知道为啥，就是不用了卸载了
最后
最后说到这里，个人感觉使用 AI 工具肯定是必要技能，有必要花时间投入学习，共勉，respect。