震惊，客户刚提完需求，原型直接用 WorkBuddy 发布到测试环境进行交流确认

关于我：

我是连续创业者峰哥，长期关注 AI Agent 与高效办公。

希望我的文字，能帮助更多普通职场人从“会用 AI”走向“会管理 AI”，把重复工作交给数字员工，把时间留给真正重要的事。

上周，我去外地见了一位客户。

原本出差要讨论一套自动化测试平台，内容横跨三块：

• 接口测试工具；
• 性能测试工具；
• UI 测试工具。

开会之前，以为这次交流的主要任务仍然是梳理需求、确认边界，然后回去写方案。

但在第一轮沟通中，客户提出了一个很具体的问题：

接口测试里已经维护好的场景和接口，能不能直接复用到性能测试，而不是重新配置一遍？

继续往下聊，问题又多了几层：

• 是按场景导入，还是按单个接口导入？
• 同一个接口有多个版本时，应该导入哪一个？
• 导入以后，能不能看见它来自哪里、当前使用什么版本？
• 接口发生变化时，能不能比较不同版本的差异？

这些需求写成文字并不难。

难的是：所有人脑子里的页面，根本不是同一个页面。

我不想再走一遍传统原型流程

按我过去熟悉的做法，这场会结束以后，大概率会经历这样一条路线：

整理会议记录 → 编写需求说明 → 用原型工具画页面 → 导出截图或链接 → 再约客户确认 → 根据反馈修改 → 交给开发实现 → 部署到测试环境

这条路线没有错。

但它有一个明显的问题：客户第一次真正看到“可以操作的东西”，往往已经比较晚了。

在这之前，大家一直在用文字解释文字。

“从接口平台导入”是一句话。

可它究竟是一个按钮、一个下拉菜单，还是一个单独页面？

“支持选择版本”也是一句话。

可版本选择放在导入前还是导入后？切换版本会不会影响已经编排好的性能场景？

这些问题如果只靠文档，很容易在每个人的理解里各自长出一个答案。

所以这一次，我不想先做一套只能看的传统原型。

我决定在第一次交流后，直接用 WorkBuddy 把刚刚讨论的内容变成一个可以运行、可以点击、可以继续修改的页面。

口头需求变成“可执行约束”

我先把刚才确认的内容压缩成一份任务说明，大意如下：

请基于现有自动化测试平台，设计接口测试与性能测试之间的用例复用流程。 核心场景： 1. 用户可以把接口测试场景推送为性能测试用例； 2. 用户也可以在性能测试计划中，按场景或按接口导入； 3. 导入时可以选择接口版本； 4. 导入成功后，列表展示来源和版本； 5. 用户可以查看历史版本，并选择两个版本进行差异比较。 设计要求： - 尽量沿用现有平台的导航、列表和弹窗结构； - 优先完成主流程，不扩展未经确认的业务规则； - 页面必须可以点击和演示； - 使用脱敏的示例项目、接口名称和数据； - 输出可直接部署到测试环境的版本。

这一步很重要。

因为客户说的是业务，页面需要的是交互，而 WorkBuddy 真正需要的是明确的执行边界。

我需要决定：

• 哪些是客户已经确认的需求；
• 哪些只是我对页面的理解；
• 哪些规则还不能擅自补充；
• 哪条操作路径必须优先跑通。

WorkBuddy 负责加速执行，但需求判断仍然由我完成。

做出来的不是一张图，而是一段完整操作

这次原型最关键的，不是页面看起来有多精致。

而是客户第二天打开测试环境后，可以亲手走完一段流程：

1. 进入性能测试计划；

2. 在场景管理中点击“添加接口”；

3. 选择“从接口平台导入”；

4. 在场景和接口两个视图之间切换；

5. 勾选需要复用的接口；

6. 为接口选择具体版本；

7. 导入后，在列表里看见来源和版本信息。

如果需要确认接口变化，还可以打开历史版本，选择两个版本查看差异。

这时候，原本抽象的需求开始变得具体。

客户不再需要想象“版本管理大概是什么样”。

他可以直接指出：

• 版本号应该在这里选择；
• 来源信息应该保留在列表里；
• 按场景导入和按接口导入要放在同一个入口；
• 这个操作以后还要考虑权限和变更影响。

可操作的页面，替代了大量来回解释。

第二天，沟通对象已经变了

第一次见面时，我们讨论的是“需求应该怎么理解”。

第二天再交流时，我们讨论的是“眼前这个功能应该怎么调整”。

这两种沟通看起来只差一天，效率却完全不同。

前一种交流里，每个人都要在脑子里构造页面。

后一种交流里，所有人面对的是同一个页面、同一条路径和同一组操作结果。

客户最终采纳了这套原型方向。

让我感受最深的，并不是 WorkBuddy 帮我画了几个页面，而是这个原型已经直接发布在测试环境中。

它不是一份等着被讲解的静态文件。

它可以打开，可以点击，可以现场修改，也可以继续成为后续开发和验收的共同参照。

为什么我认为这次尝试值得记录

过去，原型通常是需求和开发之间的一份中间材料。

这一次，原型更像一个可以运行的需求共识。

它至少带来了三个变化。

1. 客户更早看见真实操作

文字里的“支持导入”和“支持版本选择”都很正确，但只有落到按钮、列表、弹窗和状态变化以后，隐藏的问题才会出现。

越早发现这些问题，后面的返工越少。

2. 需求确认从复述变成共同修改

以前我可能会问：“我刚才理解得对不对？”

客户只能继续用语言解释。

现在我可以直接问：“如果从这里导入，并在这里选版本，是不是你想要的路径？”

客户面对具体对象，更容易给出明确反馈。

3. 原型与测试环境之间不再隔着很长的交接链

传统原型确认以后，还要重新进入实现阶段。

而 WorkBuddy 生成的是可运行成果。只要项目结构、部署方式和环境条件允许，它可以更早进入测试环境，成为下一轮讨论的基础。

这并不意味着正式开发、测试和验收都被省略了。

它意味着我们可以先把最容易产生误解的部分跑起来。

WorkBuddy 没有替代的三件事

这次实践很顺利。

至少有三件事，仍然必须由人负责。

第一，判断客户真正要解决的问题。

客户提出的可能是一个按钮，也可能是一个版本字段，但背后真正的问题是测试资产重复维护和变更不可追踪。这个判断不能只看表面功能。

第二，控制未经确认的扩展。

接口、性能、UI、节点监控和角色权限彼此有关。WorkBuddy 可以继续展开，但第一版原型不能因为“都能做”就把所有内容塞进去。

第三，区分原型确认与生产验收。

客户采纳原型，代表交互方向和业务路径得到了认可；正式投入使用之前，仍然需要完成数据模型、权限、安全、异常处理、性能和兼容性验证。

测试环境里的可运行原型，是更高质量沟通的开始，不是项目交付的终点。

如果再做一次，我仍然会选择这种方式

因为对我来说，这次真正节省的，不只是画原型的时间。

更重要的是，它缩短了从“客户说出一句需求”到“双方看着同一个结果讨论”的距离。

第一次交流，客户提出问题。

我用 WorkBuddy 把业务语言变成页面和操作。

第二天，客户直接在测试环境里验证，并采纳了原型方向。

这条链路让我重新理解了 AI 在客户项目里的位置：

它不只是会后整理材料的助手，也可以成为交流现场与下一次确认之间的执行者。

写在最后

很多人谈 AI 提效，最先想到的是写文档更快、画页面更快、写代码更快。

但在真实项目里，更昂贵的往往不是某一个步骤花了多少时间，而是信息在客户、产品、设计、开发和测试之间传递时，逐渐产生了多少偏差。

如果 WorkBuddy 能让一个刚刚说出口的需求，更早变成可以共同查看、共同操作、共同修改的结果，那么它改变的就不只是制作原型的速度。

它改变的是我们形成共识的方式。

—— END ——