从真实业务问题到AI交付的四步方法

第一步：诊断真实业务问题

• 问题发生在哪个具体流程和岗位
• 当前怎样处理，重复、等待、返工或遗漏在哪里
• 问题多久发生一次，影响什么业务结果
• 谁最了解现场，谁有权确认问题值得解决
• 若暂不处理，企业会继续付出什么成本

第一步的输出：一张问题定义卡

问题定义卡至少写清业务对象、当前流程、可观察损失、相关人员、可用资料和首期边界。不能用“建设一个智能体”代替问题描述，因为智能体是可能的实现方式，不是业务目标。

第二步：定义最小交付方案

• 确定一个真实入口和一个最终业务输出
• 列出首期必须使用的资料、规则和系统连接
• 划分自动处理、人工判断与审批动作
• 明确资料、异常、使用和最终结果的责任人
• 把验收条件和证据在实施前写下来

第二步的继续条件

只有当资料来源、流程边界、负责人和验收方式都能确认时，项目才进入实现。若需要同时改造多个核心系统、没有业务负责人或只能凭主观感受验收，应先缩小范围。

第三步：用真实资料验证最小闭环

• 选择正在发生的任务，不使用为演示专门制作的理想样本
• 先跑通输入、处理、人工确认和业务输出
• 连续验证多批任务，记录处理时间和人工修改
• 覆盖缺失、冲突、越权和连接失败等异常
• 修正后使用新的真实样本复验

第三步的证据

保留输入版本、规则依据、处理过程、异常记录、人工确认、最终输出和业务去向。一次漂亮结果只能证明功能可能可用，连续复做和异常处理才接近交付证据。

第四步：进入业务并完成验收

• 真实使用者能否独立完成下一批任务
• 结果是否进入现有审批、交付、运营或经营流程
• 关键动作是否由正确的人确认
• 过程、异常和结果是否可以追溯
• 试点前后是否能用同一真实口径比较

第四步的决定：扩展、整改或停止

验收不是默认通过。流程稳定且价值可验证时才扩大范围；资料、权限或异常仍有明确缺口时整改或缩小；真实业务无法跑通，或继续投入明显高于可确认价值时停止。

四步中最容易被跳过的事项

• 用功能清单代替业务问题
• 在没有真实资料前承诺效果
• 让技术人员代替业务负责人确认规则
• 只测试正常路径，不测试异常
• 先买工具，再补验收标准
• 项目结束后没有继续、整改或停止的明确结论