我最近搭了一套每天北京时间 8 点运行的行业简报：抓取五个中文信息源的近 24 小时内容，让方舟 Seed 2.1 lite 判断每条内容是否值得读者花 5 分钟，过线后再生成摘要、阅读价值和行动建议，最后以折叠卡片推进飞书群。
这次实践的重点不在「接上哪个模型」，而在三个更具体的问题：信息源是否真的可用，评分标准是否贴近读者行动，以及推送和定时任务能否稳定运行。目前我完成了本地与云端运行、飞书实际推送，并做了一组 Seed lite 与 DeepSeek V4.1 Flash Economy 的同条件对照。Seed 臂这次处理的 token 按官方单价估算约 0.089 元；对照只有一组，不能据此给两个模型排长期名次。
整条流水线按「信息源 → 阅读价值评分 → 筛选与成稿 → 飞书卡片」运行。评分先于写作：没达到阈值的内容不会进入摘要生成阶段，这样既减少群里的信息量，也避免为不重要的新闻支付额外输出费用。
我把评分问题改成了「这条新闻对谁有用」
这份简报的预设读者是内容创作者和小生意经营者，不是追踪每个技术版本的工程师。因此，「技术新闻重要性」不能直接当成阅读价值：一个底层框架升级可能技术含量高，却不要求做电商的读者今天采取任何行动。
我为这套简报写了四份规则文件，分别定义内容范围、评分标准、输出结构和写作口径。评分被拆成下面几档：
- 9–10 分：平台规则、价格或功能发生直接影响经营的变化，晚看可能错过处理窗口；
- 7–8 分：本周能用上的工具、内容选题或经营信息；
- 5–6 分：值得了解，但今天不读也不会影响行动；
- 3–4 分：常规更新、缺少具体事实或主要面向其他人群；
- 0–2 分：推广填充、标题党或与读者无关的内容。
7 分是当前推送阈值。摘要之外，输出还包括「阅读价值」和「行动建议」：前者要说明适合谁、为什么值得读，后者给出能执行的动作或内容角度。规则也允许模型在没有真实行动价值时省略建议，避免为了填满格式硬编一句「值得关注」。
这里最关键的设计是允许模型明确说「这条对某些人有价值，但不适合你」。例如国行 Apple 智能开放测试那条内容，Seed 版除了概括功能和机型限制，还把数码创作者与普通用户分开：前者可以从实测边界里找选题，后者如果不准备安装测试版，等到 12 月正式版即可。
信息源先实测，再写进配置
候选清单最初包含 36氪、虎嗅和新榜。我逐个请求了八个候选源的订阅地址，检查返回内容是否是真正的 RSS，再看实际条目数，而不是仅凭网站知名度决定采用谁。
| 信息源 | 本次实测 |
|---|---|
| 少数派 | 正常，返回 10 条 |
| 爱范儿 | 正常，返回 20 条 |
| 量子位 | 正常，返回 10 条 |
| 雷峰网 | 正常，返回 20 条 |
| 极客公园 | 正常，返回 30 条 |
| 36氪 | 订阅地址返回网页 HTML，本次不可用 |
| 虎嗅 | 连接失败 |
| 新榜 | 未找到公开 RSS 入口 |
最终保留前五源。它们覆盖数字工具、消费电子、AI 行业、创业与电商动态，并提供一定冗余：某个源当天失效时，不至于整份简报没有内容。表中的条数只是 11 月 4 日探测时看到的结果，不代表每天固定返回这么多内容。
模型调用也做了同样的检查。价格页上的 doubao-seed-2.1-lite 是展示名称，直接作为模型 ID 调用会返回 404。我通过模型列表接口查看当前凭据可见的 55 个模型，再发最小请求验证，最终使用 doubao-seed-2-1-lite-260915。另外，Coding Plan key 使用 /api/plan/v3，按量 key 使用 /api/v3；两种凭据和路径不能混用。
实际推送到群里的简报长什么样
下面的截图来自 11 月 5 日实际推送的折叠日报。进入群聊后，先看到本期从多少条内容中筛出多少条，再看到每条标题和分数；只有需要进一步判断的内容才展开。
这次展示的是六条内容，标题上分别标注 8 分或 7 分。折叠结构解决的是阅读顺序问题：分数和标题用于快速排除，完整摘要留给确实感兴趣的内容。
展开「腾讯混元 Hy4 正式版上线 WorkBuddy」后，可以看到摘要中保留了免费窗口、API 定价和实测任务等具体信息；后面两段分别说明它适合哪类读者，以及可以在免费期内怎样测试。这里的截图只能证明真实推送和输出结构，不能单凭一张图证明长期内容质量。
一组同源对照：Seed 与 DeepSeek 的写作差异
为了观察 Seed lite 写中文简报的表现，我增加了一组 DeepSeek V4.1 Flash Economy 对照。两臂使用相同的信息源、评分规则、写作要求、API key 和接口路径，也都在 GitHub Actions 的相同运行环境中执行；唯一有意改变的变量是模型。两臂各使用独立的数据目录，避免历史检索读到对方生成的摘要。
两臂串行执行，抓取时间相差约一分半，因此进入处理的内容分别为 42 条和 41 条。这是 24 小时抓取窗口边缘的自然变化，不能解释成模型选择了不同信息源。
这次 Seed lite 有 9 条超过 7 分，主题去重后留下 6 条；DeepSeek 有 7 条过线，去重后留下 4 条。Seed 的输出文件为 9,366 字节，DeepSeek 为 5,788 字节；token 总消耗分别为 89,492 和 69,067。更长的成稿与更多的入选内容同时发生，因此不能把文件变长单独理解成写作更详细。
同一篇《国行 Apple 智能开放测试》能更直观地显示差异。Seed 版强调功能边界、支持机型和内容创作者的选题方向；DeepSeek 版则补充了「iPhone 15 和 15 Plus 因 6GB 内存无缘」「首次下载支持内容最多约 7GB」「千问扩展需手动开启」等操作细节。评分上，Seed 本次的六条分为 8 分和 7 分两层，DeepSeek 的四条全部为 7 分。
这组数据只能说明本次输入下的差异。它既不足以证明 Seed 的评分一直更有区分度，也不足以证明 DeepSeek 一贯更注重细节；生成随机性、当天素材和串行抓取都可能影响结果。后续样本需要继续检查这些现象是否重复出现。
Seed 臂的 89,492 个 token 由 80,191 输入和 9,301 输出组成。按 lite 输入 0.8 元、输出 2.7 元每百万 token 估算，分别约 0.064 元和 0.025 元。
这是根据 token 和公开单价得到的估算，实际费用以方舟账单为准；DeepSeek 托管模型的本次单价未核实，所以这里没有给两臂做成本优劣比较。
上线前发现的几个问题
本地出稿后，云端第一次运行只用了 12 秒就退出。原因不是模型或网络，而是 webhook secret 尚未设置时，GitHub Actions 会提供一个存在但为空的环境变量；程序进入 webhook 校验后直接报错。我在任务里加了空值判断：没有配置 webhook 时先关闭推送，保证出稿与归档仍能完成。配置完成后再恢复推送。
飞书还出现过一次「HTTP 200，但群里没有卡片」。继续读取响应正文后才看到错误码 19021：机器人启用了签名校验，而当前推送模板不能生成所需签名。测试机器人随后改用「自定义关键词」模式，关键词设为 Horizon；再次运行后，响应正文与群内实际消息都确认成功。这个例子说明 webhook 推送不能只看 HTTP 状态码，飞书会在 200 响应的正文里返回业务错误。
本地环境有两个与文件系统有关的问题。项目所在的 exFAT 移动盘上，uv 创建 Python 虚拟环境时卡住；排查后把虚拟环境移到内置盘解决。这个文件系统还会生成 ._ 开头的 AppleDouble 文件，第一次提交时被一起带入仓库，后来通过清理和 .gitignore 排除。它们与模型质量无关，却会直接影响部署和仓库归档，值得在自动化前处理干净。
参考资料：
- Horizon（MIT，底层采集与简报组件）：github.com/Thysrael/Ho…
- 火山方舟模型价格页（成本估算依据）：docs.volcengine.com/docs/ark/mo…
- 项目自测：2026-11-05 单组双臂运行记录；Seed 臂 89,492 tokens，DeepSeek 臂 69,067 tokens，原始简报与运行日志已归档。
