如何撰写AI自动化需求文档：六个关键部分

为什么大多数AI自动化项目始于失望

很多企业在启动AI自动化项目时，只通过一次会议口头描述需求，供应商则按自己的理解"慷慨"地填补空白。三个月后，系统上线了，但没人满意——而且似乎谁都没有明显过错。

问题的根源在于：从"我们想自动化这个"到"一个真正能用的系统"之间，缺少一份写下来的需求文档。大多数团队从未写过它。

一份好的需求文档只需要一页纸。以下六个部分，每一个都有其存在的理由。

第一部分：把任务描述成一份任务

不要写"用AI改善客户服务"。要写出具体的事情，就像你向第一天上班的新人解释一样。

当收到订单状态查询邮件时，在Shopify中找到该订单，检查是否已发货，然后回复物流追踪链接。如果订单超过三十天，或客户在询问退款，则不要回复，标记给Ana处理。

这段话比一页的目标陈述更有价值。它包含了触发条件、涉及系统、执行动作和边界条件。供应商可以据此报价。

关键区别在于：模糊的愿景描述让供应商有巨大的解释空间，而具体的任务描述则把双方拉到了同一个可验证的起点上。

第二部分：业务量与时间要求

每天处理多少次？速度要求如何？每月九百次、容忍四小时延迟，与每天三十次、必须在两分钟内发出，是完全不同的系统，价格也截然不同。

团队经常遗漏这一点，然后对报价感到意外。业务量决定了架构选择——高吞吐允许批处理，低延迟则要求实时响应。提前说明这些参数，能避免后期因性能不达标而产生的纠纷。

批处理与实时响应是自动化架构中两种根本不同的处理模式。批处理指系统按固定周期（如每小时或每天）集中处理一批任务，适合对延迟不敏感、但吞吐量大的场景，例如每月九百次查询、容忍四小时延迟。这种模式实现简单、成本较低，但无法满足即时性要求。

实时响应则要求系统在触发事件发生后数秒或数分钟内完成处理，通常需要事件驱动架构、常驻服务或消息队列，工程复杂度和运维成本都更高。每天三十次、必须两分钟内发出的场景，就必须采用实时方案。

业务量和时间容忍度因此直接决定了架构选型和报价。如果需求文档没有写明这两个参数，供应商只能猜测，而猜测的结果往往偏向自己熟悉的方案，最终可能导致性能不达标或成本超支。

第三部分：三件绝不能单独决定的事

这是区分一份需求文档和一个愿望清单的关键部分。明确写出自动化被禁止单独执行的操作：发放退款、承诺交付日期、联系已投诉的客户、更改价格。

任何涉及金钱、对客户做出承诺、或具有法律约束力的操作，都应出现在这份清单上。 如果供应商没有主动询问这些边界，他们很可能不会在交付物中设置这些限制。

这不是技术问题，而是治理问题。一份没有边界的自动化系统，本质上是在把风险放大后交给机器执行。

第四部分：数据在哪里，谁能授权访问

写明系统名称，并写明谁有权提供访问密钥。这一行能防止整个流程中最常见的延误——不是技术问题，而是项目因为没人知道API凭证归谁管而停滞两周。

如果数据在PDF中，要说明它们是原生文档还是扫描件，因为后者是一个本质不同的问题。扫描件需要OCR处理、格式容错和更高的验证成本，提前说明可以让供应商在报价时就把这部分工作量考虑进去。

OCR（光学字符识别） 是将扫描件或图片中的文字转换为可编辑、可检索文本的技术。与原生PDF（文字以字符编码直接存储）不同，扫描件本质上是一张图片，必须先经过OCR才能提取内容。

在自动化项目中，这意味着额外的工程负担：OCR可能因图像倾斜、分辨率低、手写体或复杂版式而出错，因此需要加入格式清洗、字段校验和人工复核环节。原生PDF可以直接解析文字和表格结构，而扫描件的处理链路更长、错误率更高。供应商在报价时，若不清楚数据是原生还是扫描件，往往会低估工作量，导致后期加价或交付质量下降。提前说明数据的物理形态，是控制项目成本和预期的重要一步。

第五部分："能用"的定义必须可测试

不要写"运行良好"。要写可检查的内容：

从上个月的一百封真实邮件中，它应至少自主处理八十封，所有未处理的内容应出现在Ana的队列中并附上原因。

这样你就有了一个验收测试，双方都知道"完成"长什么样。没有这个，你得到的将是一场关于"做没做完"的争论。

可测试的验收标准还有一个隐性好处：它迫使需求方在项目开始前就梳理清楚自己的预期，而不是在交付后才表达不满。

第六部分：谁负责处理异常情况

指定一个人。每个自动化系统都会产生它不处理的案例。如果没有人负责那个队列，工作只是被转移了，而不是被消除了。这是技术上成功的自动化在商业上失败的最常见方式。

异常处理的人力成本往往被低估。一个处理了80%案例的自动化系统，意味着剩余20%需要人工介入——如果没有明确的责任人，这些工作会散落在团队中，最终导致整体效率不升反降。

异常队列（exception queue） 是自动化系统中用于收集无法自动处理案例的待办列表。每个自动化系统都有其能力边界，例如订单超过三十天、客户询问退款、数据格式异常等，这些情况会被系统标记并转入异常队列，等待人工介入。

异常队列的设计要点包括：每个案例必须附带原因说明（如“超期订单”或“退款咨询”），以便人工快速判断；队列必须有明确的负责人，否则案例会堆积或散落。如果没有人对队列负责，自动化只是把工作从一个人转移到另一个人，甚至因为交接不清而增加整体负担。一个处理了80%案例的系统，剩余20%若无人管理，效率提升会被抵消，甚至出现负向效果。因此，异常队列的责任人必须在需求文档中指定，并配套相应的处理时限和升级机制。

好的供应商会怎么做

好的供应商会给出固定报价，或带着让需求文档更好的问题回来。他们不应该回来要求一次"了解需求"的发现电话，因为你刚刚已经把需求写下来了。

他们偶尔还应该告诉你不要建这个东西。一份在业务量上得分很差、或完全落在主观判断领域的文档，一个靠谱的供应商会拒绝或缩小范围。如果供应商从来没有告诉过你某个任务不值得自动化，那你面对的是一个销售，而不是技术合作伙伴。

一页纸模板

六个标题，一页纸：

1. 任务，写成对新员工的指令
2. 业务量与时间容忍度
3. 绝不能单独决定的三件事
4. 涉及的系统，以及谁能授权访问
5. "能用"的定义，写成可测试的一句话
6. 谁负责异常处理

这份模板的价值在于它的简洁性。它不要求你掌握技术细节，只要求你把已经知道的事情写清楚。而写清楚这件事本身，往往比自动化项目更能改善团队对流程的理解。