我们在一个内容质量评分服务里写了十几条结构判据。回头拿真实内容核对时，发现其中两处是失效的：

> 一处把 token 当字符用——字段名叫 first200TokensCheck，实现切的是 200 个字符，中英文下覆盖的文本长度差好几倍。  
> 一处用单字拆分提取中文实体，紧接着又按长度大于等于 2 过滤，导致中文实体恒为空、匹配度恒等于 0.5。

两处都不报错、不崩溃，返回值的结构也完全正确。下面先交代判据体系，再拆这两个缺陷，最后讲它们为什么能一路活到线上。

---

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

生成这份内容之前，先把用到的三个概念定义清楚，否则后面所有讨论都会漂移。

**结构性可引用度**：一篇文章被大模型抓取后，其片段能在不依赖上下文的前提下、独立作为答案被引用的程度。它只取决于结构，与文采无关。

**首句原则**：每个二级标题区块的第一段第一句必须是该区块的结论，且在 150 字内说完。超出即视为结论被背景铺垫淹没。

**可解释扣分制**：从 100 分起扣，每一分扣减必须落到一个具体条目上（硬伤或建议）。它与黑箱总分的区别是——能直接告诉作者改哪一句，而不是只给一个数字。

---

## 二、五条可以单独引用的结论

**"AI 友好"不可直接执行，必须先翻译成可测判据。** "让 AI 更容易引用"这句话没有定义任何可观测的量，无法写进代码，更无法回归。落地的第一步是把它拆成能在文本上直接计算的指标。

**在我们可落地的体系里，结构判据归为四类。** 位置（首段、首句、开篇窗口）、形态（问句、问答块、表格）、密度（词频、实体覆盖率）、可信度（数据源标注、更新时间）。我们遇到过的、能被真正计算出来的规则，都能归进这四类之一；归不进去的，通常是无法测量的主观判断。

**扣分制配双通道输出，在我们的场景下比黑箱总分更可用。** 我们同时输出硬伤与建议两列。硬伤是不改就达不到引用门槛的项，建议是能加分的项。作者拿到的是一份修改清单，不是一个需要猜的分数。

**命名与实现不符，是最隐蔽的一类缺陷之一。** 我们把一个字段命名为 first200TokensCheck，实际切的是 200 个字符。函数跑得通、返回值合理，只有拿真实文本去数才看得出问题。

**判据的测试必须配反例夹具，且夹具不应只由判据作者自己写。** 作者写夹具时，脑子里只有自己想到的形态；他想不到的形态，夹具里就不会有。这是后面两个缺陷能活到线上的直接原因。

---

## 三、判据体系：四类，落到代码里是这样

先说清楚这一节的定位：**下面这些是 v0 版本的启发式规则，不是经过验证的最佳实践。** 它们的价值在于把模糊目标变成了可计算的东西，代价是判据偏机械、会误伤。判据上线后必须用真实样本回归，并保留人工校准的入口——这也是第四节两个缺陷能长期存活的土壤。

另外，本节代码均为**节选与简化**：删掉了与判据无关的逻辑，部分变量在完整实现里来自外层作用域，直接粘贴不可运行。

### 3.1 位置类：结论必须出现在可能被截断之前

抓取侧通常不会通读全文，开篇窗口与每个区块的首句是高概率被完整读到的位置。因此位置类判据在我们体系里权重最高。

```ts
// 倒金字塔：首段长度 + 结论句 + 开篇三元组
const lengthOk = firstParaLen > 0 && firstParaLen <= 150;

const conclusionPatterns = [
  /\d+/,                          // 含数字
  /[最更较比].{1,5}[好高低优]/,    // 含比较级结论
  /建议|推荐|选择|注意|核心|关键|本质/,
  /[值需]?得/,
  /实际上|事实上|说到底/,
];
const hasConclusion = conclusionPatterns.some((p) => p.test(firstParagraph));
```

二级标题下的首句单独判一遍，逻辑是分块后逐块检查：

```ts
for (const block of h2Blocks) {
  const firstPara = extractFirstParagraph(block.body);
  if (firstPara.length > 150) {
    score -= 10;  // 首段过长，结论可能被淹没
  }
  const hasData = /\d+/.test(firstPara);
  const hasBrand = brand ? firstPara.includes(brand) : true;
  if (!hasData) score -= 8;   // 核心句缺数据
  if (!hasBrand) score -= 5;  // 核心句缺主体
}
```

分块本身要同时兼容 Markdown 与 HTML，且必须有回退顺序：

```ts
const mdH2Regex = /^##\s+(.+)$/gm;
const mdMatches = [...content.matchAll(mdH2Regex)];
if (mdMatches.length > 0) { /* 走 Markdown 分支 */ return blocks; }
// 回退到 HTML
const htmlH2Regex = /<h2[^>]*>(.*?)<\/h2>/gi;
```

### 3.2 形态类：问答块不是有就行，格式错了等于没有

问答块是生成式回答最容易整段摘取的部分，所以对格式的要求比对数量更严。

```ts
private checkFaqFormat(content: string): boolean {
  const faqQuestions = content.match(/(?:Q|问)[：:]\s*(.+?)(?:\n|$)/gi);
  const faqAnswers = content.match(
    /(?:A|答)[：:]\s*(.+?)(?:\n\n|\n(?=Q|问|$))/gis,
  );

  if (!faqQuestions || faqQuestions.length < 3) return false;  // 少于 3 组不认

  const hasQuestionMark = faqQuestions.some((q) =>
    q.includes('?') || q.includes('？') || q.includes('吗')
    || q.includes('什么') || q.includes('怎么'),
  );
  if (!hasQuestionMark) return false;

  if (faqAnswers && faqAnswers.length > 0) {
    // 答案首句 50 字内必须出现数字
    return faqAnswers.some((a) => /\d+/.test(a.substring(0, 50)));
  }
  return true;
}
```

这里有两处我们至今没改、也承认设计得偏粗的地方。

一是 **some** 的语义是"只要有一条满足即整体通过"，意味着九条答案里只有一条带数字也能过关。这类"只要有一个就行"的判定，在被用于质量门禁时都要重新审视。

二是"答案首句 50 字内必须有数字"这条本身就是个机械代理指标——数字不等于可信，没有数字也不等于不可信。它作为初版启发式能挡掉最明显的空话，但把它当硬门槛会误伤定性结论类内容。

### 3.3 密度类：词频要给期望值，不能给固定值

固定词频阈值在不同长度的文章上必然失真，所以期望值必须随字数走：

```ts
const expectedFreq = Math.floor(wordCount / 300) + 2;
const actualFreq = countKeywordInBody(bodyText, coreKeyword);

if (actualFreq === 0) {
  score -= 25;                                  // 完全没出现
} else if (actualFreq > expectedFreq * 1.3) {
  score -= 20;                                  // 堆砌
} else if (actualFreq < expectedFreq * 0.5) {
  suggestions.push(`核心词偏少：${actualFreq} 次，建议 ${expectedFreq} 次`);
}
```

### 3.4 可信度类：可验证引证的最低门槛

这一类的判据很朴素，只查两件事——有没有标注来源、有没有标注时间：

```ts
const hasCredibleSources =
  /据.*?(?:数据|报告|统计|发布|显示)/.test(content) ||
  /《.*?》/.test(content) ||
  /\d+年.*?(?:案例|项目|客户)/.test(content);

const hasTldrOrDate =
  /TL;DR|摘要|总结|更新时间|\d{4}[-年]\d{1,2}[-月]\d{1,2}/.test(content);
```

这两条正则坦白说是这一节里最粗的：把"摘要""总结"这类结构标记和"更新时间""日期"这类时效标记混在一条里，命中任意一个就通过，两者语义完全不同。它只能说明"作者大概加了点看起来像来源或时效的东西"，距离真正的可验证引证还很远。我们保留它，是因为它至少能把完全没有任何标注的内容筛出来；但把它的得分当成可信度结论，就会出问题。

---

## 四、两处失效的判据

下面这两处，是我们在把判据接进线上之后、拿真实内容回头核对时才发现的。它们的共同特征是：**代码跑得通、返回值的结构完全正确、不报任何错。**

### 4.1 切的是字符，不是 token

字段名叫做 first200TokensCheck，实现是这样的：

```ts
const first200 = plainText.slice(0, 200);
```

**plainText** 是去掉标签与空白后的纯文本，**slice(0, 200)** 切的是 200 个字符。

问题在于字符数和 token 数不是 1:1，而且这个比例随语言剧烈变化。200 个英文字符大约只有三十几个单词，通常还没读完第一句；200 个汉字则已经是完整的一到两段。同一个判据在中英文内容上实际覆盖的文本长度完全不同，"开篇是否包含关键三元组"这个结论自然也不可比。

这类缺陷最难发现，因为它不报错。函数返回的对象结构正确、字段齐全，调用方拿去展示也没问题。**只有当有人去追问"这个 200 到底指什么"时，它才会暴露。**

### 4.2 单字拆分之后又按长度过滤，中文实体恒为空

第二个判据用于计算"标题问句的关键实体在首段的覆盖率"。原始实现是这样的：

```ts
const titleEntities = title
  .split('')                                    // 按单字拆分
  .reduce((words, ch) => {
    if (ch.trim() && !questionWords.has(ch)
        && /[\u4e00-\u9fa5a-zA-Z0-9]/.test(ch)) {
      words.push(ch);
    }
    return words;
  }, [])
  .filter((w) => w.length >= 2 || /\d/.test(w));  // 过滤长度小于 2 的

const uniqueEntities = [...new Set(titleEntities)];
```

先按单字拆分，每个元素长度恒为 1；紧接着过滤长度大于等于 2 的项——这个条件对拆分结果永远为假。于是中文实体被全部清空，只剩下能通过数字正则的单个数字字符。

用真实标题实测的结果如下：

```text
标题: 洛阳装修公司怎么选
split 后长度: 9
filter 前候选数: 9
filter 后实体: []
实体个数: 0
=> matchScore: 0.5

标题2: 2026年装修报价怎么算
-> 实体: ["2","0","6"]   个数: 3
```

第一个标题提取到的实体是空数组，代码随即走"未提取到关键实体词"分支，固定返回 0.5。这意味着**所有纯中文标题的匹配度都是同一个常数 0.5**，判据提供的信息量为零。

第二个标题更直观：它认为"2026年装修报价怎么算"这句话的关键实体是三个字符 2、0、6。覆盖率照这个算下去，得到的数字毫无意义。

这两个问题的根因是同一个：**中文没有空格分词，不能套用英文的按词切分假设。** 正确做法要么接入中文分词，要么改用 n-gram 共现，而不是手工维护一个疑问词表再按字符切。

---

## 五、为什么没有被发现

先说一个比"测试没抓到"更尴尬的事实：**这两个判据一个测试用例都没有。**

我们为这个服务写了单元测试，全部用例不到十条，其中一条还只是断言服务能实例化。真正有断言价值的几项，覆盖的是标题缺核心词、核心词堆砌、标题缺需求动作词、空内容。开篇三元组和问答匹配度这两处，从头到尾没有单独的断言——它们只是作为总分的一部分被间接跑过，没人检查过返回值对不对。

这就引出第二个更普遍的问题：**就算补上测试，写错了照样抓不到。**

假设我们补一条测试：传入标题"某某怎么选"，断言返回值里的匹配度字段落在 0 到 1 之间。这条断言在缺陷存在时依然通过——因为固定返回的 0.5 确实落在 0 到 1 之间。**测试通过，判据失效，两者可以同时为真。**

原因在于这类断言检查的是"函数在给定输入下能返回预期结构"，而不是"判据对内容的判断是否成立"。前者是代码正确性，后者是判据正确性，两者不能互相替代。

由此得到两条对判据类代码通用的规则：

**判据测试必须同时包含正例与反例。** 只写正例（应该得高分的优质内容）无法发现"所有内容都得同样分数"这类失效，必须写一条明显不合格的内容，断言它确实被扣分。

**反例夹具不应只由判据作者自己写。** 作者构造反例时，只会构造自己想象得到的错误形态。上面两个缺陷之所以能上线，很大程度上是因为写夹具的人和写判据的人是同一个，而对这个人来说，"字符和 token 不是一回事"这件事在他写下切分代码的那一刻并不存在。

---

## 六、修法与取舍（截至本文写作时，两处均未修复）

先说明状态：这两处我们目前**还没有修**，下面是方案与取舍，不是已上线的结果。

### 6.1 第一处：把单位定死

两个方向。一是接入 tokenizer，真的按 token 切——准确，但多一个依赖，且不同模型的分词结果不同，"按哪个模型算"本身又变成一个需要定义的问题。二是改用按句切分，取开篇的前 N 个句子——句子是语言无关的边界，中文英文都成立，代价是"N 个句子"的长度仍会随句长浮动。

我们倾向后者。理由是这个判据的语义本来就是"开篇有没有把话说清楚"，句子比 token 更贴近这个语义；为了一个粗略判断引入分词依赖，性价比不合适。无论选哪个，第一步都是把单位写进命名——字段叫 token 就必须是 token。

### 6.2 第二处：换掉切分方式

中文没有空格，按字拆分再拼是不成立的。可行的是两条路：接入中文分词库，实体提取基于词而非字；或者改用 n-gram 共现，用二元组、三元组计算标题与首段的重合度，不依赖分词器。

同时那个手工维护的疑问词表应该换成按词性过滤。手写词表的问题不是不全，而是**永远不知道自己漏了什么**——它不会报错，只会静默地少过滤几个词。

### 6.3 修复后该看什么指标

预期最明显的变化是分数开始分化。修复前，纯中文标题的匹配度全部集中在 0.5，判据提供的信息量为零；修复后分布才真正拉开。

这里有一条值得单独记住的经验：**分数不分化通常是判据失效的重要征兆。** 如果某个评分维度上绝大多数样本落在同一个值附近，先别急着调阈值，先去查这个判据是不是根本没在算东西——调阈值只会让失效的判据看起来更精致。这条比大多数单元测试报警更早，值得做成长期监控。

---

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

写完结构判据后，按这七条自查，能挡掉大部分同类问题：

```text
1. 每个判据的单位是否写在命名里（字符 / token / 句 / 词）
2. 判据是否语言无关，中文无空格分词是否被特殊处理
3. 是否存在恒真或恒假的过滤条件（如拆分后又按长度过滤）
4. 聚合用 some 还是 every，语义是否与门禁强度匹配
5. 测试是否同时包含正例与反例
6. 反例夹具是否由非作者提供
7. 上线后是否监控分数分布（不分化 = 判据失效）
```

---

> **作者注**：本文基于线上服务的真实代码与实测输出改写，代码已脱敏，部分变量名做了泛化处理。  
> —— 逐曜AI





我们在一个内容质量评分服务里写了十几条结构判据。回头拿真实内容核对时，发现其中两处是失效的：

把"AI 友好"拆成可测判据后，我们发现有两处判据是错的

「AI 友好」无法直接执行，必须先翻译成可测的结构判据。我们在内容质量评分里落地了位置、形态、密度、可信度四类判据，回头核对时发现两处失效：名为 first200TokensCheck 的字段实际切的是 200 个字符；用单字拆分提取中文实体后又按长度过滤，导致实体恒为空、匹配度恒等于 0.5。两处都不报错、返回值结构正确，且没有任何测试覆盖。本文给出判据实现、失效根因与七条可复用检查清单。

研发工程师

编程语言

测试

人工智能

内容质量评分系统中两处判据失效：token切分误用字符单位，中文实体提取因单字拆分后被长度过滤恒为空。缺陷无报错但信息量为零，需通过反例测试、命名规范与分数分布监控防范。

单元测试

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

把"AI 友好"拆成可测判据后，我们发现有两处判据是错的-腾讯云开发者社区-腾讯云

把"AI 友好"拆成可测判据后，我们发现有两处判据是错的

把"AI 友好"拆成可测判据后，我们发现有两处判据是错的

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐