一、从业务现象出发，别先选工具
“需要一个 AI 平台”和“需要更准确的补货判断”，对应的项目完全不同。前者很容易变成采购清单；后者要求先查清 SKU、仓库、在途和销量预测分别由谁负责。第一次讨论，我更愿意让企业拿出一张真实订单、一份报表和一条异常记录。
| 看到的现象 | 先核实什么 | 建议先做 | 第一项验收 |
|---|---|---|---|
| 店铺利润、财务报表与 ERP 各算各的 | 退款归属、汇率日期、平台结算周期、广告与仓储费用分摊 | 统一指标定义，建立订单到结算的可追溯数据链 | 抽取已结算订单，能逐项说明收入、费用和差额来源 |
| 海外仓有货，前台却缺货或超卖 | SKU 映射、可售与实物库存的区别、接口延迟、取消单与退货事件 | 补齐事件同步、幂等处理、对账与异常告警 | 重放重复、延迟和乱序事件，库存结果仍可核对 |
| 多语言客服反复查询物流与售后规则 | 身份核验、订单查询接口、按站点生效的政策、人工接管路径 | 从只读查询和回复草稿试点，再评估是否开放业务写入 | 未授权用户查不到他人订单；政策无依据时转人工 |
| 老板每天追问销售、毛利与库存变化 | 指标口径、数据截止时间、店铺与市场权限、异常定义 | 先做可信经营看板，再让 AI 解释变化并链接原始记录 | 回答给出口径、时间和来源；同一问题能与看板核对 |
这张表有一个共同点：先建立可靠的业务事实。模型可以帮助理解和表达，但不应替企业决定哪一套库存、利润或客户身份才是真的。关于数据底座，可继续阅读ERP 与数据仓库的基础作用。
二、保留能用的系统，把责任边界接清楚
判断 ERP 要不要换，我会先看三件事：核心交易能否稳定运行，关键数据能否获取，必须变化的流程是否被系统彻底卡住。若前两项成立，增加集成与数据层往往值得先验证；若基础交易已频繁失真，给它加一个聊天入口只会把问题放大。具体尽调方法见旧系统该留、该改，还是该换。
- 交易系统保管事实。订单、库存、采购、退款仍由相应业务系统执行并留痕。明确每类实体的权威来源，避免同一份数据多处自由修改。
- 集成层处理可靠性。接口鉴权、限流、重试、幂等键、事件顺序和定期对账应有明确实现。尤其不能让一次工具调用重试变成两次退款或两张采购单。
- 数据与知识层提供依据。经营指标记录计算口径与更新时间；客服规则按站点、产品、版本和生效时间检索。历史政策不能混入当前答案。
- AI 层理解、建议与受控执行。先读数据、出草稿，再按风险逐项开放操作。涉及改价、退款、采购与客户承诺时，分别设置权限和人工确认。
- 运营机制兜底。每次执行能追到请求人、输入、工具参数和结果。出现错误时，有暂停入口、补偿处理和人工接管人。
在多市场业务中，还要提前约定币种、时区、语言和业务日的含义。“昨日销量”应按哪个市场的日期计算，是接口设计时就该回答的问题。数据托管与访问范围也应在方案阶段逐项核对。
三、用 90 天验证一项能力，再决定是否扩建
下面是一种试点安排，适合范围已收敛、关键数据可获取、业务负责人能参与的项目。它是讨论建设顺序的参考，不是所有企业的固定工期。ERP 迁移、历史数据补齐或外部接口审批可能需要单独排期。
第 1—15 天：把问题查实
梳理一条端到端流程，抽样查看正常和异常记录，记录当前处理时间、错误与返工。交付问题清单、系统依赖图、指标定义和首个试点范围。
进入下一阶段前：业务负责人确认问题值得解决，技术负责人确认数据和接口确实可用。
第 16—45 天：跑通受控闭环
连接最少的系统，先只读或影子运行。让模型结果与原流程并行比较，收集答错、拒答、接口失败和权限异常，形成可重复使用的评测集。
进入下一阶段前：业务验收人认可评测样本；失败有处理办法，而不只是演示顺利。
第 46—75 天：小范围进入真实业务
限定店铺、站点、品类或一组客服。按批次扩大使用，记录人工修改、接管、业务结果和总成本。对新增写入能力单独验收。
进入下一阶段前：能够识别错误影响范围，出现问题能暂停并回到原流程。
第 76—90 天：交接与投资决策
交付代码与部署说明、接口清单、评测集、告警、权限表和操作手册。让接手团队独立完成一次更新、回归验证与故障演练。
阶段结论：继续扩展、缩小范围、补基础，或者停止。每个选项都要附业务证据。
负责人不能只填“业务部门”和“供应商”。项目至少需要四个明确角色：决定投入的人、负责日常流程的人、对技术方案与上线负责的人、能够签字验收的人。一人兼任可以，责任空缺不行。
四、验收看真实任务，也看失败怎么处理
“准确率达到某个百分比”不能单独代表业务可用。先固定任务范围、样本组成、正确答案和评分规则，再分别报告各类任务的结果。退款查询答对、身份越权答错，不能简单平均成一个漂亮数字。
- 业务结果：用同口径样本比较处理时间、完成率、返工与人工接管。样本中应包含不同站点、语言、订单状态及异常情况。
- 事实与权限：回答是否有数据来源，规则是否在有效期内，角色是否只能访问自己有权限的客户和店铺。
- 接口可靠性：超时、限流、重复请求和部分失败是否可恢复，是否产生重复业务操作。
- 运营与交接：谁查看告警、谁维护知识、模型或提示更新后如何回归，供应商离场后能否继续运行。
先按“有效完成一次业务任务”算成本。统计周期内的模型、软件、基础设施、人工复核、返工和维护成本，应共同纳入，再除以有效完成任务数。一次性集成费用另列，并按企业约定的使用期摊入投资测算。不要只比较模型单价。
对收益也要做同样的检查：节省了操作时间，不等于立刻减少现金支出；客服响应更快，也不等于销售提升全部来自 AI。先说明收益如何发生、如何衡量，再谈是否扩大投入。可直接下载技术项目优先级与验收工作表（CSV），将候选项目放在同一套条件下比较。
五、找技术顾问，先看能否给出这些判断
出海企业常缺的不是会展示工具的人，而是能同时看懂业务流程、系统依赖和交付风险的人。选顾问或供应商时，可以围绕下面几件事展开讨论。
- 能否说明哪些需求应该延后。路线图需要写清依赖和取舍，而不只是将所有需求装进一期。
- 是否愿意检查真实接口与样本。只看产品演示，不核实企业当前数据，很难估计集成工作量。
- 能否在报价前约定验收方式。交付范围、失败处理、变更机制、数据与代码交接应能进入合同附件。
- 能否说明持续成本和退出方式。账号归属、服务依赖、配置导出、模型替换及供应商交接，都应有具体安排。
如果企业缺技术负责人，可评估外部 AI 技术办公室；已经有团队，则可用技术诊断与路线图明确优先级，再决定由内部实施还是共同交付。已有应用需要持续改进时，重点转向评估、运营与交接。
讨论技术建设时，经常被问到的几个问题
做 AI 之前一定要换 ERP 吗？
不一定。先核实 ERP 的交易稳定性、数据可获取性和关键流程约束。能够稳定提供业务事实的系统可以保留，通过接口与数据层支持试点；基础交易已失真或关键能力无法扩展时，再评估改造与替换。
没有 IT 团队，还能做技术与 AI 试点吗？
可以，但企业必须指定业务负责人，并补上技术责任机制。先选择范围小、数据可获得、结果可验收的流程，由外部技术负责人协调架构、供应商、上线和交接，避免采购后无人持续负责。
数据质量一般，是先治理数据还是先验证 AI？
先检查目标流程需要的最少数据。若订单身份、库存数量或结算口径等关键事实不可信，应先修复；若局部数据足以支撑只读查询或草稿生成，可以在明确边界内并行验证，不必等待全公司数据全部治理完成。
第一阶段应该交付什么，才算值得继续投入？
至少交付业务基线、流程与系统依赖图、可重复的评测集、试点结果和下一阶段建议。试点应说明成功与失败分别发生在哪些任务上，谁处理异常，继续投入需要满足什么条件。