设备参数写成表格还是写成散文，AI 引用差多少：一次 30 天受控对比实验的完整数据
争论的起因很具体。一家做工业传感器的客户的官网改版评审会上，前端同学主张参数一律用 HTML 表格承载，内容同学认为 AI 引擎更喜欢成段的自然语言描述，因为"人是这么读的"。会上没人能给出证据，最后按"谁负责谁决定"分了工，于是半年后站上出现了两种风格并存的页面——一部分型号页全是表格，另一部分是成段描述。
与其继续争论，我们做了一件更简单的事：挑 40 个参数规格相近的型号页，随机分成两组，只改参数呈现形式，其它全部保持一致，然后观察 30 天。 这篇文章把实验设计、控制变量和结果数据完整贴出来。
一、实验设计
1.1 分组与变量
| 组别 | 数量 | 参数呈现方式 | 其它变量 |
|---|---|---|---|
| A 组（表格） | 20 页 | HTML 表格，一行一个参数 | 相同模板、相同 Schema、相同内链结构 |
| B 组（散文） | 20 页 | 自然语言段落，一段覆盖 2~3 个参数 | 同上 |
| 对照 | 全站其余 300+ 页 | 维持原样 | 用于识别站级波动 |
关键控制点有三个。第一，两组的参数内容完全相同，只是组织方式不同——这点看似显然，实际执行时最容易出错，因为把表格改写成散文会不自觉补充解释性文字，我们把两组的文本长度差控制在 8% 以内。第二，两组页面的内链数量、外链引用、页面加载性能都对齐。第三，分组是随机的，不是按型号销量或页面权重挑的，避免把"热门型号本来就容易被引用"这个混淆因素带进来。
1.2 观察指标
flowchart LR
A[40 个型号页] --> B[分组改造 A表格 / B散文]
B --> C[每日抓取日志统计]
B --> D[每周 AI 引用探测]
B --> E[页面行为数据分析]
C --> F[汇总对比]
D --> F
E --> F
指标定义为：AI 引用次数（固定 25 个参数类问题，每周探测一次，记录回答中出现该型号参数值的次数）、AI 爬虫抓取次数（日志按 UA 统计，只看详情页路径）、被引用片段的类型分布（手工抽样归类）。
二、原理剖析：结构为什么会影响被引用概率
结果出来之前，先讲清楚机制，否则数据只是现象。
生成式引擎处理页面时，会先做一次信息抽取（Information Extraction），把游离文本转成"实体—属性—值"的形式。这一步对不同类型的输入成本不同：
flowchart TD
A[页面 HTML] --> B{内容形态判断}
B -->|表格| C[按行列对齐<br/>属性-值直接成对]
B -->|段落| D[句法分析<br/>需判断属性与值的关系]
C --> E[三元组]
D --> E
E --> F[进入索引]
表格的优势在于结构即语义：<th>量程</th><td>0~10MPa</td> 这一对单元格天然表达了"量程 = 0~10MPa"，抽取器不需要判断句子成分。段落则要先做句法分析，还得处理指代省略（"该型号支持……"里的"该型号"指谁）、多值并列（"支持 4~20mA、RS485 与 Modbus"）、范围表述（"0 到 10 兆帕"）等一堆情况。抽取成功率存在差距，而抽取失败的内容不会进入索引。
但表格也有弱点，而且这个弱点在实验中被验证了：表格擅长表达离散的数值型参数，不擅长表达条件关系。 "在 -20℃ 环境下精度降为 ±1%，常温下为 ±0.5%"这种带条件的表述，塞进表格会变成两个难以理解的单元格；而用一句话说清楚反而更完整。这决定了实验的最终结论不是"谁更好"，而是"各自适合什么"。
三、执行细节
3.1 统一输出结构
两组页面共用同一套 Schema，避免结构化数据差异干扰结果：
{
"@context": "https://schema.org",
"@type": "Product",
"name": "压力变送器 PT-208",
"sku": "PT-208",
"additionalProperty": [
{ "@type": "PropertyValue", "name": "量程", "value": "0~10MPa" },
{ "@type": "PropertyValue", "name": "精度", "value": "±0.5% FS（常温）" },
{ "@type": "PropertyValue", "name": "输出信号", "value": "4~20mA" }
]
}
两组的差别只在页面可见内容的组织方式，Schema 完全一致。这样做是为了回答一个更精确的问题：在结构化数据已经完整的前提下，可见内容的组织形式还会不会影响引用？ 实验证明会，而且幅度不小。
3.2 数据采集
探测脚本负责每周向多个 AI 引擎提问并记录回答，判定方式是"回答中是否出现该型号的某个参数值"：
# 环境：Python 3.10+，仅标准库 + requests
# 作用：对固定问题集做引用探测，输出按型号、按分组的引用命中记录
import json
import re
import time
from collections import defaultdict
import requests
QUESTIONS = [
'量程 0~10MPa 的压力变送器有哪些精度等级',
'PT-208 的输出信号是什么',
'PT-208 的工作温度范围',
# …… 共 25 个参数类问题
]
def ask(engine_endpoint: str, question: str, timeout: int = 30) -> str:
"""调用探测接口获取回答文本；具体 endpoint 由内部探测服务提供"""
resp = requests.post(engine_endpoint, json={'q': question}, timeout=timeout)
resp.raise_for_status()
return resp.json().get('answer', '')
def hit(answer: str, sku: str, values: list[str]) -> bool:
"""命中判定：回答里同时出现型号与任一参数值"""
if sku.lower() not in answer.lower():
return False
return any(re.search(re.escape(v), answer) for v in values)
def probe(groups: dict[str, list[dict]]) -> dict:
stats = defaultdict(lambda: defaultdict(int))
for group, models in groups.items():
for model in models:
for question in QUESTIONS:
answer = ask('https://internal-probe.example.com/ask', question)
if hit(answer, model['sku'], model['values']):
stats[group][model['sku']] += 1
time.sleep(1.5) # 控制频率，避免触发限流
return stats
if __name__ == '__main__':
groups = json.load(open('experiment_groups.json', encoding='utf-8'))
result = probe(groups)
json.dump(result, open('probe_result.json', 'w', encoding='utf-8'),
ensure_ascii=False, indent=2)
3.3 片段类型归类
引用命中的片段我们手工归了类，样本为全部命中记录。归类规则是看回答中引用的内容单元形态：单个参数值、参数组合、条件性描述、解释性说明。
四、30 天结果
4.1 总体对比
| 指标 | A 组（表格，20 页） | B 组（散文，20 页） | 差异 |
|---|---|---|---|
| 引用命中次数/周（第 4 周） | 38 | 24 | 表格组高约 58% |
| 单值型参数被引用（精度、量程等） | 71% | 44% | 表格组明显占优 |
| 条件型参数被引用（温漂、降额等） | 29% | 56% | 散文组明显占优 |
| AI 爬虫日均抓取 | 96 | 88 | 差异不显著 |
| 平均响应时间 | 412ms | 398ms | 无实质差异 |
4.2 按参数类型拆分
这张表是整次实验里最有实用价值的部分。把参数分成两类看，两组的优劣正好互换：
| 参数类型 | 举例 | 表格组命中 | 散文组命中 | 建议形态 |
|---|---|---|---|---|
| 离散数值型 | 量程、精度、接口、供电 | 76% | 41% | 表格 |
| 条件/组合型 | 温度降额、多信号兼容、选配关系 | 22% | 58% | 段落 + 列表 |
| 说明性内容 | 适用工况、安装注意 | 35% | 47% | 段落 |
4.3 一个预期之外的现象
实验第 3 周出现了一次站级波动：B 组有 3 个页面的引用突然上涨，追查发现是这几个型号在某个行业论坛被讨论，外部链接带来了额外的抓取。这提醒我们这类实验至少要跑 30 天、并且要看周均值而不是单日数据，否则很容易把外部事件误读成实验效果。对照组的 300 多个页面在同期波动幅度在 ±12% 以内，也说明站级因素是可识别的。
五、结论与落地方式
5.1 最终采用的页面结构
实验结束后，我们把型号页的参数区统一成"分段混合"结构：
- 离散数值参数 → 表格（首屏可见，服务端直出）；
- 条件与组合关系 → 段落 + 无序列表；
- 说明性内容 → 段落，每段不超过 3 个技术点。
改造后全站 340 个型号页的引用命中从每周 62 次提升到 96 次（第 8 周数据），提升幅度与实验预估接近。
落地时还顺手解决了一个老问题：过去参数表格的样式由设计同学在模板里写死，运营想调整行列顺序必须找开发。这次改造把表格数据挪进了产品的参数表，页面按固定顺序渲染，运营改顺序只需调整字段的排序值。改动的直接收益不是引用数据，而是"改一次参数不再需要排期"，这类工程收益往往比指标提升更能持续。
5.2 实验方法上的三条经验
第一，控制文本长度。把表格改写成散文时，如果不控制字数，两组差异里会混入"内容更丰富"这个变量，结论就不可靠了。第二，随机分组。按页面权重或销量分组会引入选择偏差，尤其是"热门型号更容易被引用"这条。第三，保留对照组。站级波动是真实存在的，没有对照组就无法区分实验效果与外部事件。补充第四点：把"命中判定"的规则提前写死。我们最初的判定脚本要求型号与参数值同时出现，后来发现部分回答只带了参数值没带型号，判定口径一改数据就变，所以判定规则必须在采集开始前固定下来，中途不改。
六、误区与趋势
误区一：以为表格一定优于段落。 数据不支持这个简化结论。表格在离散参数上优势明显，但在条件型信息上反而吃亏。真正有效的做法是按信息类型分配形态。
误区二：只改可见内容、不管结构化数据。 这次实验刻意让两组 Schema 一致，是为了单独测量可见内容的影响。真实改造中两者要一起做，Schema 保证机器读到的是确定的值，可见内容保证这些值在页面里有清晰的承载。
误区三：用一周数据下结论。 索引更新有延迟，一周的数据里噪声占比很高。我们的经验是至少 30 天、看周均值，并且把站级波动单独识别出来。
趋势上，信息抽取对内容结构敏感这一点不会改变，但会越来越"宽容"——抽取能力在提升，模糊表达的容忍度会增加。不过对工业品这类参数决定采购的类目，把参数写成机器友好的形态仍然是成本最低的确定性收益。技术上的收尾建议：把"离散参数用表格、条件关系用段落"写进内容规范，并给页面模板加上"参数区必须服务端直出"这条硬约束。你们站上的参数是怎么呈现的，欢迎在评论区聊聊实验设计上的想法。
参考与延伸
- Schema.org PropertyValue 定义：https://schema.org/PropertyValue
- Google 搜索中心：结构化数据功能与可用性说明：https://developers.google.com/search/docs/appearance/structured-data/search-gallery
- HTML 表格语义规范（WHATWG）：https://html.spec.whatwg.org/multipage/tables.html
- Schema.org Product 类型定义：https://schema.org/Product
关键词：GEO 生成式引擎优化、AI 优化 AIO、信息抽取、Product Schema、PropertyValue、A/B 测试、结构化数据、工业品官网