需求分析基础：需求的定义与分类

说实话，做了这么多年法律AI产品，我见过太多项目死在「需求不清」这四个字上。你想想看，一个法律检索系统，律师说要「快」，法官说要「准」，法务说要「全」——到底听谁的？

这就是我们今天要聊的核心问题。需求分析，说白了就是搞清楚「到底要做什么」这件事。别小看它，我见过太多团队一上来就写代码，结果三个月后推倒重来。

需求到底是什么？

我个人习惯把需求定义为：用户期望系统具备的能力或行为。但在法律AI场景里，这个定义要更具体一些。

举个例子。去年我参与一个合同审查AI项目，客户说「我要一个能自动审合同的系统」。嗯，这句话听起来很明确对吧？但等我追问下去才发现——

• 律师想要的是「找出所有风险条款」
• 法务想要的是「对比历史版本差异」
• 业务员想要的是「告诉我能不能签」

你看，同一个「审合同」，三个角色三种理解。所以我在团队里一直强调：需求不是一句话，而是一组可验证的期望。

需求的分类：别把「想要」当「需要」

做AI产品最容易踩的坑，就是把用户的「愿望」当成「需求」。我刚开始做法律AI时也犯过这个错——客户说「我要一个能预测判决结果的AI」，我就真去做了。结果呢？准确率永远达不到预期，因为法律判决本身就有不确定性。

所以，我建议把需求分成这几类：

分类	定义	法律AI场景举例
功能需求	系统必须做什么	「能自动提取合同中的违约金条款」
非功能需求	系统做得怎么样	「检索结果必须在2秒内返回」
业务需求	业务目标是什么	「将合同审查时间缩短50%」
用户需求	用户具体怎么用	「律师希望批量上传合同，而不是一份一份传」
约束条件	不能做什么	「不能存储当事人的敏感个人信息」

需求分析在AI产品中的重要性

为什么需求分析对AI产品特别重要？原因有三：

1. AI有「黑箱」特性：传统软件你写什么功能它就做什么，但AI模型的行为不完全可控。需求分析不到位，模型训练出来可能完全跑偏。
2. 数据决定了AI的边界：法律AI需要大量标注数据。如果需求没搞清楚，你标注的数据可能全是废的。我见过一个团队花了三个月标注「合同风险条款」，结果发现客户要的是「合同合规审查」——两个概念差远了。
3. 法律场景的特殊性：法律行业容错率极低。一个错误的判决预测，可能影响当事人的一生。所以需求必须精确到「什么情况下AI可以给建议，什么情况下必须转人工」。

需求分析的核心流程

嗯，这部分我直接给框架图吧。这是我多年总结出来的，适合法律AI产品的需求分析流程：

这个流程看起来是线性的，但实际上是个循环。我特别强调反馈循环——你验证时发现需求不对，就得回到采集阶段重新来。别怕麻烦，我见过最惨的项目，需求确认阶段没发现问题，上线后才发现用户要的根本不是这个。

每个阶段具体怎么做？

需求采集：别只问「你想要什么」。我习惯用「场景还原法」——让用户描述一个完整的工作场景。比如律师审合同，从收到邮件开始，到最终签字结束，中间每一步都问清楚。

需求分析：这里要区分「核心需求」和「边缘需求」。法律AI产品，核心需求往往是「提高效率」或「降低风险」。边缘需求可能是「界面好看」——嗯，虽然也重要，但优先级可以往后放。

需求验证：我建议做低保真原型。别一上来就写代码，用Axure或Figma画个界面，让用户点一点。你会发现，用户看到原型后说的「对对对，就是这个」，和之前说的「我想要那个」，往往不是一回事。

需求确认：最后一步，写需求文档。但注意，法律AI的需求文档要特别注明数据边界和模型能力边界。比如「本系统仅适用于合同金额100万以下的租赁合同审查」——把话说死，后面少扯皮。

好了，这一章就到这里。记住一句话：需求分析省下的时间，会在开发阶段加倍还回来。我踩过的坑，希望你别再踩一遍。