当产品用 AI 做工具,测试用 AI 查 Bug

需求其实挺具体，但她在网上找了一圈，也没找到特别合适的工具。有的软件功能太多，显得笨重；有的看起来差不多，却偏偏少了她想要的功能。

我听完之后，随口建议她，不如用 AI 做一个浏览器插件。这类功能并不算复杂，应该很快就能做出个能用的版本。

她一开始有点犯难，说自己也不会开发，不知道该从哪里开始。说来也挺有意思，她每天都在参与我们公司的软件产品设计，熟悉需求、交互和功能，却不太习惯把自己放在开发者的位置上。以前一个想法要变成软件，通常得先交给研发同事评估，再排期、实现、测试。让她自己动手做，听起来还是有些陌生。

我大致讲了讲流程，她用 WorkBuddy，开始和 AI 对话。说得形象一点，就是最近大家常说的“许愿式编程”：把自己想实现的功能告诉 AI，再根据结果让AI不断调整。

大概不到半个小时，第一版插件就出来了。AI把它装进了浏览器，她试了一下发现还真能完成自己想做的事，一下子开心起来。那份开心我很能理解。原本找了半天都没找到的工具，现在竟然可以根据自己的需要做一个出来，而且并不需要先学会编程。

没想到，尝到甜头以后，她又开始琢磨别的东西。

她一直想要一款能定时提醒自己站起来活动一下的小软件。之前也试过一些类似产品，但总有不太满意的地方。于是她空闲时间，花了几个小时，让 AI 帮自己做了一个。她还把家里猫咪的照片放进去，让这只熟悉的小家伙按时出现在屏幕上，提醒她别一直坐着。

做完之后，她把软件发给我，邀请我体验，顺便帮她找找问题。我也把家里猫咪的照片放了进去，试了试提醒功能，再把遇到的问题反馈给她。

那一瞬间，我突然觉得有点好笑。她是产品经理，我是做了九年开发的程序员。以往更多时候，是产品提出需求，我们负责实现，再交给别人测试。而这一次，她成了软件的制作者，我反倒成了帮她体验和测试的人。我们的职业角色，像是短暂地发生了一次反转。

更重要的是，她的变化并不只是“会用 AI 做了个插件”。从第一次需要别人告诉她可以试试，到第二次主动想到用 AI 实现生活中的需求，她已经开始用另一种方式看待软件了。遇到不合适的工具，不一定只能继续找，或是将就着用；有时候，还可以试着自己做一个。

这件事也让我想到，产品和研发之间那些熟悉的对话。一个功能能不能实现、实现起来有多麻烦、为什么需要换一种设计方式，以前产品同事往往需要依靠研发的解释。现在，她至少可以借助 AI 做一个初步验证。未必能得到完全正确的答案，但有机会更早地发现问题，也更容易理解过去沟通中那些自己没有考虑到的技术细节。

类似的变化，不只发生在产品岗位。

有一次，我还看到一位测试同事在提交一个被标注为“无需修复”的 Bug 时，附上了一段 AI 的分析。他把问题描述和相关后端代码交给 AI，让它帮忙判断问题出在哪里。AI 给出的结论大概是：这更像是代码实现中的功能性问题，而不是产品需求本身无法实现。他便把分析结果贴在 Bug 单里，供开发同事参考。

后来，开发同事确实承认是代码的问题，也完成了修复。

大家在群里略带玩笑地说了一句：“看来以后轻易忽悠不到了。”

这话听着有些调侃，却也说出了过去工作中真实存在的一种情况。测试人员发现异常，开发可能认为这是需求设计不合理，也可能说技术上做不到。有些解释当然是成立的，但有些时候，连开发自己也未必判断得准确。由于双方掌握的信息不同，测试同事即使有疑问，也不一定有足够的依据继续讨论。

现在情况开始有些不同了。测试未必需要掌握完整的开发技能，也能尝试借助 AI 阅读代码，给自己的判断找到一些技术依据。AI 当然也会分析错，它给出的结论不能代替开发人员的核查。但至少，原本只能凭现象沟通的问题，多了一条可以共同验证的路径。少一些误解和含糊的解释，对大家来说都是好事。

回头看这几件小事，我感受到的“技术平权”，并不是所有人的技术能力突然变得一样了。AI 降低了获取和运用技术能力的门槛，却没有抹平专业知识、经验和判断力之间的差距。做出一个能运行的小工具，与设计一个长期稳定、可维护的软件系统，依然是两回事。复杂问题的分析、质量和安全上的取舍，也不会因为能让 AI 生成代码就自动消失。

但我确实感觉到，一些原本很清晰的职业边界，正在慢慢变得模糊。

过去，产品负责设计，研发负责实现，测试负责验证。这样的分工有其合理性，也构成了我们熟悉的互联网行业职业体系。如今，产品可以亲自做出原型，测试可以尝试从代码里寻找依据，开发也可能借助 AI 去完成过去需要其他岗位配合的工作。每个人在一个强大的外部工具帮助下，都有机会把自己的工作范围往外延伸一点。

只是偶尔还是会想，照这个趋势发展下去，未来真正重要的，又会是什么？