企业官网建设流程全解析

1. 一份“每日简报”背后到底在解决什么问题

每天早上打开十几个信息源，把前一天冒出来的论文、模型发布、工具更新、行业动态过一遍，再筛出真正值得看的那几条——这件事我断断续续干了快两年。最开始是手动刷，后来写脚本抓，再后来干脆做成了一套固定流程，每天产出一份“每日 AI 研究简报”。标题里那个日期，本质上就是这份简报的版本号，它代表的不是某一条新闻，而是一整套“信息采集—筛选—压缩—归档”的流水线。

这份东西能做什么？说白了就三件事：把散落在各处的 AI 研究动态收拢到一处；用一套相对稳定的标准把噪音过滤掉；把剩下的内容压缩成十分钟内能读完的形态，并且留下可回溯的记录。它解决的核心痛点是信息过载下的决策疲劳——你不需要每天重新决定“今天该看什么”，流程替你做完了初筛，你只需要在结果上做二次判断。

适合谁参考？三类人。第一类是独立研究者或小团队的技术负责人，没人帮你做情报整理，只能自己搭；第二类是想保持技术敏感度的工程师，每天愿意花十分钟跟进但不希望被信息流牵着走；第三类是做技术内容或投资研究的人，需要一个可积累、可检索的素材库。基础要求不高，会写一点脚本、能读懂 JSON 和 Markdown 就够了，剩下的都是流程设计问题。

我先把结论摆前面：这套东西的价值不在“抓得多”，而在“筛得准”和“存得住”。抓取是最容易的部分，任何一个刚学编程的人都能写出来；真正拉开差距的是筛选规则的设计和归档结构的设计，这两块决定了你三个月后还能不能从简报里翻出有用的东西。下面我按设计思路、核心细节、实操流程、问题排查四个层面拆开讲，中间会穿插我踩过的坑和现在还在用的具体参数。

2. 整体设计与思路拆解

2.1 为什么是“简报”而不是“聚合器”

一开始我也想过做成一个网页聚合器，把所有源拉到一个页面上滚动展示。试了两周就放弃了，原因很实际：聚合器解决的是“看到”，但没解决“判断”。信息全堆在一起，读者的认知负担反而更重，因为你还是得逐条判断哪条重要。简报的逻辑不一样，它在展示之前就完成了一次排序和裁剪，输出的是已经做过取舍的结论，读者拿到的是一个有观点的列表，而不是一个原料堆。

这个取舍带来的直接好处是归档友好。聚合器的历史数据是一堆原始条目，检索时噪音极大；简报每天一份，天然按日期切分，每份内部又有固定的分节结构，三个月后想找“某类方法在某个时间段的变化”，直接按日期和分节定位就行。我现在的归档目录就是按年/月/日期.md存的，配合简单的全文检索，回溯效率比聚合器高一个量级。

另一个考量是产出节奏。聚合器是实时的，简报是定时的。定时意味着你可以把处理放在低峰时段跑，也意味着读者形成了固定的阅读预期。我实测下来，每天早上七点前生成、七点半推送，打开率明显高于随机推送。节奏感本身就是产品的一部分。

2.2 信息源的选型逻辑：少而稳，分层管理

信息源这块我走过弯路。最开始贪多，列了四十多个源，结果每天抓取失败率接近三成，维护成本高得离谱。后来砍到十几个，按“信噪比”和“更新频率”两个维度分层，才稳定下来。

我的分层是这样的：第一层是核心源，五到六个，特点是更新稳定、内容质量高、格式规整，这部分要求抓取成功率在 95% 以上，任何一天缺了都要报警；第二层是补充源，六到八个，更新不规律但偶尔有独家内容，抓取失败可以容忍，不报警；第三层是观察源，数量不定，主要是新出现的方向或工具，手动加进去试跑一段时间，表现好就升级到第二层，表现差就删掉。

为什么这么分？因为维护精力是有限的。如果所有源一视同仁，你会把大量时间花在修那些本来就没什么价值的抓取上。分层之后，核心源出问题立刻处理，补充源攒着周末一起修，观察源直接删了重加，心理负担小很多。这里有个经验：核心源不要超过六个，超过之后每天的异常处理就会挤占筛选时间，得不偿失。

选源的时候我有个笨办法但很有效：连续观察一个源两周，记录它每天产出的条目里，真正被你点开细看的有几条。低于 10% 的直接降级。这个比例听起来苛刻，但实测下来，大部分泛资讯类源都过不了这一关，能留下来的往往是垂直度高、编辑有筛选的源。

2.3 筛选规则的设计：三层漏斗

筛选是整个流程里最需要动脑子的部分。我的做法是三层漏斗，每层解决不同的问题。

第一层是去重与格式清洗。同一篇内容经常在多个源出现，标题措辞还不一样。我用的是标题指纹加正文首段的组合哈希，相似度超过阈值就判为重复，保留最早出现的那条。这一层能砍掉大约四成的条目，而且几乎不误伤。

第二层是关键词与来源加权。给每个源一个基础权重，再给关键词表里的词分配权重，条目得分等于来源权重乘以关键词命中权重之和。关键词表分三档：核心词（比如具体的方法名、模型架构名）权重高，领域词（比如某个应用方向）权重中，泛词（比如“突破”“发布”这类）权重低甚至为负。这一层的目的是把明显不相关的东西挡在外面，同时让核心源的内容有优先级。

第三层是人工复核规则。这一层不是每天手动看，而是维护一份“黑名单”和“白名单”规则。黑名单是明确不要的内容类型，比如纯融资新闻、纯人事变动；白名单是必须保留的类型，比如某个特定方向的方法论文。规则用简单的配置文件维护，每天跑之前加载。这一层看起来原始，但灵活性最高，遇到新情况改一行配置就行，不用动代码。

三层下来，四十条原始条目通常剩八到十二条进入简报，比例大概四比一。这个比例是我反复调出来的，太高了读者觉得水，太低了又怕漏掉重要内容。你可以从五比一开始，根据自己读者的反馈微调。

2.4 输出结构的设计：固定骨架加弹性区块

简报的 Markdown 结构我改过很多版，现在稳定在一个“固定骨架加弹性区块”的形态。固定骨架是每天必有的部分：日期头、今日概览（三到五句话）、分节内容（按主题分，比如方法、工具、应用、观点）、末尾的归档链接。弹性区块是按需出现的，比如“本周值得回看”“待验证的线索”，不是每天都有。

为什么要有固定骨架？因为读者的阅读习惯是养成的。固定结构让读者知道去哪找什么，扫读效率高。弹性区块则是给那些不适合塞进固定分类的内容留的口子，避免为了归类而扭曲内容。我试过全固定结构，结果有些内容硬塞进去很别扭；也试过全弹性，读者反馈说每天结构都不一样，读起来累。折中下来这个方案最舒服。

分节的主题也不是一成不变的。早期我按“论文、产品、观点”分，后来发现论文和产品经常交叉，就改成按研究方向分，每个方向下面再区分类型。这个调整的依据是读者的使用场景：大部分人看简报是为了跟进某个方向，而不是为了看某一种内容类型。按方向组织比按类型组织更贴近真实需求，这一点在多个领域的简报产品里都验证过。

3. 核心细节解析与实操要点

3.1 抓取环节：稳定比快更重要

抓取这块我的原则很明确：稳定优先于速度，结构化优先于完整。具体说，我宁愿某个源每天晚十分钟抓到，也不愿意它时快时慢导致后续流程时序错乱；宁愿只抓到标题和摘要，也不愿意为了抓全文而频繁触发反爬导致整个源被封。

实现上，每个源一个独立的抓取函数，返回统一的中间结构，字段包括标题、链接、发布时间、摘要、来源标识、原始分类。这个中间结构是整个流程的契约，后面的去重、打分、渲染都只认这个结构，不关心源的具体格式。这样做的好处是加新源的时候只需要写一个转换函数，其他部分完全不用动。我现在的源配置就是一个列表，每项包含源标识、抓取函数名、权重、超时时间，加源就是往列表里加一项。

超时时间我设的是每个源 15 秒，整体流程 5 分钟硬超时。为什么是 15 秒？实测下来大部分源在 3 秒内返回，15 秒足够覆盖网络抖动，再长就是源本身有问题，等下去也没意义。整体 5 分钟是为了保证简报能在固定时间产出，个别源卡住就跳过，记录到异常日志里，第二天再看。

注意：抓取频率一定要克制。同一个源两次抓取间隔不要低于它的更新周期，否则既浪费资源又容易触发限制。我的做法是每个源配置一个最小间隔，流程启动时检查上次抓取时间，没到间隔就跳过。

还有一个细节是时间窗口的处理。简报是每日的，但源的更新不是按自然日切的。我的做法是抓取时带上一个时间窗口参数，默认是“过去 26 小时”，比 24 小时多留两小时缓冲，避免因为时区或发布延迟漏掉内容。多出来的部分在去重阶段会被自然过滤，不会重复出现。

3.2 去重算法：指纹怎么算才靠谱

去重看起来简单，实际坑不少。最早我用标题完全匹配，结果同一篇内容在不同源标题差几个字就漏过去了。后来改成标题的字符级相似度，又出现误判——不同内容标题很像的情况在 AI 领域特别常见，比如一堆“某某方法在某某任务上的新进展”。

现在用的是组合指纹：标题去掉标点和空格后取前 30 个字符，加上正文摘要的前 80 个字符，拼起来做一次哈希。判重的时候不是比哈希相等，而是比两个指纹的编辑距离，距离小于阈值的判为重复。阈值我设的是标题部分允许 3 个字符差异，摘要部分允许 10 个字符差异。这个参数是试出来的，太严了漏判，太松了误判，3 和 10 是我这边数据上比较平衡的点。

为什么用编辑距离而不是更高级的语义相似度？因为语义相似度需要模型，模型有延迟也有成本，而去重这个环节对准确率的要求没那么极致——漏掉一个重复最多是简报里多一条，误判一个不重复的才是真问题。编辑距离在这个场景下性价比最高，纯字符串操作，毫秒级完成，规则透明好调试。如果条目量级上去了，可以考虑加一层向量召回做粗筛，但目前这个规模没必要。

去重之后还要做一次同源合并。同一个源在同一天可能发多条相关内容，比如一个系列的多篇。我的处理是把同源、同分类、发布时间间隔小于两小时的条目合并成一条，标题取第一条，摘要拼接。这样避免简报里出现连续几条来自同一源的碎片内容，阅读体验好很多。

3.3 打分与排序：权重表怎么维护

打分公式本身很简单：条目得分等于来源权重乘以关键词得分，关键词得分是命中词的权重之和，没命中任何词得基础分。复杂的是权重表的维护。

我的关键词表是一个 YAML 文件，分三组：core、domain、noise。core里的词权重 3 到 5，是具体的方法名、架构名、技术术语；domain里的词权重 1 到 2，是应用方向、任务类型；noise里的词权重负 1 到负 3，是那些一看就是营销话术的词。来源权重在另一个配置里，核心源 1.5，补充源 1.0，观察源 0.6。

维护节奏是每周一次。每周五花二十分钟，看这周的打分结果，把明显打高或打低的条目拎出来，调整对应的词权重。调整的时候有个原则：一次只动一个词，动完观察三天。同时动多个词会导致你分不清是哪个改动起了作用。这个习惯是从调参里带过来的，用在权重维护上同样有效。

排序不是单纯按分数从高到低。我的做法是先按分节分组，组内按分数排序，但每组强制保留至少一条低分条目。为什么？因为高分条目往往是共识内容，大家都觉得重要；低分条目里偶尔藏着冷门但有价值的东西，强制保留一条是给这类内容留个口子。这个设计是我从一位做编辑的朋友那里学来的，他说好的版面要“有主有次，但次不能没有”。用在简报上，效果确实比纯按分数排要好。

3.4 摘要压缩：人工规则加模板

摘要这块我没有用生成模型，原因有两个：一是每天条目不多，人工写摘要的成本可以接受；二是生成模型的摘要容易趋同，读多了会发现每条都长得差不多，反而失去区分度。

我的做法是半自动：脚本从原文里抽取关键句（包含数字、方法名、结论词的句子优先），拼成一个草稿，然后我手动改。改的时候遵循一个模板：一句话说做了什么，一句话说结果如何，一句话说为什么值得关注。三句话，不超过 120 字。这个模板强制我把“是什么”和“为什么重要”分开写，避免摘要变成内容复述。

提示：摘要里尽量保留具体数字和具体方法名，删掉所有形容词。读者要的是可判断的信息，不是感受。

这个环节每天花的时间大概十五到二十分钟，是整个流程里唯一的重人工环节。我试过完全自动化，产出质量下降明显，读者反馈“看了摘要还得点进去才知道在说什么”，那就失去简报的意义了。十五分钟换一份能直接用的简报，这笔账是划算的。

4. 实操过程与核心环节实现

4.1 环境与目录结构：先定规矩再写代码

动手之前先把目录结构定下来，这一步很多人跳过，后面会吃大亏。我的结构是这样的：

briefing/ config/ sources.yaml keywords.yaml rules.yaml scripts/ fetch.py dedupe.py score.py render.py run_daily.sh data/ raw/2026/10/19.json processed/2026/10/19.json output/ 2026/10/19.md logs/ 2026-10-19.log

config放所有可调参数，scripts放流程脚本，data分原始和处理后两层，output是最终简报，logs按天切分。这个结构的关键是原始数据和处理后数据分开存。原始数据是抓下来没动过的，处理后是去重打分完的。分开存的好处是，如果某天发现筛选规则有问题，可以直接拿原始数据重跑，不用重新抓。我吃过没存原始数据的亏，有一次规则改错了，想回滚重跑，结果源已经更新了，抓不到当时的内容，只能作罢。

环境上没什么特殊要求，Python 3.9 以上，依赖就几个：抓取用requests加beautifulsoup4，配置解析用pyyaml，日期处理用标准库。不引入重型框架，因为流程本身不复杂，框架带来的抽象成本大于收益。整个项目代码量控制在八百行以内，一个人维护毫无压力。

4.2 每日流程的编排：五个阶段串起来

每天的流程分五个阶段，用一个 shell 脚本串起来，每个阶段失败都不阻断后续（除了抓取完全失败），失败信息写进日志。

第一阶段抓取，并行跑所有源，每个源独立超时，结果汇总成一个 JSON。第二阶段去重，读原始 JSON，输出去重后的 JSON。第三阶段打分排序，读去重结果加配置，输出带分数的 JSON。第四阶段渲染，读打分结果，生成 Markdown 草稿。第五阶段人工复核，我打开草稿改摘要、调顺序、补弹性区块，然后发布。

为什么用 shell 串而不是一个 Python 脚本跑到底？因为分阶段之后，每个阶段可以单独重跑。比如渲染出问题，改完直接重跑第四阶段，不用重新抓取和打分。这种可重入性在调试时太重要了。shell 脚本里每个阶段就是一行命令，加个set -e之外的错误处理，简单直接。

#!/bin/bash DATE=$(date +%Y-%m-%d) python scripts/fetch.py --date $DATE || echo "fetch failed" >> logs/$DATE.log python scripts/dedupe.py --date $DATE python scripts/score.py --date $DATE python scripts/render.py --date $DATE

这段脚本没什么技术含量，但它是整个流程的骨架。我建议你一开始就把这个骨架搭好，哪怕每个脚本里先写个空函数，先把流程跑通，再往里填逻辑。先通后优，比一上来就追求完美实现要快得多。

4.3 渲染模板：Markdown 怎么写才好读

渲染这块我用的是 Python 的字符串模板，没上模板引擎。原因是简报结构固定，模板引擎的抽象在这里是负担。模板大致长这样：

TEMPLATE = """# 每日 AI 研究简报 · {date} ## 今日概览 {overview} { sections } --- 归档：{archive_link} """

分节部分按主题循环生成，每节下面是条目列表，每条包含标题链接、来源、摘要、分数（可选显示）。这里有个细节：分数默认不显示，只在调试模式下显示。读者不需要知道打分细节，显示了反而干扰阅读。这个开关放在配置里，调试时打开，平时关掉。

排版上有几个我坚持的规则。第一，每条摘要控制在三行以内，超过就说明写啰嗦了。第二，条目之间空一行，但不用分隔线，分隔线多了页面很碎。第三，链接用行内链接，不用引用式，因为简报是单文件阅读，引用式反而增加跳转成本。第四，日期头用一级标题，分节用二级，条目用无序列表，层级不超过三层。这些规则看起来琐碎，但累积起来决定了阅读体验。

注意：Markdown 渲染出来之后一定要在手机上看一眼。很多在电脑上排版正常的简报，手机上因为链接太长会撑破布局。我的做法是链接文字用短标题，完整链接放在行内，必要时用短链接服务压缩。

4.4 归档与检索：让三个月后的你能找到今天的内容

归档不是把文件存下来就完事，关键是可检索。我的做法是每天的输出文件按年/月/日期.md存，同时在根目录维护一个index.json，记录每天的日期、条目数、涉及的主题标签。检索的时候先查 index 缩小范围，再在对应文件里全文搜索。

主题标签是渲染阶段自动提取的，来源是打分阶段命中的core和domain关键词。每天大概三到五个标签，存进 index。这样三个月后想找“某个方向的所有简报”，直接按标签过滤 index 就行，不用逐个文件打开。这个设计成本很低，但回溯效率提升明显。

还有一个习惯是每周做一次合并视图。每周日把过去七天的简报合并成一个周报文件，去重、按主题重组、加一段本周趋势的短评。周报的存在让“日更”不至于变成信息碎片，也给那些不是每天看的人一个补课入口。合并逻辑很简单，读七天的 processed JSON，按主题分组，每组内按分数排序取前若干条。趋势短评是手写的，三到五句话，说说这周哪个方向动静大、哪个方向安静。这段手写内容是周报里最有价值的部分，也是我坚持不自动化的地方。

5. 常见问题与排查技巧实录

5.1 抓取失败：先分清是网络问题还是结构问题

抓取失败是最常见的问题，但失败原因差别很大，处理方式完全不同。我的排查顺序是：先看 HTTP 状态码，再看返回内容长度，最后看解析结果。

状态码 4xx 一般是请求本身有问题，比如路径变了、参数缺了，这种要改抓取函数。状态码 5xx 是对方服务问题，等一段时间重试就行，不用改代码。状态码正常但返回内容长度异常短，通常是触发了限制或者返回了错误页，这时候要看返回内容里有没有提示信息。解析结果为空但内容长度正常，那就是页面结构变了，需要更新解析规则。

我整理了一个速查表，贴在显示器旁边：

这张表覆盖了我遇到过的九成情况。剩下的一成是源本身下线了，那就直接从配置里删掉，不用纠结。源是可以替换的，流程的稳定性比某个具体源重要，这个心态要有。

5.2 去重误判：宁可漏判不可误判

去重误判的典型表现是两条明显不同的内容被合并成一条，读者会发现简报里少了东西。排查方法是把当天的去重日志调出来，看被判为重复的条目对，逐对检查指纹差异。

我遇到过的误判原因主要有两个。一是标题太短，前 30 个字符几乎覆盖了整个标题，不同内容标题相似度高的时候容易撞。解决办法是给短标题加一个长度惩罚，标题短于 15 个字符时降低相似度阈值。二是摘要开头雷同，很多源的第一句都是套话，导致摘要指纹部分失效。解决办法是摘要取指纹时跳过前 20 个字符，从正文实质内容开始取。

调整之后误判率降下来了，但漏判率会略微上升。这个取舍我想清楚了：漏判的代价是多一条重复内容，误判的代价是丢一条内容，后者严重得多。所以所有阈值调整都往“宁可漏判”的方向偏。这个原则在去重、打分、筛选各个环节都适用，因为简报的定位是“不漏重要内容”，而不是“绝对精简”。

5.3 打分失衡：某类内容总是霸屏

打分失衡的表现是连续几天简报里某一类内容占比过高，读者反馈“怎么全是这个”。原因通常是某几个关键词权重给高了，或者某个源权重给高了。

排查方法是把当天的打分明细导出来，按来源和关键词分组统计贡献。我遇到过一次，某个泛词被误放进了core组，权重 4，结果所有带这个词的条目分数都虚高。改回domain组权重 1 之后，分布立刻正常了。还有一次是某个补充源权重给到了 1.5，和核心源一样，导致它的大量低质内容挤进简报。降到 1.0 之后问题解决。

这里有个经验：每次调整权重之后，连续观察三天的分布。单看一天看不出问题，三天的分布才能反映趋势。我现在的习惯是每周五调整，下周一复盘，看周末三天的分布是否合理。这个节奏比每天调要稳，也比每月调要灵敏。

5.4 人工复核时间失控：给自己设个硬上限

人工复核是最容易失控的环节。一开始我每天花一个小时改摘要，后来发现投入产出比不对——多花四十分钟改出来的简报，读者感知的提升很有限。现在给自己设了硬上限：二十分钟。时间到了就停，没改完的条目直接保留草稿状态发布。

为了在二十分钟内完成，我把复核拆成固定动作：先扫一遍标题，删掉明显不合适的；再快速过摘要，只改那些读起来别扭的；最后补弹性区块，有就写没有就跳过。每个动作有时间盒，超了就进入下一个。这个流程听起来机械，但实际执行下来，二十分钟足够处理十到十二条条目，质量也在可接受范围内。

提示：复核时不要点进原文细读，除非摘要草稿完全看不懂。点进去就容易陷进去，二十分钟变一小时。相信你的筛选规则，它已经帮你做过一轮判断了。

5.5 简报变成流水账：定期做减法

跑久了最容易出现的问题是简报越来越长、越来越像流水账。原因是筛选规则只加不减，源只增不删，关键词表越来越臃肿。我的对策是每月做一次减法：删掉过去一个月里从没被点开过的源，删掉三个月没命中过的关键词，合并重复的分类。

减法比加法难，因为删东西有心理负担，总觉得“万一以后有用呢”。我的判断标准很粗暴：过去一个月没产生过任何进入简报的条目，就删。一个月足够覆盖大部分源的更新周期，没产出就是没价值。删掉之后如果后悔，加回来也就几分钟的事，成本很低。这个习惯让我的源列表始终保持在十几个，关键词表始终在两百个词以内，流程跑起来轻快。

6. 我在这套流程上的一些个人体会

这套东西跑到现在，最大的感受是：简报的质量上限由筛选规则决定，下限由抓取稳定性决定。抓取不稳，每天光修 bug 就没精力做筛选；筛选不精，抓再多也是噪音。两者之间，我花在筛选上的时间大概是抓取的三倍，这个比例我觉得是合理的。

另一个体会是关于“自动化”的边界。全自动听起来很美，但简报这个场景里，人工复核那二十分钟恰恰是价值所在。它逼着你每天真正读一遍内容，而不是把判断完全外包给规则。规则会漂移，人的判断也会漂移，两者互相校准，简报才不会越跑越偏。我见过一些全自动的简报产品，跑三个月之后内容越来越同质化，就是因为缺少这个校准环节。

最后说一个具体的技巧：给简报加一个“昨日回看”的小节，每天从昨天的简报里挑一条，附一句“后续有没有新进展”。这个动作成本极低，但让简报有了连续性，读者能感觉到这是一个持续跟踪的过程，而不是每天孤立的信息碎片。我加了这个小节之后，读者反馈里提到“有跟踪感”的比例明显上升。这个设计后续还可以扩展成“本周线索追踪”，把跨天的同一主题串起来，那又是另一个层面的价值了。