十年测试，若说测试，那可以说是资深，若说测试开发，约等于开发，写代码只能算初级，会用自动化测试的常用几个框架，在框架中维护测试用例，仅限于此了。之前也朝着开发测试平台去发展，学习vue、flask等，但都是皮毛。
AI编程的出现，让我曾经有一段时间以为自己就要成为一名资深测试开发工程师了，以为自己什么都会开发了。
宋代禅宗大师青原行思提出参禅的三重境界：看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水。AI编程于我，也有这三重。
初用AI编程——看山是山
我最开始是用PyCharm中的通义灵码插件。那时的我对AI编程的认知很简单：它能帮我补全代码。比如写一个用例、一个公共方法，AI帮我补充，我选择用或者不用。
当时的我，对AI的认知还停留在提高效率的层面，并没有改变我的编程思维，我依然按照自己的习惯写代码。
再用AI编程之TRAE——看山不是山
真正让我对AI编程产生深刻认知的，是使用TRAE。
狂喜：AI可以帮助我成为“厉害的测试开发”
当我第一次让TRAE生成UI自动化测试框架时，内心的狂喜难以言表。TRAE不仅生成了完整的项目结构，还包含了配置文件、基础类、日志模块和几个示例测试用例。
那一刻，我天真地以为：有了AI的帮助，我可以轻松成为厉害的测试开发工程师。AI似乎无所不能，它能帮我解决所有编程问题。
失落：AI也有「局限性」，它帮不了我
然而，这种狂喜很快就被现实打破。在一次pytest批量执行测试用例的场景中，我发现了AI给的解决方案的也不是最好的。
当时，TRAE生成的四个测试用例文件名都是以search开头的。当我想要批量执行这些测试用例时，只执行了一个用例，另外三个没执行。AI给出的解决方案是：修改pytest的配置文件，让它执行以search开头的用例。
但这个修改方式有个严重的问题：当前这四个测试用例是搜索功能的测试，但后续我还会添加其他功能的测试用例，它们不可能都以search开头。AI在修改的时候只考虑了当下，也不了解pytest的命名最佳实践。
正确的解决方案应该是：修改已有的四个测试用例文件名，使其符合pytest的命名规范：以test_开头或_test结尾
这次经历让我有些失落：AI并不是无所不能的。它虽然能生成代码，但有时给出的解决方案并不符合行业最佳实践。如果我不了解pytest的命名规范，就会盲目接受AI的建议，写出很蠢的代码。
觉醒：AI是“剑”，我是握剑的问
后来，我意识到：用AI编程，首先得自己知道，自己做过。AI只是我手中的一把剑，它的威力取决于握剑的人。如果我对编程规范、最佳实践一无所知，就无法判断AI给出的解决方案是否合理，输出的代码的改动会越来越多直到无法改下去。
我需要了解基本的编程规范和最佳实践、能够判断AI解决方案的合理性、主导AI的编程方向，而不是被AI牵着鼻子走。
三用TRAE——看山仍是山
经历了狂喜与失落之后，我对AI编程的态度变得更加理性和成熟。我开始学习如何正确使用AI。
去魅：AI就是AI，它只是我的帮手
我不再将AI视为神，也不再因为它的局限性而否定它的价值。它能帮我快速生成代码、解决重复性问题，但它无法替代人类的经验、判断和创造力。至少现在还不行。
冷静：掌握AI编程的正确姿势
在使用AI编程时，我开始注重利用好规则rule、文档doc、上下文。将已有的代码整理成rules，将文档上传给TRAE，规范它，帮助它，这样AI生成的代码会更加符合我的预期，减少返工的概率。
另外，在处理复杂问题的时候，先生成plan，确认后再执行。现在TRAE有了SOLO模式，可以先用plan模式生成计划，自己做个判断，如果没问题了，再让AI写代码。在rules、doc的约束下，结合上下文，有了plan，那么，生成的代码质量会符合我的预期。
实践：AI助我高效成长
不管是框架搭建、用例编写、历史项目的维护、代码的阅读、项目部署，都可以让AI帮忙，让TRAE帮助我。
阅读代码，梳理结构：
部署项目：
虽然过程中遇到一些问题，不过两个小时就部署好了，如果没有AI，是没办法这么快的。
心态：不幻想也不丢弃，与AI共同成长
现在的我，对AI编程持有一种平和的心态：不幻想AI能解决所有问题，也不丢弃AI的强大功能，把AI当作伙伴，在使用AI的过程中，不断学习和成长，同时也引导AI变得更懂我的需求。
Al是一把锋利的剑，但握剑的手和挥剑的智慧永远属于人类
我们是朋友，我们互相帮助，我们并肩前行。
