AI 需求文档怎么写：把「想要智能化」变成可验收需求

AI 需求文档的核心，不是描述「要一个聪明的系统」，而是约定系统解决哪个业务问题、拿什么输入、交付什么结果、在哪些边界内运行，以及怎样才算通过验收。缺少这些约定，开发团队只能猜，业务团队也只能凭演示时的感觉判断好坏。

它可以比传统产品需求文档短，却必须更重视不确定性。普通规则程序按预设路径执行；AI 输出会受输入质量、上下文和模型能力影响。因此，文档既要写期望结果，也要写不确定结果出现时由谁判断、如何转人工、怎样恢复原流程。

先把业务问题压缩成一页决策摘要

不要从「接入大模型」「增加智能问答」或功能菜单开始。需求首页应该让不参加项目的人也能回答五件事：谁在什么环节遇到什么问题，当前流程怎样处理，问题造成什么可观察的影响，本次准备改变哪一步，哪些事情明确不在范围内。这一页定义的是决策边界，不是宣传愿景。

例如，「客服回复太慢」仍然不够具体。更可执行的表述是：售后坐席需要在多个文档中查找保修规则，高峰期首轮答复排队；本项目只为已登录坐席推荐答案和出处，不自动向客户发送，不处理退款审批。问题、用户、环节、目标动作与范围外事项都出现了，后续讨论才有共同对象。

现状基线不必一开始就追求精密，但必须可补测。写明当前处理量、等待时间、人工步骤、返工类型和数据来源；没有可靠数据时，直接标注「待采样」，同时指定采样周期和负责人。先把整条业务路径画清楚，再决定 AI 放在哪个节点，可参考自动化之前要先画清楚什么。若候选节点很多，则用哪些业务适合 AI 自动化的判断框架筛掉输入未数字化、结果难验证或错误不可逆的环节。

输入和输出必须能拿真实样本对照

「读取公司资料」不是输入定义。文档要写成输入契约：资料来自哪个系统或目录，包含哪些文件类型和字段，语言与篇幅可能怎样变化，是否存在扫描件、图片、空字段、重复记录和历史版本，谁有权提供与更新。再附一组脱敏样本，既包含常见情况，也保留几种麻烦输入。没有样本的需求评审，很容易把理想数据当成真实数据。

输出也不能只写「生成答案」。输出契约至少说明交付对象、格式、必要字段、依据和后续动作。客服建议答案可以要求同时返回引用片段、资料版本、无法判断的原因和建议处理队列；表单抽取可以要求固定字段、原文位置及异常标记。结构越明确，越容易自动检查，也越不依赖某个人对文风的主观偏好。

样本集应覆盖正常、边界和拒绝三类结果。正常样本告诉团队理想路径是什么；边界样本检验信息不完整、说法冲突或格式异常时的行为；拒绝样本确认系统遇到权限外资料、无法核实的问题或高风险动作时会停下来。需求阶段确定这些样本，开发、测试和业务验收才能使用同一把尺。

能力边界要写成允许、禁止和转人工

AI 需求里最容易漏掉的一行，是系统不能做什么。建议把每项能力写成三个层次：允许自动完成的动作，需要人确认后才能继续的动作，以及无论如何都禁止执行的动作。读取公开产品手册、生成内部答复草稿，可能属于第一层；修改订单、给客户承诺赔付，可能需要授权人确认；跨部门读取受限资料，则应直接禁止。具体边界要按企业制度和场景风险确定，不能照抄示例。

边界同时包括数据、用户、工具和动作。谁能提交任务，系统能看到哪些字段，能调用哪些接口，结果可以保存多久，能否写回业务系统，都要落到文档。涉及公司资料时，可用管理者需要先确定的数据边界检查资料分级、授权、外发和留存。权限设计不是上线前补一个账号开关，而是需求本身。

转人工也要有具体去处。「交给人工」如果没有队列、优先级、通知方式和接手时限，只是把失败藏起来。文档应说明触发条件，例如信息缺失、多个来源冲突、置信不足、用户要求人工或动作超过授权范围；还要说明人工处理后的结果是否回写，是否用于更新规则或测试集。

正常路径之外，例外才是需求的重点

正常路径往往几句话就能讲完：收到请求，读取资料，生成结果，用户确认。真正决定系统能不能长期使用的，是路径旁边的例外。需求评审时，可以从每个输入、判断、调用和输出节点追问「这里拿不到、看不懂、互相矛盾或执行失败会怎样」，把答案写回文档。

• 输入缺字段、格式损坏或内容超出支持范围时，是拒绝、补问还是进入待处理队列。
• 两个有效资料给出冲突结论时，按版本、发布日期或指定责任人处理，不能让模型自行选择更像真的答案。
• 上游系统不可用、接口超时或写回失败时，是否重试，怎样防止重复提交，何时恢复人工流程。
• 结果质量不足、依据找不到或涉及敏感动作时，必须停止自动路径并保留原始输入与处理记录。
• 用户修改 AI 建议后，最终版本、修改原因和审批人是否留痕，谁可以查看这些记录。

每条例外都要补齐检测方式、处理责任、恢复路径和留痕要求。只写报错文案不算处理方案；只写「系统自动重试」也不够，因为重试次数、重复执行风险和最终接手人仍然未知。把例外写清，开发团队才知道要建设哪些保护层，业务团队也能估算真实运营工作量。

验收条件要覆盖质量、效率和运行状态

「回答准确」「提升效率」「用户满意」都不是可直接验收的条件。合格的条件必须带上样本、口径、阈值、责任人、时间窗口。例如，谁准备测试集，哪些问题计入分母，引用正确与答案可用分别由谁判断，低质量结果是否成功进入人工队列，试点运行多长时间后做决定。具体写法可参照把效率提升变成可检验条件。

质量指标不宜只剩一个平均准确率。不同错误的业务后果不同：漏掉必填字段可以补录，给出错误价格可能需要立即拦截。需求文档应把关键错误单独列为否决项，再用一般质量指标观察其余结果。效率也不能只看生成耗时，要把人工准备、复核、返工和异常接管一起计入，否则系统端快了，整条流程可能反而更慢。

运行状态是第三类条件，包括可用性、失败告警、日志完整性、权限验证和回退演练。这里不必预设一个适合所有项目的数字，而要让业务风险决定门槛：内部低风险建议工具可以边使用边修正；对外发送、写回核心系统或影响客户权益的动作，需要更严格的人工闸门和停止条件。

把一句坏需求改成可交付的版本

原始表述的问题不在短，而在没有判断依据

假设原始需求只有一句：「做一个 AI 客服，自动回答客户问题，准确率要高。」它没有限定客户类型与问题范围，没有资料来源，没有说明自动发送还是坐席辅助，也没有定义「高」由谁、用什么样本判断。供应商可以做出一场漂亮演示，却无法据此估算数据整理、接口、测试和长期运营。

重写后的需求先锁定一个可闭环场景

可交付的版本可以这样组织：为已登录售后坐席提供保修政策答复建议；输入为客户问题、产品型号和当前有效的政策库；输出包含建议答案、引用出处、适用条件和无法判断标记；首期只覆盖已确认的高频问题，答案必须由坐席确认后发送；资料冲突、产品型号缺失或问题超出范围时进入指定队列；用冻结的测试集和一段真实试运行共同验收，并记录复核、返工与接管时间。

这段话仍不是完整文档，却已经足以拆出数据清单、界面、权限、测试集、异常队列和运营责任。之后再补字段、接口与交互细节，是在共同边界内深化；若连这段场景都无法达成一致，直接进入原型或采购，只会把分歧推迟到成本更高的阶段。

评审顺序决定文档会不会沦为功能清单

评审应按业务问题、用户流程、数据可得性、风险边界、技术方案和验收口径的顺序进行。业务负责人确认问题是否值得解决和范围是否正确；一线使用者验证真实输入与例外；数据、IT、安全或合规角色确认可访问性与约束；技术方和供应商再讨论实现路径。各方谁负责准备、谁最终拍板，可结合企业 AI 项目的职责分工写进文档首页。

需求会变化，但变化必须留下业务理由、影响范围和批准人。新增一个资料源可能带来权限和质量测试，新增自动写回可能改变风险等级，扩大用户范围也会增加培训与运营负担。用变更记录把这些影响摆在同一页，团队才能决定是本期接受、延后，还是用替代方案解决。

一份好的 AI 需求文档不是把未知全部消灭，而是把未知放进可管理的路径：能验证的用样本验证，暂时不确定的设试点观察，需要人判断的保留明确闸门，出错时能够回退和追溯。做到可复核、可回退、可追责，文档才真正把「想要智能化」变成了可交付的工作。