Vibe Coding 一个游戏的收获
我想做一个游戏，不是因为我是个开发者，不是因为我有宏大的产品愿景，我只是一个想法、一个空闲的周末，还有 Claude。能有多难呢？
事实证明，非常难！
作为一个有趣的副项目开始的事情，很快成为我 BA 职业中最出人意料的教育体验之一。因为构建 Adulting——一个你在生活中滑过各种责任（房租、税务、倦怠和周一）的浏览器游戏——教会了我关于需求收集、提示词工程和用户体验的比我预期的更多。
以下是我学到的：
BA 教训 1：提示就是需求收集
我最大的误解是第一个。
我以为提示词工程很简单。你描述你想要什么，AI 构建它，完成。就像在一份非常聪明的菜单上点菜。
错了。
我很快发现，给 AI 提示就像从一个异常有能力但对你实际意思毫无上下文了解的利益相关者那里收集需求。
AI 会精确地执行你要求的，而这正是问题所在。因为你要求的和你想要的往往是两件完全不同的事。
当我说"让游戏更好玩"时，没有任何有意义的改变。当我说"增加跳跃弧度，使滑手在空中停留足够长的时间，以在每帧 2.6 个单位的前进速度下越过 54px 的障碍物"时，事情才开始发生变化。
这就是模糊的业务请求——"我们需要更好的报告"——和实际需求——"客户端需要一个聊天机器人，能在 3 秒内响应客户查询"——之间的区别。
提示词工程不是技术技能。它是沟通技能。而 BA 们已经受过这方面的训练了。我们只是还没把它应用到这里。
BA 教训 2：永远不要外包愿景
我的第二个错误是让 AI 为我设计游戏。
我给了 Claude 一个模糊的简报，基本上说"给我惊喜"。它确实给了——给了我不喜欢的东西。所以我一次又一次地要求。直到我停止让 AI 想象游戏，开始自己描述它——确切的颜色、速度、障碍物、感觉、机制、名字——游戏才变成我引以为傲的东西。
突破发生在我不再把 Claude 当作创意总监，而是当作一个速度极快、极其字面化的开发者。我的工作是愿景。Claude 的工作是执行。
这直接映射到 BA 工作中的核心张力之一：收集需求和引导需求之间的区别。你不能只是打开一个会议说"告诉我你需要什么"。你必须带着假设、原型、挑衅性想法来。你必须有自己的观点，即使它会改变。
AI 也是一样的。它会构建你能表达出来的任何东西。瓶颈永远是表达。
BA 教训 3：上下文是非功能需求
我的初始版本在桌面上很棒。流畅、响应迅速、有趣。
然后我在手机上测试了一下，灾难！又慢又笨重。跳跃感觉不对，速度感觉不对，控制感觉不对。在大屏幕上运行良好的一切，在 390px 的 iPhone 上感觉全坏了。
关键在于，代码是完全相同的。这不是 bug。这是对上下文的根本误解。
我不得不回去重新思考几乎所有面向移动端的东西。不仅仅是技术意义上的"自适应"。我的意思是，重新思考体验。速度需要感觉更快，因为画布显示更小。跳跃弧度需要更干脆，因为拇指的反应和键盘不同。控制需要是本能的，不是学习来的。
我实际上不得不给 Claude 一个提示，分别为桌面和移动端指定滑手的速度。两个不同的数字，两种不同的感觉，因为相同的值在每个设备上产生了完全不同的体验。这种程度的特异性不是我一开始就会想到要提供的。测试迫使我发现了它。
我最终先为移动端构建，然后适配到桌面。与我开始时完全相反。
作为业务分析师，我们一直在谈论非功能需求。性能、可用性、可访问性。但我们在签字确认之前，实际跨上下文测试的频率有多高？我们多久会问一次：这在用户每天实际使用的设备上是否以相同的方式工作？
移动端是人们生活的地方。如果体验在那里不行，体验就不行。
BA 教训 4：测试是一个发现活动
有一个时刻我以为游戏完成了。代码是对的，逻辑是对的。Claude 确切地实现了我要求的东西。然而，当我玩它的时候，有些不对劲。滑手穿过障碍物而不是跳过它们。三跳机制意外触发。没有人想要冥想彩蛋时它却触发了。
任何数量的阅读代码都不会发现这些问题，只有玩它才会。
我必须成为用户。而我这么做的时刻，我不知道自己拥有的需求开始倾泻而出。
"跳跃需要感觉更宽，不是更高。""加速应该是默认速度，不是奖励。""下蹲机制需要在两次点击之间有最小间隔。按住按钮不应该算三次单独的点击。"
这些不是实现细节，这些是需求！它们直到有人使用这个东西才存在。
这就是 UAT 存在的原因。这就是为什么我们要带着利益相关者走查原型，而不是仅仅问他们想要什么。人们不知道自己想要什么，直到他们能感觉到不想要什么。
测试不是末尾的阶段。它是真正需求所在的地方。
BA 教训 5：迭代就是规格说明
我不是一次提示做到的，甚至十次，甚至二十次。
它花了 30 次迭代，有时从头重建机制，有时只改变一个数字，游戏才感觉完全正确。每次迭代都揭示了新的东西。一个新的边缘情况、一个新的偏好、一个我不知道自己关心的新东西——直到看到替代方案。
这就是好产品构建的方式。不是在一个出色的规格说明中，而是在构建、测试、学习、完善的循环中。老实说，这也是好的需求文档的编写方式，即使我们假装不是这样。
没人说的部分：当它是你自己的东西时，发布很难
这是我没有预料到的事情。
在某个时刻，游戏真的很好。我的妻子 Bhawna 玩了它并问我是否要把它放到 App Store 上。我笑了，但我也没有发布它。
不是因为它没准备好，而是因为我一直认为我可以让它更好。
速度可以更令人满意一点。音乐可以更好。再来一次迭代。再来一个改变。
迭代游戏变成了游戏本身。
我注意到了这种感觉中的一些东西。一旦你自己构建了某样东西，你就会以一种几乎不理性的方式保护它。你看到每一个缺陷。你是最严厉的批评者，也是最不情愿的发布者。
有一种完美主义伪装成质量。它告诉你再来一次迭代终于能让它足够好。不会的。它只会让它变得不同。
发布它。让人们玩它。他们的反馈教会你的比你接下来三十次迭代所能教的多得多。
这对我们作为业务分析师意味着什么
如果你从来没有 vibe-coded 任何东西，我真心鼓励你试试。不是为了成为开发者，而是为了对这个过程产生同理心。
因为构建 Adulting 提醒了我：
需求永远不会在第一次就完整。测试是一个需求收集活动。非功能需求不是可选的额外品。它们是"能用"和"人们真正使用"之间的区别。而"客户说他们想要这个"和"客户喜欢这个"之间的差距，几乎总是通过迭代来弥合的，而不是通过更好的初始简报。
提示词工程不是魔法。它只是带有更快反馈循环的需求收集。
也许这就是为什么，对一个业务分析师来说，vibe coding 感觉如此奇怪地熟悉。
原文链接: What Vibe Coding a Game Taught Me About Requirements Elicitation
汇智网翻译整理，转载请标明出处