公众号文章采集：结构化存储、全文检索与相似度去重

1. 先把采集想清楚目标、边界与合规底线做公众号文章采集这件事我一直觉得它的难点不在技术而在想清楚。很多人一上手就找工具、写脚本、搭数据库折腾两周最后库里堆了两千篇文章一篇没读、一次没检索纯粹给自己增加了一个电子垃圾场。信息收集效率的提升本质不是收集得更多而是从想到某篇文章到把它调出来的时间变短。我自己踩过最典型的一个坑是早期把采集做成了无差别囤积。那时候我的判断标准特别简单标题看起来有用就存。结果三个月后我发现存下来的内容里有大量同质化的行业通稿、重复转载、以及读完就忘的营销文案。真正需要回头查资料的时候我在几千篇文章里搜关键词出来的前二十条全是同一篇稿子的不同版本。那一刻我才明白采集策略的核心不是抓取能力而是筛选规则、结构化程度和可检索性这三件事。所以这篇文章我想讲的是一个内容从业者、研究者或者行业观察者怎么把公众号文章这一类半封闭、重排版、强图文混排的信息源纳入自己的个人知识体系。这套方法适合每天需要跟进十几个甚至几十个信息源的人也适合只是想给自己建一个主题资料库的新手。你不需要会写代码也能跑起来会一点 Python 可以让它跑得更顺。1.1 三种典型需求场景对应三套完全不同的方案我先按需求把人群分一分因为不同目标的方案差别很大选错了就是白费力气。第一种日常跟进型。你的目标是不漏掉重要动态每天花 20 到 30 分钟扫一遍看到关键的就标记、存档。这种需求的核心指标是时效性和覆盖度不需要全文入库只需要标题、来源、发布时间、一句话摘要。方案上应该走轻量订阅 快速浏览的路子工具越少越好最好是一个界面看完所有源。第二种主题研究型。你要围绕某个具体议题比如某个技术方向的演进、某个行业的政策变化做长期跟踪需要往回查、需要横向对比、需要引用原文。这种需求的核心指标是全文可检索、元数据完整、版本可追溯。方案上必须做结构化存储至少要有一个支持全文索引的本地库纯靠文件夹是扛不住的。第三种素材积累型。你做内容创作需要攒案例、攒观点、攒金句、攒数据。这种需求的核心指标是片段级检索和标签复用。整篇文章对你意义不大你需要的是把文章拆成观点块打上主题标签随时能被调用出来。方案上要偏向笔记系统而不是文件系统。我见过最多的失败案例是拿第三种需求的方法去做第一种需求——给每条订阅都建标签、写摘要、做双链坚持一周就放弃了。反过来拿第一种方案去做第二种需求三个月后就会发现我知道我存过但就是找不到。所以在动手之前先花十分钟想清楚你到底属于哪一类这是投入产出比最高的一步。1.2 合规边界哪些动作可以做哪些坚决别碰这一块我必须单独拎出来讲因为它决定了你这套东西能不能长期稳定地跑下去。第一优先使用平台自身提供的功能。大多数内容平台都提供了收藏、标签分组、历史记录这类原生能力这些是最稳的。你不需要对抗任何机制只需要把原生功能的产出物定期导出、整理、归档。第二公开内容的合理使用有边界。你自己订阅、自己阅读、做个人学习研究用的存档和把内容二次分发、商业使用、批量转载是完全不同的性质。前者属于个人使用范畴后者涉及著作权问题。我的原则很简单采集库是私人书架不是二次分发渠道。库里有什么只有我自己看。第三控制请求频率别给别人添麻烦。如果你确实要用脚本处理自己有权访问的内容务必做到低频、串行、加间隔。我个人习惯是单次任务不超过几十条间隔 3 到 5 秒一天最多跑两三轮。这个频率对任何服务都不会造成压力也避免了触发各种限制导致任务中断。第四不要把绕过限制当成技术挑战。有些人喜欢研究怎么突破访问频次限制、怎么处理登录态这属于明确不该碰的区域。一旦你的方案依赖对抗它就极其脆弱——对方一次调整你全部重来。真正稳定的方案永远是顺着规则走。第五敏感和个人信息不采集。文章里出现的个人联系方式、身份信息、未公开的内部数据一律不做结构化提取。这条不是技术问题是底线问题。我把这五条写在脚本的注释第一行每次改动代码前都会看一眼。听起来有点小题大做但这确实是让我这套系统跑了两年没出过问题的原因。1.3 采集前必须定义好的四个字段很多人搭采集系统第一步是写抓取逻辑这是本末倒置。正确的顺序是先定义你要存什么再决定怎么拿。我把每篇文章的元数据压缩到最小必要集合一共四个核心字段加三个可选字段字段是否必填说明为什么需要标题必填原文标题不做改写检索的第一入口也是最可靠的唯一性参考来源必填账号名称用统一简称判断可信度和立场倾向做来源权重时必需发布时间必填精确到日即可时间轴回溯、判断信息新旧正文纯文本必填去掉排版后的文字全文检索、关键词统计、摘要提取的基础原文链接选填用于回看原排版图文类内容必须回原文看纯文本会丢信息标签选填3 到 5 个主题词主题聚合但不要过度依赖摘要选填自己写的一句话只有精读过的文章才写别机械生成这里有个细节值得说来源字段一定要用统一简称不要用原始账号名。因为账号名经常带各种符号、后缀、大小写变化同一个号在不同时间抓到的名称可能不一致最后做统计的时候会分裂成一堆近似来源。我的做法是维护一张映射表第一次遇到新来源时手动确认一次之后全部走映射。另外发布时间在很多场景下是拿不到精确值的尤其是转载类文章页面上显示的可能是转载时间。这时候我宁愿把它标成未知或者只精确到月也不去猜。数据里有一个不可靠字段比没有这个字段更危险因为你会在检索时误信它。2. 信息源分层把公众号文章纳入整体情报体系单看公众号这一个来源很容易做成孤岛。我的经验是把它放进一个三层结构里订阅层负责发现归档层负责保存索引层负责调用。三层各司其职任何一层出问题都不会导致整个体系瘫痪。2.1 订阅层用最少的动作覆盖最多的源订阅层要解决的是我怎么知道有新内容。这里的原则是能聚合就聚合不能聚合就分组。能聚合的情况优先走标准化订阅。很多内容源除了平台内阅读还会提供结构化的更新输出比如站点自带的订阅格式。这类输出的好处是字段规整、带发布时间、正文相对干净、可以一次性在阅读器里看完几十个源。我自己的主力阅读器里一大半信息源都是走这种方式每天早上一次性过一遍十分钟能扫完。不能聚合的情况就老老实实做分组。我的分组逻辑不是按行业而是按阅读优先级每天必看、每周扫一次、按需查阅。这个划分标准非常粗暴但极其有效——它直接决定了你每天打开应用时的行为顺序。以前我按行业分类结果每个分类里都有必看和随便看看等于没分类。提示订阅层千万不要追求全。我测试过当订阅源超过 40 个之后我的实际阅读率会掉到 20% 以下。后来砍到 18 个阅读率回到 70% 以上而且真正有价值的信息反而更多了。源少一点读得认真一点。2.2 归档层剪藏不是目的可回看才是归档层要解决的是我怎么把它留下来。这里有两条路原样保存和结构化解构。原样保存适合图文混排重、有大量图表和排版设计的文章。这类文章的价值很大一部分在视觉呈现上你把它压成纯文本等于把一半信息扔了。我的做法是保留一份完整快照离线可读的完整页面同时在库里记一条纯文本条目用于检索两边用同一个 ID 关联。结构化解构适合观点密集、逻辑清晰的深度文章。这类文章我通常会做三件事提取核心论点、摘出支撑数据、写下我自己的反驳或延伸思考。三个动作加起来大概五分钟但这五分钟决定了这篇文章以后还能不能被用上。这里我必须提醒一个非常常见的误区很多人把剪藏当成了学习。一键保存的爽感会给你一种我已经掌握了的错觉实际上你的大脑什么都没留下。我现在的规则是任何一篇文章如果在保存后 24 小时内我没有对它做过任何加工哪怕只是写一句心得它就会被自动打上未处理标记每周清理时优先丢弃。这个机制逼着我少存、精存。2.3 索引层让我记得存过变成三秒能调出来索引层是整个体系的胜负手。前面两层做得再漂亮如果检索体验差这套系统就废了。我的索引方案是文件名规范 全文索引 标签辅助三重叠加。文件名规范解决粗定位。我的命名格式是日期_来源简称_标题精简版例如2024-03-15_某观察_关于内容分发的三个误区。这个格式的好处是按文件名排序天然就是时间序同时来源和主题一眼可见。千万别用未命名1新建文档这种那是自毁检索。全文索引解决精定位。我用的是轻量本地方案几百 MB 的文本量完全够用建索引几秒钟查询毫秒级。核心是一个支持中文分词的全文检索表后面第 3 节我会给具体建表语句。标签解决模糊定位。比如我想找所有讨论内容审核边界的文章可能标题里根本没出现这几个字但内容里有标签就能兜住。标签的颗粒度要控制在 3 到 5 个太多等于没有。注意索引层的一个隐藏陷阱是重复内容。同一篇文章被多个号转载你的库里会出现三到五份正文几乎一致的条目。如果不做去重检索结果会被同质内容淹没。去重的具体方法我在 3.4 节展开。3. 核心环节实操从看到到存下来的完整链路这一节是纯操作部分。我从单篇采集开始一路讲到批量整理、正文清洗、去重最后给出可以直接跑的代码片段。你不需要全部照做挑自己缺的环节补上就行。3.1 单篇采集的标准动作五步两分钟我给自己定的单篇处理流程是五步熟练之后每篇两分钟左右一天处理十篇也就二十分钟。第一步判断归属。扫一眼标题和前两段先问自己这条信息属于必看备查还是路过。路过的直接跳过不要犹豫。这一步能砍掉 60% 的内容是整个流程里最省时间的一步。第二步粗读并做标记。快速滑到底遇到觉得有用的段落就选中标记。这个动作的目的不是精读而是给后面的加工留下锚点。我一般不会在这一步做笔记因为此时还没形成整体判断。第三步提取核心。用一句话写下这篇讲了什么结论。注意是结论不是主题。写某类内容的分发效率取决于账号定位清晰度是有价值的写讲内容分发等于没写。第四步补充我的判断。这句话可以很短比如这个结论只在特定品类成立数据来源存疑和我上个月看到的另一个说法矛盾。这一步是文章从别人的内容变成我的素材的关键转折。第五步落库。按 1.3 的字段表填进去命名按规范正文做清洗存原始快照。五步走完这篇文章就算真正进入了我的体系。这里有个反直觉的经验不要试图给每篇文章都打完美的标签。我早期在标签上花了大量时间后来发现标签的使用率极低——我真正检索的时候80% 的情况是搜关键词15% 是按时间翻只有 5% 是按标签浏览。所以现在我的策略是能打就打打不出就空着绝不为一个标签纠结超过十秒。3.2 批量整理目录结构与命名规范单篇处理能解决质的问题批量整理解决量的问题。当你的库超过 500 篇之后目录结构的重要性会突然凸显出来。我的目录结构是按年月平铺不按主题嵌套archive/ 2024/ 01/ 2024-01-05_某观察_内容分发的三个误区.md 2024-01-08_某研究_用户留存的五个阶段.md 02/ ... 2025/ ...为什么不按主题分因为一篇文章往往属于多个主题而只属于一个时间。按主题分的话你要么建大量交叉引用要么在分类上反复纠结。按时间分天然唯一永不分歧而且符合我大概记得是几月份看到的这种真实回忆方式。主题维度交给全文索引和标签去解决就行了。命名规范有三个硬性要求日期用YYYY-MM-DD补零格式保证字符串排序等于时间排序来源和标题之间用下划线分隔避免中文空格被某些工具吞掉标题超过 30 字就截断加省略号文件系统对长文件名不友好。还有一个细节同一篇文章的不同版本要保留但要标注。有些深度文章作者会修改或者有勘误。我的做法是在文件名后面加_v2并在正文头部记一行更新说明某年某月某日修订了某段。这个习惯在做长期追踪时非常有用因为你能看到观点的演进过程。3.3 正文清洗把能看变成能算从页面上拿下来的正文直接存是没问题的但如果你想做关键词统计、相似度去重、摘要提取就必须先清洗。清洗的目标是去掉一切非文字内容保留语义完整的段落。清洗规则我整理成了一张表按顺序执行步骤处理内容具体做法为什么1去除脚本与样式删掉 script、style 标签块这些内容会污染分词结果2提取正文容器优先找正文语义标签退化为最长文本块避开导航、推荐位、评论区3压缩空白连续空行合并为一个段落分隔统一格式便于分句4过滤噪声行删除点击关注扫码进群等固定句式这类内容重复率极高干扰检索5统一标点全角半角混合的统一成全角影响分句和检索匹配6保留段落边界用空行分隔段落不做整体拼接后续做段落级检索的关键关于第 4 步我维护了一个噪声句式清单大概三十条比如点击上方蓝字关注长按识别二维码本文首发于某某转载请注明出处。这些句子在检索时毫无价值但会在关键词统计里频繁出现把真正的高频词挤下去。清单需要定期维护因为这类话术是不断变形的。关于第 2 步我踩过一个坑早期我用最长文本块作为正文判据结果遇到那种评论区比正文还长的文章提取出来的全是评论。后来改成优先语义标签 段落密度加权就是统计每个候选块的p标签密度和文字长度取综合分最高的。这个改动之后准确率提升非常明显。清洗完的文本大概是这样的结构标题某篇文章的标题 来源某观察 日期2024-03-15 --- 第一段正文内容包含完整的句子和段落。 第二段正文内容。 --- 清洗统计原文 4821 字清洗后 4103 字删除噪声行 7 条。最后那行统计信息是我特意加的它能帮你快速发现异常。如果某篇文章清洗后字数只剩原文的 20%那大概率是提取逻辑出错了需要回原文人工核对。3.4 去重与相似度别让转载淹没你的检索结果这是我认为整个体系里最被低估的一环。公众号生态里转载、洗稿、摘编的比例非常高同一篇内容你可能在不同账号看到四五次。如果不去重你的检索结果会变得极其低效。去重分两个层次精确去重和近似去重。精确去重很简单对清洗后的正文做一个哈希哈希相同就是完全一样。这个能解决一字不改的转载大概能砍掉 20% 到 30% 的重复。近似去重就麻烦一些因为转载经常会改标题、加导语、删结尾、换配图。我的做法是分段指纹 相似度阈值把正文按段落切开过滤掉短于 20 字的段落每个段落做一次哈希得到这篇文章的段落哈希集合两篇文章的相似度 交集大小 / 并集大小Jaccard 系数相似度超过 0.6 判定为疑似重复进入人工确认队列。阈值 0.6 是我实测调出来的。低于 0.5 会漏掉大量改头换面的洗稿高于 0.75 又会把同主题的不同文章误判为重复。0.6 这个点在中文长文场景下比较平衡。下面是这套逻辑的核心代码用 Python 写的依赖标准库就够import hashlib import re from typing import List, Set def normalize_text(text: str) - str: # 去掉所有空白统一标点降低格式差异带来的干扰 text re.sub(r\s, , text) text text.replace(, ,).replace(。, .).replace(, :) return text def split_paragraphs(text: str, min_len: int 20) - List[str]: # 按空行切段过滤过短的噪声段 raw re.split(r\n\s*\n, text) return [p.strip() for p in raw if len(p.strip()) min_len] def paragraph_fingerprints(text: str) - Set[str]: # 每个段落做哈希文档表示为段落哈希集合 paras split_paragraphs(text) return { hashlib.md5(normalize_text(p).encode(utf-8)).hexdigest() for p in paras } def jaccard(a: Set[str], b: Set[str]) - float: if not a or not b: return 0.0 return len(a b) / len(a | b) def find_duplicates(articles: dict, threshold: float 0.6) - List[tuple]: # articles: {文章ID: 正文文本} prints {aid: paragraph_fingerprints(txt) for aid, txt in articles.items()} ids list(prints.keys()) pairs [] for i in range(len(ids)): for j in range(i 1, len(ids)): score jaccard(prints[ids[i]], prints[ids[j]]) if score threshold: pairs.append((ids[i], ids[j], round(score, 3))) return sorted(pairs, keylambda x: -x[2])这段代码在 800 篇、平均 3000 字的语料上跑单次大概十几秒可以接受。如果库大了可以先用首段哈希做粗筛只对首段哈希相近的做精细比对能快十倍以上。提示判定为重复之后不要急着删。我的做法是保留最早发布的那一篇作为主条目其余的在主条目里记一行同文转载某来源 某日期。这样既保持了库的干净又保留了信息传播路径——这个路径本身有时候就是有价值的信息。4. 工具选型按投入产出比排优先级工具这个话题最容易写偏因为大家总想找最强方案。但我的实际经验是90% 的人只需要前两个档位的工具剩下的 10% 里有一半是在给自己找事做。4.1 三档方案对比先想清楚你愿意付多少维护成本档位典型组成上手成本维护成本适合人群主要短板轻量档平台原生收藏 分组 定期导出半天每周 10 分钟日常跟进型无法全文检索导出后结构丢失中量档阅读器 剪藏工具 本地笔记库2 到 3 天每周 30 分钟素材积累型元数据不统一跨工具关联弱重量档订阅解析 清洗管道 本地全文库 脚本1 到 2 周每月 1 小时主题研究型前期投入大需要一点编码能力我自己的组合横跨中量和重量档日常浏览用阅读器值得留的用剪藏工具落地成 Markdown正文清洗和索引用脚本跑查询靠本地全文库加命令行。整套东西的日常维护时间大概每周 40 分钟其中一半花在清理未处理条目上。有个判断标准可以帮你选档如果你每天需要检索历史内容的次数少于 3 次那你不该上重量档。投入产出的临界点大概就在这里。检索需求是这套系统唯一的产出如果这个需求不存在再漂亮的架构都是自娱自乐。4.2 我实际在用的组合以及为什么这么配订阅解析用轻量脚本。核心就是一个订阅格式的解析库读 XML、抽字段、去重、落库二十几行代码。为什么不找现成的大工具因为我的需求太特殊了我要自定义字段映射、要控制入库节奏、要在入库前做一次噪声过滤。用大工具反而要绕开它的一堆默认行为。轻量脚本的好处是每一行我都知道它在干什么。正文清洗用成熟的提取库 自己的后处理。现成的正文提取库能解决 80% 的情况剩下 20% 靠我自己写的规则补。这里不要追求一个库解决所有问题那不现实。我的做法是提取库出结果我的规则做二次校验字数比例、段落数、是否包含噪声句式校验不通过就打标记进人工队列。存储用单文件数据库。这是我最满意的一个选择。单文件数据库的好处是整个库就是一个文件备份就是复制迁移就是拷贝不需要装服务、不需要配用户权限。我用的是 SQLite建一张主表加一张全文索引表CREATE TABLE articles ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, source TEXT NOT NULL, pub_date TEXT, content TEXT NOT NULL, url TEXT, tags TEXT, summary TEXT, content_hash TEXT UNIQUE, created_at TEXT DEFAULT (datetime(now, localtime)) ); CREATE VIRTUAL TABLE articles_fts USING fts5( title, content, tags, contentarticles, content_rowidid, tokenizeunicode61 );content_hash上加了唯一约束精确去重直接靠数据库层面拦掉插不进去就说明重复了省掉一堆判断逻辑。检索用命令行。我试过给这套东西做个界面做了两天就放弃了。原因很实在我 95% 的检索场景就是输入关键词看标题列表命令行一行sqlite3 archive.db SELECT ...完全够用。为了那 5% 的场景去维护一个界面不值。4.3 脚本的核心模块拆解整个脚本我拆成了四个函数每个函数只做一件事方便单独调试和替换。模块一订阅读取。读订阅源输出一个待处理条目列表每条带标题、链接、发布时间。这一步不涉及正文所以很快可以先跑一遍看看有多少新内容再决定要不要继续。模块二正文提取。对每个条目的链接取回页面提取正文纯文本和原始 HTML。这一步是唯一涉及网络的环节所以必须加间隔、加超时、加失败重试。我的参数是超时 10 秒最多重试 2 次每次间隔 3 到 5 秒随机单次任务上限 30 条。模块三清洗与校验。按 3.3 的规则表处理输出清洗后的正文和一份统计信息。校验不通过的条目标记为needs_review不直接入库。模块四入库与去重。先算精确哈希重复的直接跳过没重复的尝试做近似去重命中阈值 0.6 的标记为suspected_dup都通过的写入主表同时触发全文索引更新。下面是正文提取环节的一个骨架示例重点是展示单条失败不影响整体的错误处理结构import time import random import logging logger logging.getLogger(__name__) def fetch_article(url: str, timeout: int 10, max_retry: int 2) - dict: for attempt in range(max_retry 1): try: resp request_page(url, timeouttimeout) # 自定义取页函数 if resp.status_code ! 200: raise RuntimeError(f状态异常 {resp.status_code}) text, raw_html extract_main_content(resp.text) if len(text) 200: raise RuntimeError(正文过短疑似提取失败) return {ok: True, content: text, html: raw_html} except Exception as exc: logger.warning(第 %d 次失败 %s: %s, attempt 1, url, exc) if attempt max_retry: time.sleep(random.uniform(3, 5)) return {ok: False, content: , html: } def batch_fetch(urls: list, limit: int 30) - list: results [] for i, url in enumerate(urls[:limit]): r fetch_article(url) results.append({url: url, **r}) if (i 1) % 10 0: logger.info(已处理 %d / %d, i 1, min(limit, len(urls))) time.sleep(random.uniform(3, 5)) return results这套结构的价值在于它永远不会因为单条失败而整体崩掉。我早期写的版本是一条失败抛异常结果 30 条的任务第 3 条挂了后面 27 条全部白跑。改成现在这样之后最差的情况也就是几条进重试队列第二天补上就完了。5. 落地流程让这套系统每天只占你 30 分钟工具搭好只是开始真正决定成败的是日常节奏。我见过太多人把系统搭得很漂亮然后因为没有固定的使用习惯一个月后就荒废了。所以这一节我讲的是怎么用而不是怎么建。5.1 日、周、月三级节奏每日节奏20 到 30 分钟固定时段。早上或者午休后打开阅读器把当天的源过一遍。遇到必看型内容走 3.1 的五步流程遇到备查型只做落库不打标签遇到路过型直接跳过。整个过程不做深度思考保持流水线状态。这条流水线最大的敌人是停下来精读一篇一旦精读你今天就只能看这一篇了。我的做法是把精读挪到晚上白天只做分拣。每周节奏30 到 40 分钟。三个动作清理未处理条目超过 7 天没加工的直接删或者归档到冷区、跑一次近似去重、检查一下本周新增的来源质量。第三个动作很重要——每过一段时间就会有新的好号冒出来也会有老号质量下滑来源列表是需要动态调整的。每月节奏1 小时。做一次主题回顾翻一翻这个月存了哪些东西有没有形成新的认识有没有需要跟进但断了线的线索。这个动作看起来虚但它是我这套系统里唯一产生新认知的环节。前面所有的采集、清洗、索引都是在为这一个小时服务。提示三级节奏的关键是固定时间。不要有空就整理那等于永远不整理。我现在把每日流程绑在早上的第一杯咖啡上已经变成条件反射了。5.2 检索与再利用让库真正产生价值存下来的内容如果不用等于没存。我总结了三类高频复用场景每一种都有对应的检索姿势。第一类写东西的时候找论据。这时候我知道自己要论证什么需要的是支撑材料。检索方式是用两三个核心词做全文搜索按时间倒序看前十条只挑那些带着具体数据或者具体案例的。抽象论述类的直接跳过因为写东西的时候最缺的是细节不是观点。第二类做判断的时候找历史参照。比如某个新模式出现了我想知道三年前有没有类似的东西当时怎么演的。这时候检索方式是先按时间范围圈定再用相似模式的不同表述去搜。这一步很看关键词的功力所以我平时会在标签里存一些同义说法就是为了这一刻。第三类复盘的时候看自己的认知变化。这个最有用也最少人做。翻出半年前对同一件事的判断和现在的对比往往能发现自己思维里的固定偏差。我现在的习惯是每季度做一次观点对照把我写过的判断和后来发生的事实摆在一起看。这件事对我的帮助比读一百篇文章都大。6. 常见问题与排查技巧实录这一节全是我自己踩过的坑按发生频率排序。6.1 常见问题速查表现象最可能的原因排查顺序处理办法正文提取出来很短页面结构特殊正文不在常规容器先看原文是否有大量图片/表格手动改提取规则或标记进入人工队列同一篇文章存了多份近似去重阈值过高抽查几组重复对的相似度分数把阈值从 0.75 降到 0.6检索搜不到明明存过的内容全文索引没更新直接查主表看有没有这条记录重建索引检查入库后是否触发了更新中文检索结果乱分词器未适配中文用一个双字词测试换支持中文的分词配置或改用字符级索引来源统计分裂成一堆近似值账号名未做统一映射按来源分组看数量分布补映射表批量 UPDATE 历史数据每天都在处理但库里没增长存了没入库或者卡在待处理队列看待处理队列长度简化流程砍掉非必要字段脚本跑到一半中断单条失败抛出未捕获异常看日志最后一条改成 try/except 包裹单条处理6.2 三个印象最深的坑第一个坑过早追求自动化。我最早的版本是全自动的一天跑三次自动入库、自动打标签、自动摘要。跑了两个月库里 3000 条质量惨不忍睹——标签是机械生成的摘要是一句话套模板去重阈值调得太松导致大量半重复条目。最后我花了整整一个周末做人工清洗那两天的枯燥程度至今记忆犹新。后来我把流程改成了半自动脚本负责搬运和清洗人工负责判断和标注。自动化率从 100% 降到 60%但库的可用性提升了不止一个档次。教训是在流程没跑顺之前不要自动化判断类的工作。第二个坑忽视编码问题。中文内容处理里编码是个阴魂不散的问题。我遇到过同一篇内容在某个环节变成了乱码导致哈希计算完全失效去重全部失灵。更隐蔽的是乱码的文本还能被索引还能被搜到只是搜出来是问号。后来我在管道里加了三个检查点取页后检查一次、清洗后检查一次、入库前检查一次任何一个检查点发现异常字符比例超过 5%就整条打回。这个改动之后编码问题基本绝迹。第三个坑把存档和备份搞混了。有一段时间我的库只存在一台机器上某次系统问题之后半年的积累没了。好在大部分原始链接还在花了几天重新跑了一遍。现在的做法是原始快照和数据库每天自动同步到另一个位置每周做一次完整快照命名带日期。这件事花的时间很少但它决定了你这套系统能不能长期存在。6.3 几个提高效率的小技巧技巧一用首句摘要代替全文阅读做初筛。中文深度文章的第一段往往就交代了核心论点。我现在的初筛动作是只看每篇的第一段三十秒能筛十篇。真正值得读的再往下看这个习惯帮我省下了大量时间。技巧二给高价值来源单独建一个快速通道。我把三个最信任的来源放在独立分组里每天优先看看到就精读。其他的源只做快速扫描。这个权重划分让我的注意力分配更合理——重要的内容得到了充分处理次要的内容也没漏掉。技巧三定期做减法。每季度我会强制自己删掉 10% 的存量内容。删除的标准是三个月内没有被任何一次检索命中、且我自己也想不起来它讲了什么。这个动作听起来有点浪费但它保证了库的平均质量在上升而不是下降。一个不断膨胀但从不清理的库最后会变成一座你不敢进去的仓库。技巧四把检索语句存下来。我常用的几条检索语句比如按来源时间范围找数据类文章都存成了脚本别名一行命令调用。这件事的收益是复利型的——每次省下十几秒一年下来就是好几个小时更重要的是它降低了懒得去查的心理门槛。这套东西我前后迭代了两年从最开始的抓一堆存着到现在每天稳定跑 30 分钟。中间最大的转变其实不是技术而是心态从我要尽可能多地收集变成我要确保每一条存下来的东西将来都能被用上。前者会让人焦虑后者会让人踏实。如果你现在正打算动手搭这么一套我的建议是别从脚本开始先从定义那四个字段开始先用最笨的手动方式跑两周跑顺了再考虑把哪一步交给机器。