主题
专题定位:AI 项目的失败,70% 死在需求阶段——不是技术做不出来,而是从一开始就没搞清楚"到底要解决什么问题、AI 是不是对的锤子、数据够不够支撑"。本专题把"需求工程"从产品经理的 PRD 写作,还原成 FDE 在客户现场的实战方法:怎么从老板一句话里挖出三层需求、怎么辨别真伪痛点、怎么判断该不该上 AI、怎么管住"渐进明细"过程中的需求漂移。所有方法都给可直接套用的模板和检查清单,不卖方法论的概念。
一、AI 需求与传统软件需求的本质差异
照搬互联网产品的需求方法去做 AI 项目,是 FDE 新人最常见的踩坑起点。二者差异不是程度上的,而是类别上的。
差异一:需求是模糊的、涌现的,不是清晰的、固定的。 传统软件需求可以写成"用户登录后跳转到首页,首页显示最近 10 条订单",验收边界明确。AI 项目的需求往往是"帮我把客服工单自动分类""让质检少漏一些缺陷"——这类需求里藏着大量未定义变量:分多少类?谁定的类目?类目之间允许重叠吗?"少漏一些"是少漏多少?这些答案不是客户能一次说清的,而是在数据体检和原型反馈中涌现出来的。把模糊需求当清晰需求做,等于把地基打成流沙。
差异二:需求是数据驱动的,不是功能驱动的。 传统需求问的是"系统要做什么功能",AI 需求首先要问的是"有没有数据支撑做这件事"。一个"用大模型做合同智能审查"的需求,如果客户过去三年的合同都是纸质扫描件、从未结构化、关键条款字段缺失,那么需求本身在当前数据条件下就不成立。需求工程的第一步不是画原型,而是做数据体检——这一步在传统软件里几乎不存在。
差异三:需求是效果导向的,不是规格导向的。 传统软件的验收是"功能 A 跑通、接口 B 返回正确、压测到 C 并发不崩"。AI 项目的验收是"召回率 ≥ 85%、误报率 ≤ 5%、人工复核工作量下降 40%"——这类指标天然带有概率性和波动性,不可能 100% 确定。这意味着需求文档里必须写效果区间和兜底机制,而不是写"必须 100% 准确"(这是 AI 项目最常见的不合理需求)。
差异四:需求会随系统上线而变化。 传统软件上线后,需求基本冻结,进入维护期。AI 系统上线后,用户会根据系统的实际表现反过来调整自己的预期和用法,原本"自动分类"的需求会演化成"自动分类 + 置信度标注 + 低置信转人工 + 每周类目复盘"。需求工程在 AI 项目里是一个贯穿全生命周期的持续活动,而不是一个前置阶段。
一句话原则:传统需求工程是"把客户说的话翻译成规格";AI 需求工程是"和客户一起,在数据和原型反馈中,共同发现真正值得解决的问题"。
二、需求的三层结构:战略层 / 价值层 / 约束层
客户高层一句话需求(比如"我们要上大模型""今年要搞 AI 质检")背后,实际压着三层完全不同的东西。FDE 进场第一周的核心任务,就是把这三层拆开,分别记录、分别对齐、分别验证。
第一层:老板想做的(战略层)。 这一层回答"为什么是现在做、为什么是 AI 做、做完对老板意味着什么"。常见动机包括:对上有数字化/AI 化考核指标、对同业有对标压力、对内有降本增效 KPI、对投资人有故事可讲。战略层需求不能直接拿来设计系统,但它是项目立项和预算的源头,忽视它会导致项目"做对了事却拿不到验收"——比如系统真降本了,但老板要的是"对外能讲故事",结果验收时各种挑刺。
第二层:业务真正需要的(价值层)。 这一层回答"一线业务到底痛在哪里、解决之后能省多少时间/钱/差错"。这一层只能通过跟一线泡在一起挖出来,老板说不清,中层说不准。典型例子:老板说"我们要 AI 客服",业务一线真正痛的是"夜间值班客服查不到历史工单",正确的解法可能是给夜间客服配一个工单检索 RAG,而不是上一个全量对话机器人。
第三层:技术上可行的(约束层)。 这一层回答"在现有数据、算力、网络、合规边界下,能做到什么程度"。这一层是 FDE 的专业判断,客户任何一层都给不出准确答案。常见约束:数据量不够训练专用模型(只能用通用大模型 + Prompt)、数据出不了内网(只能本地部署小模型)、合规要求留痕(必须每条结果可追溯)。
三层需求往往互相打架:战略层要"全量自动化",价值层只要"减少 30% 重复劳动",约束层只允许"半自动 + 人工复核"。FDE 的工作不是消灭冲突,而是把三方拉到一张桌子上,用一张"三层需求对齐表"把矛盾显性化,然后共同做取舍。
三层需求对齐表(模板)
| 维度 | 战略层(老板) | 价值层(一线) | 约束层(技术) | 对齐结论 |
|---|---|---|---|---|
| 真实诉求 | 对集团讲 AI 转型故事 | 夜间客服查历史工单难 | 内网部署、数据不出 | 上线内网工单检索 RAG,作为 AI 转型首期落地案例 |
| 成功标准 | 集团简报有素材 | 单工单处理时长 -20% | 召回 ≥ 85%、响应 < 3s | 三项均纳入验收指标 |
| 优先级 | 高(年内要出成果) | 中(能用上就行) | 数据准备需 3 周 | MVD 范围限定为 3 个高频业务类目 |
| 风险 | 故事讲太大后续难收 | 一线不愿用新工具 | 历史工单字段缺失 | 灰度先行 + 字段补录流程 |
三、需求挖掘的五种方法
需求不是问出来的,是挖出来的。FDE 在 Context 阶段至少要用到以下五种方法中的三种,任何单一方法都会带来系统性偏差。
方法一:浸泡观察(Shadowing)。 跟着一线业务人员完整走 1-3 个班次,不提问、不打断,只记录他每分钟在做什么、用了什么系统、卡在哪里、用什么 Excel/微信群 workaround。浸泡观察能挖到访谈挖不到的东西,因为一线自己已经习惯了某些低效操作,问不出来。关键纪律:不要只看熟练工,要至少跟 1 个新手和 1 个绩效靠后的员工,后者的痛点往往才是真痛点。
方法二:多层级访谈。 至少覆盖三级:高层(战略 + 预算 + 验收口径)、中层(流程 + KPI + 部门利益)、一线(实际操作 + 真实痛点 + 对工具的态度)。三级访谈要分别做、分别记录,然后做一次"三角验证"——同一件事三级说法不一致的地方,就是需求模糊地带,要重点澄清。反模式:只访谈对接人(通常是中层),拿到的需求是经过中层过滤的版本,既不代表高层意图,也不反映一线实情。
方法三:数据体检(Data Audit)。 在动手设计前,先把客户相关业务系统的数据抽样出来,系统性地回答六个问题:有哪些数据源、数据量级、字段完整度、历史覆盖时间窗、质量(缺失率/错误率/重复率)、合规边界(能否用于训练/能否出网)。数据体检报告是后续所有需求可行性的地基。常见坑:客户说"我们有十年的数据",体检发现真正结构化、字段齐全的不超过六个月,其余都是扫描件或自由文本。
方法四:竞品/同业分析。 调研同行业已经落地的类似 AI 项目,看他们做了什么、没做什么、踩了什么坑。同业案例的价值不在于抄,而在于校准预期——客户经常因为看了某篇行业新闻,对一个 AI 项目的效果和周期产生不切实际的预期。把同业真实数据(召回率、上线周期、投入人力)摆出来,是管理预期最有效的工具。
方法五:5 Why 根因追问。 当客户提出一个具体需求时,连续问五次"为什么",把表层诉求追到根因。典型例子:
客户:"我们要一个 OCR 识别发票的系统。" Why 1:"为什么需要?"——"财务录发票太慢。" Why 2:"为什么慢?"——"每张发票要手工敲 12 个字段。" Why 3:"为什么要敲 12 个?"——"其中 8 个 ERP 系统能自动带出,但 4 个必须手填。" Why 4:"为什么这 4 个必须手填?"——"因为供应商主数据不全。" Why 5:"为什么供应商主数据不全?"——"新供应商上线流程没有强制补全。"
追问到第五层,真正的需求不是 OCR 系统,而是"新供应商主数据补全流程 + 4 个字段的 OCR 兜底"。直接照搬表层需求做全量 OCR,是典型的过度设计。
一句话原则:需求挖掘的目标不是"把客户说的话记下来",而是"比客户更懂他的真实问题"。
四、从模糊到清晰:三件套模板
挖出来的需求是散的,要靠三个工具把它们收敛成可设计、可验收的东西:问题定义卡、价值假设、北极星指标。这三件套是 Gate-C(问题定义门)的核心交付物。
模板一:问题定义卡
markdown
# 问题定义卡 v0.x
## 1. 问题陈述(用客户自己的话,一句话)
[谁] 在 [什么场景下] 遇到 [什么问题],导致 [什么可量化的后果]。
## 2. 现状基线(可量化)
- 指标名:[如 工单平均处理时长]
- 当前值:[如 18 分钟/单]
- 数据来源:[如 2025 年 Q4 客服系统导出]
- 测量口径:[如 仅计算人工处理时间,不含排队]
## 3. 目标效果(可量化,带区间)
- 指标名:[同上]
- 目标值:[如 降到 12 分钟/单,降幅 33%]
- 验收口径:[灰度连续 2 周达到]
## 4. 不做什么(明确边界)
- [如 不做对外 C 端客服,只做内部工单流转]
- [如 不做多语言,首期仅中文]
## 5. 关键假设(若不成立则方案失效)
- [如 假设历史 6 个月工单可作为训练/检索语料]
- [如 假设一线愿意在灰度期使用新系统]
## 6. 兜底机制(AI 失效时如何不中断业务)
- [如 置信度 < 0.7 自动转人工,系统不阻断工单流转]
## 7. 干系人签字
- 业务方:____ IT 方:____ FDE 负责人:____问题定义卡的精髓是第 4 条"不做什么"和第 6 条"兜底机制"——这两条是 FDE 守住项目边界的核心。客户天然倾向把第 4 条写满(什么都想要),FDE 的职责是把第 4 条压窄、把第 6 条写实。
模板二:价值假设
价值假设是一句可证伪的话,形式固定:"如果我们做 [X],那么 [Y 业务指标] 会改善 [Z 幅度],因为 [因果机制]。" 例:
如果我们为夜间值班客服上线一个基于历史工单的 RAG 检索系统(覆盖近 12 个月高频类目),那么单工单平均处理时长会从 18 分钟降到 12 分钟(降幅 33%),因为夜间 60% 的工单是历史相似问题的重复,检索系统能让客服在 30 秒内找到参考处置方案,而不是翻 Excel 或问值班长。
价值假设必须满足三个条件:可量化(具体指标 + 幅度)、可证伪(灰度后能用数据验证对错)、有机制(说出为什么 X 能导致 Y,而不是空喊口号)。没有机制的价值假设等于没有假设。
模板三:北极星指标
一个 AI 项目只能有一个北极星指标(其他都是辅助指标)。北极星指标必须满足:与业务价值直接挂钩、可被业务方理解和认可、可量化采集、对方案改进敏感(改方案能反映到指标上)。
北极星指标的常见错误:选"模型准确率"作北极星(业务方听不懂、且准确率高不一定业务价值大)、选"用户满意度"作北极星(滞后、主观、采集成本高)、同时定三个北极星(互相打架时无法决策)。正确做法:从问题定义卡的目标效果里直接继承一个指标作北极星,其余指标作为诊断用,不参与验收主判断。
五、需求的真伪辨别:真痛点 vs 伪需求
客户提出的需求里,真伪混杂。FDE 要用一套结构化方法辨别,而不是凭经验拍脑袋。最实用的工具是**"可解性 × 价值"二维矩阵**。
| 高价值 | 低价值 | |
|---|---|---|
| 可解(AI 能搞) | 第一象限:真痛点,优先做 | 第三象限:锦上添花,排后做或不做 |
| 不可解(AI 搞不了/数据不够) | 第二象限:重要但当下做不了,转人工/改流程/等数据 | 第四象限:伪需求,直接砍 |
判断"可解性"的检查项:
- 是否有足够且质量达标的数据?(没数据 = 不可解)
- 任务是否有可定义的正确答案?(开放式创作 = 难评估 = 半可解)
- 错误的代价是否在业务可承受范围?(医疗诊断/法律判决 = 高代价 = 需要人机协同)
- 是否有清晰的输入输出边界?(输入是整个互联网 = 不可解)
判断"价值"的检查项:
- 影响多少用户/多大业务量?(只影响 3 个人 = 低价值)
- 现状 baseline 的痛感有多强?(没人吐槽 = 低价值)
- 解决后能省多少时间/钱/差错?(算不出钱 = 多半低价值)
- 是不是"做了之后才发现根本没人用"的需求?(问一线愿不愿意用)
伪需求的四种典型来源,看到就要警惕:
- 领导拍脑袋型——"别的公司都有,我们也要有",没有业务场景支撑。
- 供应商忽悠型——"用我们的大模型什么都能做",把技术能力当业务需求。
- 需求错配型——业务真正痛的是流程问题,却包装成 AI 需求(如上面 5 Why 例子)。
- 未来焦虑型——"现在不做怕落后",但当下既无数据也无场景。
辨别真伪的核心动作:拿着需求去找一线验证。一线说"这玩意儿就算做出来我也不会用",基本就是伪需求;一线说"要是有这个我每天能早下班一小时",基本就是真痛点。
六、AI 适用性判断:哪些该用 AI / 哪些用规则 / 哪些改流程
不是所有问题都该用 AI 解。FDE 必须在需求阶段就给出"该用什么锤子"的判断,否则会出现"用大模型解一个 SQL 就能解的问题"的荒谬局面。
判断流程,按顺序问四个问题:
第一问:能不能用规则/配置解决? 如果业务逻辑是确定性的、规则可枚举的(如"金额超过 10 万走审批""周末不计加班费"),就不要用 AI。规则的好处是 100% 可解释、100% 可控、零幻觉。反模式:为了"用上 AI"而把明确的规则硬塞给大模型,结果是模型偶尔出错、业务方失去信任、还多花一笔推理费。
第二问:能不能用传统软件/统计方法解决? 如果是结构化数据的分类/预测,样本量大且稳定,传统机器学习(随机森林、XGBoost)往往比大模型更准、更便宜、更可控。大模型的优势在非结构化文本理解、少样本、多任务泛化,在结构化数据上并不占优。
第三问:如果用 AI,用通用大模型还是微调/小模型? 判断依据是:任务复杂度、数据量、延迟要求、成本预算、合规要求。通用大模型 + Prompt + RAG 能覆盖 80% 的非结构化场景;只有当任务高度垂直、数据量大、对延迟/成本敏感时,才考虑微调或本地小模型。
第四问:如果 AI 解决不了,能不能改流程解决? 大量"AI 需求"其实是流程问题。例如"AI 自动审批报销"——如果报销审批规则本身混乱、审批节点冗余,改流程比上 AI 见效更快、成本更低。FDE 要敢于对客户说"这个问题不该用 AI 解,改流程就行",这反而是专业度的体现。
AI 适用性快速判断表
| 任务特征 | 推荐方案 |
|---|---|
| 规则明确、可枚举 | 规则引擎/配置,不上 AI |
| 结构化数据、样本足 | 传统 ML(XGBoost 等) |
| 非结构化文本、少样本、多任务 | 通用大模型 + Prompt + RAG |
| 高度垂直、数据量大、延迟敏感 | 微调 / 本地小模型 |
| 开放式创作、无标准答案 | AI 辅助 + 人工终审 |
| 流程冗余导致的"效率低" | 改流程,不上 AI |
| 错误代价极高(医疗/法律/安全) | 人机协同,AI 只做初筛 |
七、需求变更管理:渐进明细与阶段门控制
AI 项目的需求必然会变——这是数据驱动和效果导向的必然结果,不是客户"作"。FDE 的工作不是阻止变更,而是用结构化方法让变更可控、可追溯、不失控。
原则一:渐进明细(Progressive Elaboration)。 承认需求会随数据体检、原型反馈、灰度数据而逐步清晰,不要在 C 阶段强行冻结需求。但要明确每一阶段的"需求成熟度":C 阶段是问题级(搞清楚解决什么问题)、D 阶段是方案级(搞清楚怎么做)、E 阶段是细节级(搞清楚每个字段怎么处理)。每一级都有对应的文档和签字,不允许跨级跳。
原则二:阶段门控制。 每个阶段结束有 Gate,通过即锁定该级需求,后续变更必须走变更流程。Gate 不是阻止变更,而是让变更有成本——变更要重新评估范围、工期、验收标准,而不是口头一句"再加个功能"就吞下去。
变更控制流程(轻量版,适合 FDE 项目)
- 任何变更必须提变更申请单(一段话:变更内容、原因、影响范围、期望时间)。
- FDE 评估变更的三影响:对范围的影响、对工期的影响、对验收指标的影响。
- 三影响任一超过阈值(如工期 > 3 天、验收指标变动),必须客户业务方 + FDE 负责人共同签字。
- 变更登记到变更日志,每周复盘变更来源(客户主动 / FDE 发现 / 数据驱动),识别需求漂移模式。
- 重大变更(改变 MVD 范围或北极星指标)触发 Gate 重开,重新对齐三层需求。
需求漂移的预警信号:变更频率突然上升(每周 > 3 条)、变更来源集中在某一类(全是老板临时想法)、变更之间互相矛盾(这周加的下周又删)。出现这些信号要立刻停下来做需求重对齐,而不是继续埋头做。
八、需求文档:轻量 PRD for AI
传统 PRD(几十页、含完整交互稿、用例图)在 AI 项目里既重又无效——因为 AI 的行为本身是概率性的,无法像传统软件那样逐字段定义。AI 项目用轻量 PRD,核心是五块:场景、数据、约束、效果、兜底。
轻量 PRD for AI 模板
markdown
# [项目名] AI 需求文档 v0.x
## 1. 场景(Scenario)
- 用户角色:[谁用]
- 触发条件:[什么时候用]
- 使用频率:[每天/每周多少次]
- 典型用例:[2-3 个真实业务场景描述,不是抽象功能点]
## 2. 数据(Data)
- 输入数据:[字段、格式、来源、量级]
- 历史样本:[是否有标注、量级、时间窗]
- 数据质量:[缺失率、错误率、已知问题]
- 合规边界:[能否用于训练、能否出网、留痕要求]
## 3. 约束(Constraints)
- 部署:[云/本地/混合,是否出网]
- 性能:[延迟、并发、吞吐]
- 成本:[单次推理成本上限、月度预算]
- 合规:[行业准入、数据安全等级、审计要求]
## 4. 效果(Effect)
- 北极星指标:[名称、baseline、目标、验收口径]
- 辅助指标:[2-3 个诊断指标]
- 评估方法:[测试集、灰度对照、A/B]
- 验收门槛:[连续 N 周达到 X]
## 5. 兜底(Fallback)
- 置信度阈值:[低于 X 转人工]
- 异常处理:[模型不可用时业务如何继续]
- 人工复核机制:[哪些结果必须人审]
- 降级方案:[性能不达标时关闭哪些功能]轻量 PRD 的精髓:每一条都要可执行、可验证、可追溯。写得越长不代表越专业,反而往往是没想清楚才用篇幅掩盖。一份合格的 AI PRD 应该在 5-8 页内说完,FDE 能用它和客户、和开发、和自己对齐,这才算合格。
九、反模式:FDE 需求工程的五个坑
把踩过的坑总结成反面教材,比讲方法论更管用。
反模式一:照单全收。 客户说什么就记什么、要什么就答应什么,把 FDE 退化成"需求传声筒"。结果是范围爆炸、工期失控、最后做出来的东西没人用。破解:每条需求都过一遍真伪辨别和 AI 适用性判断,敢对客户说"不",这反而是专业度的体现。
反模式二:过度设计。 客户只想解决一个具体问题,FDE 却设计了一个"通用 AI 中台""全场景智能助手"。过度设计的根源是技术自嗨和简历驱动开发。破解:严格圈定 MVD 范围,把"不做什么"写得比"做什么"还详细,每加一个功能都要问"这个功能去掉,北极星指标还能达成吗"。
反模式三:忽视数据可行性。 需求设计得很漂亮,数据体检没做或做得粗,做到一半发现数据不够、质量差、出不了网,项目卡死。破解:数据体检前置到 C 阶段第一周,数据不达标的需求直接砍或转方案,绝不带着数据问题进入开发。
反模式四:把战略需求当业务需求做。 老板要的是"故事",FDE 却老老实实做了一个朴素的内网工具,验收时老板不满意;反过来,老板要的是降本,FDE 却搞了一个炫技 demo,一线用不上。破解:三层需求对齐表强制使用,每个 Gate 都让三层代表同时在场,矛盾当场暴露当场取舍。
反模式五:需求文档一次性写死。 C 阶段写一份"完整 PRD",然后假装需求不会变,开发到一半发现 PRD 早过时了,要么硬着头皮按过时 PRD 做,要么口头改需求但文档不更新,最后交付物和文档对不上,无法追溯。破解:渐进明细 + 阶段门,每级需求文档对应一级成熟度,变更走流程、进日志,保证任何时刻文档都是当前真实状态的反映。
本专题小结
AI 项目的需求工程,FDE 视角下归结为五句话:第一,AI 需求是模糊、涌现、数据驱动、效果导向的,不能套传统软件的需求方法。第二,一句话需求背后压着战略/价值/约束三层,必须拆开分别对齐,用三层需求对齐表把矛盾显性化。第三,需求是挖出来的,浸泡观察 + 多层级访谈 + 数据体检 + 竞品分析 + 5 Why,至少用三种,单一方法必带偏差。第四,从模糊到清晰靠三件套——问题定义卡(含"不做什么"和"兜底")、价值假设(可证伪)、北极星指标(只有一个)。第五,需求工程贯穿项目全周期,渐进明细 + 阶段门控制是管住变更的唯一办法,轻量 PRD for AI(场景/数据/约束/效果/兜底)是承载物。最后,AI 适用性判断要敢说"这个不该用 AI"——真正的专业不是什么都用 AI 解,而是只在该用 AI 的地方用 AI。