企业官网建设流程全解析

做信息收集、竞品调研、技术选型这类活儿的人，应该都有同一个体会：传统搜索引擎越来越回答不好"最近发生了什么"这个问题。你输入一个关键词，排在前面的往往是几个月前甚至几年前的旧文，偶尔有几条新消息，又被大量SEO软文和标题党冲得七零八落。Last30Days-skill这个开源项目，核心思路就是把"过去30天"做成一个硬性的时间窗口，围绕这个窗口去做多源信息聚合、信号评分和结构化输出，直接绕开传统搜索引擎在时效性上的短板。它能做的事很明确：你给它一个主题，它返回过去一个月内跟这个主题相关的、经过打分排序的高质量信息条目，每条都带来源链接和评分明细。适合谁用？做技术选型调研的开发者、盯行业动态的产品和运营、写报告要引用的研究员，以及所有被信息碎片折磨的人。

这个项目我在本地跑了一段时间，最大的感受是它不像普通爬虫工具那样只解决"抓取"问题，而是把"什么信息值得看"这个判断逻辑也做成了可配置的工程。下面我从设计思路、架构分层、评分体系到实际操作，完整拆一遍。

1. 项目核心思路：为什么非要把"30天"做成硬窗口

1.1 传统搜索引擎到底"慢"在哪里

很多人以为搜索引擎是实时索引，其实不是。搜索引擎从发现页面、抓取内容、解析入库，到最终参与排序，这中间有明显的时间差。大型搜索引擎对中小站点的抓取频率可能是一周甚至一个月一次，结果就是你搜"某某框架最新进展"，首页还挂着三个月前的版本发布公告。

更麻烦的是排序机制的惯性。一个页面如果积累了多年的外链和权重，即使内容已经过时，它在搜索结果里的排名也不会快速下降。那些写于两年前、靠SEO吃饭的"教程文"会持续霸榜，因为它们的外链多、点击率高、停留时间长，搜索引擎认为它们是"优质内容"。这就形成了一道信息壁垒——不是内容不存在，而是旧内容的权重太高，新内容根本上不来。

1.2 一个时间窗口解决三类典型场景

把时间范围硬性限定在30天，等于在抓取和排序之前先做了一道"时效性闸门"，从机制上绕开旧内容霸榜的问题。我在实际使用中总结出这三类场景，用这个窗口都特别顺手：

• 技术选型与生态观察：想看某个语言、框架、开源项目最近一个月有没有版本更新、社区讨论、新出现的坑和解决方案。30天足够覆盖一个版本迭代周期，又不会把一年前的陈年讨论混进来。
• 行业动态与竞品跟踪：竞争对手的新功能发布、融资合作、媒体报道，这类信息生命周期很短，必须在一个月内捕捉才有价值。
• 热点事件的时间线梳理：一个事件从爆发到发酵、到各方表态、再到出现反转，大多数在30天内能走完一个完整周期。

这三类场景有个共同点：先过滤时间，再谈质量。时效性是第一道闸门，信息质量排在后面。这也是Last30Days-skill把时间窗口放在架构最前端的原因。

2. 架构拆解：分层数据管道的设计与数据流动路径

这个项目的架构不复杂，但分层很清晰，一共五层：采集层、归一化过滤层、信号评分层、输出组装层、存储层。数据按顺序流过这五层，每一层只做一件事，互不越权。

2.1 采集层：多源异步抓取，而不是无脑爬虫

采集层的数据源分三类。第一类是公共RSS/Atom订阅源，这是最初版本的主力，因为RSS结构规整、流量友好、不会被反爬；第二类是开放API，比如GitHub Releases、Hacker News、某些行业数据接口，这类源的优点是结构化程度最高，字段齐全；第三类是种子站点列表，也就是内置维护的一批高质量网站首页和专栏入口，用户在配置文件里可以自由增删。

技术选型上，项目用了Python 3.10+、httpx异步客户端、feedparser做RSS解析、lxml+BeautifulSoup做HTML解析。这里有个值得说的工程决策：采集策略是"订阅+白名单"，而不是"爬全网"。也就是说，它从一批用户认可的高质量源里拉取更新，再配合网站的自定义搜索接口做补充，而不是像搜索引擎那样无差别抓取。这个设计大幅降低了反爬压力和维护成本——你不需要维护上亿的URL队列，只需要维护几千个信源。

异步并发也是必须的。如果串行抓取几百个源，一轮下来可能要十分钟以上，信息的新鲜度就打折扣了。httpx的异步并发能把一轮抓取压到几十秒内完成，同时对每个源做限速，避免给对方服务器造成压力。

2.2 窗口过滤与时间归一化层：所有时间统一到UTC

各个数据源返回的时间格式五花八门，有Unix时间戳、RFC 2822、ISO 8601、甚至"3 hours ago"这种相对时间。归一化层要做的第一件事，就是把所有时间统一转成UTC的ISO 8601字符串，存储时再用epoch秒做索引。

窗口过滤的逻辑是保留published_time在[T-30天, T]区间的条目。注意这里有个隐藏细节：项目默认给边界留了12小时的容差。为什么？因为不同源站的服务器时区设置不一样，一篇正好在第30天零点发布的文章，解析后可能落在第29天23点59分，如果卡死边界就会被误杀。12小时容差能消化这类时区误差。

对于解析不出时间的条目，处理策略也很务实——不丢弃，单独放进unknown列表，用户可以决定是否纳入后续流程。我遇到过一些网站把发布时间藏在JavaScript里，静态抓取拿不到，这种条目直接扔掉可惜，留个口子是对的。

2.3 信号评分层：先粗排再精排

信号评分层做的事情，是对窗口内所有条目做多维打分和排序，把"噪声"压下去，把"值得看"的顶上来。这个评分体系是项目的核心卖点，下一章单独展开。这里只说一个设计原则：评分层不应该试图直接给出最终答案，而是做粗排，把候选集从几百条压缩到几十条，再由输出层做去重和摘要。这种"粗排+精排"的思路，比一上来就精算每条信息要稳健得多。

2.4 输出组装层：去重、摘要、引用溯源

很多人会觉得聚合工具的输出不就是要个列表吗，其实坑很多。首先是去重，同一个事件会有多家媒体转发，标题可能都改过，但正文高度相似，所以项目用组合策略：标题归一化加SimHash内容指纹。标题归一化要处理全角半角、大小写、连续空格和标点差异；SimHash则对正文去掉HTML后的前500字符计算，这个长度在实际测试里对近义改写最敏感。

摘要方面，项目不是调用大模型做生成式摘要，而是采用抽取式：优先取元描述字段，没有的话取正文前几句话，中文控制在200字左右。这样做的原因是快、稳定、不依赖外部AI接口，而且不会出现生成式摘要常见的"脑补"问题。

引用溯源是我特别看重的一块。每条输出结果都保留原始URL、源站名称、入库时间、评分分项明细和命中关键词上下文。做调研报告的人都知道，信息可追溯比信息本身更重要，你拿一条评分0.87的条目给同事看，对方势必要看到原始出处。

输出格式支持三种：JSON Lines给程序处理，Markdown给人阅读，CSV给表格工具。默认是JSON Lines，因为大多数脚本处理起来最方便。

2.5 存储层：增量更新而不重复计算

存储用SQLite就够了，不需要上重型数据库。条目表的关键字段包括source_url、title_hash、content_hash、first_seen_time、published_time，以及五个评分维度的分项得分。增量更新的逻辑是双key判断：入库时间去重加上内容指纹去重，只要有一个命中就认为条目已存在。这个设计保证了评分排序的稳定性——如果每次运行都把同一条抓两遍重新打分，排序结果会抖动，用起来非常难受。

3. 信号评分体系：五个维度与权重调配逻辑

信号评分体系是整个项目里最有琢磨头的地方，也是我花时间最多的一块。它的本质，是把"什么信息值得看"这种主观判断，拆解成可以计算、可以调试的客观信号。

3.1 五个信号维度分别解决什么问题

时效性是第一个要看的信号。它解决的是"看起来在30天窗口内，但其实是旧闻重发"的问题——有些内容农场的惯用伎俩是给旧文改个新日期重新发布。所以Recency不是按抓取时间算，而是按发布时间算，用指数衰减函数做平滑处理，后面细说。

权威性解决的是信源质量问题。内容农场的文章也可能很新、也可能标题带关键词，但可信度为零。项目内置了一套域名分级表，一级来源包括官方机构、学术期刊和大型媒体，二级是行业垂直媒体和资深个人博客，三级是普通个人站点和论坛，四级基本就是内容农场和聚合站了。这个分级表用户可以自己维护——比如你所在行业的几个关键信息来源，完全可以手动提到一级。

相关性解决跑题问题。标题命中关键词的算强相关，正文多次出现的算弱相关，只有语义相关但字面不匹配的算边缘相关。这里有个教训，相关性权重偏低的话，结果里会混进大量打擦边球的内容，比如查"Spring Boot"却给你推一堆Java泛谈文章。

传播度作为一个辅助信号，考察的是公开互动数据。但它在实际使用中是最容易失真的信号——刷量、机器人评论、标题党天然高传播。所以项目在设计上把它归一到0到1区间后还要做截尾处理，超过一定百分位的直接压到上限，权重也给得较低。

内容质量信号是最底层的及格线约束，看正文长度、段落结构、是否有结构化元数据等。短讯、空模板页、纯视频页没有正文内容，直接在这个维度上露馅。

3.2 归一化方法和加权公式

总得分不是简单的五个维度平均，而是加权求和：

Score = Σ(weight_i × signal_i)，signal_i ∈ [0, 1]

默认权重如下：

这个权重分配是经过多轮测试调出来的。如果时效性权重给到0.5以上，你会看到排名靠前的全是碎片短讯和标题党，因为这类内容生产即高峰、发布即传播；如果权威性权重过高，Top结果确实都是大媒体，但很多垂直领域的真实动态恰恰是小众博客和论坛先发出来的，30天窗口的意义就大打折扣了。这套分配本质上是在信噪比和质量之间做了妥协。

各维度的归一化方法也值得说。时效性用指数衰减，半衰期设为7天：也就是说一篇发布时间在7天前的文章，时效性得分降为0.5，14天前降为0.25，呈现"最新内容快速靠前、旧内容缓慢沉底"的分布，这比线性衰减更贴合信息消费习惯。权威性用分级映射表，不搞百分制打分。传播度用截尾式min-max归一化，先对所有条目的互动数排序，超过第95百分位的统一设为1.0，低于第5百分位的设为0，中间线性映射，这样能有效对抗刷量。相关性直接看命中类型，强相关默认0.9，弱相关0.6，边缘相关0.3，没有命中给0。内容质量信号则是一个组合判断，综合正文长度、段落数量、图片数和元数据完整度打分。

3.3 一个完整评分过程的带参示例

我觉得光讲公式不好理解，走一个真实计算过程。假设我在做技术调研，查询"Spring Boot 3.4 发布"，系统抓到一条来自InfoQ的报道：

• 发布时间是7天前，按半衰期7天的指数衰减计算，时效性得分 =0.5^(7/7)= 0.5
• InfoQ在域名分级里属于一级来源，权威性得分 = 0.9
• 标题命中核心关键词，正文中"Spring Boot"出现12次，相关性得分 = 0.92
• 这条报道的转发评论量处于中位水平，截尾归一化后传播度 = 0.55
• 全文1200词，段落完整，带技术标签和作者署名，内容质量 = 0.88

总得分计算：

Score = 0.30×0.50 + 0.25×0.90 + 0.20×0.92 + 0.10×0.55 + 0.15×0.88 = 0.150 + 0.225 + 0.184 + 0.055 + 0.132 = 0.746

0.75分在这个体系里属于"值得看的位置"。为什么不是最高分？因为一条1小时前发布的官方Release公告，时效性得分可能高达0.98，权威性也不低，总分自然压过媒体评测。这符合直觉：官方原始公告永远比二手报道更值得优先看。

我还想强调一点：权重不是运行时自动调的，而是通过场景配置文件预设的。项目内置了三套预设——hot模式（热点事件追踪）把时效性权重提到0.40、传播度提到0.15；research模式（技术调研）把权威性提到0.35、相关性提到0.25；default就是上面那套均衡配置。切换场景就切换配置，逻辑清晰，不会在运行时瞎算。

4. 实战使用：从安装部署到产出信息报告

理论部分讲完，落到实际操作。这个项目跑起来不复杂，但我第一次用的时候还是踩了五六个坑，这里把完整流程和参数说明一起写清楚。

4.1 环境准备与安装部署

前置条件只有Python 3.10+，建议用虚拟环境隔离依赖，别直接装在系统Python里。安装过程三步走：

git clone https://github.com/your-fork/last30days-skill.git cd last30days-skill pip install -r requirements.txt

装完后做初始化，生成默认配置文件：

last30days init

这个命令会在当前目录生成一个config.yaml和data_sources.yaml。data_sources.yaml是内置的信源列表，按类型分组，刚上手的时候先别急着改，用默认的跑一遍，熟悉流程后再替换成跟你行业相关的源。

4.2 配置文件核心参数逐项说明

config.yaml是核心，关键参数如下：

window: days: 30 # 时间窗口长度 grace_seconds: 43200 # 边界容差12小时 scoring: min_score: 0.50 # 最低展示分数 hard_filter_quality: 0.40 # 低于此质量分直接过滤 weights: recency: 0.30 authority: 0.25 relevance: 0.20 quality: 0.15 engagement: 0.10 query: default_region: cn # 区域偏好 max_results: 50 # 单次查询最多返回条数 output: format: jsonl # jsonl / markdown / csv dir: ./output

几个参数我想专门说一下。min_score默认0.50，这是我实际跑过几百次查询后得到的经验值——低于0.5的条目，要么是相关性不足，要么是内容太短，淹没了真正有价值的信息。但也不要调太高，0.7以上会把一些时效性稍低但内容扎实的长文排除掉，反而丢失信息宽度。hard_filter_quality是一个硬过滤门槛，质量得分低于0.4的直接不进候选集，这个机制比单纯调权重管用得多——它是及格线，不参与排序竞争。

4.3 命令行实战：三个典型查询

安装配置好之后，实际查询命令长这样：

# 技术主题调研：查Spring Boot 3.4相关信息，输出Markdown报告 last30days query "Spring Boot 3.4" --days 30 --format markdown # 行业动态跟踪：查新能源汽车销量，只看中文源，最低分0.6 last30days query "新能源汽车 销量" --region cn --min-score 0.6 --format csv # 热点追踪模式：用hot场景权重跑一轮 last30days query "大模型 应用落地" --scene hot --format jsonl

--scene hot这个参数会切换内置场景预设，热点场景下时效性权重提升，适合处理"最近大家在聊什么"这类查询。跑完的Markdown报告会生成在当前output目录下，文件名带时间戳，不会覆盖历史报告。

我建议第一次实战时，拿一个你自己特别熟的主题来跑——比如你的专业领域里最近一个月发生的事。因为你熟，你能立刻判断排序合不合理、有没有漏掉关键信息、有没有莫名其妙的内容混进来。这样比拿陌生主题跑更能暴露问题。

4.4 作为Agent技能集成到大模型工作流

项目名字里的"skill"已经暗示了它的定位——它不仅是命令行工具，更是给智能体准备的一套技能封装。部署好之后可以启动服务模式：

last30days serve --port 8765

然后在Agent代码里以工具函数的方式调用：

import requests def search_last30days(topic: str) -> dict: resp = requests.get( "http://127.0.0.1:8765/query", params={"q": topic, "format": "jsonl"} ) return resp.json()

Agent拿到返回的JSON结构化数据后，可以做三件有价值的事：第一，基于评分结果生成自然语言摘要；第二，对Top条目做交叉对比，挑出不同来源表述不一致的地方；第三，把多天查询结果累积起来，生成趋势日报。这种组合模式下，大模型负责"理解"和"表达"，Last30Days-skill负责"找"和"筛"，各干各擅长的事。

4.5 结果解读：一份真实输出拆解

跑一轮查询，输出大概是这样的（简化示例）：

## 查询主题：Spring Boot 3.4 ## 窗口：2025-11-01 ~ 2025-11-30 ### 1. Spring Boot 3.4.0 正式发布 来源: spring.io（官方） ｜ 发布时间: 2天前 ｜ 综合评分: 0.91 时效性: 0.94 ｜ 权威性: 1.00 ｜ 相关性: 0.95 ｜ 质量: 0.85 ｜ 传播: 0.62 摘要: Spring Boot 3.4.0 带来模块化配置增强、Docker镜像构建优化...（正文前200字） ### 2. Spring Boot 3.4 新特性深度解析 来源: InfoQ ｜ 发布时间: 6天前 ｜ 综合评分: 0.80 时效性: 0.66 ｜ 权威性: 0.90 ｜ 相关性: 0.92 ｜ 质量: 0.88 ｜ 传播: 0.55 摘要: 本文从代码层面解析了Spring Boot 3.4的核心变化，包括启动加速...

注意第一条，来源是官方域名，权威性给满1.0，发布时间又近，综合分直接到0.91，排第一没有争议。第二条是媒体深度评测，时效性因为过了半衰期降下来了，但权威性和质量都很扎实，排第二。这种排序逻辑是符合直觉的：官方公告优先，深度解读其次，凑热闹的碎片内容沉底。你在自己的领域跑一次，用这个标准审视结果，就能判断排序到底靠不靠谱。

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

再好的工具，实际用起来总会遇到各种意外。这块内容是我从自己的调试记录里整理出来的，含金量我觉得比前几章都高。

5.1 数据源抓取失败、大面积超时与"空窗"现象

最常见的坑是某个数据源拖垮整个抓取流程。RSS源挂在普通虚拟主机上，响应慢是常态，如果程序是串行抓取，一个源超时30秒，整个流程肉眼可见地变慢。项目的解决办法是：单请求超时3秒，超时重试2次，连续失败3次自动把源标记为unhealthy并从后续轮次剔除。但如果你用的是早期版本，没这个机制，可以在配置里自己添加弱网源的优先级降级。

还有一个我踩过的隐蔽坑：某个RSS源改版后，服务器返回200但内容字段为空，程序没有对空内容做检查，结果评分层收到一批"空模板条目"，质量分极低、相关性为0，虽然没有污染前排，但在统计报告里制造了大量无效噪音。排查方法很简单，抓完一轮看unhealthy_count和empty_count指标，前者偏高是网络问题，后者偏高说明源的HTML结构变了，需要更新解析规则。

5.2 重复信息与"旧闻新发"的识别

多源转发是聚合工具的日常。同一篇新闻被十个站点转载，去重做得不好，报告里就会出现十条几乎一样的内容。项目的双通道去重策略在大部分场景下有效，但有三个短板：疑似AI生成的洗稿（同义词替换后SimHash偏低）、不同语言版本的同一事件、以及只改标题不改正文的转载。最后一类特别阴，标题归一化根本拦不住，只能靠正文指纹兜底。

"旧闻新发"是另一个麻烦。有些网站很流氓，把去年12月的文章发布日期改成今年12月再发一遍。应对手段有两个：一是抓取时检查URL路径里是否包含旧年份（很多系统的文章URL带年份目录，如/2024/）；二是检查文章正文里是否有跟"当前日期"矛盾的时间表述。第二招不是绝对可靠，但作为辅助信号很管用。

5.3 排序结果出现"不合理高排位"时的调参顺序

当你发现Top3里混入了明显不该排前面的内容，先别急着改权重。我的经验是按顺序排查：

1. 先看分项得分，确认是哪个维度把它顶上来的。是时效性太高？还是权威性分级表把它误归为一级来源？
2. 如果是权威性误判，改分级表，把该域名降级，这是最精准的修正。
3. 如果是因为内容里恰好反复出现查询词导致相关性虚高，说明相关性计算逻辑需要加入"标题命中优先"的加权——标题命中的相关性得分应该显著高于正文命中的。
4. 最后才考虑调权重。权重要一次只动一个维度，动完用同样的查询集跑一遍对比分布变化，不要同时改两三个权重，那样你根本说不清是哪个改动起了作用。

还有个实用技巧：把内容质量信号做成硬过滤，往往是性价比最高的优化方向。很多"不合理高排位"的内容其实质量分很低，但其他维度拉高了综合分，这时候如果设了硬过滤门槛，它们直接出局，比调权重效率高得多。

5.4 限流与抓取合规

最后必须说一个容易被忽略的问题：做信息聚合工具，还涉及抓取合规和数据源伦理。这个项目的设计本身对这个问题很友好——默认优先用公开REST API和RSS，这两类源都是站点主动开放的，不存在协议违规问题。但对于没有RSS的站点，它也存在常规网页抓取。

实操层面我的原则是三条。第一，严格遵守robots.txt，对方明确禁止的路径绝对不碰。第二，请求频率要克制，每个源至少保持10秒间隔，不要开50个并发去抓同一个站点，那等于DoS攻击。第三，抓到的内容只做聚合展示和摘要引用，不做整站镜像、不批量导出后二次转售。做工具的人更应该爱惜数据源，把信源维护好，这个工具才能长期运转下去。

我自己跑下来的体会是：这种"时间窗口+信号评分"的思路，比单纯做关键词搜索或者单纯堆数据源要高级得多。传统搜索引擎解决的是"历史上有没有人聊过这件事"，Last30Days-skill解决的是"最近有什么值得关注的新动静"，两者压根不在同一个维度上。项目还有不少可以扩展的方向，比如把窗口从30天做成7/30/90天的多级策略，或者接入学术预印本、GitHub Release、行业白皮书这类垂直数据源。你如果也有信息调研方面的需求，不妨拿它跑一轮真实查询，跟你自己手动搜的结果对比一下，感受会非常直观。