先找摩擦，再选模型
有价值的第一项工作，应从一个团队能够描述的流程开始：输入是什么？由谁处理？哪些信息需要复制或检查？哪里经常延迟？下一步应发生什么？这些问题明确之后，再考虑模型。
记录最近一次真实任务，包括涉及的工具和例外情况。如果团队连当前流程都无法达成共识，自动化可能只是让混乱跑得更快。先确认责任人。
寻找输入清楚、反复发生的任务
咨询分配、基于批准资料生成草稿、整理记录、确认状态后通知同事，都可能是合适的起点。输入应相对一致，输出应容易检查。
区分固定规则和理解判断。如果客户选择的服务分类已经对应固定负责人，传统自动化可能足够。长消息需要摘要或意图分类时，AI 才可能有帮助，而且应该设计备用路径。
开发前评估四件事
频率：任务发生得是否足够多，值得投入开发与维护？清晰程度：能否定义正确结果？风险：执行失败或答案错误会发生什么？可观察性：人工能否看到执行经过并纠正问题？
用实际样例记录基线，例如耗时、返工、遗漏交接或重复查找。不要把粗略估算变成收益承诺。基线用于评估试点，不是公开营销数字。
重要操作保留人工审核
优先从草稿、分配建议或只读检索开始。删除记录、发送敏感信息、修改权限等动作，应保留人工审核，并明确系统不能做什么。
先考虑失败，再设计顺利路径。来源可能过时、接口可能不可用、请求可能模糊。系统需要可见的失败状态和明确的人工责任人，不能默默跳过任务。
用一组小而完整的样例验收
收集经过授权的样例，覆盖正常请求、缺少资料、特殊表述和应当转人工的情况。为每条样例约定预期结果。修改前后重复核验，避免正常路径掩盖例外问题。
试点的价值是产生证据，并留下可以维护的交接。如果固定规则解决了问题，就保留固定规则；如果 AI 改善了某一步，就给这一步有限权限和清晰审核路径。只有观察到的收益支持新增复杂度时，才扩展范围。