生成式 AI 的潜在应用场景似乎无穷无尽。虽然这令人兴奋，但也可能让人不知所措。因此，团队在使用这项技术时需要有明确的目标：关键是要明确生成式 AI 在团队工作中能产生哪些实质性影响。

在软件工程中，一个引人注目的应用场景是需求分析。这是一个常常被忽视但充满挑战的环节，如果处理不当，可能会带来许多负面的后续影响。

本文描述了我们与一位客户进行的试点项目，我们的团队验证了一个假设，即利用生成式 AI 创建高质量的用户故事可以缩短交付周期并提高需求分析的质量。在这个案例研究中，我们验证了这一假设，并解释了我们做了什么以及得出了哪些结论。

方法

确定范围和目标

在选定该团队作为试点后，我们与他们举办了一次研讨会，确定哪些任务可以通过 AI 支持。我们还与他们合作，定义了使用 AI 可能带来的影响。研讨会达成了两个主要目标：

1. 找出适合 AI 支持的任务

团队讨论了他们经常进行且伴随一定难度的任务。随后，他们选择了部分高价值且 AI 可行性较高的任务。其中一个被选中的任务是需求分析，因为团队的工作领域相对复杂，开发过程中常常因需求被误解或遗漏边缘情况而返工。

2. 定义假设和预期结果

在研讨会的第二步，团队定义了使用 AI 期望实现的目标。以下是需求分析的假设：

实施

我们利用服务工具包中的加速器帮助实施 AI 支持。HaivenTM 团队助理 是我们与客户合作时使用的一个加速器，它为软件交付团队提供了一个试点生成式 AI 支持的精简方式。在该项目中，它为用户提供了集成上下文信息和可重用提示词的 AI 功能。

团队的业务分析师（BA）和质量分析师（QA）是主要的工具使用者。他们在各自领域都有丰富经验，并在该团队工作了很长时间。在这次试点中，他们使用该工具将三个新的史诗需求分解为用户故事。每个史诗都是关于为现有功能增加额外能力的。

收获

上下文是关键！

其中一个关键收获是团队需要为 AI 提供多少上下文信息才能让其发挥作用。Haiven 在这方面非常有帮助，因为它允许用户定义可重用的上下文描述，每次与 AI 交互时都可以调用。这意味着他们不必每次都重复相同的上下文信息。

正如我们之前提到的，团队的工作领域相对复杂，史诗的目标是扩展现有功能。因此，他们最初花了一些时间向 AI 描述领域和架构，以便每次与 AI 交互时能够重复利用。这些上下文描述既提供了逻辑和领域语言的总体描述，也明确了当前功能的工作原理，帮助 AI 进行功能扩展的支持。

这种方法显著提高了结果质量，但也表明，在他们的情况下，前期投入是必要的。类似编程助手，使用 AI 修改现有需求比从头设计新功能要困难得多。

用户需要时间适应 AI 支持

最初，用户在如何有效地与 AI 互动方面遇到了困难。了解大语言模型（LLM）响应的非确定性并理解其影响需要一个学习过程。随着时间推移，用户调整了对 AI 的期望，逐渐适应了将 AI 作为助手，而不是一个能够提供完美结果的软件。他们还学会了如何在聊天对话中让 AI 纠正方向，当初始输出不准确时进行调整。

开发人员经常报告在使用编程助手时会出现“审查疲劳”，因此我们也询问了 BA 和 QA 对审查 AI 输出的感受。他们表示审查这些场景并不太繁琐，至少在他们的经验水平下是如此。

很难定量衡量影响

我们发现，衡量 AI 在需求分析中的影响比在编程中的影响更难。

• 这些任务不像编程那样频繁，因此对它们的改进难以单独量化。
• 史诗比用户故事或技术任务更难比较，因此难以与历史数据直接对比。
• 需求分析质量的一个指标是故事在流程中被阻塞或反复返回的次数，因为不完整或不清晰。这类数据通常不会非常细致地跟踪，因为那样会让流程和任务看板过于复杂。

尽管如此，无法定量衡量并不意味着它没有价值！以下关于质量和速度的观察基于 AI 用户在该案例中的估计。

对质量和团队流程的影响

重申一下，假设的一部分是使用 AI 进行需求分析会缩短交付周期，减少返工，并减少因进一步澄清而被阻塞的故事。

业务分析师报告说，由于他们的准备更加高效和全面，AI 助手使他们在与开发人员讨论时更加自信。他们能够回答开发人员在估算会议中提出的问题，不必再进行需求填补。

质量分析师发现，一旦上下文明确，AI 生成的验收标准和测试场景比他们自己生成的要好。当他们开始测试开发人员的工作时，发现的 bug 和返工原因减少了大约 10%，因为用户故事定义更好地涵盖了边缘场景。

对分析速度的影响

虽然三个史诗的样本量不足以得出明确结论，但团队估计分析时间减少了约 20%，尽管创建上下文花费了一定时间。随着上下文创建的优化和上下文的重复

使用，未来的时间节省预计会更为显著。

结论与展望

总之，这项案例研究表明，AI 能够在质量、速度和整体团队流程上带来好处。在该组织中，下一步是将这种方法应用于其他团队，这些团队的经验水平和流程有所不同，以验证是否能重复这些收获，并进一步提高效率。

这项经验以及其他 AI 在软件团队中的使用经验再次证实了上下文编排的重要性。

• 上述团队工作在相对复杂的领域，他们发现，只有在为 AI 提供了详细的领域上下文描述后，AI 才真正有用。对于那些在电子商务或客户数据管理等常见领域工作的团队，这一障碍要低得多，因为这些领域的模型训练数据通常能广泛适用于相关用例，而无需额外的引导。

• Haiven 支持半手动的上下文编排，并允许重复使用上下文描述：团队将领域描述作为提示词的一部分，并为助理应用程序编制了相关维基文档的索引。虽然这需要一些设置工作，但它仍然是探索 AI 潜力的精简方式。然而，我们密切关注软件工具市场的创新，以实现更加自动化和智能化的上下文编排，从而为客户提供最佳建议，帮助他们充分利用 AI。

• 代码库是应用程序工作原理的最终真实信息。它始终比可能过时或不准确的文档或描述更可靠。在本案例研究之外，我们已经与客户一起探索了为 AI 提供代码库上下文的有趣而强大的方式，这使得用户能够在不需要理解或浏览代码的情况下提出问题。尽管该团队在此次试点中未使用此类工具，但其潜力显而易见，尤其是在指定现有功能的更改时。

关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。

各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责：

• 中央/分销预订系统性能优化
• 活动&券等营销中台建设
• 交易平台及数据中台等架构和开发设计
• 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
• LLM Agent应用开发
• 区块链应用开发
• 大数据开发挖掘经验
• 推荐系统项目

目前主攻市级软件项目设计、构建服务全社会的应用系统。

参考：

• 编程严选网