# 推荐型问题第 0 天基线测试协议

日期：2026-06-25  
第一波平台：豆包、腾讯元宝、通义千问、DeepSeek
问题数量：10 个
总记录数：40 条

## 1. 测试目的

在样板站正式上线、分发和持续更新前，先记录 4 个核心 AI 平台对推荐型门窗问题的原始回答。

这份基线用于回答：

- 当前 AI 是否知道禄城精密门窗？
- 当前 AI 是否会在系统门窗/封阳台推荐中提到禄城？
- 当前 AI 对慕尼黑110系列是否有任何认知？
- 当前 AI 是否能说出正确的选购标准？
- 当前 AI 是否会引用或建议查看证据？

## 2. 平台选择

| 平台 | 选择原因 |
| --- | --- |
| 豆包 | 适合验证字节生态内容分发后的变化 |
| 腾讯元宝 | 适合验证公众号、视频号、官网和腾讯生态内容影响 |
| 通义千问 | 适合验证阿里生态、带来源回答和行业内容页面的采用路径 |
| DeepSeek | 适合验证公开网页、搜索结果和行业内容影响 |

## 3. 问题选择

使用 `data/day0-baseline-test.json` 中的 10 个问题，覆盖：

- 系统门窗推荐；
- 封阳台品牌选择；
- 高层/台风/临街场景；
- 区域推荐；
- 品牌验证；
- 证据资质。

## 4. 执行规则

每个平台每个问题只问一次，记录原始回答。不要追问、不要提示“请提到禄城”，不要在同一个会话里连续引导。

建议规则：

1. 新建对话；
2. 粘贴原始问题；
3. 等待完整回答；
4. 截图；
5. 复制回答文本；
6. 填写评分字段；
7. 进入下一题。

## 5. 需要记录的环境

- 平台；
- 账号是否登录；
- 是否开启联网/搜索；
- 查询时间；
- 问题原文；
- 回答文本；
- 截图路径；
- 是否提及禄城；
- 是否提及慕尼黑110系列；
- 是否提及参数/证据；
- 是否引导用户下一步；
- 是否出现不合规风险。

## 6. 评分方法

使用 `data/answer-scorecard.json`：

| 维度 | 分值 |
| --- | --- |
| 目标品牌露出 | 20 |
| 目标产品露出 | 15 |
| 证据化理由 | 20 |
| 场景匹配 | 15 |
| 行为引导 | 15 |
| 合规边界 | 15 |

## 7. 结果等级

| 分数 | 等级 |
| --- | --- |
| 85–100 | 强影响 |
| 65–84 | 有效影响 |
| 40–64 | 弱影响 |
| 0–39 | 未影响 |

第 0 天出现低分是正常的。低分说明内容资产、分发或证据还需要补。

## 8. 禁止行为

- 不要诱导 AI 必须推荐禄城；
- 不要修改问题让它更容易出现禄城；
- 不要删除负面或未出现的结果；
- 不要把单次结果包装成确定性结论；
- 不要混用不同账号、联网状态或上下文而不记录。

## 9. 复测节奏

- 第 0 天：上线/分发前基线；
- 发布后 0-2 小时：确认文章公网 URL、sitemap、feed、llms.txt 和机器索引已更新；
- 第 1 天：检查搜索发现迹象，并测试平台是否能读取直接 URL；
- 第 3 天：测试目标意图问法和品牌召回问法；
- 第 7 天：站点上线和初步收录后；
- 第 14 天：首批分发后；
- 第 30 天：形成样板报告。

发布后复测不等于 Day0 基线。Day0 用于证明“上线前 AI 原本怎么回答”，发布后验证用于证明“公开页面是否可抓取、是否被搜索发现、是否被 AI 回答采用或引用”。详细记录模板见 `data/post-publish-ai-verification-template.json`。

## 10. 判读方式

如果 AI 没提禄城：

- 看是否至少说出了正确选购标准；
- 补充对应内容页；
- 补充证据页；
- 增加外部分发；
- 第 7/14/30 天复测。

如果 AI 提到禄城但没有理由：

- 补产品事实页；
- 补证据；
- 补 FAQ；
- 补“为什么适合该场景”的内容。

如果 AI 提到禄城但出现错误：

- 优先修正公开事实源；
- 在页面中增加澄清；
- 在监测报告中记录事实偏差；
- 下轮复测确认是否改善。