答案摘要：企业 AI 智能体需求文档要把角色、任务、知识、工具、权限、异常和验收分开描述，不能只写“接入大模型、实现智能问答”。聚匠科技通常先把一个真实业务流程拆成可查询、可生成、可执行和必须人工确认的动作，再据此评估接口、数据与交付范围，并明确甲乙双方责任。
先写业务决定，不要先列模型名称
需求评审最容易失焦的地方，是一上来讨论模型参数、Agent 框架和向量数据库，却没有说明谁在什么情况下使用。客服主管想减少重复工单，销售想快速整理客户背景，员工想查制度，三个目标需要的资料、权限和验收方式完全不同。模型可以替换，业务责任却不能含糊。
一条合格的需求应该能回答：“哪个角色在什么入口发起任务，系统读哪些资料，是否调用业务接口，结果写回哪里，失败后由谁接手。”如果这句话写不完整，开发排期和报价通常也不稳定。
需求表至少拆成六列
| 栏目 | 要写清的内容 | 示例 |
|---|---|---|
| 角色与入口 | 谁使用、从哪里进入 | 客服从企微工作台发起 |
| 任务与结果 | 任务起点、完成条件 | 生成工单摘要并返回工单号 |
| 知识来源 | 资料范围、版本、负责人 | 只引用生效中的售后政策 |
| 工具与字段 | 允许查写哪些接口字段 | 查订单状态，不允许改退款金额 |
| 确认与异常 | 何时停下、转给谁 | 投诉或低置信度转人工队列 |
| 验收样本 | 正常、模糊、越权、失败问题 | 接口超时不得重复建单 |
把“能做”改写成可验收动作
“支持知识库问答”太宽，无法直接验收。可以改成：“员工在钉钉提问报销标准时，只检索当前部门可见且状态为生效中的制度；答案展示制度名称和版本日期；没有依据时明确提示未找到，并给出行政联系人。”这样开发能配置检索条件，业务能准备样本，测试也知道什么算通过。
工具调用同样要写成状态变化。例如“创建 CRM 跟进记录”应继续说明客户主键来自哪里、摘要写入哪个字段、重复提交如何识别、接口失败是否进入待处理队列。AI 文案是否自然只能算体验项，不能替代业务结果验收。
评审前检查清单
- 是否只选了一个主要角色和一个高频流程作为第一阶段。
- 知识资料是否有来源、权限、版本、生效状态和维护人。
- 每个工具是否标明只读、写入、审批或高风险动作。
- 是否定义拒答、转人工、接口超时、重复执行和回滚规则。
- 是否准备真实样本，并给出甲乙双方各自负责的验收项。
除功能清单外，还要补充响应时间、并发、日志留存、数据脱敏、知识更新时效和停用方式等非功能要求。比如“十秒内返回”要说明是首字响应还是完整任务完成；“支持一百人使用”要说明是否同时在线。没有口径的性能数字，到了验收阶段很容易产生不同理解。
需求版本也要可追踪。业务口径、提示词、知识库范围和接口字段发生变化时，应记录提出人、确认人、生效时间和受影响样本。这样问题出现后，才能判断是模型变化、资料过期还是需求本身已调整。
哪些情况先不要进入开发
如果业务流程仍由不同部门各自解释、接口负责人未确定、知识资料没有有效版本，先开发只会把分歧固化到系统里。此时更适合先做流程梳理和资料治理，再进入 AI 智能体定制开发 的 PoC；涉及多步执行时同步评估 工作流智能体，需要跨 CRM、OA、工单协同时再纳入 多系统协同 AI。
