> 一篇技术文章发出去两天后被 AI 收录了。我们写了两个只读小工具去验证"它到底读没读"，结果是：能搜到我们是谁，但讲技术问题时不引用我们；而当我们拿一个只有正文才有的事实去问它时，它给出的答案和我们文章里的结论**正好相反**。
>
> 12 个会话、15 分钟，只读不发送。结论分三层：L1 收录成立、L2 引用 0/7、L3 带出账号名未达成。

先说清楚这件事为什么值得写：我们原本以为"被收录"就是结果。实测证明它不是。而且这次最有价值的产出不是收录本身，是一个反面案例——**我们用来验证"AI 有没有读我们"的那把尺子，本身是坏的**。

---

## 一、先把三个概念钉死

这一节和上一篇文章的结构一样，但概念完全不同。混用会导致后面的结论全部漂移。

**L1 收录**：内容进入了 AI 的检索库，能被搜到。这是最低一层，也是绝大多数人默认的"生效"。

**L2 引用**：当有人问一个技术问题时，AI 的回答把我们的内容当来源。**收录解决不了这一层。**

**L3 带出账号名**：引用时显示我们的账号名。这一层是账号名策略的最终目的，但它必须建立在 L2 之上——L2 为 0 时，L3 没有着力点。

三层是递进关系，不是并列关系。实测数据里最容易被误读的就是这一点：L1 亮绿灯，L2 和 L3 全灭。如果只看"有没有被收录"，会得出"我们做成功了"的结论。

**探针（独占词探针）**：验证"AI 是否真的读过我们的正文"的一种测试手法。做法是自己造一个词，比如我们造过"结构可引用度"，然后直接问 AI 这个词是什么。如果它能答出定义，说明它读过。听起来很严密——**这次实测证明它不严密，而且失败方式值得单独写一节。**

---

## 二、我们做了两个只读小工具

工具本身不复杂，但有两个设计约束值得先讲，因为它们直接决定了数据可不可信。

### 2.1 工具一：会话只读采集

浏览器自动化读取 AI 助手的**已存在会话**，不发送任何新问题。唯一的界面交互是点开"参考 N 篇资料"面板。

难点不在抓取正文，而在**必须剔除侧边栏**。原因是这类助手的侧边栏里全是历史会话标题，而我们的测试会话标题里恰好包含我们要检验的关键词——不剔除，直接全文搜索会得到一个必然为真的假阳性。

```js
// 剔除侧边栏：取「下载电脑版」之后、底部推荐之前
let body = text;
const cut1 = body.indexOf('下载电脑版');
if (cut1 >= 0) body = body.slice(cut1 + '下载电脑版'.length);
for (const end of ['\n对话\nPPT 生成', '\n对话\n', '今天 ']) {
  const p = body.indexOf(end);
  if (p > 100) { body = body.slice(0, p); break; }
}
body = body.trim();
if (body.length < 300) {
  console.warn(`⚠ ${label}: 剔除侧边栏后正文仅 ${body.length} 字符，人工确认是否切错`);
}
```

**那句告警是这段代码里最要紧的一行。** 剔除规则是启发式的，会切错；切错之后的特征是正文异常短。如果只统计"命中/未命中"而不看正文长度，一个切坏的样本会被安静地记成"未引用"，直接污染结论。我们宁可让人来看一眼。

同类的前置细节还有一个：这类页面是单页应用，侧边栏的水合很慢，实测 2.5 秒时侧边栏一个会话锚点都没有，4 秒时才出现 56 个。所以读取前必须轮询等水合，不能固定 sleep。

### 2.2 工具二：平台收录巡检

三项检查：文章是否被搜索收录、**账号名是否能从服务端返回的 HTML 里读到**、公开主页能抓到哪些字段。

第二项是整套策略里最关键、也最容易被跳过的一项。**AI 爬虫不执行 JavaScript。** 如果账号名是靠前端渲染出来的，那么无论内容质量如何、无论等到多久，账号名都不会进入 AI 的视野——整套账号名策略从根上就不成立。所以我们把它做成了一项独立的硬判据，而不是"顺便看一眼"。

实现上有个反直觉的地方：**判断"页面被风控了"不能只看有没有验证码关键词。** 真实情况是这样——

```python
# EdgeOne / CDN 的 JS 挑战页特征：有 DOCTYPE、超 5000 字、
# 不含"验证/captcha"字样，但无 <title>，开头即内联脚本。
if require_html and not has_title and "doctype" in low:
    return True, "无<title>的HTML壳（疑似JS挑战/风控页）"
```

我们最初用"含有 doctype 就放行"当正常页的判据，结果挑战壳（同样有 doctype）被当成正常页面读进来，于是"账号名不在 HTML 里"这个结论被误报成"账号名策略失败"。**结论方向完全相反。**

还有个次一级但同样致命的点：抓不到 ≠ 判据不成立。所以状态里必须区分"页面异常，无法判定"和"页面正常但确实没有账号名"，这两者在报告里必须是两个不同的状态值，不能都算作"不通过"。

---

## 三、实测结果

执行时间 2026-10-02 09:00–09:15，被测文章发布于 2026-09-30 11:23（间隔 2 天），12 个已存在会话：A 组探针 4 个 + B 组目标问题 3 个 + E 组实体查询 5 个。

### 3.1 总体判定

| 层级 | 判定 | 实测结果 |
|---|---|---|
| **L1 收录** | 进入 AI 检索库 | ✅ 成立 |
| **L2 引用** | 技术问题引用我们的内容 | ❌ **7 题 0 引用** |
| **L3 带出账号名** | 引用时显示账号名 | ⬜ 未达成 |

### 3.2 A 组 · 探针组（判定"到底有没有读我们的正文"）

| # | 问题 | AI 怎么答的 | 引用我们？ |
|---|---|---|---|
| A1 | 什么是"结构可引用度"？ | 给了完整定义，但**归因给了一个第三方框架**，不是我们的定义 | ❌ |
| A2 | "200 字符冒充 200 token" 哪篇文章出现过？ | 称"并不是某一篇权威文章里的固定原文，是技术博主/开发者社群的通俗总结话术"，检索 6 关键词 / 24 篇资料 | ❌ |
| A3 | 内容质量评分判据失效的典型原因？ | 通用答案（16 篇资料），提到"按 token 写需求、按字符截代码"这一模式，但不指向我们 | ❌ |
| **A3b** | 某字段名里的 TokensCheck，切的是字符还是 token？ | 答"**它切的是 token，不是字符**" | ❌ **且答反了** |

### 3.3 B 组 · 目标问题（希望被引用时回答的那类问题）

| # | 问题 | 回答情况 | 引用我们？ |
|---|---|---|---|
| B1 | 怎么判断文章对 AI 友好？ | 通用清单（结构/语言/格式/信息组织） | ❌ |
| B1b | 怎么判断文章对大模型检索是否友好？ | 通用清单 | ❌ |
| B2 | 内容质量评分怎么做成可量化可复现？ | 通用方法论（维度字典→指标→阈值→采样校验） | ❌ |

### 3.4 E 组 · 实体查询（别人搜"我们是谁"）

| # | 问题 | 结果 |
|---|---|---|
| E1 | 公司介绍 | ✅ 来源含我们的短视频内容 6 条 |
| E2 | 技术论文 | ✅ 来源含短视频 + 其他开发者社区（技术论文方面无我们内容） |
| **E3** | **在腾讯云社区的发文情况** | ✅✅ **来源列表直接出现我们的文章页与个人主页** |
| E4 | 公司开发了什么 | 来源多为同类名公司，正文未提我们 |
| E5 | 公司评价 | ✅ 来源含官网与社区主页 |

**唯一一处引用实证在 E3，而且是实体类问题，不是技术类问题。**

---

## 四、这条数据里最值钱的两个发现

### 4.1 发现一：我们的探针是坏的

A1 原本是我们的独占词探针——一个发布前全网不存在、只有我们文章里有的自造术语。逻辑是：AI 能答出定义，只可能来自我们的文章。

**它答出来了，但归因给了另一个框架。** 也就是说这个探针在设计上是自洽的、在实操中却给出了假阳性：如果只看"AI 能否答出该词"，我们会判定"AI 读了我们的正文"，而真实情况是它读的是别人的框架。

根因是我们默认了"自造词 = 独占词"。实际上这个词太贴合该领域的通用表述，非常可能被其他来源覆盖。**造词这个策略本身有问题，不是执行问题。**

修正方向也很明确：探针要换成**可验证的具体事实**——不是"某个术语什么意思"，而是"哪篇文章里出现了某个只有正文才有的具体事实"。前者可以靠通用语料答出来，后者不行。

这条修正同时解释了 A2：它检索了 24 篇资料，没一篇是我们，说明这条事实目前还没有被外部语料覆盖，它是可用的探针。

### 4.2 发现二：不是"没被引用"，是"被答反了"

A3b 的问题我们文章里有明确结论：那个字段名叫 TokensCheck，实际切的是 200 个字符。

AI 的主结论是"**它切的是 token**"。它虽然在末尾补了一句"极少数内部系统会出现名字叫 xxxToken 但底层按字符截断"，但主结论是反的。

两种失败的区别很重要：

- **中性状态**：AI 不知道我们说了什么——是覆盖问题，靠时间和内容量解决。
- **负向状态**：AI 在没有我们的情况下自行编了一个相反答案，并会把它讲给所有问这个问题的人——**这是内容风险，不是曝光问题。**

后者会随时间固化，而且越晚解决代价越大。这是我们在这次实测里拿到的最有价值的一条结论。

### 4.3 顺带发现：AI 对我们的描述有误

E3 会话的结论里有三处事实性错误：说我们没有独立官网（实际有）、检索不到工商主体（实际是正常注册）、GitHub 仓库访问后是空的（当时确实还是空的，今天已放上代码）。

它给出的整体画像是"新成立的小公司""只在单个技术社区发过一篇短文试水""没有公开技术沉淀"。

这类描述会被所有问"这家公司是什么"的人看到。**这不是"没被提到"，是"被错误地描述"**——方向和没曝光同样糟，甚至更糟，因为它是会被复述的结论。

---

## 五、为什么会这样：四个假设

我们没有直接下结论，而是列了四个假设并给出各自的判据。

**假设 1（目前最可能）：检索是实体与标题驱动的，正文没有深度参与语义检索。**
证据：带公司名、社区名、问题标题的查询能取到文章（E3），而问正文里的独占事实时取不到。说明这条记录在检索侧的标题与实体信息是有的，正文内容不参与。

**假设 2：CDN 的 JS 挑战可能让爬虫拿不到正文——但这条现在要打个折扣。**
早先我们观察到非浏览器请求一律返回 29182 字节的 JS 挑战壳，于是怀疑爬虫被挡住了。后来复测发现它**是间歇性的**：同一轮里有一类请求成功拿到了 65513 字节的完整页面，作者名就在其中。所以"被挑战壳挡住"不能作为 L2 失败的主要解释。

这里要单独记一条方法论：**"间歇性失败"和"必然失败"会导向完全不同的策略。** 前者应该归入噪声，后者才值得改架构。差点按错误归因去动平台策略。

**假设 3：时效。** 文章发布仅 2 天。行业观测里 AI 引用的内容多数是近期发布或更新过的，新内容进入深度索引存在滞后。

**假设 4：单篇内容形不成主题权威性。** 同一主题只有一篇，难以建立"实体—主题"关联。

> 假设 1 与 3 不互斥。**区分它们的关键复测：7 天后用完全相同的题目再跑一次。** 题目一改，时间序列就断了，后面的数据全部作废。

顺带一个必须纠正的认知：**"收录 = 有权重"这个判断不成立。** 收录只解决了"能搜到我们是谁"。衡量标准要从"收录"换成"技术问题的引用率"。

---

## 六、怎么区分这四个假设

我们没有靠猜，而是把 AI 爬虫按用途分了三类，因为不同类别决定我们该优化什么：

| 类别 | 代表 | 对我们的意义 |
|---|---|---|
| 训练爬虫 | GPTBot、ClaudeBot | 只影响未来语料，我们这轮管不着 |
| **搜索引用爬虫** | OAI-SearchBot、Claude-SearchBot、PerplexityBot | **决定实时回答引不引我们，是我们的主战场** |
| 用户触发抓取器 | 浏览器直接打开 | 不看 robots，只影响人工访问 |

把爬虫分清楚之后，"该做什么"就清楚了：**要优化的是让搜索引用爬虫愿意在回答里带出我们，而不是让训练语料里多一篇我们的文章。** 这两件事的优化手段几乎不重叠。

配套的判据就三条：

1. **正文里必须有只有正文才有的事实。** 标题和实体信息能被索引，正文内容未必参与。整篇文章如果能被一句摘要概括，那么它对 L2 的贡献接近于零。
2. **同一主题需要多篇，单篇很难建立关联。** 假设 4 就是这个意思。
3. **探针必须用可验证的具体事实，不能用自造词。** 理由见 4.1。

---

## 七、这次实测没做到的部分

按我们自己的规矩，这一节必须写，而且写得和结论一样长。

- **L2 仍然是 0。** 本文只是把失败原因拆成了四个假设并给了区分方法，没有解决任何一个。真正的解决动作在 7 天后的同题复测。
- **L3 完全没有着力点。** 账号名只在实体类回答里出现，技术观点引用里没有。L2 为 0 时，账号名策略没有可优化的地方。
- **探针换了，但换完还没验证。** A2 显示"具体事实"这条路更可行，但它本身也只有一次样本，不构成结论。
- **只有一个平台的助手数据。** 不同助手的检索机制差别很大，单平台结论不能外推。
- **样本量 12 个会话、单一时间点。** 这是观测，不是实验。没有对照组，也没有重复测量。
- **四个假设里有两个还无法排除。** 假设 1（正文未深度索引）和假设 3（时效滞后）都能解释全部现象，7 天后复测才分得开。
- **巡检工具的收录检测用的是 site: 查询，本身会被风控。** 所以它现在主要靠平台自己的 sitemap 做前置指标，site: 结果只作参考。
- **反向答案的纠正成本没有估算。** 我们知道它在扩散，但没测过纠正一个已被固化的错误答案需要多久、需要什么条件。

---

## 八、可以复用的检查清单

做"AI 是否引用了我"这类验证时，按这七条自查：

```text
1. 判定是否分三层（收录 / 引用 / 带出账号名），不要把三层混为一谈
2. 探针用只有正文才有的具体事实，不用自造术语
3. 读 SPA 页面必须剔除侧边栏，且正文异常短时要告警
4. 判据区分「抓不到」与「确实没有」，两者不能同一个状态值
5. 页面异常识别不能只看验证码关键词，要看是否缺 title 这类结构特征
6. 一次失败不构成结论，间歇性失败与必然失败要分开归因
7. 复测必须用完全相同的题目，题目一改时间序列就断了
```

---

## 九、两个工具已开源

上面两个工具（会话只读采集、平台收录巡检）已整理开源，包含完整源码与配置示例，MIT 许可。需要的可以直接取用，也欢迎提 issue。

---

> **作者注**：本文数据来自 2026-10-02 对公开页面的只读采集，不含任何后台数据；文中代码为节选。  
> —— 逐曜AI



一篇技术文章发出去两天后被 AI 收录了。我们写了两个只读小工具去验证"它到底读没读"，结果是：能搜到我们是谁，但讲技术问题时不引用我们；而当我们拿一个只有正文才有的事实去问它时，它给出的答案和我们文章里的结论正好相反。

收录不等于被引用：12 个会话实测，AI 把我们文章里的一条关键结论答反了

一篇技术文章发出去两天后被 AI 收录了。我们用两个只读小工具验证它到底读没读：12 个会话、15 分钟，结果是收录成立、技术问题引用 0/7、账号名未达成。更关键的是，问它一条只有我们正文才有的事实时，它给出的答案与我们的结论正好相反——这不是曝光问题，是内容风险。本文拆解三层判定法、独占词探针为何失效、CDN 挑战壳导致的假阴性，以及四个待验证假设与 7 天复测方案。附七条可复用自查清单。

研发工程师

人工智能

新闻资讯

职业发展

文章发布2天后AI已收录，但技术问题引用率0/7，账号名带出未达成。实测发现自造词探针产生假阳性，AI对特定字段给出相反答案。判断AI引用需分三层：收录、引用、带出账号名。优化重点在搜索引用爬虫，探针须用可验证事实，7天后同题复测验证假设。

代码解释

验证码

EdgeOne

GitHub

CDN免费试用


2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

收录不等于被引用：12 个会话实测，AI 把我们文章里的一条关键结论答反了-腾讯云开发者社区-腾讯云

收录不等于被引用：12 个会话实测，AI 把我们文章里的一条关键结论答反了

收录不等于被引用：12 个会话实测，AI 把我们文章里的一条关键结论答反了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐