能回答“报销制度在哪里”的聊天机器人，不等于能整理报销材料的数字员工。后者还要知道任务从哪一步开始、能读取哪些资料、哪些字段必须填写、何时调用系统、遇到例外找谁确认，并为每次操作留下记录。部署应从一个具体任务起步，而不是从“替代一个岗位”起步。

先把任务写成可检查的工作说明

用最近发生过的真实任务描述输入、步骤、输出、责任人和例外。例如“根据工单和设备手册整理处理建议初稿”，输入包括工单字段和获准使用的手册，输出是带来源的草稿，最终处理方案由工程人员确认。只写“辅助运维”无法测试。

同时列出不做的事项：不修改设备参数、不关闭工单、不对安全风险作最终判断。边界写在试点说明中，后面选择模型、接口和页面才不会越做越大。

  • 任务触发条件和结束条件

  • 必需输入、允许缺失项和异常输入

  • 输出格式、必填字段和引用要求

  • 人工确认点、接管人和禁止自动执行的动作

知识、流程、工具、权限和日志要同时具备

知识层保存有效资料及来源；流程层规定步骤和分支；工具层连接查询、表单或工单等获准接口；权限层限制谁能用、能看什么和能做什么；日志层记录输入、检索、调用、结果与人工确认。缺任何一层，系统都容易停在演示状态。

知识库不应把旧版文件与现行文件混在一起，工具也不应使用个人账号。流程中的例外不能只靠模型临场猜，至少要有停止、询问或转人工的明确路径。

按风险决定自动化到哪一步

只读查询、整理草稿、写入暂存区、正式提交和不可逆操作的风险不同。首期可让系统完成检索和草稿，把提交留给人；当样本、接口和责任机制成熟后，再评估是否扩大。审批、付款、人员处分、诊疗及其他高风险决定不应由系统独立完成。

所谓人工确认不是在页面上放一个“确定”按钮。确认人应看到系统准备做什么、依据是什么、影响哪些对象，并能修改、拒绝或要求补充材料。确认动作和最终结果都要记录。

验收要看任务结果，不看对话是否流畅

准备常见、边界、错误资料、无权限、接口失败和重复提交等样本。逐项检查必填字段、来源支持、工具参数、人工接管和日志。记录系统完成情况、人工修改量、失败原因及处理时间，不只挑成功案例演示。

还应做一段时间的受控试用，与现有人工流程对照。若复核成本高于节省的步骤、知识无人维护或异常过多，可以缩小到只读问答或停止，而不是为了“上线数字员工”继续扩大权限。

换一个部门，就要重新问一遍边界

试点通过只对约定岗位、任务、资料版本、接口和环境有效。换部门、换系统、增加正式写入或更换模型时，应重新评估和测试。

部署验收时逐项签字的内容

验收记录应写清通过项、限制项和未解决问题，不能只留一段演示视频。尤其要把人工接管和禁止自动执行的动作交给实际责任人确认。

  • 一个任务是否有真实输入、正确输出和停止条件

  • 知识是否标注来源、版本、权限和更新责任人

  • 工具调用是否使用独立身份与最小权限

  • 人工确认是否展示依据、参数和影响范围

  • 失败、接管、修改和最终结果是否全程可查

  • 误区：聊天效果好就能执行；把个人账号给系统；先追求无人确认再补控制

常见问题

数字员工必须接入业务系统吗？

不一定。它可以先做资料检索、字段摘录和草稿整理。只有任务确实需要、接口条件允许且权限风险已评估时，再接入查询或写入能力。

怎样判断应该转人工？

至少包括资料不足或冲突、无权限、超出任务范围、接口异常、不可逆操作前和高风险判断。具体条件要写进流程并用样本测试。

上线后多久复查一次？

按资料、规则、接口和风险变化确定。重要制度或系统变更应立即触发复测；平时也要查看错误和接管记录，而不是只按固定周期走形式。