前面我写了一系列关于智能问数的技术解读文章：
- 《智能问数技术路线与选型》
- 《智能问数语义层框架：Cube Core 介绍》：Cube 是一个开源语义层，可以让组织“define metrics once and use them everywhere”，从 BI、嵌入式分析到 AI agents 都能复用同一套指标定义。
- 《从 Anthropic Financial-Services 看通用企业 Agent 架构》：说明智能问数可以看作业务 Agent 的一种典型实例，智能问数遇到的问题，很多业务 Agent 也都会遇到。
- 《智能问数没有失败，只是需要换一种落地方式》：寻找那些历史包袱更轻、语义边界更清楚、结果更容易验证的新场景，例如 AI-native 系统。
接下来，我准备以一个 AI-native 示例项目《面向个人跨境卖家的亚马逊选品与竞品评论智能问数系统》为例，使用公开数据，从零实现一个语义原生智能问数系统。这个项目会以“智能问数”作为第一入口，但底层不是简单 NL2SQL，而是基于 Cube 构建统一语义层，让人类、AI Agent、Dashboard 和后续机器学习模型都通过同一套业务语义访问数据。由于内容较多，这个项目会做成一个系列。每篇文章都会对应一部分开源内容，随着系列推进，逐步把完整代码和文档开源出来。
本系列对应的开源代码已发布在 GitHub：xuanagi/semantic-native-nlq-demo。
这个项目想验证几件事：
1）智能问数不是一个孤立功能，而是业务 Agent 落地时经常需要具备的一类基础能力。业务 Agent 要从辅助分析走向业务自动化，首先要能正确取数、理解统一口径，并让人类能够审核它基于哪些数据、哪些指标和哪些证据做出了判断。
2）不少智能问数项目，尤其是开源项目，仍然把重点放在 Text2SQL 上，但真实落地时，更难的是业务语义、指标口径和多入口一致性。当前项目使用 Cube 实现语义层，相比直接 Text2SQL，更有利于指标治理、口径复用和多入口一致性；同时，Cube 的缓存和预聚合能力也为后续性能优化提供了空间。
3）语义层的价值不只是服务人类问数。无论是人类查询、业务 Agent 调用、Dashboard 展示，还是后续机器学习特征生成，都应该复用同一套业务语义，而不是在不同提示词、SQL 脚本和 Notebook 里各算各的。
4）这也是对之前提出的“语义原生”路径的一次实践：传统路径是“先乱后治”，AI-native 路径应该是“边建边沉淀语义”。
一、这不是一个普通的亚马逊评论分析工具
在正式介绍项目之前，必须先澄清一点：
这个项目不是为了再做一个 Amazon Review Analyzer。
因为这个方向已经有很多成熟产品。
Amazon 自己就有 Product Opportunity Explorer，用于帮助卖家理解 niche、搜索词、点击、购买、评论和定价等信息；Amazon 的 Customer Feedback API 也提供来自 customer reviews 和 returns 的洞察，并且说明其提供的信息与 Seller Central 和 Vendor Central 中 Product Opportunity Explorer 的信息一致。
VOC AI 这类工具也已经把 Amazon 评论洞察做得很产品化，公开页面显示其强调分析大量 Amazon reviews，帮助卖家发现 product gaps、监控品牌和理解消费者反馈。
因此，这个项目不是把“更全的数据、更实时的监控、更完整的卖家运营功能”作为第一目标，而是：
用亚马逊选品和竞品评论这个具体业务场景，做一个语义原生智能问数的开源参考实现。
这是当前项目的定位。
换句话说，现有工具主要回答的是：
卖家怎样更高效地分析评论、理解市场、辅助选品？
而这个项目更想回答的是：
如果我们要把“问数”这件事做成一个可复用、可验证、可被 Agent 调用的系统，底层应该怎么设计？
所以它选择了一个已经被验证有价值的业务场景，但真正要沉淀的，是一套语义原生智能问数的参考实现方法。
二、更大的意义：数据智能体的可信取数基础设施
这个项目旨在展示语义原生智能问数系统应该如何实现。
在 AI-native 场景下，智能问数不只是人类用自然语言查数，更是数据智能体可信运行的基础能力。智能体要从辅助分析走向业务自动化，首先要能取到正确的数据、理解统一的业务口径，并且让人类能够审核它基于哪些数据、哪些指标、哪些证据做出了判断。
因此，这个项目真正想展示的是：如何通过语义层，把业务对象、指标口径、查询逻辑、证据链和智能体调用统一起来，让人类可以问数，Agent 可以调用，机器学习可以复用，而所有结果都基于同一套业务语义。
三、为什么选择个人跨境卖家和亚马逊评论场景
虽然亚马逊评论分析工具已经很多，但这个场景依然非常适合作为智能问数的落地样板。
主要有四个原因。
1. 问题具体，且与真实经济价值高度相关
“个人跨境卖家”这个场景足够具体，且天然有选品、竞品、评论、Listing 优化等高频分析需求。
这个群体通常会关心非常具体的问题：
我应该做哪个类目？ 哪些商品最近需求增长快？ 哪些竞品虽然卖得不错，但用户不满意？ 差评集中在哪些方面？ Listing 应该突出哪些卖点？ 哪些风险应该提前规避？
2. 数据相对容易公开复现
可以使用 Amazon Reviews 2023 这样的公开数据集。这个数据集由 McAuley Lab 收集，包含 user reviews、ratings、text、helpfulness votes、item metadata、descriptions、price、images 和 bought-together graphs 等内容；其 2023 版本包含 571.54M reviews、54.51M users、48.19M items、33 个 domain，时间范围到 2023 年 9 月。
这意味着项目可以开源复现，不必依赖实时爬虫、私有数据或第三方 API。
3. 问题天然适合智能问数
跨境卖家不是只想看一张报表，而是想围绕选品和竞品做决策。
例如：
最近 90 天 Beauty 类目里，哪个价格带评论增长最快？ 竞品差评主要集中在哪些方面？ 用户正面评价中最常提到的卖点是什么？ 哪些商品有需求增长，但用户满意度不高？
这些问题不是简单 SQL，也不是纯文本总结，而是需要把商品、评论、评分、时间、价格带、竞品、用户痛点和证据链组合起来。
这也是智能问数适合发挥价值的地方。
4. 后续可以自然扩展到监控、预警和辅助决策
评论数据既有结构化部分，也有非结构化文本，适合逐步引入：
痛点聚类 负面评价异常检测 评论增长预测 机会分数模型
也就是说，基于智能问数，后续可以自然结合机器学习等算法，进一步增强辅助决策能力。后续这些能力可以被 Agent 或业务工作流调用，进一步形成监控、预警和辅助决策闭环。
也说明从第一天就要想清楚：
机器学习特征也应该从语义层获取，而不是训练脚本自己写一套 SQL。
四、系统整体架构
这个项目的整体架构可以分成六层。
公开数据 / 用户导入数据 ↓ 数据清洗与标准化 ↓ 数据仓库层：商品、评论、评论洞察、商品日指标 ↓ Cube 语义层：指标、维度、口径、关系 ↓ 智能问数层：自然语言 → Cube Query → 答案生成 ↓ Agent / Dashboard / ML Pipeline
结语
第一篇先讲清楚项目背景、定位和整体架构。
从下一篇开始，我们会进入具体实现：先准备 Amazon Reviews 2023 的样本数据，把商品、评论、评分、价格、类目等信息整理成可分析的数据模型。后续再逐步实现 Cube 语义层、智能问数接口、评论语义增强、Agent 调用和机器学习增强。