企业官网建设流程全解析

做 AI 日报这个项目到今天，我已经稳定跑了小半年，2026年10月5日这期是第一百多期。当初启动的原因很简单：每天打开电脑，信息流里全是 AI 相关的内容——大模型发布、开源项目上新、学术论文、行业观点、产品更新，光是把这些看完就得两个小时，更别说还要消化和理解。所以我就想，能不能搭一条自动化流水线，把散落在各处的权威信息抓下来，用大模型做初筛和摘要，再由自己快速审校，最终产出每天一份十来条的 AI 日报。今天这篇不聊新闻本身，就聊聊这套日报系统是怎么设计和落地的，踩了哪些坑，以及什么样的架构和流程才能真正长期跑下去。如果你也想搭一套属于自己的 AI 信息日报，或者对信息采集、LLM 辅助写作、自动化内容生产感兴趣，这篇应该对你有用。

1. 内容定位与整体思路拆解

1.1 日报不是新闻流水账，而是筛选与解读

一开始我踩过一个大坑：把日报做成了“今天的 AI 新闻聚合”。数据是全的，但这也就意味着没有重点。后来我把内容重新定位成了三个方向：模型与产品的发布更新、开源项目与工程实践、行业观点与应用案例。一条信息如果落不进这三个方向，哪怕热度再高，也不会进日报正文。

为什么这样设计？核心原因在于用户场景不同。有人读日报是为了追踪前沿，比如哪家又发了新模型、哪个项目又刷榜了；有人是为了找可落地的工具，比如某个好用的 AI 编程插件、某个测试开发框架；还有人是为了理解趋势，比如企业里的技术管理者需要知道 AI Agent 搭建方式发生了什么变化。如果一股脑全塞给所有人，等于谁都服务不好。所以我给日报定了硬性指标：每天 10 到 15 条，每条必须至少满足“新信息、高价值、可执行”中的两个条件。

就拿 2026 年 10 月 5 日这期来说，日报里既有大模型相关的行业动态，也有 AI 编程工具链的更新（比如 PyCharm 上新的 AI 插件、付费编程工具 Codex 的进展），还有智能体工程实践的深度内容。这些都是典型的“读者点开以后愿意读下去”的选题。相比之下，那些纯营销性质的通稿、只会重复已有信息的内容，一律不进正文。

1.2 全自动还是半自动？我选择在自动化里保留一道人工

这个项目从一开始就面临一个选择：能不能做到全程无人值守？技术上完全可以——定时触发脚本、让大模型挑选和总结、再自动发布。但我试跑了两周之后，果断放弃了全自动，改成“自动收集、大模型初筛、人工复核”的半自动模式。原因很简单：LLM 生成的摘要偶尔会出错，尤其是在转述链接内容时，有概率出现事实偏移。日报和聊天机器人不一样，聊天错了可以撤回重说，日报一旦发布，错误会跟随一整天。而且日报的核心价值是审美和判断力，机器能帮我们把 100 条压缩到 20 条，但最终留下哪 12 条，需要懂技术的人来做最后决策。

现在的流程控制在五十分钟以内：采集和初筛全自动，大模型生成摘要，之后我花二十分钟做审校，改掉不准确的表述，确认链接可用，再发布。这看似是退了一步，实际上是把自动化用在最耗时的环节，而把判断力留给真正需要人的地方。

2. 信息源选型与采集架构

2.1 信息源不是越多越好，而是分层分级

信息源选型是这套系统最基础的部分。我的原则是：优先权威一手源，其次才看媒体解读。下表是我目前实际在用的信息源分类和权重配置：

没必要贪多。我一开始挂了六十多个源，结果每天抓到大量噪音，比如某个小模型的宣传稿、某篇文章里顺手提了一句“AI”。后来逐步精简到三十个左右，反而筛选效率提高了不少。每个源还有自己的权重，权重会直接影响排序，这一点在后面筛选的逻辑里会详细讲。

2.2 采集实现：RSS 为主、API 为辅、爬虫兜底

采集层面我采用的是“RSS 为主、API 为辅、爬虫兜底”的组合方案。为什么 RSS 是主力？因为它结构标准、更新稳定、对目标站点压力极小。很多中文站点没有原生 RSS，就用 RSSHub 这样的服务把网页转成 RSS，实测下来基本够用。对于没有 RSS 也没有现成转制的站点，再写轻量爬虫去抓页面关键字段。

存储用的是 SQLite 单文件数据库。有朋友问我为什么不上 PostgreSQL 或 ES，我的答案是：日报的数据量一天最多一两千条原始记录，单文件足够，而且备份就是复制文件，省掉所有运维成本。表结构非常简单，核心字段包括标题（title）、来源（source）、链接（url）、正文摘要（content）、发布时间（published_at）、抓取时间（fetched_at）、分类（category）、质量分（quality_score）以及去重哈希（dedup_hash）。去重哈希很关键，我会把标题做归一化——去掉空格、标点、统一大小写——再取 SHA256 值，几天内的重复内容用这个字段就能直接挡掉。

整个采集任务挂在 GitHub Actions 的 cron 上，核心源每半小时跑一次，长尾源每天固定跑两次。为什么选 GitHub Actions 而不是自己买服务器？因为我不想为了一个个人项目去维护一台常驻机器，而且 GitHub Actions 的免费额度对日报项目来说完全够用。如果你想自己搭，用一台轻量服务器的 crontab 也是一样的效果。

3. 大模型如何参与筛选、排序与摘要生成

3.1 “值得进日报”的判定标准：新、重要、可落地

有了原始信息之后，下一个问题是：哪些值得进日报？我把这拆成三个打分维度。第一是“新”：这条信息是不是最近 24 小时内发布的，或者是不是对旧闻的突破性进展；第二是“重要”：它影响的人群范围有多大，是影响全体开发者还是一个细分小圈子；第三是“可落地”：读者看完能否直接转化行动，比如安装一个工具、了解一个方案、调整一个技术选型。

每个维度打 1 到 5 分，再乘以信息源的权重。举例来说，一篇关于 AI 大模型基础理论的科普文章，在“新”上可能只有 2 分，但如果它写得足够通俗且适合入门读者，在“重要”和“可落地”上可以各给 3 分。这种内容我不会放进当天日报，而是归入每周精选。相反，某官方博客发布了新模型的技术报告，三个维度分数都会很高，直接进当日头条。

3.2 多模型协作：不要让一个模型干完所有活

很多人以为用 LLM 生成日报就是把几十条信息一股脑丢给一个模型，让它“总结一下”。我尝试过，效果非常不稳定——信息一多，模型容易遗忘前文，输出格式也会走样。后来我的方案是“多 AI 协作”，不同环节用不同模型。具体分工是：第一个模型负责把原始标题和摘要快速分类（模型体积小、速度快、成本低）；第二个模型负责对初筛后的内容生成摘要和推荐理由；最后再用一个能力更强的模型做质量审核，检查摘要中是否有事实性错误、是否偏离原文。

这样做的好处是把“管道任务”和“判断任务”分开。分类是低难度重复劳动，没必要用大模型；摘要生成对语言组织能力要求高；质量审核则需要对语义有更深的理解。多模型协作看上去复杂了一点，但对结果稳定性和成本控制都有效。我实际跑下来，相比单模型一次搞定，成本大约省了 40%，而出错率下降了不止一半。

3.3 摘要与解读的书写规范：说人话，别端着

大模型生成摘要很容易写出“本文介绍了 X 技术的原理与应用场景”这种正确但无用的句子。所以在提示词里我做了非常强硬的约束：不许出现“本文介绍了”“综上所述”“随着人工智能的发展”这类句式；必须用口语化短句；必须说清楚“为什么同类读者值得关注这条”。同一个提示词模板反复迭代了十几次，现在输出的质量已经相当接近人工写的摘要了。

下面是我当前在用的摘要生成提示词模板，截取了核心部分，你可以直接拿去改：

你是一名资深 AI 领域编辑。根据以下原始信息，生成一条日报条目。 要求： 1. 标题：不超过 22 个字，提炼最关键的信息点。 2. 摘要：不超过 90 个字，说清楚“发生了什么事”和“为什么值得关注”。 3. 落地建议：一句话，告诉读者可以采取什么行动。 4. 禁止使用“本文介绍了”“总而言之”“随着人工智能的发展”等模板句。 5. 用口语化表达，像经验丰富的同行在聊天。 原始信息： <标题>${title}</标题> <正文>${content}</正文>

需要说明的是，这一段是基于我自己的实践总结出来的提示词结构。如果你想用于自己的项目，必须根据使用的模型做微调——不同模型对“要求”的遵从度差异很大，有的模型要用“你是一个……你必须……否则……”这类强约束，有的模型只需要温和叮嘱。这些都是需要反复试验才能找到平衡的点。

4. 自动化流水线的实操细节

4.1 一天的运行时间线：从采集到发布

我把整套流程固定成了每天固定的时间线，以 2026 年 10 月 5 日这期为例：

• 05:30 采集脚本触发，抓取三十个信息源的最新内容，写入 SQLite。
• 05:45 初筛脚本执行：去重、过滤旧闻、按规则筛掉明显低质内容。
• 06:00 第一轮 LLM 批处理：生成分类标签与粗摘要。
• 06:15 第二轮 LLM 处理：对初筛结果打分排序，取出前 20 条。
• 06:30 第三轮 LLM 生成正式日报条目，输出 Markdown 草稿。
• 06:45 个人审校，修改表述，核对链接。
• 07:00 发布到对应渠道。

这套时间线最核心的设计是“留出缓冲”。如果某一轮运行失败，后续还有重试空间，不会影响当天发布。编排上我用的是 GitHub Actions 的 workflow，每一步是一个独立的脚本，任何一个步骤失败了，都不会影响已经跑完的步骤。

name: daily-ai-report on: schedule: - cron: "30 21 * * *" jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: "3.12" - run: pip install -r requirements.txt - run: python scripts/fetch.py - run: python scripts/dedup_filter.py - run: python scripts/llm_summarize.py - run: python scripts/llm_rank.py - run: python scripts/llm_writedaily.py

注意这里的 cron 用了 UTC 时区，30 21对应北京时间凌晨 5 点 30 分。这一步看似不起眼，但确实有很多人直接复制网上的配置导致时间差了好几个小时。我的 YAML 里选用 UTC 是为了和 GitHub Actions 的默认环境保持一致，省去环境变量配置，你们在自己部署时如果用TZ=Asia/Shanghai的方式也是可以的，只要全程统一，不要在同一个项目里混用两套时区逻辑就行。

4.2 提示词工程：把日报草稿当成“产品”来约束

日报草稿生成是整个流水线里最需要打磨的环节。最开始我只是简单地对前二十条信息说“请生成 12 条日报”，结果模型经常自作主张地调整顺序、合并条目、甚至加入它认为“热门”但没有出现在输入里的内容。这个问题的解法是给出极清晰的输出模板，包括一级标题、二级标题、每条条目的字段顺序。模型只要遵从模板，结果就差不到哪里去。

这里也给一下我常用的输出结构模板：

## ${date} AI 日报 ### 今日头条 - 标题：xxx - 摘要：xxx - 为什么值得关注：xxx ### 模型与产品 - 标题：xxx - 摘要：xxx ### 开源与工程实践 - 标题：xxx - 摘要：xxx ### 行业观点与应用 - 标题：xxx - 摘要：xxx

这个结构的好处是：固定框架之下，模型不用考虑整体排版，只需要在每一段里填充内容，生成速度更快，格式也更稳定。而且固定结构对我的审校环节也友好，我在修改时只需要看“今天头条选得准不准”“开源与工程实践里有没有值得替换的”，不需要从头梳理。

4.3 成本估算：一次日报到底要花多少钱

成本是很多想复刻的人最关心的问题。我来拆一下实际账单。每天原始采集约 1000 条，去重和规则过滤后剩 200 条左右进入 LLM 初筛环节。分类与粗摘要用轻量模型，200 条约消耗 3 到 4 万 tokens。打分排序和正式日报生成用更强模型，输入是筛选后的 40 条，输出是完整日报，消耗 2 万 tokens 左右。三顿操作加在一起，一天大约消耗 6 万 tokens，按几个常见商用 API 的价格折算，成本控制在 1 到 2 元人民币之间。再加上 GitHub Actions 免费额度，整月成本不到 60 元。

如果不追求最强模型的生成质量，还可以用本地部署的开源模型做初筛，成本能压到零边缘。我在日报的高频环节上选择商用 API 的原因纯粹是时间成本——自己部署和调优一个本地模型的时间，远比每天多花一块钱要贵。

5. 质量保障、人工审校与效果反思

5.1 机器生成日报的四个高频翻车点

自动化跑久了，你会摸清 LLM 在内容生产上的“脾气”。第一个翻车点是幻觉链接。模型偶尔会生成一个看起来非常合理、但实际上并不存在的链接。这已经不是摘要准确性的问题，而是事实层面的错误。我的应对方式是：链接一律从采集阶段的数据里带过来，绝不允许模型凭空生成 URL。在提示词里明确写“禁止生成任何原文中不存在的链接”，自那以后这个问题基本绝迹。

第二个翻车点是过时信息。某个技术工具的旧教程在沉寂许久后被人翻出来，转帖热度突然高了，模型可能把它当成新内容推荐。这个问题靠“发布时间”字段过滤，凡是发布时间超过 7 天、并且不是重大进展解读的内容，直接不进当日候选池。

第三个翻车点是观点失衡。对于有争议的技术话题，模型生成摘要时可能偏向其中一种表达。所以我在审校时会特别留意否定词和情绪词，发现问题就改成中性表达。

第四个翻车点是同质化。某天如果同时出现了三家媒体关于同一件事的报道，模型可能选出两三条相似度极高的条目。我后来给去重逻辑加了“语义相似度检查”，超过相似度阈值的只保留权威源那条，其他直接淘汰。

5.2 人工审校清单：每天 20 分钟，改什么、查什么

我一直坚持日报最后的发布需要人工确认。这不是对自动化不信任，而是对读者负责。审校时我主要按这张清单过一遍：

整个过程我控制在 20 分钟以内。为什么可以这么快？因为大模型已经帮我把“快速筛选”这件事情做了，人工只是最后的抽查和兜底。我见过一些团队做 AI 日报，完全依赖人工从零开始看完全部链接，那本质上就是个搬运工项目，谈不上自动化；也有团队把流程全都交给机器，然后被幻觉内容打脸。我的看法是，人工环节不应该被省掉，但应该被优化到“只做最后确认”的程度。

5.3 用数据反馈反哺内容：日报是能“越跑越懂你”的

最后想聊聊反馈闭环。初期日报的内容选择完全依赖我的主观审美，后来我加了一个简单的统计：记录每条日报的点击量、收藏量和“标为不感兴趣”的数据，按周汇总，再根据这些数据调整信息源的权重。比如某个技术社区的资讯连续三周贡献了高点击，它的权重就上调；某个来源经常被用户标记为不感兴趣，就降权甚至移出。

这个循环跑起来之后，日报的选题口味会越来越稳定。这其实也是 AI 工程里常说的“数据飞轮”——内容系统本身不出彩没关系，只要用户行为数据能回流到筛选策略里，系统就会逐渐自我优化。从技术角度看，这个过程我不会让它自动执行，因为单周点击数据波动很大，人工确认后再调整权重，比模型直接改权重更稳。说白了，AI 日报的竞争力从来不在自动化程度，而在于判断力；机器是帮你做初筛和提效的，判断力还是得靠人。

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

6.1 典型问题一：某个信息源突然抓不到了

做日报小半年，最常遇到的故障是 RSS 源失效。某个源站点改版、关停或者出于其他原因关闭了 RSS 输出，采集脚本就会持续报错。如果我的脚本里没有健康检查机制，这个问题可能要过好几天才能被注意到。后来我加了一套简单的健康检查：每个信息源连续三次抓取失败后，脚本会打印出明显的警告日志，同时把这条源标记为“异常”，不再让它参与后续的抓取流程。

排查时先用最直接的方法确认 RSS 地址是否还活着：

curl -I https://example.com/rss.xml

看返回的状态码，如果 200 说明源正常，是解析环节出了问题；如果 404 或者 301，说明源已经迁移或下线，需要去站点上找新的 RSS 地址，或者改用 RSSHub 重新生成。这个命令很简单，但能帮你快速定位是网络问题、还是源本身的问题。

6.2 典型问题二：某天跑出来的日报全是旧闻

这个问题大概率出在“发布时间”字段上。很多站点 RSS 里的发布时间并不准确，有些是页面生成时间，有些是文章创建时间，如果脚本里没有对这个字段做规范解析，就会出现入库时间混乱，导致筛选时把旧文章当成新内容。我的处理方式是：解析 RSS 时同时读取多种时间格式，并且在入库前统一转成时间戳；另外在筛选逻辑里加一个“发布时间必须在最近 72 小时内”的硬性条件，超过直接丢弃，从根上杜绝旧闻混入。

排查时可以直接查数据库里的记录：

sqlite3 daily_ai.db "select title, published_at, fetched_at from articles order by fetched_at desc limit 10;"

如果 published_at 和 fetched_at 差距过大，说明时间解析有问题，要去检查 feed 解析逻辑。

6.3 典型问题三：模型生成摘要时出现事实偏移

这是最严重的一类问题，因为日报一旦发出，错误就会被读者看到。我的防范措施是双重校验。第一重，在提示词里强约束：“如果原文内容不足以支撑摘要中的任何一个论断，请在摘要中删去该论断”。第二重，在生成摘要后加一个事实一致性校验步骤，用一个能力更强的模型去检查摘要和原文之间是否存在矛盾。这个步骤会多花一点时间和 tokens，但是对于面向公众的内容产品来说，值得。

如果在校验环节发现摘要与原文不符，就退回直接引用原文中的表述，不做提炼。宁可用词朴素一点，也不能用一句看起来漂亮但失真的话。

我自己从这些故障里学到的经验是：这套系统的可靠性不是来自某一个聪明设计，而是来自一层层不起眼的保护。健康检查、去重哈希、事实校验、人工复核，每一层单独看都很简单，但叠在一起之后，日报的稳定性就基本有了保证。哪怕某一天模型输出抽风了，后面的环节也能把它拦下来，而不是直接推到读者面前。这也是我认为所有 AI 内容类项目都应该认真对待的思路：自动化解决效率，层层保障解决信任。