找人开发 AI 智能体前，先填这份需求文档

找人开发 AI 智能体前，最有用的材料不是一串功能名，而是一份描述“谁在什么情况下，把什么交给系统，系统允许做什么”的需求文档。先把一个实际任务写完整，供应商才能判断需要知识库、固定工作流还是额外开发。这份方法适合业务负责人起草需求，不能代替业务制度本身的审批。

用一个结果代替抽象目标

“提高客服效率”可以是目标，却不能直接作为开发输入。把它改写为：已登录客服提交产品编号和问题，系统查已批准的售后条款，返回带来源的答复草稿；缺少产品编号时追问，不允许自行承诺退款。这样，成功结果、缺失信息与禁止动作都有了落点。

需求文档首页先说明当前做法。是谁接收问题、在哪里查资料、哪一步最容易返工、最后由谁承担答复责任。再写希望改变哪一步，例如减少重复查找，而不是把全部判断交给模型。只有先讲清工作对象，才知道聊天界面是否必要、是否需要接现有客服系统。

下载可填写需求文档，内含三个合成任务段落，可直接替换。角色区列业务使用者、资料管理员、审核人和运维人；输入区列文字、文件或系统字段，注明必填项与允许格式；动作区逐条写查询、生成、修改、提交的权限；输出区列字段、来源和状态；人工确认区说明确认发生在哪一步；验收区给输入与期望行为。

角色不宜只写“员工”。普通客服可能只能看公开条款，售后主管可以看内部补偿口径，两者即便输入同一句话，也可能获得不同答案。把访问范围写进角色说明，再要求系统负责人确认身份从哪里取得。用户自己在聊天里说“我是主管”，不能作为访问内部资料的依据。

输入说明也要包含不接受的内容。比如附件只接收脱敏工单，不接收客户证件照片；问题最多涉及一个产品，多个产品时要求拆开。这样的边界既能减少误用，也能防止开发时把未讨论的数据类型默认为支持。文件解析、图片理解与文字问答应分别列出，不要写成一个万能上传入口。

动作写到业务对象。与其说“调用工具”，不如说“读取指定订单的配送状态，不能修改地址”。对写动作继续描述人工确认的呈现内容：提交前展示订单编号、目标系统、将改变的字段和申请理由；用户取消后不得写入。确认按钮需要对应明确动作，不能一开始点一次同意就覆盖后续所有操作。

正常样例：问题包含产品编号，批准条款有答案，系统引用对应版本生成草稿。缺资料样例：输入仅有故障描述，没有型号，系统追问型号并保持待补充状态。越权样例：普通客服要求查看内部特殊补偿规则，系统不给出受限内容，并说明可走主管审批。

每个样例记录期望行为之外，还应写禁止结果、依据资料、判定人和失败后处理。不能只记录一句“回答正确”。若条款规定十四天以内可以申请而不是必然批准，草稿不得改写为“保证退款”。业务负责人应把这些容易被语言流畅性掩盖的区别提前标出来。

当输出要接另一个系统时，用字段契约补足自然语言说明。JSON Schema 官方文档展示了如何声明必填属性，这能帮助双方区分“可能出现的备注”和“必须存在的处理状态”。实际还要补充字段含义、枚举值与缺失时的业务处理，格式合法不等于业务结论可用。

让未参与起草的人按文档走一遍任务。如果他无法判断系统什么时候该停、审核人该看什么、失败记录在哪里，就把这部分补回需求。尤其检查跨系统的步骤：当前系统给出订单号，下一个系统是否使用同一个编号；一个系统写入成功但通知失败，应该补发通知还是撤销动作。

常见失败是需求同时写“完全自动”和“任何问题先问负责人”。这会让操作范围不可判定。解决办法是按风险分支列出可自动完成、只能形成草稿、必须人工接管的任务。若资料存在冲突，则先由业务负责人决定有效依据，开发团队不应凭模型输出替企业确定制度。

需求不是越长越好。先冻结一个任务的字段和验收样例，再把新增流程放到后续清单，避免供应商在讨论中默认为全部纳入。关于平台能覆盖到哪里，可对照低代码能力边界；资料型任务也可看内部知识库专题。

准备好流程和脱敏样例后，可从定制咨询入口提交需求文档。咨询重点是确认任务边界、资料可用性与接口条件，让这份材料成为可讨论、可验收的开发输入。