AI项目需求把控：当业务提出智能化诉求时的破局之道

业务方最常说的一句话："我们想搞个智能化的 XX。"

听到这话，别急着答应，也别急着回绝。因为"智能化的"三个字，在业务脑子里可能是一种魔法，在你脑子里是一堆工程。中间差着的，就是需求梳理的全部活儿。

我带过十几个 AI 项目，几乎所有需求对接的起点都是模糊的。不是因为业务方讲不清，而是 AI 能落地的场景太多了，业务方不清楚具体该要什么。需求管理的本质，是把"魔法"转译成"工程"。

今天把这套转译方法拆给你，包含真实对话记录和能直接套用的模板。

先搞明白为什么 AI 需求梳理比传统软件难：

传统需求管理的核心是"记录和管控变更"，AI 需求管理的核心是**"转译和甄别真伪"**。你记下来的不是业务讲什么，而是业务真正需要什么——这两者经常对不上。

我处理模糊需求，有一套固定的四步，基本能把魔法变成可落地的需求。

"智能客服"到底智能在哪？是自动答 FAQ，还是自动填单，还是自动处理投诉？这三件事技术方案相差十万八千里。

对话实录：

业务："我们想做个智能客服。"

PM："好的，能具体讲讲智能客服要做什么吗？"

业务："就是用户提问题，AI 自动回答。"

PM："用户一般提什么类型的问题？"

业务："退货流程、订单状态、产品使用说明之类的。"

PM："现在这些问题谁在答？"

业务："客服三个人轮班。"

PM："一天大概多少条？"

业务："大概三四百条。"

到这一步，"智能客服"已经被转译成了"自动回答退货流程/订单状态/产品使用类问题，日处理量 300-400 条"——这已经是一个可以开工的东西了。

转译的关键技巧：追问三件事——"现在谁在干？""怎么干的？""一天几次？"

需求落地的关键，是定义清楚输入是什么、输出要什么样。

比如"智能审合同"，拆解后：

定义到这层，算法才知道要做什么。很多需求卡住，就是因为没拆到输入输出，大家都在聊"智能"这个空词。

拆输入输出的模板：

"不做"这一栏特别关键。 AI 项目最容易范围蔓延——业务说"既然能审合同，那能不能顺手生成合同？"范围一扩，排期和成本全乱。在需求阶段就把"不做"钉死。

业务说"要准一点"，我问"多准算够"。他说"尽量别错"，我说"万分之一的错率和百分之一，成本差十倍，你挑哪个量级"。

需求阶段不逼出量化标准，验收阶段必扯皮。

量化标准的对话技巧：

业务："准确率要高一点。"

PM："现在人工处理的准确率大概是多少？"

业务："大概 90% 左右吧。"

PM："那 AI 目标定多少？和人工持平的 90%，还是比人强一点的 95%？"

业务："当然越高越好。"

PM："95% 和 99% 的成本差 3-5 倍。95% 意味着 100 条错 5 条，99% 意味着 100 条错 1 条。你愿意为多对 4 条多花 3-5 倍的钱吗？"

业务："那就 95% 吧。"

这段对话的精髓：不让业务说"越高越好"，而是让他在具体数字和成本之间做取舍。这才是真实的需求。

量化标准需要定义的内容：

这是我最爱用的一招，也是砍掉最多无效项目的招。

业务说要 AI 自动写周报，我不当场调模型，而是先人工用模板生成一周，给他看："你要的是这种吗？"

哑巴版的操作方式：

很多"智能需求"在哑巴版阶段就被业务自己推翻了——"不对，我要的是能追问的""不对，我要的是能导出 Excel 的""不对，这个格式不对"。

用一个低成本的人工/规则版本快速验证，比直接上模型便宜十倍，还能逼出真需求。

哑巴版验证后，需求通常会大改。改需求在哑巴版阶段只需要 1 小时，在开发后改需要 1-2 周。这就是哑巴版的价值。

AI 需求可以分成四类，我有一个判断框架：

判断需求该不该接的三句话：

三条全过才进立项；过不了，先回去做哑巴版或需求澄清，不进开发。

AI 项目的需求变更比传统项目频繁得多——因为业务在看到 AI 效果之前，自己讲不清要什么。看到效果后，需求会大变。

这不是业务的问题，是 AI 的特性。所以变更管理不能照搬传统项目的"提变更→评估→审批"流程，要更灵活。

我的分层变更管理：

POC 阶段是变更的窗口期。 我鼓励业务在 POC 阶段多提反馈、多改需求——因为这时候改成本低。开发后改成本高，要严格管控。

一个原则：变更可以，但每次变更都要评估"对排期/预算/效果的影响"，并且业务方要签字确认接受影响。 不能白改。

需求转译完之后，要写成一份结构化的需求文档。这是我用的模板：

这份文档不是走形式的——它是后面立项书、验收标准的基础。需求文档写不清楚，后面全乱。

坑一：业务说"都要"。 问业务"智能客服要答什么"，他说"什么都要答"。这是最危险的——范围无限大，永远做不完。解法：逼他排优先级。"如果只能先做一类，你选哪个？"

坑二：只听一个人的。 业务部门领导说要 AI，但一线员工不用。解法：需求调研至少访谈 3 个人——决策者、执行者、受影响者。

坑三：需求转译了一次就不更新了。 转译完需求，过两周业务说"不对，我想了想不是这个意思"。解法：需求文档每次 POC 评审后更新一版，保持和业务确认。

坑四：技术方案先于需求。 算法说"我们用 RAG 做吧"，然后倒推需求。解法：需求先行，技术方案服从需求，不能反过来。

坑五：忘了"不做"的定义。 需求文档只写了"做什么"，没写"不做什么"。结果上线后业务说"怎么不能做 XX？"你说"当时没说要做啊"。解法："不做"栏和"做"栏同等重要，必须写。

AI 项目最大的需求陷阱，是"智能"这个词太魔幻，让人忘了问"到底要解决什么"。

需求管理不是记笔记，是把魔法翻成工程、把空话翻成标准。翻译得越清楚，项目死得越慢。

我做需求管理的心得就一句话：别信业务嘴上说的，信他手上做的。 他说"要智能的"，你去看他现在怎么干活的——那才是真需求。