从"开盲盒"到工程化：一个测试开发的 AI 工作流演进
这不是一篇 AI 工具安利。这是一个测试开发工程师，从把想法丢给 AI 就期待奇迹，到摸索出一套可复用工作流的过程。踩过的坑可能比方法论更有价值。
开头：我也曾经"开过盲盒"
年初公司开始推广 AI 提效，领导推荐使用TRAE，于是我兴奋地装上了它，打开一个项目，输入了一句话：
"帮我实现 xxx 功能。"
AI 确实生成了代码。我满怀期待地运行——报错。改了 prompt 再来——能跑了，但逻辑不对。再改——这次倒是对了，但把另一个模块搞坏了。
来来回回几轮下来，我的感受是：这东西像开盲盒。有时候惊喜，有时候惊吓，但你永远不确定下一次打开会是什么。
后来我想明白了一件事：问题不在 AI，在我。
我既没有给它明确的边界，也没有建立验证机制，更没有想清楚"我到底要它做什么"。我只是把一个模糊的想法丢出去，然后期待它猜对我的意思。
那之后，我开始调整使用方式。从"让 AI 自由发挥"，到逐渐形成一套工程化的工作流。踩了不少坑，也总结出了一些真正有用的经验。
一、三个花了代价才想通的认知
1. AI 没有最好，只有适合场景的
这段时间我试了很多 AI 形态——Chat 对话、IDE 插件、命令行 Agent、各种集成工具。
最大的感受是：没有哪个 AI 是万能的，也没有哪种使用方式一定最好。
- Chat 适合你方向不明确的时候，帮你梳理思路；
- IDE 插件适合写代码时的即时补全和小修小补；
- Agent 适合目标明确后，让它进入项目上下文做大块工作。
而且 AI 是"越用越好用"的——不是因为它在进步，而是因为你越来越清楚它的能力边界。你知道什么时候该信它，什么时候该自己判断。
这种边界感，才是使用 AI 最重要的能力。
2. AI 不怕你不会写，怕你不知道自己要什么
这是从"开盲盒"经历里得出的最核心的教训。
你可以不知道某个框架的 API 怎么调，AI 会帮你查。你可以不熟悉某种设计模式的写法，AI 会帮你实现。但有几样东西你必须自己清楚：
- 业务流程是什么——整个系统的数据怎么流转，模块之间什么关系；
- 为什么选这个技术栈——不一定要知道每行代码怎么写，但要知道选型理由和它的局限性；
- 怎么判断 AI 的产出对不对——如果你自己都不知道"对"是什么样子，AI 给你什么你都分辨不出来。
你给 AI 的输入不可能覆盖所有场景，所以你必须有能力从它的产出中筛选和纠偏。 这需要的不是编码能力，而是工程判断力。
3. 用了 AI 之后，文档和版本管理更重要了
很多人觉得有了 AI 就不需要写文档了——恰恰相反。
AI 的上下文和记忆并不完全可见、也不完全稳定。你以为它记住了上一轮对话里你说的约束条件，但下一轮它可能就忘了。你以为它理解了项目的整体架构，但它可能只看到了当前文件。
文档是明确的、稳定的上下文。 关键想法、方案演进、技术约束和决策过程，都应该沉淀成文档。
版本管理也一样。让 AI 改代码时，如果没有 Git，改歪了就真回不来了。每完成一个小需求就提交一次，Git 就是你让 AI 放手干活时的安全绳。
二、我现在的 AI 工作流
踩完坑之后，我逐渐形成了一套相对稳定的工作流。不复杂，但有效。
graph LR
A[Chat 梳理思路] -->|明确方向| B(文档沉淀)
B -->|明确约束与标准| C{Agent 分步执行}
C -->|局部代码产出| D[Review 验证]
D -->|未对齐预期| B
D -->|代码符合要求| E((Git 小步提交))
style A fill:#2A2D34,stroke:#4CAF50,stroke-width:2px,color:#fff
style B fill:#2A2D34,stroke:#2196F3,stroke-width:2px,color:#fff
style C fill:#2A2D34,stroke:#FFC107,stroke-width:2px,color:#fff
style D fill:#2A2D34,stroke:#FF9800,stroke-width:2px,color:#fff
style E fill:#2A2D34,stroke:#9C27B0,stroke-width:2px,color:#fff
第一步：Chat 梳理方向
如果对一个事情还比较模糊，我不会一上来就让 AI 写代码，而是先跟它聊。
这个过程更像是在找一个陪你梳理思路的人。你说出粗略的想法，AI 帮你补充技术方案、提出你没想到的边界情况、拆解实现路径。聊着聊着，方向就逐渐清晰了。
Chat 的价值不是给你答案，而是帮你把问题想清楚。
第二步：文档沉淀
想清楚之后，我会把目标、约束条件、技术方案和验收标准写成文档。
这一步很多人会觉得多余——"我脑子里清楚了直接干不就行了？"但我的经验是：写给 AI 看的文档，其实是在逼自己想清楚。 如果你没办法用结构化的语言描述清楚你要什么，那大概率你自己也还没想透。
比如：以前我可能是让 AI“写个解析协议的函数”；现在我的文档里会明确写“输入是 Hex 字符串，输出是 JSON，需处理粘包异常，且绝对不能改变原数组对象”。 一点点具象的约束，就能让 AI 的产出从“薛定谔的状态”变成“极度可控的组件”。
这份文档同时也是后续 Agent 执行的输入和 Review 时的校验基线。
第三步：Agent 进入项目
目标明确后，我会让 AI Agent 读取项目代码。
关键是不要一上来就说"帮我重构"。我的习惯是分三步走：
- 先让它总结当前项目的实现方式——看它理解得对不对；
- 再让它分析需要改动的点——和你自己的判断做对比；
- 最后列出改造计划，确认后再分步执行。
这样做的好处是：每一步你都有校验点，不至于到最后才发现它理解错了需求。
第四步：Review
Review 不能只看 AI 的文字解释。我一般会做两件事：
- 看 AI 给出的修改说明，和我的预期是否一致；
- 直接打开关键文件，看实际代码变更是不是合理。
有些 AI 的解释写得很漂亮，但实际代码里可能有遗漏或硬编码。所以必须看代码本身。
第五步：Git 提交
每完成一个小功能、一个小模块，就提交一次。不要攒着一把梭。
这不只是好习惯，更是和 AI 协作时的风控手段——如果 AI 在第三步把某个模块改坏了，你可以直接回退到上一个正确的提交，而不是花半天去找它到底改了哪里。
三、一个真实案例：IoT 设备模拟器重构
理论讲完了，来看一个完整的实战案例。
背景
我所在的团队负责 IoT 智能表计系统的测试。团队有一个内部工具——设备模拟器，用来模拟各种表计设备的协议报文，这样测试时就不用依赖真实的硬件设备。
这个项目已经被多人迭代过好几轮，技术栈混乱、依赖冲突频繁、没有统一规范。我接手的时候，光搭本地开发环境就花了两天——这还是在有人指导的情况下。
如果连维护者自己都要花两天才能跑起来，那新人接手的成本只会更高。这个项目的问题不在代码逻辑本身，而在工程化程度极低。
我的判断
梳理完现状后，我确定了重构的优先级：先治理，再扩展。
不是急着加新功能，而是先做三件事：
- 统一技术栈、理清依赖——做到一键安装部署，消灭"环境地狱"；
- 抽象协议公共类——把各协议的重复代码提炼成可复用模块，让后续接入新协议从"写一遍"变成"配一下"；
- API 化——把模拟器从"手动操作的工具"变成"可以被自动化脚本调用的服务"。
执行过程
这次重构完整走了上面的工作流：
- Chat：先和 AI 讨论了整个项目的技术栈现状和可能的重构方向。AI 帮我补全了一些我不熟悉的前端框架升级路径；
- 文档：列出了重构目标、优先级、技术约束（服务器资源有限、不能停服太久）和验收标准；
- Agent：让 Agent 先读取项目、总结现有实现，然后分模块执行——后端 API 重构、前端现代化改造、依赖清理、部署脚本编写，逐个推进；
- Review：每个模块改完后我都会检查关键文件，尤其是协议解析相关的核心逻辑——这部分 AI 容易遗漏业务细节；
- Git：每完成一个模块就提交，最后整个重构过程有清晰的版本记录。
结果
| 维度 | 重构前 | 重构后 |
|---|---|---|
| 环境搭建 | ~2 天 | 一键 install |
| 前端流畅度 | 明显卡顿 | 提升约 80% |
| 历史 Bug | 长期存在 | 修复 ~10 个 |
| 新协议接入 | 从头开发 | 基于公共类适配 |
| 部署方式 | 手动多步 | 一键打包 + 一键部署 |
| 开发周期 | 组内预估 20-25 天 | 约一周完成 |
这里最值得说的不是"快"，而是为什么能快。
不是 AI 替我做了所有事。而是因为我在 Chat 和文档阶段就想清楚了重构的优先级和边界，Agent 执行时不需要反复修正方向。再加上小步提交和实时 Review，返工率非常低。
AI 加速的不是编码，而是"从判断到落地"的整个链路。
四、一个框架：AI 可以介入测试研发的 5 个位置
从上面的实践中，我总结出一个通用框架。AI 在测试研发工作流中，可以在 5 个层面产生价值：
1. 理解层 — 读代码、读需求文档、读日志
接手一个陌生项目时，让 AI 先帮你读懂现有实现，比自己一行行看要快得多。但记住，它的理解需要你验证。（💡 特别提醒：作为测试开发，如果日志中包含真实生产数据，在交给云端大模型分析前务必做好数据脱敏，安全红线不能碰。）
2. 生成层 — 脚本、测试用例、接口定义、文档
AI 最直观的提效点。重复性的编码工作让 AI 生成初稿，你负责审查和调整。
3. 执行层 — 自动化运行、并发策略、CI/CD 集成
当 AI 帮你生成了测试脚本，下一步是让它们自动跑起来——接入 CI/CD 流水线，提交代码就自动触发测试、自动推送结果。
4. 分析层 — 测试报告分析、失败归因、风险摘要
这是我正在探索的方向。AI 不只是帮你跑测试，还应该帮你理解测试结果——哪些失败是环境问题，哪些是真正的 Bug，风险集中在哪些模块。
5. 沉淀层 — README、项目规范、知识库、团队模板
AI 可以帮你快速生成文档的初稿，但更重要的是：这些沉淀下来的文档反过来可以让 AI 读取，形成正循环。项目规范越清晰，AI 的产出越符合预期。
真正有价值的不是一次 AI 对话，而是把 AI 放进工作流的关键节点。
结尾：回到起点
回到最开始"开盲盒"的问题。
现在回头看，从"开盲盒"到现在，中间差的不是一个更好的 AI 模型，而是一套工程化的使用方式：想清楚再动手，给明确的边界，分步执行、逐步验证，过程留痕、可以回退。
说白了，这些方法论并不新。它们就是软件工程的基本功——需求分析、方案设计、分步实现、代码审查、版本管理。
AI 改变的不是方法论本身，而是每一步的效率。但前提是，你得先有这套方法论。
有人说 AI 变化太快，学不过来就不学了，等等再说。
我的看法恰恰相反：AI 变化快，才更应该现在就开始用。 因为工具会变，但"先想清楚再动手"的习惯不会变。"人来判断、AI 来加速"的协作模式不会变。越早建立这种工作方式，后面换任何工具都能快速上手。
最好的开始时机，就是现在。
本文是"AI 质量工程"系列的第一篇。后续会分享大模型驱动 UI 自动化探索、测试资产技术债治理等更深入的实践。欢迎交流。
