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

大约三个月前，我和Jean-Francis Ochs共同得出一个简单结论：许多项目的问题并非首先出在技术方案，而是在更早的阶段——需求尚未被充分理解、质疑和明确表达。

01许多项目都会遇到的问题

每当开始新的客户项目，我们经常遇到相同困难：需求描述过于笼统、文档细节不足，或关键决策从未被真正明确下来。

客户通常很了解自己的业务，也知道希望解决什么问题，但未必能预见需求涉及的全部影响：异常场景、用户角色、所需数据、业务规则、与现有工具的依赖，以及判断项目成功的验收标准。

在某些项目中，更充分的前期界定原本可以降低成本，也能避免团队到后期才发现需求表述不清、不完整或存在多种理解方式所带来的挫败。

这并不一定是谁的过错。需求会在交流中自然演进；真正的问题，是这种变化没有被系统梳理，模糊区域也未在开发开始前被识别。

02寻找解决方案

确认这个问题后，我们开始寻找一种方案，帮助负责收集和明确需求的人。

我们的目标不是取代 AMOA、业务分析师或项目经理，而是用工具增强他们的工作：提出恰当的问题、发现缺失信息，并深入分析那些乍看理所当然的内容。

因此，我们自然想到使用 AI。对话模型很适合这类场景：它可以分析初始描述、追问细节、质疑假设，并逐步帮助梳理需求。

03面向 AMOA 与业务分析师的助手

AskLeopold 的定位很简单：在整个需求界定阶段陪伴 AMOA 或业务分析师。

工具从首次交流就开始介入，此时需求往往还不完整。它负责提出真正有用的问题，包括那些可能令人不适或看似过早的问题：

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

这些问题看似简单，但最昂贵的误解往往正是因为没有及时提出它们。

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

项目开始时，我们有两种选择。第一种是编写一份最佳实践指南，包括方法、问题清单和供需求负责人使用的文档模板。

这种方式更简单、更快，但有一个明显限制：指南只是静态文档，可能被遗忘、只执行一部分，或无法适应具体项目情境。

第二种选择更有挑战：开发一个能真正陪伴用户、根据回答调整方向，并在对话中持续深化问题的工具。

和我们共同项目中的许多时候一样，我们选择了更复杂的路径：打造一款我们自己也愿意使用的产品。

05为什么选择 Vibe Coding？

多年来，Jean-Francis 和我一直在做所谓的“夜晚与周末项目”。这些项目面向我们自己或部分客户，不采用大型 IT 项目的传统组织方式。

这类项目规模通常不会吸引大型 IT 服务公司，却能为实际使用它们的企业带来很高价值：针对明确需求、预算有限，同时强调快速交付。

然而，AskLeopold并不是一个小项目。如果没有 AI 辅助开发工具，仅靠晚上和周末，我们无法完成这样规模的应用；所需时间也很可能与其他工作安排无法兼容。

Vibe Coding 让我们在保持设计主导权的同时加快开发。我们负责定义架构、明确开发规则、审核技术选择，并引导智能体实现设想中的产品。

关键在于，我们从未让 AI 自行决定 AskLeopold 应该成为什么。我们为它提供了框架、要求、产品愿景和工作方法。

06三个月将想法变为现实

三个月内，我们把共同观察到的问题变成了一款在线应用。我们需要把抽象想法转化为用户流程，设计助手的工作方式，组织项目结构，并做出足够简单的界面，避免给本就复杂的需求界定阶段再增加负担。

AI 辅助开发显著缩短了实现时间，也让我们可以快速迭代：尝试一种方案、评估、质疑并改进，而不必在每个版本之间等待数周。

我们很自豪能在三个月内交付首个可用版本，但这并不意味着工作结束。产品会随着真实用户、实际用法和反馈持续演进。

我们相信，AskLeopold 可以改变部分团队启动项目的方式。它不是要取代专业能力，而是帮助团队在错误答案变得昂贵之前，把更多时间花在正确的问题上。

07现在呢？

下一步，是让 AskLeopold 面对更多真实场景，倾听用户反馈，并逐步改进引导方式。

我们希望工具保持简单易用，同时坚持严谨追问；既服务经验丰富的专业人员，也帮助偶尔需要正式梳理需求的人。

最初的判断没有改变：在正确时机提出几个好问题，可能省去数周无效开发。