很多 AI Agent 项目一开始听起来都很顺：“让 AI 自动整理线索”“让 AI 自动回复客户”“让 AI 帮我跑日报”。但真正做起来，最容易卡住的不是模型会不会回答，而是需求没有写清楚。输入从哪里来、输出给谁看、什么情况要人工确认、失败后怎么补救，如果这些没说清，后面很容易变成一边做一边返工。
AI Agent 项目需求文档的作用，不是写一份很厚的 PRD，而是把一个自动化想法变成能评估、能开发、能验收、能维护的交付说明。你可以把本文和 AI智能体与自动化专题、老达AI实践专题 放在一起看，适合个人站长、小团队、AI副业接单和内部效率项目使用。
先写清楚：这个 Agent 到底替谁做什么
需求文档第一段不要写“做一个智能体”。更好的写法，是用一句话说明使用者、任务和结果。
- 使用者：谁会触发它，是运营、客服、销售、老板，还是外部客户。
- 任务：它要处理哪类固定工作，不要一开始就写成万能助手。
- 结果：最后输出什么，是回复草稿、表格记录、任务卡片、报告，还是审批建议。
- 边界：哪些事情不能自动做，必须交给人工判断。
比如“让 AI 自动处理客户咨询”太宽，可以改成：“当表单收到新线索后，Agent 读取客户需求，判断行业和紧急程度，生成一段跟进建议，并把结果写入线索表，等待销售确认。”这句话虽然不华丽，但已经能指导后面的流程设计。
把场景拆成输入、处理和输出
AI Agent 项目最怕“只描述效果，不描述材料”。需求文档里至少要把输入、处理和输出拆开写。
输入要写清数据来源和字段：表单、聊天记录、飞书表格、邮箱、网页、CRM、知识库，分别有哪些字段，哪些字段必填，哪些字段可能为空。
处理要写清判断逻辑：是分类、总结、打分、检索、生成回复，还是调用外部工具。每一步最好都有“成功条件”和“异常情况”。
输出要写清落点：发到群里、写入表格、创建任务、返回给用户、进入审批流，还是只生成草稿给人工复制。
如果这个项目和 Dify、n8n、MCP 或飞书自动化有关，可以参考站内的 AI Agent 任务队列设计。那篇重点讲避免重复执行和漏处理，和本文的需求文档正好互补。
需求文档里一定要有“人工兜底”
很多人写 AI Agent 需求时，默认它应该一路自动跑完。现实项目里更稳的做法，是先把人工兜底写进流程。
- 低风险任务：可以自动执行，比如归类、摘要、生成草稿、写入待确认记录。
- 中风险任务：需要人工确认，比如发送报价、改客户状态、创建正式任务。
- 高风险任务：只能给建议，比如退款、合同、权限开通、删除数据。
在文档里可以直接写：“Agent 可以生成建议，但不得直接发送正式报价；报价必须由负责人确认后发送。”这种限制不是降低效率，而是让项目上线后更可控。站内的 AI自动化接单流程 也强调过，交付项目要先讲清边界，再谈自动化程度。
工具和权限不要写得含糊
一个 Agent 能不能稳定运行，很大程度取决于它能调用哪些工具。需求文档里建议单独列一个“工具与权限”部分。
- 能读取哪些数据：知识库、表格、文件夹、网页、数据库、聊天记录。
- 能写入哪些位置：任务清单、客户表、内容日历、日志表、消息群。
- 能调用哪些外部接口：模型 API、CRM、邮件、飞书、企业微信、支付或订单系统。
- 哪些动作只读，哪些动作可写，哪些动作必须二次确认。
不要只写“连接飞书”或“接入数据库”。更好的写法是：“只允许读取客户线索表的姓名、需求、预算、来源字段；只允许新增跟进记录，不允许删除或修改历史记录。”权限越具体，后面的开发和验收越省事。
给 Agent 写一份可执行 SOP
需求文档不是只给人看的，也应该能变成 Agent 的执行步骤。可以用下面这个结构写 SOP：
- 读取新任务，确认任务来源和唯一编号。
- 检查输入字段是否完整，缺少关键字段时标记为“待补充”。
- 根据规则分类，例如客户类型、优先级、需求阶段。
- 检索知识库或历史案例，提取可参考材料。
- 生成建议输出，保留理由和不确定点。
- 写入记录或发送给人工审核。
- 记录执行日志，包括时间、输入、输出、失败原因和人工处理结果。
SOP 不需要一开始写得很复杂，但必须能让人复盘：这次为什么这么判断？失败在哪里？下一次怎么优化？如果你做的是客户项目，建议把 SOP 和 AI副业交付SOP 一起使用，减少验收时的口头扯皮。
验收标准要写成“可检查”的句子
AI Agent 项目不能只用“效果不错”来验收。需求文档里至少要写几类可检查标准：
- 功能验收：正常输入能跑完流程，输出到指定位置。
- 异常验收：字段缺失、知识库无结果、接口失败时，有明确提示和兜底动作。
- 权限验收：没有越权读取、越权写入或绕过人工确认。
- 日志验收：关键步骤能追踪，出了问题能找到输入、输出和失败节点。
- 业务验收：输出内容能被实际负责人使用，而不是只看起来像答案。
建议在上线前准备 10 到 20 条测试样例，覆盖正常情况、边界情况和故意写得很差的输入。AI Agent 越像一个能执行任务的同事，越需要把“怎么验收”提前写清。
一份轻量模板
如果你要马上开始，可以用这份简版结构：
项目名称：
使用者：
要解决的问题：
输入来源与字段：
处理步骤：
输出位置与格式：
工具与权限：
必须人工确认的动作：
异常情况与兜底：
日志记录：
验收样例：
上线后维护人和复盘周期：这份模板不追求完整覆盖所有项目，但足够把大多数“想做一个 AI Agent”的模糊需求拉回到可交付状态。真正的重点是：先把任务边界写清楚，再让工具执行；先保证流程可控，再逐步提高自动化程度。
老达点评
AI Agent 项目最容易被高估的，是“模型能不能聪明一点”；最容易被低估的，是“需求能不能写具体一点”。对小团队来说，一份好的需求文档不需要很厚，但要把场景、数据、权限、人工兜底和验收标准说清楚。只要这些写清楚，后面无论用 Dify、n8n、MCP，还是直接接 OpenAI API，项目都会稳很多。
