汽车内容知识库如何统一车型与文章，真正困难的通常不是完成一次 API 调用，而是让结果可以校验、失败可以定位、后续能够回到原始证据。本文围绕“如何将车型主数据、汽车文章和用户情感标签组织成可更新的知识库”给出一套可以直接落到任务状态和数据契约上的实现方式。
问题与结果
车型实体与内容记录解耦，通过稳定车型标识关联文章、关键词和情感结果。
最终交付不是一段不可追溯的模型回答，而是一组带来源、版本、状态和失败记录的数据。这样既方便接入后续系统，也能在接口、页面或模型输出变化时定位问题。
适用场景
- 汽车资讯聚合
- 车型导购知识库
- 品牌和车型舆情整理
实现前先确定边界
- 先完成品牌、车系和车型实体归一
- 文章抽取失败时保留来源但不生成标签
- 情感分析针对文本片段，不能直接代表整车评价
可验证工作流
API 编排与职责
| 步骤 | 接口 | 请求方式 | 用途 |
|---|---|---|---|
| 查询车型库 | 汽车车型库数据 | GET | 获取品牌、车系、车型三级基础数据 |
| 抽取文章 | 文章抽取信息化 JSON | POST | 从汽车资讯 URL 抽取标题、正文和结构化信息 |
| 提取关键词 | 多语言长文本 AI 关键字提取 | POST | 提取车型、配置、价格、评价等关键词 |
| 情感分析 | 多语言文本 AI 情感分析 | POST | 判断内容倾向，辅助舆情归类 |
| 网页正文 | 网页可读内容抽取 | POST | 在需要时获取网页正文作为备用内容 |
最小可运行实现
先获取品牌列表：
curl -G "https://api.gugudata.com/v1/vehicleBrands" \ --data-urlencode "appkey=YOUR_APPKEY" \ --data-urlencode "pageIndex=1" \ --data-urlencode "pageSize=50"根据品牌公开 ID 查询车系：
curl -G "https://api.gugudata.com/v1/vehicleSeries" \ --data-urlencode "appkey=YOUR_APPKEY" \ --data-urlencode "brandId=BRAND_ID" \ --data-urlencode "pageIndex=1" \ --data-urlencode "pageSize=50"抽取一篇汽车资讯：
curl -X POST "https://api.gugudata.com/ai/v1/articles/extract?appkey=YOUR_APPKEY" \ -H "Content-Type: application/json" \ -d '{ "url": "https://example.com/auto/news/001" }'Agent 可以把车型匹配写成一个独立步骤：
def match_vehicle_terms(article_text: str, catalog_terms: list[str]) -> list[str]: """Match known vehicle terms from extracted article text.""" normalized = article_text.lower() return [term for term in catalog_terms if term.lower() in normalized]知识库字段设计
汽车内容入库时建议保留这些字段：
| 字段 | 说明 |
|---|---|
| brand_id | 品牌公开 ID |
| series_id | 车系公开 ID |
| trim_id | 车型公开 ID |
| source_url | 内容来源 URL |
| title | 文章标题 |
| extracted_text | 抽取后的正文 |
| keywords | 关键词列表 |
| sentiment | 情绪倾向或内容态度 |
| published_at | 内容发布时间 |
这里的关键是把外部内容映射到车型库，而不是只保存文章。只有形成品牌、车系、车型维度，后续才能做车型详情页、导购问答、内容推荐和舆情趋势。
失败分类与降级
如果文章抽取失败，Agent 可以尝试网页可读内容抽取作为备用；如果仍然失败，应记录来源 URL 和失败原因。若车型匹配到多个候选，应优先保留候选列表，不要强行选择一个车型。
对于品牌简称、车系别名、海外车型名称，需要维护可审计的别名表。别名表属于业务资产，不建议让模型每次临时猜测。
数据契约与留痕
建议至少保存以下字段；真实项目可以继续拆分，但不要删除来源、版本和状态信息。
| 字段 | 作用 |
|---|---|
vehicle_id | 稳定业务标识，用于关联记录并避免名称冲突 |
brand | 业务数据字段，保存时记录来源、口径和缺失状态 |
series | 业务数据字段，保存时记录来源、口径和缺失状态 |
model | 业务数据字段，保存时记录来源、口径和缺失状态 |
article_url | 来源或目标 URL，保留最终跳转前后的差异 |
content_hash | 内容哈希，用于完整性校验、版本识别和去重 |
keywords | 业务数据字段，保存时记录来源、口径和缺失状态 |
sentiment | 业务数据字段，保存时记录来源、口径和缺失状态 |
所有派生结果都应带生成时间和输入版本。发生重试时新增尝试记录，不要覆盖最后一次失败，以免排查时只剩“最终成功”而看不到中间问题。
验收清单
- 同一车型的别名可归一
- 文章更新能生成新版本
- 标签可回到原始文本和来源
能力边界
外部文章和评论只代表其来源内容，车型参数与在售状态需要结合权威数据持续更新。
示例中的YOUR_APPKEY仅为占位符。真实密钥只能放在服务端环境变量或密钥管理系统中，不应进入前端、文章、日志或版本库。
