在给企业“上 AI”之前，最好先回答一个问题：数据是否准备好说出真相？如果库存数据不准，模型也不会准。如果 CRM 里同一个人有三个不同电话，助手会自信地胡说八道。
本文介绍适用于电商、ERP 和支付网关的可审计数据管道——不承诺奇迹，从设计阶段就纳入业务指标和隐私保护。
推荐顺序
- 业务问题（“降低客服工单”、“优先处理线索”）。
- 单一数据源（ERP、电商、CRM）。
- 质量与 PII。
- 版本管理：数据集 / 导出。
- 小型、可衡量的模型或 RAG。
- 产品（API、面板、自动化）+ 人工反馈。
质量检查清单
- 重复记录与自然键（什么标识一个客户？）。
- “静默”空值（0 vs 空 vs
NULL）。 - 单位和货币（USD/PAB、税费）。
- 漂移：六个月前的目录不是今天的。
- 支付状态与网关一致，而非前端展示的状态。
- 订单和 webhook 时间戳的时区一致。
以 Laravel 为数据源的模式
- 定义事件或实体（订单、线索、工单）及其 JSON/SQL 契约。
- 通过 API 或只读副本提供受控读取。
- 用于导出和摄取的 Jobs/队列（幂等）。
- 带日期 + transform 的 git SHA 的版本化表或文件。
- 新鲜度指标：“最后一笔订单何时到达数仓？”。
以 WordPress / WooCommerce 为数据源
- 订单 + 行项目 + meta：记录哪些 meta keys 重要。
- 用户/客户：按邮箱去重，规则明确。
- 多站点：决定按站点分析还是合并分析。
- RAG 内容：已发布页面、稳定 slug、干净 HTML。
- 避免抓取前端：用只读用户的 REST/export/SQL。
隐私
- 最小化字段（“这份报告需要身份证号吗？”）。
- 环境隔离；不要把完整生产库拷到笔记本。
- 必要时脱敏或哈希。
- 含 PII 的日志设定保留期限。
- 按角色访问——仪表盘也一样。
务实的 RAG
当场景是内部文档、FAQ 或产品目录时，范围清晰的 RAG 往往比昂贵的微调更划算：
- 按元数据（来源、日期、语言）切分文档。
- 存储带版本号的 embeddings。
- 对内用户始终引用来源。
- 衡量：有效引用占比、转人工比例。
- 目录或政策变更时重新索引。
常见错误
- 用测试订单和真实订单混合训练。
- 把前端购物车总额当作收入的“ground truth”。
- 仪表盘没有截止日期或“已取消订单”的定义。
- RAG 无引用：内部用户把幻觉复制给客户。
- 同步任务静默失败。