AskLeopold：用三个月 Vibe Coding 更好地梳理项目需求

大约三个月前，我和Jean-Francis Ochs共同做了一个简单的观察：在许多任务中，问题并不是立即来自技术解决方案。它开始得更早，当时必须理解、挑战和形式化需求。

01多次任务中遇到的问题

每次新的任务，我们常常遇到同样的困难：需求表达过于笼统、文件不够详细、重要决策从未真正制定出来。

客户通常了解他的业务并知道他想要解决什么问题。另一方面，他并不总是确定他的请求的所有后果：例外、用户角色、必要的数据、管理规则、与现有工具的依赖关系，甚至是允许项目被认为成功的标准。

在某些情况下，更好的框架可以降低任务成本。当团队发现某个请求措辞不当、不完整或在多个方面无法解释时，为时已晚，这也可以避免一些挫败感。

这不一定是客户、AMOA 或开发者的错。需求在讨论过程中自然演变。当这种开发结构不充分并且在生产开始之前没有识别出灰色区域时，就会出现问题。

02寻找解决方案

一旦做出这一观察，我们就开始寻找一种能够帮助负责收集和形式化需求的人员的解决方案。

我们的目标不是取代 AMOA、职能分析师或项目经理。相反，我们希望为他们提供一个能够加强他们工作的工具：帮助他们提出正确的问题，识别缺失的信息，并深入研究乍一看似乎很明显的主题。

我们自然而然地转向了人工智能。对话模型特别适合这种情况：它可以分析初始表述、询问细节、质疑某些假设并帮助逐步构建需求。

03AMOA 和分析师的助理

AskLeopold的想法很简单：在整个范围界定阶段成为 AMOA 或分析师的伴侣。

该工具必须从第一次交流开始使用，当时需求的定义还不完善。它的作用是提出有用的问题，包括那些可能看起来令人不安或不成熟的问题：

• 我们真正想解决什么问题？
• 哪些用户会受到影响？
• 名义操作有哪些例外情况？
• 需要哪些数据以及谁负责？
• 必须遵守哪些技术或监管限制？
• 我们将如何衡量该项目的成功？

这些问题可能看起来很简单。然而，他们的缺席往往会造成代价高昂的误解。

04为什么要创建一个真正的工具？

在项目开始时，我们有两种可能性。第一个部分包括制定良好实践指南：一种方法、一系列问题和一些供负责制定框架的人员使用的示范文件。

这种方法会更简单、更快。然而，它有一个重要的限制：指南仍然是静态文档。它可能会被遗忘、部分应用或不适应任务的特定背景。

第二种可能性更加雄心勃勃：开发一种能够真正支持用户、适应所获得的答案并使他们的问题在讨论过程中不断发展的工具。

正如我们的联合项目中经常出现的情况一样，我们选择了最复杂的路径：构建我们希望自己使用的产品。

05为什么vibe coding？

几年来，让-弗朗西斯和我一直在开展我们所谓的晚间和周末项目。这些项目是为我们自己或我们的一些客户开发的，不属于大型 IT 项目的常见格式。

大型 ESN 很少对它们的规模感兴趣。然而，这些应用程序可以为使用它们的公司带来强大的附加值。他们通常以有限的预算和强烈的速度期望来响应特定的需求。

然而，AskLeopold并不是一个小项目。如果没有人工智能辅助开发工具的支持，我们不可能只在晚上和周末制作出如此规模的应用程序。该项目可能需要更多时间，以至于难以与我们的其他专业活动兼容。

vibe coding 使我们能够在保持设计控制的同时加速生产。我们能够定义架构、形式化开发规则、控制技术选择并指导代理开发我们想要的产品。

重要的一点是：我们并没有要求人工智能单独决定AskLeopold应该变成什么。我们给了它一个框架、要求、产品愿景和工作方法。

06三个月将想法变为现实

三个月内，我们从共享观察变成了在线应用程序。我们必须将总体想法转化为用户旅程，组织助手的操作，构建项目并构建一个足够简单的界面，以免增加框架阶段的复杂性，而框架阶段有时已经很多了。

人工智能辅助开发使我们能够显着减少实施所需的时间。它还为我们提供了快速迭代的机会：尝试一种方法，评估它，质疑它，然后改进它，而无需在每个版本之间等待几周。

我们很自豪能够在短短三个月内将该项目推出第一个可用版本。这并不意味着工作已经完成。产品通过与用户的接触、他们的实践和反馈而不断发展。

尽管如此，我们相信像AskLeopold这样的工具可以改变某些团队处理项目的方式。并不是因为它会取代他们的专业知识，而是因为它可以帮助他们在错误的答案变得代价高昂之前花更多的时间在正确的问题上。

07现在呢？

下一步是让AskLeopold面对更多的现实场景，倾听用户的声音，逐步完善其支持度。

我们希望该工具保持简单易用，提问要求高，并且对于经验丰富的专业人士和偶尔需要正式确定需求的人来说都是有用的。

出发点保持不变：在正确的时间提出一些好的问题可以避免数周不必要的开发。