从工程视角复盘《2026毕业旅行运动鞋品牌AI心智指数报告》：一个AI品牌指数系统该如何设计？

最近看了绿雪智能科技旗下“AI心智指数”网站发布的《2026毕业旅行运动鞋品牌AI心智指数报告》，里面有一组挺有意思的数据。

这份报告围绕“毕业旅行运动鞋”这个细分场景，覆盖了6个主流AI平台：

豆包
DeepSeek
通义千问
Kimi
文心一言
腾讯元宝

每个平台进行600次独立提问采集，总计3600次。由于后续会做有效样本识别和无效回答剔除，所以最终有效样本低于3600次。

报告结果显示：

新百伦综合得分第一；
耐克提及率最高；
阿迪达斯位列第三；
李宁、安踏进入前五；
萨洛蒙、亚瑟士、Hoka One One、迈乐等功能型、户外型品牌也进入榜单。

如果从普通读者角度看，这像是一篇消费观察报告。

但如果从工程角度看，我更关心的是另一件事：

这样一个AI品牌指数系统，到底应该怎么设计？

它不是简单地问几次AI，然后数一下品牌名。

真正有工程价值的地方在于：

如何设计问题集？
如何跨平台稳定采集回答？
如何清洗无效样本？
如何识别品牌实体？
如何区分“提及”和“推荐”？
如何合并品牌别名？
如何计算指标？
如何保证结果可解释？
如何把最后的数据转成一份可以发布的行业报告？

这篇文章不复述报告原文，而是尝试从工程系统设计角度，拆解一个“AI心智指数”类产品背后的技术链路。

1. 先定义问题：我们到底在测什么？

传统品牌数据通常来自几类来源：

数据类型 常见来源
销量数据 电商平台、渠道销售、企业披露
搜索数据 搜索指数、关键词热度
内容声量 社交平台、媒体平台、短视频平台
用户口碑 评论、评分、问卷、访谈
品牌资产 市场研究、广告投放、第三方咨询报告

但AI心智指数测的不是这些。

它测的是：

当用户把一个真实问题交给AI时，AI回答里会出现哪些品牌？哪些品牌会被推荐？哪些品牌会被解释清楚？

这和传统SEO也不一样。

SEO关心的是：

用户搜索关键词 -> 搜索引擎返回网页 -> 用户点击结果

AI问答场景关心的是：

用户提出问题 -> AI生成答案 -> 用户参考答案

也就是说，系统观察对象从“网页排名”变成了“答案位置”。

这也是整个系统的核心抽象：

AI心智指数 = 品牌在AI回答中的可见度、推荐度、解释度

对应到工程指标，可以先拆成三层：

1. 是否被AI提到：Mention
2. 是否被AI推荐：Recommendation
3. 是否被AI合理解释：Explanation

本次报告公开的核心指标主要是：

综合得分
提及率
推荐率
提及次数
推荐次数

所以，一个最小可用版本的系统，至少要实现：

回答采集 -> 品牌识别 -> 提及判断 -> 推荐判断 -> 指标计算 -> 报告生成
2. 为什么问题集设计比模型调用更重要？

如果只是问：

运动鞋品牌排行榜有哪些？

那结果很容易变成传统知名品牌列表。

但报告选择的是“毕业旅行运动鞋”，这个场景就具体很多。

真实用户更可能这样问AI：

毕业旅行穿什么运动鞋比较舒服？
学生党毕业旅行买什么运动鞋合适？
去重庆旅行爬坡多，穿什么鞋不累？
准大学生暑假旅行，想买一双开学也能穿的运动鞋，怎么选？
女生毕业旅行想买舒适又百搭的运动鞋，有哪些品牌？
预算有限，国货运动鞋适合毕业旅行吗？

这些问题的价值在于，它们不是简单关键词，而是带约束条件的场景问题。

一个真实问题通常由几个部分组成：

人群 + 场景 + 品类 + 功能需求 + 预算/地点/偏好约束

例如：

准大学生 + 毕业旅行 + 运动鞋 + 长时间走路不累 + 预算有限

生成的问题可以是：

准大学生毕业旅行，预算有限，想买一双长时间走路不累的运动鞋，有哪些品牌可以参考？

从工程实现看，可以把问题集设计成一个矩阵。

audiences = ["高考生", "准大学生", "学生党", "女生", "男生"]
scenarios = ["毕业旅行", "暑假旅行", "城市旅行", "轻户外旅行"]
categories = ["运动鞋", "旅行鞋", "跑鞋", "徒步鞋"]
requirements = ["长时间走路不累", "舒适百搭", "适合拍照", "预算有限", "开学后也能穿"]
locations = ["重庆", "成都", "西安", "云南", "长沙", "青岛"]

questions = []

for audience in audiences:
for scenario in scenarios:
for requirement in requirements:
questions.append(
f"{audience}{scenario}想买一双{requirement}的运动鞋，有哪些品牌可以参考？"
)

但这里要注意一个问题：不能机械笛卡尔积生成太多重复问题。

否则会带来两个问题：

第一，问题之间相似度过高，结果会被少数模板放大。

第二，采集成本上升，但新增信息有限。

更合理的做法是给问题集分层：

核心问题：覆盖主需求
扩展问题：覆盖细分人群
对照问题：覆盖相近但不同场景
长尾问题：覆盖特殊条件

例如：

问题层级 示例
核心问题 毕业旅行穿什么运动鞋比较舒服？
人群问题 女生毕业旅行适合买什么运动鞋？
地点问题 去重庆旅行爬坡多，穿什么鞋不累？
预算问题 学生党预算有限，毕业旅行运动鞋怎么选？
功能问题 长时间走路不累的运动鞋品牌有哪些？
延展问题 准大学生买一双旅行和开学都能穿的运动鞋怎么选？

这样生成的问题集才更接近真实用户行为。

3. 采集系统：不要只保存结果，要保存全过程

一个常见错误是，只保存最后统计结果。

比如：

新百伦：提及1583次，推荐1404次
耐克：提及1639次，推荐1291次

这样当然可以出榜单，但后期很难排查问题。

生产系统应该保存完整链路。

推荐的数据表设计大概是这样：

CREATE TABLE ai_questions (
id BIGINT PRIMARY KEY,
category VARCHAR(100),
scenario VARCHAR(100),
audience VARCHAR(100),
question_text TEXT,
question_type VARCHAR(50),
created_at TIMESTAMP
);

回答表：

CREATE TABLE ai_answers (
id BIGINT PRIMARY KEY,
question_id BIGINT,
platform VARCHAR(50),
raw_answer TEXT,
normalized_answer TEXT,
is_valid BOOLEAN,
invalid_reason VARCHAR(255),
created_at TIMESTAMP
);

品牌识别结果表：

CREATE TABLE ai_answer_brand_mentions (
id BIGINT PRIMARY KEY,
answer_id BIGINT,
brand_id VARCHAR(100),
canonical_name VARCHAR(100),
mentioned BOOLEAN,
recommended BOOLEAN,
sentiment VARCHAR(50),
reason TEXT,
confidence DECIMAL(5,4),
created_at TIMESTAMP
);

为什么要这么拆？

因为后续一定会遇到这些问题：

某个品牌是不是被误识别了？
某个平台是不是异常高频推荐某类品牌？
某些问题是不是诱导性太强？
某些回答是不是无品牌回答？
品牌别名是否拆散了统计？
推荐率是不是被规则误判了？

如果只有聚合结果，基本没法复盘。

如果保存全过程，就可以从最终榜单一路回溯到原始回答。

这对一个指数类产品非常重要。

4. 多平台采集：核心是降低单模型偏差

这份报告覆盖6个平台，每个平台600次采集。

这个设计是合理的。

因为不同AI平台会有明显差异：

差异点 可能影响
训练语料不同 对不同品牌熟悉程度不同
对齐策略不同 是否愿意直接推荐品牌不同
回答模板不同 有的平台喜欢列清单，有的平台偏原则建议
中文品牌识别能力不同 国货品牌、英文品牌、别名识别可能不同
场景理解不同 对毕业旅行、学生党、轻户外的理解不同

如果只采一个平台，结论很容易变成“某个平台的偏好”。

跨平台采集的好处是：

减少单模型偏差，提高生态观察意义

工程上需要注意几个点：

4.1 平台适配层

不同平台API格式、鉴权方式、响应结构可能都不同，所以最好抽象一个统一接口：

class BaseAIProvider:
def ask(self, question: str) -> str:
raise NotImplementedError

不同平台实现自己的Provider：

class DoubaoProvider(BaseAIProvider):
def ask(self, question: str) -> str:
# 调用豆包
pass

class DeepSeekProvider(BaseAIProvider):
def ask(self, question: str) -> str:
# 调用DeepSeek
pass

上层采集任务只关心：

answer = provider.ask(question)

不要把平台差异散落在业务代码里。

4.2 任务队列

3600次采集不算特别大，但如果后续扩展到更多品类、更多平台、更多问题，就必须上任务队列。

可以抽象为：

category_run -> question_tasks -> platform_tasks -> answer_records

状态流转：

pending -> running -> success / failed -> parsed -> aggregated

如果有Celery、RQ、Sidekiq或者自研worker，都可以实现。

4.3 重试与限速

AI平台调用一定会遇到：

超时
限流
网络错误
返回空内容
安全策略拒答
格式异常

所以采集层至少要有：

timeout
retry
rate limit
error code
fallback
dead letter queue

否则最终数据会混入很多非业务因素。

5. 无效回答识别：有效样本低于3600是正常的

报告里提到，3600次独立提问后会做有效样本识别，所以最终有效样本低于3600。

这是很关键的一点。

因为AI回答中确实会出现无效样本。

常见无效回答包括：

类型 示例
拒答 无法提供具体品牌建议
过度泛化 建议选择舒适、防滑、透气的鞋，但没有品牌
空回答 平台异常或返回为空
无关回答 答非所问
重复错误 模型输出模板损坏
品类偏移 推荐了拖鞋、皮鞋、登山杖等无关对象
品牌不可识别 内容中没有明确品牌实体

有效性判断可以先用规则做一层粗筛：

def is_valid_answer(answer: str) -> bool:
if not answer or len(answer.strip()) < 20:
return False

invalid_phrases = [
"无法提供",
"不能推荐具体品牌",
"请自行搜索",
]

if any(p in answer for p in invalid_phrases):
return False

return True

但只靠规则不够，还要结合品牌识别结果。

例如，一个回答虽然很长，但完全没有品牌，也不能用于品牌榜统计。

可以进一步定义：

def is_valid_for_brand_ranking(answer: str, extracted_brands: list) -> bool:
return is_valid_answer(answer) and len(extracted_brands) > 0

这个设计也解释了为什么有效样本会低于3600。

一个严谨的系统应该宁可剔除无效样本，也不要把无品牌回答硬算进去。

6. 品牌实体识别：最容易翻车的环节

统计品牌出现次数，看起来很简单，实际上非常容易出问题。

以新百伦为例，AI可能输出：

新百伦
New Balance
NB
new balance
NewBalance

以Hoka One One为例，可能输出：

Hoka
HOKA
Hoka One One
霍卡

以萨洛蒙为例，可能输出：

萨洛蒙
Salomon
所罗门
萨洛蒙户外鞋

如果不做别名归一，同一个品牌会被拆成多个实体。

所以品牌库必须存在。

示例：

{
"brand_id": "new_balance",
"canonical_name": "新百伦",
"aliases": [
"新百伦",
"New Balance",
"new balance",
"NewBalance",
"NB"
]
}

品牌匹配至少要分三步：

文本标准化 -> 别名匹配 -> 上下文消歧

文本标准化示例：

import re

def normalize_for_match(text: str) -> str:
text = text.lower()
text = re.sub(r"\s+", "", text)
text = text.replace("-", "")
text = text.replace("_", "")
return text

别名匹配只是基础。

真正麻烦的是上下文消歧。

比如“NB”可能是New Balance，也可能是网络语气词。

推荐NB的574、327系列

这种可以算新百伦。

但：

这双鞋真的很NB

不能算品牌。

所以缩写类品牌别名需要更严格的规则：

def is_nb_brand_context(text: str) -> bool:
keywords = ["574", "327", "990", "鞋", "运动鞋", "New Balance", "新百伦"]
return "NB" in text and any(k in text for k in keywords)

当然，实际系统不应该完全靠硬编码。

更可靠的方案是：

品牌词典匹配 + 正则规则 + LLM结构化抽取 + 抽样人工校验

对于指数类产品来说，品牌实体识别是地基。

这个环节不稳定，后面所有指标都会失真。

7. 推荐识别：提到品牌，不等于推荐品牌

这是整个系统里最重要的判断之一。

“提及”和“推荐”必须分开。

比如：

可以考虑新百伦、耐克、李宁、安踏等品牌。

这里几个品牌都被提及，也都可以算弱推荐。

但如果是：

耐克和阿迪达斯知名度很高，但有些款式长时间走路不一定最舒服。

这里耐克和阿迪达斯被提到了，但不一定是推荐。

再比如：

如果更看重舒适和百搭，新百伦会更适合毕业旅行。

这是明确推荐。

推荐识别的本质是判断品牌在句子中的语义角色。

可以定义几个状态：

mentioned: 被提到
recommended: 被推荐
compared: 被比较
cautioned: 被提醒谨慎
negative: 被负面评价
neutral: 中性出现

使用规则可以做一版初筛。

recommend_keywords = [
"推荐",
"建议",
"可以选择",
"可以考虑",
"适合",
"优先考虑",
"值得看",
"比较合适",
]

def is_recommended_context(sentence: str, brand: str) -> bool:
if brand not in sentence:
return False
return any(k in sentence for k in recommend_keywords)

但规则有局限。

比如：

不太推荐选择过于厚重的鞋款，例如某些复古篮球鞋。

如果品牌出现在这类句子里，规则可能误判。

所以更稳的做法是结构化抽取：

{
"brand": "新百伦",
"mentioned": true,
"recommended": true,
"stance": "positive",
"reason": ["舒适", "百搭", "适合城市步行"],
"confidence": 0.92
}

可以用LLM做抽取，但需要给出稳定schema。

示例Prompt：

请从下面AI回答中抽取所有运动鞋品牌，并判断每个品牌是否被明确推荐。

判断标准：

1. 只要品牌名出现，mentioned=true。
2. 只有当品牌被作为建议、可选方案、适合对象、推荐选择时，recommended=true。
3. 如果品牌只是被比较、提醒谨慎或负面评价，recommended=false。
4. 输出JSON数组，不要输出解释文字。

字段：
brand_name
mentioned
recommended
reason
confidence

这一步的质量，直接决定推荐率是否可信。

8. 指标计算：不要把综合分做成黑箱

报告中的核心数据如下：

排名 品牌 综合得分 提及率 推荐率
1 新百伦 81.59 88.26% 78.00%
2 耐克 78.59 91.36% 71.72%
3 阿迪达斯 74.20 89.42% 66.00%
4 李宁 63.67 63.18% 63.94%
5 安踏 59.67 60.72% 59.11%

可以看到，综合得分不是简单等于提及率，也不是简单等于推荐率。

比较合理的指标结构是：

综合得分 = 提及能力 + 推荐能力 + 平台稳定性 + 场景覆盖度 + 解释质量

示例公式：

score = (
0.30 * mention_rate
+ 0.40 * recommend_rate
+ 0.10 * platform_coverage
+ 0.10 * scenario_coverage
+ 0.10 * explanation_score
)

这里只是示例，不代表报告实际公式。

但工程上必须注意一点：

综合分必须可解释。

如果用户问：

为什么新百伦第一，而不是耐克？

系统应该能解释：

耐克提及率最高，说明基础品牌认知强；
新百伦推荐率最高，说明在毕业旅行场景下更容易被AI作为建议输出；
新百伦的标签与舒适、百搭、城市步行、日常穿搭更贴近；
所以综合得分更高。

也就是说，综合分不能只是数字，必须能回溯到指标和样本。

否则指数产品会很难建立信任。

9. 从结果看系统：新百伦为什么能排第一？

从工程角度看，新百伦第一可以理解为：

召回能力强 + 场景匹配强 + 推荐转化强

耐克提及率最高，说明召回能力最强。

但新百伦推荐率最高，说明排序阶段更占优。

如果借用搜索/推荐系统的概念，可以这么理解：

提及率 ≈ Recall
推荐率 ≈ Ranking / Conversion
综合得分 ≈ Final Answer Value

耐克、阿迪达斯、新百伦都能被AI高频召回。

但在“毕业旅行运动鞋”这个Query Intent下，新百伦更容易被排到推荐答案里。

原因不是技术系统偏向它，而是它在AI回答语义中具有更强的场景适配：

舒适
百搭
复古
城市步行
日常穿搭
学生可接受
旅行和校园都能用

这些语义标签和“毕业旅行运动鞋”的用户需求高度一致。

所以它更像这个问题的答案。

这也说明，AI品牌排名不是传统品牌知名度排名，而是“品牌语义”和“用户问题”的匹配结果。

10. GEO视角：品牌内容正在变成AI可解析资产

这份报告背后还有一个关键词：GEO。

SEO是Search Engine Optimization，面向搜索引擎。

GEO是Generative Engine Optimization，面向生成式AI。

SEO关注：

页面是否收录
关键词是否排名
标题是否优化
外链是否足够
点击率是否提升

GEO关注：

AI是否识别品牌实体
AI是否理解品牌适用场景
AI是否能正确解释品牌优势
AI是否在用户问题中提及品牌
AI是否把品牌作为推荐答案

从工程角度看，GEO可以拆成四层：

Entity Layer：实体层
Content Layer：内容层
Scenario Layer：场景层
Answer Layer：回答层

对应品牌侧动作：

层级 目标
Entity Layer 让AI知道品牌是谁，别名是什么，产品线是什么
Content Layer 让AI理解品牌优势、产品特点和可信信息
Scenario Layer 让AI知道品牌适合哪些真实用户问题
Answer Layer 监测AI最终是否提及、推荐和解释品牌

AI心智指数最有价值的地方在于，它直接看Answer Layer。

也就是不只看品牌有没有发内容，而是看AI最后怎么回答。

这比传统内容监测更接近用户实际接触点。

11. 一个可落地的系统架构

如果要做一个AI心智指数系统，可以先按下面的架构设计。

品类配置
↓
问题集生成
↓
多平台采集任务
↓
原始回答存储
↓
有效样本清洗
↓
品牌实体识别
↓
推荐意图识别
↓
指标聚合计算
↓
报告生成
↓
前端展示与后台审核

更工程化一点，可以拆成这些模块：

Category Service
Question Generator
AI Provider Adapter
Task Queue / Worker
Answer Storage
Entity Extraction Service
Recommendation Classifier
Metric Aggregator
Report Builder
Admin Review

如果使用后端常见技术栈，可以是：

FastAPI / Django / Spring Boot
PostgreSQL / MySQL
Redis
Celery / RQ / Kafka
LLM Provider SDK
Pydantic / JSON Schema
Admin Dashboard

这个系统的关键不是“能不能调模型”，而是：

能不能稳定采集
能不能准确识别
能不能解释指标
能不能复盘样本
能不能持续扩展品类
12. 系统边界：这不是销量榜，也不是质量榜

做指数类系统，一定要把边界说清楚。

AI心智指数不能被解释成：

品牌销量排名
用户购买偏好排名
产品质量排名
市场份额排名
真实口碑排名

它只能说明：

在本次采集周期、指定问题集、指定AI平台、有效样本口径下，品牌在AI回答中的呈现情况。

这是一个很重要的产品边界。

否则用户很容易把“AI推荐率高”理解为“产品一定更好”。

工程系统也要通过字段设计和报告模板固定这个边界。

比如每份报告都应该输出：

数据来源
采集平台
采集次数
有效样本说明
指标定义
不代表事项
免责声明

这不是形式主义，而是指数产品可信度的一部分。

13. 这类系统最难的地方是什么？

我认为最难的不是模型调用，而是三个地方。

13.1 品牌归一

品牌别名、英文名、中文名、缩写、错误翻译，如果不统一，会直接影响排名。

13.2 推荐判断

提及不等于推荐。推荐语义识别不准，推荐率就会失真。

13.3 指标解释

用户看到榜单之后一定会问为什么。系统必须能解释，而不是只给一个分数。

所以，AI心智指数系统本质上不是单纯的数据采集系统，而是一个：

采集系统 + NLP识别系统 + 指标系统 + 可解释报告系统

四者缺一不可。

14. 对开发者的启发

这份报告给开发者的启发是：

AI时代，不只是做AI应用，也可以做AI观测。

现在很多AI产品都在做：

AI写文章
AI画图
AI客服
AI办公
AI搜索

但还有一类产品会越来越重要：

AI如何回答某个行业的问题？
AI如何推荐品牌？
AI如何理解公司？
AI如何呈现产品？
AI是否错误理解某个对象？
AI对竞品的回答有什么差异？

这类产品不是直接生成内容，而是监测AI生态。

从技术上看，它融合了：

数据采集
多模型调用
文本清洗
实体识别
语义分类
指标建模
报告生成
可视化展示

这是一个很典型的新型数据产品方向。

《2026毕业旅行运动鞋品牌AI心智指数报告》表面上是在讨论运动鞋品牌排名，但从工程视角看，它背后展示的是一个AI品牌指数系统的完整雏形。

它要解决的问题不是“哪个品牌最好”，而是：

当用户向AI提出真实生活问题时，AI会把哪些品牌放进答案？

这背后对应的是一整套技术链路：

问题集设计
多平台采集
有效样本清洗
品牌实体识别
推荐意图识别
指标聚合
报告生成
结果解释

这类系统未来可以扩展到很多场景：

准大学生笔记本电脑
学生防晒霜
城市旅行目的地
咖啡品牌
茶饮品牌
企业软件
云服务
开发工具
教育平台
汽车品牌

只要用户会问AI，只要AI会生成答案，就存在AI心智观测的空间。

从SEO到GEO，从搜索排名到AI答案位置，品牌竞争的入口正在发生变化。

对技术人来说，这是一个值得关注的新方向。

它不是简单的“AI写稿”，而是用工程化方式观测AI如何组织答案、如何理解品牌、如何影响信息分发。

毕业旅行运动鞋只是一个切口。

真正值得关注的是：

生成式AI正在成为新的信息分发层，而AI心智指数是在尝试量化这个分发层中的品牌位置。