推荐智能手记 — AI × 开发者博客 GLM API、Node.js 大模型接入与 AI 工程实践原创文章 https://www.githubmissyang.cn/feed.xml 2026-09-27T11:50:45.304Z 推荐智能手记 © 2026 推荐智能手记 技术文章过期检测：版本监控、复审队列与更新策略 https://www.githubmissyang.cn/articles/technical-content-freshness-version-monitoring-review-queue 2026-08-13T15:30:00.000Z 2026-08-13T15:30:00.000Z 建立可执行的技术文章过期检测机制：用 reviewedAt 与 nextReviewAt 管理复审周期，监听官方版本变更，自动检查链接和代码，并判断更新旧 URL 还是发布新文章。 技术文章过期检测：版本监控、复审队列与更新策略

技术文章最危险的状态，不是明显报错，而是看起来仍然合理，关键步骤却已经失效。模型名下线、SDK 参数改名、官方页面迁移、示例依赖升级，都可能让一篇曾经正确的教程逐渐误导读者。只在文章底部写一个发布时间，无法回答它现在是否仍可信。

可持续的技术内容需要一条维护流水线：记录上次核验时间，监听外部变化，自动执行低成本检查，把风险文章送入人工复审队列，再根据搜索意图决定更新原 URL 还是另写新文。本文给出一套可落地的 技术文章过期检测 方法，并明确一个容易被滥用的边界：不能只改日期，假装内容已经更新。

一、先区分“时间旧”和“内容过期”

文章发布得早，不等于内容错误；昨天发布，也可能引用了已经废弃的接口。过期判断应基于证据，而不是只计算文章年龄。可以把信号分为四类：

  • 时间信号：超过计划复审日期，尚未重新核验；
  • 依赖信号：模型、API、SDK、框架或运行时发布新版本，或者旧版本进入弃用周期；
  • 可执行信号：链接失效、代码构建失败、响应结构变化、截图与当前界面不一致；
  • 用户信号：站内搜索无结果、读者反馈、错误日志或客服问题指向同一篇文章。

时间信号适合提醒，其他三类更接近真实风险。维护系统不应在 nextReviewAt 到期时自动修改正文，而应生成待办并保留检测证据。

二、为每篇文章保存 reviewedAt 与 nextReviewAt

最小内容记录至少包含：

{
  "contentVersion": "1.3",
  "publishedAt": "2026-05-10T02:00:00.000Z",
  "updatedAt": "2026-07-18T08:30:00.000Z",
  "reviewedAt": "2026-07-18T08:30:00.000Z",
  "nextReviewAt": "2026-10-18",
  "reviewedBy": "editor-id",
  "reviewStatus": "verified"
}

这些字段职责不同：

  • publishedAt 是首次发布时刻，通常不应改写；
  • updatedAt 表示正文或关键页面信息最近一次实质修改；
  • reviewedAt 表示最近一次完成事实、链接和示例核验；
  • nextReviewAt 是内部任务计划，不是搜索引擎指令；
  • contentVersion 用于关联修改记录、测试结果和回滚。

只打开文章看一眼，不应直接把 reviewedAt 往后推。复审动作应有检查项与结论，例如“官方 API 文档已核对、三个外链可访问、示例在 Node.js 22 执行通过”。如果检查失败，将状态改为 needs_update 或 blocked，而不是继续显示“已验证”。

复审频率按变化风险设置，比全站统一 90 天更合理。例如模型 API、价格和 SDK 教程可每月或每季度检查；基础算法概念可以半年或一年检查；出现官方弃用公告、代码失败或读者反馈时则立即复审。这里的周期只是站内策略，不是 SEO 排名规则。

三、从正文提取依赖，监听官方版本变更

版本监控不能只订阅新闻。发布时应把文章依赖转成结构化清单：

{
  "articleSlug": "openai-compatible-multi-model-config-nodejs",
  "dependencies": [
    { "type": "npm", "name": "openai", "tested": "5.x" },
    { "type": "runtime", "name": "node", "tested": "22.x" },
    { "type": "api", "name": "chat-completions", "tested": "2026-08" }
  ]
}

监控来源优先使用官方渠道：GitHub Releases API、官方 changelog、npm 包元数据、产品弃用公告和状态页。npm outdated 可以辅助发现本地依赖版本差异，但“出现新版本”并不等于文章已经过期。系统应先比较变化类型：

  1. 补丁更新且没有影响示例的变更，记录事件即可；
  2. 次版本新增能力，检查文章是否需要补充；
  3. 主版本、弃用通知或接口字段变化，提高复审优先级；
  4. 文章指定的版本仍受支持且搜索意图是旧版维护，可保留并明确版本范围。

不要让模型只根据版本号自动重写文章。模型可以总结 changelog、定位可能受影响的段落，但最终结论必须回到官方说明和实际测试。多模型配置的具体实现可以参考OpenAI 兼容 API 多模型统一配置，其中的 provider、模型名和端点都应该成为可监控依赖。

四、链接检查不仅看 HTTP 200

定时任务可从 Markdown、HTML 和 sources 数组提取 URL，检查以下状态：

  • 404、410：目标已移除，应查找官方替代页；
  • 301、308：记录最终地址，确认不是跳到无关首页；
  • 401、403、429：可能是权限或反爬限制，不能直接判定内容不存在；
  • 200：仍要检查最终 URL、内容类型和页面标题；
  • 超时、DNS、TLS 错误：进入重试队列，连续失败后人工确认。

一个谨慎的检查器会限制并发、设置超时、遵守站点规则，并保留检测时间与最终跳转地址：

async function inspectLink(url) {
  const startedAt = Date.now();
  try {
    const response = await fetch(url, {
      method: 'HEAD',
      redirect: 'follow',
      signal: AbortSignal.timeout(8000),
      headers: { 'user-agent': 'ContentFreshnessBot/1.0' }
    });

    return {
      url,
      status: response.status,
      finalUrl: response.url,
      checkedAt: new Date().toISOString(),
      durationMs: Date.now() - startedAt
    };
  } catch (error) {
    return { url, error: error.name, checkedAt: new Date().toISOString() };
  }
}

有些服务器不支持 HEAD，出现 405 时需要用受限的 GET 复查。链接变更后还要确认新页面确实支持原文结论；把失效来源换成主题相近的页面，并不能完成事实核验。站内链接则应在每次构建时检查，具体的孤儿页与锚文本治理可参考技术博客文章内链设计。

五、代码回归要固定环境、输入与断言

代码块语法正确，不代表教程还能完成目标。可执行示例应拆成独立 fixture，记录运行环境和期望结果，并在依赖变更或复审时执行：

import assert from 'node:assert/strict';
import { normalizeModelConfig } from './example.mjs';

const result = normalizeModelConfig({
  provider: 'compatible',
  baseUrl: 'https://example.invalid/v1/',
  model: 'demo-model'
});

assert.equal(result.baseUrl, 'https://example.invalid/v1');
assert.equal(result.model, 'demo-model');

回归记录应包含 commit、Node.js 与依赖版本、测试命令、退出码以及失败摘要。涉及真实 API 时，不要把密钥写进仓库；使用隔离测试账号、最小请求和费用上限。无法稳定调用外部服务时，可以分别做 schema 校验、模拟响应测试和少量人工连通测试。

当回归失败时，先区分文章错误、示例仓库错误和上游临时故障。对 AI 接口的 429、超时与 5xx，可以沿用大模型 API 429、超时和 5xx ]]> 推荐智能手记 AI 内容管线可观测性：如何记录模型、Token、耗时、Trace 与告警 https://www.githubmissyang.cn/articles/ai-content-pipeline-observability-logs-metrics-traces-alerts 2026-08-13T14:00:00.000Z 2026-08-13T14:00:00.000Z

为 AI 内容管线建立可审计的日志、指标、追踪与告警：记录实际使用模型、Token、阶段耗时和失败类型，用 Trace ID 串联抓取到发布，并依据真实历史基线设定阈值。 AI 内容管线可观测性：如何记录模型、Token、耗时、Trace 与告警

一条 AI 内容管线可能依次经过抓取、清洗、去重、分类、总结、审核和发布。页面最后只显示一篇文章，但后台真正需要回答的是：这次总结实际用了哪个模型？消耗了多少 Token？慢在抓取还是生成？一次请求失败后切换过模型吗？发布异常能否追回最初的输入批次？

如果记录里只有一行 summary failed，就算任务最终重试成功，也无法判断成本、质量和稳定性。本篇聚焦 AI 内容管线可观测性：用日志、指标、追踪和告警还原每次真实执行。任务如何入队和重试可参考AI 内容流水线与 BullMQ 任务队列对比；429、超时和 5xx 的处置则见大模型 API 429、超时和 5xx 排查。

一、先定义要回答的问题，而不是先装监控组件

可观测性不是“日志越多越好”。设计前先列出生产排查必须回答的问题：

  1. 哪个业务任务、哪一篇文章、哪个阶段出了问题？
  2. 配置选中的模型与请求实际命中的模型是否一致？
  3. 是否发生过重试、轮询、降级或故障切换？
  4. 输入、输出与总 Token 是多少，供应商是否返回可信用量？
  5. 模型调用耗时、完整任务耗时和排队等待分别是多少？
  6. 失败属于配置、限流、网络、HTTP、解析、质量门禁还是发布？
  7. 同类异常影响一个任务、一个模型，还是整个管线？
  8. 记录能否排查问题，同时不泄露 API Key、提示词与用户内容？

这组问题决定字段和信号。日志适合保留离散事件与上下文，指标适合看趋势和触发告警，Trace 适合还原跨阶段路径。三者应通过同一个 traceId 或业务任务 ID 关联，而不是各自生成互不相干的编号。

二、记录“实际使用模型”，不能只读当前配置

后台配置会变化。任务开始时选择了模型 A，执行中可能重试到模型 B；管理员随后又把默认模型改成 C。如果任务详情只读取当前配置，它会错误地显示“本次使用 C”。

每次执行应保存不可变快照，至少区分四个概念：

字段 含义 示例用途
configuredModelId 任务创建时选中的内部配置 ID 追查当时的配置选择
attemptedModelId 本次尝试准备调用的配置 ID 分析轮询与重试路径
requestedModel 发给接口的 model 值 发现模型名配置错误
responseModel 响应中供应商返回的模型值 确认实际服务版本；无值则记 null

内部配置 ID 比展示名称稳定。供应商、base URL 主机、模型名、配置版本可以保存；API Key 和完整鉴权头不能保存。base URL 如果包含租户、部署或查询参数，也应先规范化，只保留排查所需部分。

一次调用的结构化记录可以长这样：

{
  "event": "ai_model_attempt_finished",
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "jobId": "daily-2026-08-13",
  "stage": "summarize",
  "attempt": 2,
  "providerConfigId": "model-config-02",
  "requestedModel": "example-model",
  "responseModel": null,
  "outcome": "timeout",
  "durationMs": 30124
}

这里的 responseModel: null 表示供应商没有返回或响应未完成，不能用请求模型回填并伪装成响应事实。多模型配置和轮询策略可继续阅读OpenAI 兼容 API 多模型统一配置。

三、日志：每个阶段记录开始、结果和决策

建议为抓取、去重、分类、总结、审核、发布定义统一事件，而不是让每个模块自由拼字符串：

  • pipeline_started：任务来源、配置版本和输入批次；
  • stage_started、stage_finished：阶段名、耗时、输入与输出数量；
  • ai_model_attempt_started、ai_model_attempt_finished：模型快照、尝试序号、用量和结果；
  • model_route_decided：选择、轮询、降级或切换的原因代码；
  • quality_gate_finished：通过、拒绝或进入人工审核，以及规则版本；
  • article_published：文章 ID、slug 和内容版本；
  • pipeline_finished：最终状态、总耗时和失败阶段。

错误不要只保留 message，应使用有限枚举的 errorType：

const ERROR_TYPES = new Set([
  'auth', 'invalid_request', 'rate_limit', 'timeout',
  'network', 'provider_5xx', 'response_parse',
  'quality_rejected', 'storage', 'publish', 'unknown'
]);

同时保存供应商状态码和经过清洗的错误代码。这样既能按稳定维度聚合，又不会丢失定位线索。不要把原始异常文本直接作为指标标签：它可能含敏感内容，而且高基数会让时序数据库产生大量序列。

四、Token：以响应事实为准，缺失就是缺失

支持用量字段的接口通常会提供输入、输出和总 Token，但字段名与口径可能不同。接入层应先保留供应商原始值，再映射到内部字段：

function normalizeUsage(rawUsage) {
  if (!rawUsage) {
    return { inputTokens: null, outputTokens: null, totalTokens: null, source: 'missing' };
  }

  return {
    inputTokens: rawUsage.prompt_tokens ?? rawUsage.input_tokens ?? null,
    outputTokens: rawUsage.completion_tokens ?? rawUsage.output_tokens ?? null,
    totalTokens: rawUsage.total_tokens ?? null,
    source: 'provider_response'
  };
}

需要注意：

  • 流式接口的用量可能只出现在结束事件，连接中断时可能拿不到；
  • 本地 tokenizer 的估算可用于请求前限长，但必须标为 estimated，不能混进供应商返回的实测值；
  • 不同供应商对缓存 Token、推理 Token、多模态输入的计量口径不同；
  • 成本应根据当时的价格版本单独计算，不能用今天的价格回算并声称是历史账单；
  • 若请求失败但供应商可能已经处理，Token 记录应为未知，不能直接写零。

建议同时记录输入条目数、输出字符数等非计费指标，它们能帮助发现“输入数量没变但 Token 突增”的模板或内容异常，但不能替代官方计费用量。

五、指标：控制标签基数，分别看阶段与模型

一组实用的最小指标可以包括：

ai_pipeline_runs_total{result,failed_stage}
ai_pipeline_stage_duration_seconds{stage,result}
ai_model_requests_total{provider,model,result,error_type}
ai_model_request_duration_seconds{provider,model,result}
ai_model_tokens_total{provider,model,direction,usage_source}
ai_pipeline_items_total{stage,direction}
ai_pipeline_inflight{stage}
ai_pipeline_queue_age_seconds

articleId、jobId、traceId 推荐智能手记 生产环境 Prompt 版本管理：变更记录、灰度、评估与回滚 https://www.githubmissyang.cn/articles/production-prompt-version-management-canary-evaluation-rollback 2026-08-13T12:00:00.000Z 2026-08-13T12:00:00.000Z

在 Node.js AI 内容管线中，把 Prompt 当作可发布的软件制品管理：为版本建立不可变 ID，记录输入哈希与配置快照，通过确定性灰度、离线评估和审计日志控制风险，并支持一键回滚。 生产环境 Prompt 版本管理：变更记录、灰度、评估与回滚

Prompt 一旦进入生产环境，就不再只是写在代码里的几段文字。它和模型、采样参数、输出结构共同决定内容管线的行为。只修改一句指令，也可能让分类标签漂移、JSON 解析失败，或让文章摘要的事实边界发生变化。

因此，生产环境的 Prompt 版本管理 应解决五个问题：这次请求用了哪个版本、版本包含什么配置、哪些流量收到了新版本、结果是否通过评估，以及出现问题时能否快速恢复。

本文以 Node.js AI 内容管线为例，给出一套不依赖特定模型厂商的实现框架。它关注发布控制和可追溯性，不重复讨论总结质量指标的具体设计；关于评分样本和回归集，可继续阅读AI 总结质量评估与回归测试。

一、不要用 latest 作为版本

latest、production 只是可变别名，不能回答历史请求究竟执行了什么。每个可发布 Prompt 应有不可变的 promptVersionId，并把实际内容、变量定义和运行配置固化为快照。

一个可读且稳定的版本 ID 可以由业务名、语义版本和内容短哈希组成：

import { createHash } from 'node:crypto';

function stableJson(value) {
  if (Array.isArray(value)) return `[${value.map(stableJson).join(',')}]`;
  if (value && typeof value === 'object') {
    return `{${Object.keys(value).sort().map(
      key => `${JSON.stringify(key)}:${stableJson(value[key])}`
    ).join(',')}}`;
  }
  return JSON.stringify(value);
}

function sha256(value) {
  return createHash('sha256').update(value).digest('hex');
}

function buildPromptVersion(spec) {
  const snapshot = stableJson(spec);
  const digest = sha256(snapshot);
  return {
    promptVersionId: `${spec.name}@${spec.version}+${digest.slice(0, 12)}`,
    promptHash: digest,
    snapshot
  };
}

语义版本方便人阅读，哈希负责验证内容是否被静默修改。已经发布的版本应只读；需要改一个标点，也创建新版本，而不是覆盖旧记录。

二、配置快照必须覆盖完整执行上下文

只保存 system prompt 不足以复现一次调用。建议快照至少包含：

  • system、user 模板及模板变量的 schema；
  • 模型供应商、模型名、接口协议版本；
  • temperature、top_p、max_tokens 等采样参数；
  • JSON Schema、解析器版本及后处理规则；
  • 安全规则、分类词表、知识库或检索配置版本；
  • 创建人、评审人、变更原因和关联工单。

API Key 不应进入快照。只记录密钥引用名或供应商配置 ID，敏感值继续保存在密钥系统中。模型名也不能只从当前后台配置反查，因为后台配置随后可能变化。

在每次任务入队时，把 promptVersionId 写入任务，而不是等 Worker 执行时读取 production 别名。这样即使发布切换发生在排队期间，同一任务仍使用入队时确定的版本。

三、输入哈希让请求可以核对，而不是泄露原文

审计日志需要判断两次调用是否针对同一输入，但原始文章可能包含未发布内容或个人信息。可以对规范化输入计算 inputHash：

function normalizeInput(input) {
  return input.normalize('NFKC').replace(/\r\n/g, '\n').trim();
}

function inputHash(input) {
  return sha256(normalizeInput(input));
}

哈希不是匿名化的万能方案：短文本和可枚举内容仍可能被猜测。生产日志应遵守最小化原则，正文放在受控存储中，审计表只保存哈希、对象 ID、长度和必要的脱敏元数据。若需要跨环境防止字典猜测，可使用服务端 HMAC，并把密钥独立保管。

一次调用建议关联以下标识：

{
  "requestId": "req_...",
  "articleId": "article_...",
  "inputHash": "sha256:...",
  "promptVersionId": "article-summary@2.1.0+...",
  "modelConfigId": "glm-flash-prod-3",
  "releaseId": "rel_..."
}

这组字段可以把内容对象、输入、Prompt、模型配置和发布动作串成一条审计链。

四、用确定性分桶做灰度

灰度发布不能用每次请求都重新抽签的 Math.random()。否则同一篇文章重试时可能在新旧版本之间跳动，结果难以比较。应对稳定业务键做确定性分桶：

function bucket(key, releaseId) {
  const hex = sha256(`${releaseId}:${key}`).slice(0, 8);
  return Number.parseInt(hex, 16) % 10000;
}

function selectPrompt({ articleId, release }) {
  const inCanary = bucket(articleId, release.id) < release.canaryBasisPoints;
  return inCanary ? release.candidateVersionId : release.baselineVersionId;
}

canaryBasisPoints 用万分比表示灰度比例。发布记录还应支持白名单，让内部样本和指定文章优先进入候选版本。分桶键通常选文章 ID 或任务所属租户；选择 requestId 会失去重试黏性。

发布过程可以按“内部样本 → 小比例 → 扩大比例 → 全量”推进，但具体阈值必须由真实流量、风险等级和样本量决定，不应照搬固定数字。每次扩大灰度都生成审计事件，不直接修改一条没有历史的配置。

五、评估要绑定版本和同一批样本

灰度期间至少同时观察三类信号：

  1. 系统可靠性：请求成功、超时、限流、解析与 schema 校验结果；
  2. 内容约束：必填字段、引用格式、长度、敏感词和分类合法性；
  3. 业务质量：人工审核结果及由团队定义的任务指标。

比较基线版与候选版时，应使用相同或可比的输入集合，并把评估规则版本一并记录。否则，流量主题变化可能被误认为 Prompt 改进。线上监控负责发现风险，离线固定回归集负责减少样本差异；两者不能互相替代。

如果模型供应商、模型版本或后处理器同时变化，就无法把结果变化单独归因给 Prompt。必须同时变更时，应把它们归入同一个发布单元，并在结论中明确这是组合变更。多模型配置方式可参考OpenAI 兼容 API 多模型统一配置。

六、回滚切换别名，不删除问题版本

回滚的核心是让新的任务重新指向已验证的基线版本。不要删除候选版本或改写历史日志，因为它们是定位问题的证据。

async function rollbackRelease(store, releaseId, actor, reason) {
  const release = await store.getRelease(releaseId);
  await store.transaction(async tx => {
    await tx.setAlias(release.promptName, 'production', release.baselineVersionId);
    await tx.disableRelease(releaseId);
    await tx.appendAudit({
      type: 'prompt.release.rolled_back',
      releaseId,
      from: release.candidateVersionId,
      to: release.baselineVersionId,
      actor,
      reason,
      occurredAt: new Date().toISOString()
    });
  });
}

回滚只影响尚未锁定版本的新任务。对于已经入队、执行中或等待人工审核的内容，需要明确策略：继续完成、取消重跑，还是标记为候选版本产物等待复核。该策略应进入操作手册，避免事故发生后临时决定。

七、审计日志应追加，不应覆盖

建议将版]]> 推荐智能手记 AI 内容去重实战：URL 规范化、标题相似度与内容指纹 https://www.githubmissyang.cn/articles/ai-content-dedup-nodejs-url-title-fingerprint 2026-08-13T12:00:00.000Z 2026-08-13T12:00:00.000Z

面向 Node.js 抓取与内容管线，组合 URL 规范化、标题相似度、正文指纹、幂等写入和人工复核，建立可追溯的分层去重流程，并说明 canonical 不能替代数据去重与唯一约束。 AI 内容去重实战：URL 规范化、标题相似度与内容指纹

一个内容管线同时抓取 RSS、站点列表页和公众号精选时，同一篇文章很容易以不同形式进入系统：URL 带着不同跟踪参数、标题增加栏目后缀、正文被转载或更新，定时任务重跑也可能再次写入。若直接把每条抓取结果交给模型总结，不仅浪费调用资源，还会让文章列表、专题页和站点地图出现重复内容。

可靠的去重不能只靠一个规则。更适合工程落地的方案是分层判断：先用规范 URL 拦截确定重复，再用标题相似度筛选候选，最后用正文指纹提供内容证据；无法确定的条目进入人工复核，而不是静默删除。

本文聚焦 AI 内容去重 Node.js 管线。任务队列与抓取解耦可参考AI 内容流水线：同步脚本还是任务队列，数据持久化升级可继续阅读Node.js 内容管线从 JSON 迁移到 SQLite。

一、先区分数据去重和搜索引擎 canonical

rel="canonical" 用来向搜索引擎表达一组相似页面中偏好的规范网址。它是索引信号，不会阻止你的抓取程序保存两条记录，也不会替数据库执行唯一约束。

两者职责应明确分开：

  • 管线去重：决定一条抓取结果是新增、更新、疑似重复还是跳过；
  • 数据库幂等：确保相同任务重试不会重复插入；
  • 站内 canonical：文章详情页输出唯一、可访问的首选 URL；
  • 重定向：旧 slug 或别名确认迁移后，用 301 指向规范页面；
  • 站点地图与内链：只使用规范 URL，避免持续向搜索引擎发送冲突信号。

因此，页面已经有 canonical，并不代表后台可以不做去重。相反，如果后台误合并两篇不同文章，再正确的 canonical 也无法找回被覆盖的数据。

二、建立稳定的规范 URL

URL 第一层适合处理确定性重复，例如 utm_source 不同、主机名大小写差异、默认端口或 fragment 不同。Node.js 的 URL 类可以承担解析工作：

const TRACKING_PARAMS = new Set([
  'utm_source', 'utm_medium', 'utm_campaign',
  'utm_term', 'utm_content', 'spm', 'from'
]);

export function normalizeUrl(input) {
  const url = new URL(input);
  url.hash = '';
  url.hostname = url.hostname.toLowerCase();

  for (const key of [...url.searchParams.keys()]) {
    if (TRACKING_PARAMS.has(key.toLowerCase())) {
      url.searchParams.delete(key);
    }
  }

  url.searchParams.sort();
  if (url.pathname !== '/') {
    url.pathname = url.pathname.replace(/\/+$/, '');
  }
  return url.toString();
}

不要全局删除所有查询参数。?page=2、?lang=en、文章 ID 或版本参数可能对应不同内容。更稳妥的做法是维护通用跟踪参数白名单，再为已确认的来源配置站点级规则。

还要单独保存 sourceUrl 和 normalizedUrl。前者保留证据，后者用于查重；不要为了规范化而丢失原始地址。

三、用标题相似度寻找候选，而不是直接删除

完全相同的标题可以快速匹配，但转载标题常会增加前后缀，例如“深度解读”“今日精选”或媒体名称。可以先做标题清洗，再使用 token 集合的 Jaccard 相似度筛选候选：

function normalizeTitle(value) {
  return String(value)
    .normalize('NFKC')
    .toLowerCase()
    .replace(/[\s\p{P}\p{S}]+/gu, ' ')
    .trim();
}

function bigrams(value) {
  const text = normalizeTitle(value).replace(/\s+/g, '');
  const result = new Set();
  for (let i = 0; i < text.length - 1; i += 1) {
    result.add(text.slice(i, i + 2));
  }
  return result;
}

function jaccard(left, right) {
  const a = bigrams(left);
  const b = bigrams(right);
  if (!a.size && !b.size) return 1;
  const intersection = [...a].filter(token => b.has(token)).length;
  return intersection / new Set([...a, ...b]).size;
}

这个分数只能表达字符片段的重合程度，不能证明语义相同。“模型 A 对比模型 B”和“模型 B 对比模型 A”可能高度相似，但文章观点、时间或测试版本不同。标题分数适合缩小正文比对范围，不适合单独触发永久删除。

阈值也不应凭感觉写死。应从本站历史文章中抽取一批候选，由编辑标注“重复、相关但不同、完全不同”，再观察不同阈值下的误判和漏判。没有完成标注前，应将中间区域全部送入复核。

四、正文指纹提供更强的内容证据

对正文去除 HTML、导航、空白差异和常见模板后，可以计算 SHA-256。完全一致的清洗正文会得到相同指纹：

import { createHash } from 'node:crypto';

export function contentFingerprint(text) {
  const normalized = String(text)
    .normalize('NFKC')
    .replace(/<[^>]+>/g, ' ')
    .replace(/\s+/g, ' ')
    .trim();

  return createHash('sha256')
    .update(normalized, 'utf8')
    .digest('hex');
}

密码学哈希适合判断规范化后完全一致的正文，但只改一个字，哈希也会完全不同。转载时增加编辑导语、免责声明或相关推荐，单一 SHA-256 就无法识别近似重复。

工程上可以同时保存：

  1. contentHash：完整清洗正文的精确指纹；
  2. paragraphHashes：去重后主要段落的指纹集合；
  3. contentLength：辅助发现抓取缺失或模板污染；
  4. extractorVersion：记录正文清洗规则版本。

比较段落集合可以识别“正文大部分相同但前后增加模板”的情况。若要引入 SimHash、MinHash 或向量相似度，也应把它们当作候选信号，并通过标注语料验证，不能把相似度直接包装成事实。

五、组合证据形成可解释决策

去重服务不应只返回 true 或 false，而应输出决策、理由和证据：

function decideDuplicate(candidate, existing) {
  if (candidate.normalizedUrl === existing.normalizedUrl) {
    return { decision: 'duplicate', reason: 'same_normalized_url' };
  }
  if (candidate.contentHash === existing.contentHash) {
    return { decision: 'duplicate', reason: 'same_content_hash' };
  }

  const titleScore = jaccard(candidate.title, existing.title);
  if (titleScore >= candidate.reviewThreshold) {
    return {
      decision: 'review',
      reason: 'similar_title',
      titleScore
    };
  }
  return { decision: 'new', reason: 'no_strong_match' };
}

实际系统还应限制候选范围，例如只比较相近发布日期、相同语言或相同主题中的记录，避免全表两两计算。所有阈值和规则版本都应写入判定记录，方便日后解释为什么某篇文章没有发布。

建议使用四种状态：