夜雨聆风一、焦虑的不止你一个
前段时间逛一个Reddit QA社区，看到一篇帖子。
发帖人 slacky35，用了 Claude Code 两周，拿它写自动化脚本，觉得挺顺手。
然后公司给了他一个新目标：从 PRD 生成测试用例，到自动化脚本，再到自动从 CI 捕获失败并修复。全链路 AI 化。意思是，别光自己写脚本了，把这套东西搭成一个端到端的 AI 工作流。MCP、自定义 Skill、自建 Agent，工具都给你，自己去琢磨。
他原话是：老实说，这看着挺吓人的。
他问了社区四个问题：你们用哪个代码 Agent？是一个人搞还是团队一起？多久搞出了能用的东西？最大的障碍和痛点是什么？
二、一个十年 QA 老炮的回复
帖子底下排在前面的回复来自 igntio，十多年 QA 经验，从零用 AI 搭了一整套测试体系。
他的回复第一句就是：别想了，AI 还没到那地步。用 gpt5.5 或 opus4.7 也做不到。
你能构建的最好情况，是以人类测试 + AI 专家为中心的工作流，人类质量把关是最后一道防火墙。AI 做分析和编写，但必须经过严格审查。这就是目前最现实的做法。
他还描述了一个所有用过 LLM 干活的人都体会过的场景：你每天都在用的流程，某一天会突然挂掉——LLM 莫名其妙地质疑和误解一个再简单不过的任务，毫无理由。它会幻觉，需要被密切监控。这就是现状。
测试的复杂度，远比写代码高出几个数量级。
发帖人追问他花了多久搭建这套体系，应该定个什么样的目标。
igntio 的回答是：大概花了两周，利用工作日的晚上，学 opencode CLI、VSCode，以及一般性地学习怎么用 LLM。
他特别提醒了一件事：如果你是测试或测试经理角色，坑非常多。因为 LLM 默认把自己当成开发者角色，而开发者的运作模式和 QA 完全是两码事。你不能盲目信任它，必须写出非常明确、详尽的 prompt，以及对应的 .claude 文件和 Skill 文件。他用 AI 把自己用的测试工具给 vibecode 了出来，现在用得很顺手——但这段路不容易。
然后他打了一个比喻。
AI 就像一把锤子。钉钉子比双手高效一千倍。但你必须知道怎么用、局限在哪、哪些地方很危险。你必须百分百在掌控之中，并且有足够经验去驾驭它。非常非常少的测试人员，能同时在切分 Agent 编码和 AI 执行这两个领域胜任。
就像一把锤子落在错误的人手里——造成的破坏比光用双手还要大一千倍。
三、真正实践过的人怎么说
另一个回复者 Equivalent_Union8688 的分享，提供了更具体的参考。
他的公司过去三个月经历了几乎一模一样的路径。管理层期望全自动 Agent 测试。他说，坦白讲一开始他们也很抗拒，对自己能不能驾驭这种转变缺乏信心——尤其是从传统手工脚本编写，一下子跳到 AI 主导的自动化流程。
他们做了大量的概念验证，最终选择了 OpenCode 或 Claude 这类工具，作为 AI 辅助自动化的实际标准。
结果：接近 90% 的 UI 自动化脚本由 AI 辅助生成。
但有一个重要前提——他们不是一步到位追求全自动，而是先从迁移已有脚本开始，渐进式推进。验证这一步可行之后，才把新功能纳入流水线。
他的结论同样明确：一整个季度下来，质量工程团队一致同意，AI 距离全自动 Agent 测试还有很长的路。即使提供了结构化上下文和精心设计的 Skill，AI 也无法可靠地把 PRD 自动转成可投入生产的测试用例。人在环中必不可少，AI 只能出初稿，仍然需要人工透彻审查——他甚至说，这在某种程度上反而成了一个缺点。
技术落地上，他们先在一个团队的一个仓库里做评估。看到效果后，逐步推广到其他团队，提供预制脚手架项目，包含 agents.md 和 skills.md 这类预定义上下文文件。到现在，这套体系已经在 4 个团队落地，整个质量工程组织都在贡献和改进这个共享框架。
他还提到了一个实际痛点：管理被测试产品的上下文理解，以及 token 限制。
他说，不确定这到底反映的是他们的技能问题，还是 AI 本身的局限——但每当模型遇到不稳定测试或失败用例时，最终都会开始胡言乱语，过度复杂化问题。而这种情况，在后端、前端、产品工程团队身上很少发生。
即使建立了严格规则——先切换到规划模式、提供精确 UI 元素、明确指示避免复杂化——不管用什么最先进的模型，结果在某个临界点之后，都会以同样的方式恶化。
四、一个被忽略的悖论
igntio 还说了另一段话。
他公司的高层原本看到机会就想削减 QA 人头，直接搞全 AI 化。
他的回复是：不能。
逻辑很简单——AI 辅助开发者写出的代码越多，开发人员对自己的代码越来越不亲自过手。代码变多了，功能变多了，但写代码的人对代码的理解变浅了。
这意味着对真实测试工作量的需求，不是减少了，而是增加了。
但他也说了另一个事实：没有得到更多的测试资源去创造流程和工具，把人从纯手工脚本中解放出来，转变为专家审查角色。
开发端在加速，测试端资源没变，还被寄予实现全自动化的期望。这个张力，才是测试行业眼下最真实的处境。
他说，所有负责测试或带测试团队的人，需要意识到这一点，并且把它传达给高层。否则不久的将来，AI 会狠狠打脸，到时候就晚了。
五、QA 的立场
我也是一个正在摸索 AI + 测试的测试工程师。实战有一些，成果不多。更多时候也在困惑——路到底怎么走。
这也是为什么我看到 CertainDeath777 的回复时，觉得被打中了。
他说：用批判的眼光审视输入和输出。在眼下这个场景里，你作为 QA 的工作不是去找他们想要的捷径，而是去发现他们看不到的短板，并且把它们清晰地呈现出来。把它写进你的报告和文档里，并在评估时坚定立场。
这段话把我从焦虑里拉了出来。
面对 AI，我一直在想的是怎么用它、能做什么、做不做得出来。但 CertainDeath777 提醒了一件事：发现别人看不到的问题，这本来就是 QA 的本职。管理层想要捷径，但你要呈现的是短板。这不是对抗，是专业判断。该坚持的时候，必须坚持。
但他后面还有一句：
你可能会在这个过程中发现一些更好的 AI 使用场景。他们想要的东西有点疯狂，AI 或许能产出结果，但产出的质量会非常糟糕。但同时，AI 确实能在某些地方改善你的工作流程，甚至提升质量。
否定管理层不切实际的幻想，不等于否定 AI 本身。AI 查日志、生成脚本初稿、分析失败原因——这些事情它确实能干，而且干得不错。我自己从 30 分钟压到 2 分钟的日志排查，就是证据。
所以总结下来就是三句话：找准自己的定位，坚持专业的立场，同时也要相信 AI 能给你赋能。
不盲从，不全盘否定。这才是 QA 面对 AI 该有的样子。
都到这儿了，点个赞再走呗。
我是村夫，下篇见。
