第一个任务要能重复、能核对
代码缺陷初步分析、项目资料整理、工单分类和固定格式报告比较容易建立基线。它们每周都会出现，输入与交付物相对固定，负责人也能说清什么算合格。第一次试点不宜选择“一键完成所有工作”这类范围模糊的目标，因为任何环节出错都会让团队无法定位原因。
优先选择团队每周都会做、输入和完成标准相对稳定的任务。负责人要能判断结果是否合格，试点失败也不能直接影响生产。任务最好有一定人工重复劳动，但又不是完全依赖个人判断；这样既能看出效率变化，也保留人工验收的条件。
一开始铺到全公司，或者同时接入太多系统，会让团队很难判断问题出在产品还是流程。先限定一个团队、一到两项任务和明确的数据范围。等身份、权限、记录和交接都跑通，再复制到下一个团队。
开始前记下现有做法
没有基线，试点结束后只能凭印象判断。不要让团队回忆“以前大概多久”，而是连续观察几次现有流程。把等待审批、寻找资料和人工返工也算进总时间，否则试点只比较模型生成的几分钟，会高估实际收益。
- 从接到任务到完成的总时间；
- 人工处理时间和等待时间；
- 返工次数与常见错误；
- 当前工具、模型和执行资源的成本；
- 结果由谁验收，什么条件算通过。
质量如果难以用一个分数表示，可以使用清单，例如“字段完整、来源可核对、格式符合要求、关键结论经负责人确认”。同一份清单要同时用于试点前和试点后，不能看到结果之后再改标准。
还要记录风险边界：哪些资料可以交给模型，Agent 能调用哪些系统，哪些操作必须由人确认。试点的目标不是绕开这些限制取得最好看的效率数字，而是在真实管理条件下验证能否工作。
连续运行才能看见真实问题
演示时可以挑选理想输入，日常工作不会。连续运行会遇到输入缺字段、权限申请迟迟没批、模型输出波动、工具超时和任务失败，也能看出员工是否愿意继续使用。只跑两三次成功案例，只能证明功能能工作，不能证明流程能长期使用。
每次运行要关联任务、发起人、项目、模型、用量和结果。失败后重试、切换模型或由人工接管，都应保留在同一条任务记录里。用量要归到哪几个维度，见多模型用量、额度与成本的管理方式。
团队每周只需要处理最影响结果的几个问题：哪些输入最常导致返工，哪些权限申请拖慢流程，哪些新需求超出原定边界。不要在试点中不断扩功能。新增需求先记录，只有它阻塞核心任务时才纳入当前周期，否则四到六周后会得到一套边界失控、无法验收的系统。
验收要回答继续、调整还是停止
按试点前的口径比较耗时、返工、成本和通过情况。效率提升但返工增加，或者模型费用下降但人工审核变长，都不能只看其中一个数字。再检查身份是否明确、权限能否回收、用量能否归到任务，以及异常发生时有没有暂停或人工接管方式。
结果合适就扩大到相邻任务；主要问题来自配置或流程，就调整后再跑一轮；数据表明场景不稳定、成本过高或风险无法接受时，也可以停止。停止不是试点失败，它避免企业把更多预算投入不适合的场景。验收结论要写明证据和下一步范围，不能只写“体验良好”。
试点需要留下的记录
- 确定一个团队和业务负责人；
- 选择一到两个高频可验收任务；
- 记录试点前基线与风险边界；
- 配置项目、人员、模型、工具和权限；
- 连续运行并每周复盘；
- 用相同口径验收；
- 形成停止、调整或扩大的书面结论。
这些记录既是本轮验收依据，也是下一轮复制时的起点。没有留下任务范围、配置和异常处理过程，换一个团队后仍然要从头摸索。
常见问题
第一个试点任务该怎么选？
选团队每周都会做、输入和完成标准相对稳定、负责人能判断结果是否合格的任务，并且试点失败不会直接影响生产。
试点前要记下哪些基线？
从接到任务到完成的总时间、人工处理与等待时间、返工次数与常见错误、现有工具与模型的成本，以及由谁验收、什么条件算通过。
为什么要连续运行四到六周？
演示可以挑理想输入，日常工作不会。连续运行才会遇到输入异常、权限申请、模型波动和任务失败，也才能看出员工是否愿意继续使用。
验收只看效率够吗？
不够。还要检查身份是否明确、权限能否回收、用量能否归到任务，以及异常发生时有没有暂停或人工接管的方式。