用 Codex 做一个自动发到微信的设计与 AI 日报

如果你每天都想知道设计、AI 和设计工程领域发生了什么，又不想花一个小时刷几十个网站，可以自己做一份每日信息日报。它每天定时收集内容，按照日期和主题筛选，再整理成一条适合手机阅读的消息发到微信。

下面会从头讲清楚怎么搭：先定义日报长什么样，再接入信息源，接着写一个不依赖 AI 的采集脚本，最后让 AI 处理没有 RSS 的国内网页，并把结果送到微信。日期、去重、重复发送和电脑睡眠这些细节，也会放在对应的步骤里说明。文章最后还有一份完整提示词，复制给 Codex 就能开始生成自己的版本。

先决定每天想收到什么

日报目标很简单：每天早上 9 点，收到一份只包含前一天高价值内容的中文简报，主题集中在 UI/UX、设计工程和 AI。它不需要覆盖全网，只要能稳定解决“今天有什么值得看”的问题就够了。

一条合格的日报应该满足四件事：

1. 内容确实发生在前一自然日，时间范围是完整的北京时间自然日；

2. 每条都有可以打开的原文，最好是一手来源；

3. 不只是转发标题，还要告诉读者“为什么重要”；

4. 发送失败、重复发送和来源失效，都能查到原因。

最终格式也不复杂：开头放最重要的 3 条，后面按 UI/UX、AI、设计 × AI 分区。每条内容都带标题、简短摘要、重要性判断、来源、北京时间和原文链接。把这个结果写下来，后面每一个技术选择都有判断标准，也不会一开始就接几十个来源、研究复杂推荐算法，最后却不知道什么叫做完。

画布先铺开，代码会好写很多

不要一上来就写代码。可以先用 Canvasight 把问题摊开，看清楚信息源、时间窗口、去重、评分、AI 编辑、微信发送、失败回退和验证指标分别要解决什么问题。

最后画成五个模块：

信息源
  ↓
采集与时间过滤
  ↓
去重、评分、编排
  ↓
AI 核验与编辑
  ↓
发送、回执、失败恢复

画布适合用来整理问题，代码适合把已经确定的规则每天执行起来。模块和边界画清楚以后，出了问题就能判断该查采集、筛选、编辑还是发送，所有事情也不会挤在一个大脚本里。

先看信息源有没有现成的入口

来源可以先分成三类，后面的处理方式会完全不同。

RSS 和 Atom：最省事的那一类

RSS 和 Atom 是最适合程序自动采集的来源。程序读取标题、摘要、作者、发布时间和链接，就能完成大部分工作。国外很多博客、产品发布页和技术媒体都有 RSS，所以纯脚本方案在这部分很有效。

国内官网：通常要另想办法

很多国内公司、设计团队和模型官网没有稳定 RSS，页面通常也只是一个新闻列表。与其为每个站点维护一套脆弱的爬虫，不如把它们放进 `reference` 清单，让 AI 编辑阶段定向检查。

X：能接，但要付钱

需要付费 API 的平台，最典型的是 X。稳定读取几个关注账号的内容，需要创建开发者应用、管理密钥，并按使用量付费。X API 目前按 endpoint 和读取量计费，具体价格要看[官方定价说明](https://docs.x.com/x-api/getting-started/pricing)。如果只是做个人日报，先用几十个官方 RSS 已经够用；等这份日报真的形成习惯，再考虑为 X 增加账单、限流和权限管理。

第一版只做 RSS，先把骨架跑通

第一版先不要急着接 AI。让一个 Python 程序完成下面这条最基础的链路：

读取 RSS / Atom
  ↓
按北京时间过滤前一天
  ↓
URL 规范化和标题去重
  ↓
评分、分类、限制条数
  ↓
生成 Markdown

这样做能把问题拆开：日期、去重和条数限制都由程序负责，之后加入 AI 时，也能看清楚它到底补上了哪一块能力。

日期这里最容易出错

任务在北京时间 2026-08-09 09:00 运行，日报目标日是北京时间 2026-08-08 的完整自然日：

[2026-08-08 00:00, 2026-08-09 00:00)

内部可以转换成 UTC 比较，但语义必须一直是北京时间自然日。不要用“当前时间减 24 小时”，也不要直接使用机器本地时区。

如果 feed 没有发布时间，只在官方 URL 自己包含 `/YYYY/MM/DD/` 日期路径时恢复日期；否则宁愿丢弃，也不猜。

同一条消息不要收两遍

程序可以做三层处理：

• 清理 `utm_source`、`ref` 等追踪参数，得到 canonical URL；

• canonical URL 相同的内容合并；

• URL 不同但标题完全一致、发布时间相差 72 小时以内的内容，视为同一事件。

评分使用可解释的五个维度：实际影响 30%、新颖性 20%、来源可信度 20%、主题相关性 20%、证据完整度 10%。

最后再做编排限制：最多 15 条，单一作者最多 2 条，Figma 内容最多占最终条数的 25%，内容不足时少发，不拿低价值内容凑数。

国内网站没有 RSS，AI 才有了用武之地

纯脚本方案在国外网站上运行得不错，接入国内来源后，问题很快就出来了：很多官网没有 RSS，页面结构也不统一。这里采用一个折中的办法，给 AI 一份明确的官方来源清单，让它只检查这些页面，并把检查结果交回程序验证。

1. 程序先用 RSS 生成确定性候选；

2. AI 读取候选和 `reference` 来源清单；

3. AI 逐个打开官方页面，核验目标日期有没有更新；

4. AI 只根据原文写摘要、中文标题和“为什么重要”；

5. AI 保存来源审计文件；

6. 程序最后检查格式、日期、链接和来源审计，检查失败就不发送。

AI 在这里负责网页核验和编辑。它可以用搜索结果定位页面，但最终写入日报的事实必须回到官方原文；它也不能自行扩大来源范围，更不能把搜索摘要直接当成事实。

为什么选 Luna 5.6 的中等思考

模型配置上，推荐使用 **Luna 5.6 的中等思考模式**。每日任务要处理的是读取候选、检查页面、整理摘要和生成日报，重点是速度和成本都能接受，Luna 5.6 中等思考已经够用。遇到复杂故障、来源冲突或代码重构，再临时切换到更强的配置，日常运行保持中等思考就好。

事实和判断也要分开：

Webflow 发布了一个 AI 应用构建案例，文章介绍了服务端代理和评估流程。

**为什么重要**：生成式功能进入真实产品后，安全边界和可观测性会影响它能不能上线。

第一段应该能被原文证明，第二段是编辑判断，不能把判断伪装成原文结论。

消息最后怎么进微信

发送链路可以设计成：

BotTalk ClawBot
      ↓ 失败
Server酱 Turbo
      ↓ 再失败
记录错误，等待补跑

发送层至少要处理四件事：

• 请求超时和重试；

• 主通道失败后的备用通道；

• 用“日期 + 内容哈希”防止同一日报重复发送；

• 只有拿到本次真实发送回执和消息 ID，才写入成功记录。

还有一个实际限制：ClawBot 如果连续收到多期消息却没有互动，通道可能暂停。使用时偶尔回复一次，并保留 Server酱作为兜底，稳定性会好很多。

让电脑每天早上还醒着

代码写完只是开始，运行任务的电脑也要配置好。否则脚本逻辑没有问题，机器一睡眠，早上的日报还是不会出现。

Codex 项目别先删了

这里有一个容易忽略的坑：Codex 的项目级定时任务和项目上下文绑定在一起。项目移除后再添加，旧任务可能仍然指向旧绑定，执行时会报错。项目目录、虚拟环境、环境变量、运行数据和定时任务最好一起维护；需要移动项目时，先处理任务迁移或重新绑定。

合盖之前，先把电脑配好

电脑需要做两层设置：Codex 允许锁屏后继续执行，macOS 则要在接电时保持系统运行，显示器可以关闭，但机器不能跟着睡眠。

Mac 可以先查看当前配置：

pmset -g custom

临时测试时，可以用：

caffeinate -dimsu

如果需要让接电时不自动睡眠，可以设置：

sudo pmset -c sleep 0

这会改变接电时的睡眠策略，不要在电池模式下使用；测试结束后，在系统设置里恢复原来的电源习惯。

合盖也有条件。MacBook 通常需要接电，并连接外接显示器、键盘和鼠标，进入 closed-display / clamshell 模式。单纯保持网络连接，不能保证合盖后机器继续运行。

Windows 可以把接通电源时的“合上盖子”设置成“不采取任何操作”：

powercfg /setacvalueindex SCHEME_CURRENT SUB_BUTTONS LIDACTION 0
powercfg /S SCHEME_CURRENT

设置完成后先做一次真实测试：锁屏，手动运行任务，合盖，然后检查日志和消息是否送达。

先跑一段时间，再交给它自动发

验证可以分成三轮：

1. **离线验证 7 天**：只用 fixture 和 RSS，检查日期、去重、筛选和输出格式；

2. **测试通道 3 天**：真实发送，但先发给测试微信；

3. **自动运行 7 天**：观察送达时间、链接有效率、重复率、来源失败率和人工漏报。

每次运行都保存原始候选、筛选结果、日报 Markdown、运行状态、来源审计和发送回执。这样出了问题，可以回答三个关键问题：

• 今天为什么没有这条内容？

• 为什么两条相似内容只留下了一条？

• 这次到底有没有真正发送成功？

信息源可以从这些开始

先接少量官方、一手、更新稳定的来源，再根据一周的候选质量扩展。下面是可以优先考虑的清单。

AI 和模型

产品设计和设计系统

UX 研究和方法

设计工程和 AI 产品

国内官网，先放进 reference

这些来源更适合作为 `reference`，交给 AI 编辑阶段定向查看。确定性采集器只处理有稳定 feed 的来源：

RSS 地址会变，网页会改版，所以“能打开”不等于“适合长期接入”。新增来源时，至少检查 HTTP 状态码、Content-Type、XML 是否可解析、发布时间是否存在，并连续观察一周候选质量。

如果你想今天就跑起来

如果你不想从头读完整个工程，可以直接让 Codex 按下面的提示词在一个新项目里搭建 MVP。它会先实现 RSS 版本，再预留国内官方网页的 AI 编辑层；X 不默认接入，因为那部分需要付费 API。

使用方法：

1. 在 Codex 中新建一个项目，并保持项目不要移除；

2. 把下面整段提示词复制进去；

3. 按提示补充发送渠道和来源；

4. 先 dry-run 7 天，再接微信发送；

5. 如果使用 Codex 项目级定时任务，把项目路径、虚拟环境和 `.env` 保持不变。

把下面这段提示词交给 Codex：

你现在是一个负责落地的工程师，请在当前 Codex 项目目录中，从零创建一个“个人每日设计与 AI 信息日报”项目。

目标：
每天北京时间 09:00，整理前一自然日值得关注的 UI/UX、设计工程和 AI 动态，生成简体中文 Markdown，并通过用户配置的微信渠道发送。项目必须能 dry-run、能补跑、能审计、能防止重复发送。

模型配置：
优先使用 Luna 5.6 的中等思考模式。它适合每日重复执行，速度快、成本相对经济；只有遇到复杂故障、来源冲突或代码重构时，才临时提高思考配置。

一、技术边界

1. 使用 Python 3.9+，运行时尽量只使用标准库，不依赖必须付费的第三方服务。
2. 默认支持 fixture、RSS、Atom 三类自动来源。
3. 预留 reference 来源类型：确定性采集器跳过这些来源，由 Codex 的 AI 编辑任务打开官方网页核验。
4. 不接入 X API。请在 README 中明确说明：读取 X 账号内容需要开发者 API 和按使用量付费，不能把它当作免费 RSS。
5. 不使用搜索摘要、搬运站、镜像或非官方代理作为最终事实来源。
6. 不把 API 密钥、个人路径和本机用户名写入代码或文档；所有秘密放在 `.env` 或环境变量中。

二、请创建的文件

src/digest_app/
  __init__.py
  __main__.py
  cli.py
  domain.py
  sources.py
  time_window.py
  pipeline.py
  composition.py
  delivery.py
  storage.py
  application.py
config/sources.example.json
config/sources.json
config/crontab.example
prompts/daily-editor.md
examples/fixtures/sample.json
tests/
README.md
.env.example
pyproject.toml

三、确定性采集和筛选

1. `--date` 表示运行日期；日报日期是该日期在 Asia/Shanghai 的前一自然日。
2. 使用半开区间 [00:00, 24:00)，内部可以转 UTC 比较。
3. RSS/Atom 条目至少解析 title、link、published、updated、author、summary。
4. 优先使用发布时间；没有时间时，只有当官方 URL 含有 /YYYY/MM/DD/ 日期路径才允许恢复日期，否则丢弃。
5. 清理 utm_source、utm_medium、utm_campaign、fbclid、gclid、ref 等追踪参数。
6. canonical URL 相同的候选去重。
7. 标题完全一致且发布时间相差 72 小时以内的候选视为同一事件，优先保留更权威、证据更完整的来源。
8. 每个来源独立失败，不得因为一个 feed 失败而终止整次运行；失败要写入 run.json。
9. 评分维度为：实际影响 30%、新颖性 20%、来源可信度 20%、主题相关性 20%、证据完整度 10%。
10. 最多保留 15 条；单一作者最多 2 条；Figma 相关内容不超过最终条数的 25%；内容不足时少发，不要补低价值内容。

四、AI 编辑和来源审计

创建 `prompts/daily-editor.md`，要求 AI 编辑：

1. 先读取 dry-run 生成的 run.json、raw.json、candidates.json、digest.json。
2. 再读取 config/sources.example.json 中所有 enabled=false 且 kind=reference 的官方页面。
3. 逐个检查目标北京时间自然日是否有更新。
4. 搜索结果只能用于定位；最终事实必须来自公开可访问的官方原文、文档、论文或仓库。
5. 对每条候选写：中文标题、1–2 句事实摘要、具体的“为什么重要”、来源、作者、北京时间和 HTTPS 原文链接。
6. 明确区分原文事实和编辑判断，不编造原文没有的数字、功能或结论。
7. 把每个来源的 ok、no_update 或 failed 写入 `var/ai-digests/<date>.sources.json`，失败不能静默跳过。
8. 把最终 Markdown 写入 `var/ai-digests/<date>.md`。
9. 非空日报必须以 `# 设计日报 · <date>` 开头，每条都必须有 `**为什么重要**` 和 `[原文](https://...)`。

五、发送和幂等

实现以下发送适配器：

1. BotTalk ClawBot 主通道，读取 BOTTALK_SENDKEY。
2. Server酱 Turbo 备用通道，读取 SERVERCHAN_SENDKEY。
3. 可选 DIGEST_WEBHOOK_URL 作为后备 webhook。
4. 请求超时 30 秒，失败最多重试 3 次。
5. 主通道失败后才调用备用通道。
6. 使用 `digest:<date>:<content_hash>` 作为幂等键。
7. 发送前使用原子 claim 防止并发重复发送。
8. 只有远端返回成功且拿到本次 message_id，才写入 sent.json。
9. `publish` 命令必须在发送前校验标题日期、HTTPS 原文、source audit 和入选来源链接。

六、CLI

至少实现：

validate-config --config <path>
run --config <path> --date YYYY-MM-DD --output var --dry-run
run --config <path> --date YYYY-MM-DD --output var --send
publish --input <markdown> --source-audit <json> --date YYYY-MM-DD --output var
feedback --run-id <id> --item-id <id> --value useful|irrelevant|seen
test-clawbot
test-push

七、测试和文档

测试必须覆盖：

1. 北京时间前一自然日转换为 UTC 的边界；
2. 追踪参数清理和 URL 去重；
3. 72 小时标题事件去重；
4. 来源失败隔离；
5. 单作者、Figma 占比和最多 15 条的编排约束；
6. BotTalk 失败后回退 Server酱；
7. 相同内容不重复发送；
8. publish 拒绝缺日期、缺 HTTPS 原文或缺 source audit 的内容。

README 必须说明：

1. 安装、dry-run、测试和发送命令；
2. 如何配置 RSS、Atom 和 reference 来源；
3. X API 需要付费，项目默认不接；
4. Codex 项目级定时任务与项目绑定，项目不要移除后再添加；
5. Mac/Windows 需要接电，并正确配置锁屏、睡眠和合盖行为；
6. 先 dry-run 7 天，再测试通道 3 天，最后自动发送；
7. 所有失败必须留在日志和运行目录中，不能假装成功。

完成后先运行全部测试，再用 fixture 执行一次 dry-run，把输出、测试结果和下一步需要用户提供的密钥列出来。不要发送真实消息，除非用户明确要求。

这套方法适合什么，不适合什么

这套方案适合个人日报、团队内部简报和小规模信息监控。大规模抓取社交平台需要得到授权，把所有网页交给模型自由浏览也会带来成本、稳定性和事实核验问题。

真正值得复刻的是下面这条执行顺序，发送服务和来源清单以后都可以替换：

先定义结果
→ 再分来源类型
→ 先做确定性脚本
→ 再补 AI 网页编辑
→ 再接发送和幂等
→ 最后做电脑、调度和失败恢复

按这个顺序做，即使以后换信息源、换模型、换微信通道，系统也不会推倒重来。