基于豆包与飞书多维表格构建个人情报站：自动采集、处理与推送

1. 个人情报站的核心思路与方案选型1.1 为什么需要个人情报站信息过载这件事做了几年内容工作的人应该都有切身体会。每天要盯的源头太多了行业群里的讨论、飞书文档的更新、竞品动态、技术社区的热帖、自己收藏夹里攒着没看的文章。靠人脑记、靠手动整理最后的结果往往是收藏夹吃灰、重要信息漏掉、想找的时候翻不到。个人情报站要解决的就是这个问题把分散在各处的信息自动汇聚到一个地方做初步的清洗和分类再按需推送到我面前。它不是那种大而全的企业级知识管理系统而是一个轻量、可控、能自己迭代的小工具。核心诉求就三条自动采集、结构化存储、按需推送。豆包在这个链路里扮演的是“大脑”的角色。它的长文本理解能力、指令跟随能力以及网页版和客户端都能用的便利性让它很适合做信息的摘要、分类和二次加工。而飞书多维表格则承担“数据库看板”的职能API 打通之后整个流程可以做到无人值守。这套方案适合谁适合每天需要处理大量信息、又不想被信息淹没的人。不管你是做运营、做研究、写代码还是做投资只要你有“信息焦虑”这套思路都能直接抄。1.2 整体架构拆解整套系统分四层从下往上依次是采集层、处理层、存储层、推送层。采集层负责把信息抓回来。来源可以是 RSS、网页、飞书群消息、API 返回的数据。采集方式我试过几种最稳的是用定时脚本拉取配合飞书机器人做手动投递的补充。手动投递这个入口很重要因为有些信息是突发的、非结构化的比如群里有人甩了一张截图这种靠爬虫抓不到得留个人工入口。处理层是豆包的主场。原始信息往往很脏有广告、有重复、有无关内容。直接丢给豆包做摘要和分类让它输出结构化的 JSON后面就好处理了。这里有个关键点指令要写得足够具体。比如“请提取这篇文章的核心观点输出三个要点每个要点不超过 30 字并判断它属于技术、产品还是行业动态”这种指令比“帮我总结一下”效果好得多。存储层用飞书多维表格。选它而不是本地数据库原因有几个一是多人协作方便二是自带视图和筛选三是 API 成熟四是手机端体验好。字段设计上我一般会留这些列标题、来源、原文链接、摘要、分类、标签、重要程度、入库时间、处理状态。处理状态这个字段很关键用来标记哪些已经推送过、哪些还需要人工确认。推送层就是飞书机器人。把筛选后的内容按格式发到指定群或者私聊支持表格卡片和文本两种形式。表格卡片适合批量推送文本适合单条提醒。1.3 工具选型背后的考量豆包、飞书、云电脑、Agent、API 这几个关键词里每一个选型都有理由。豆包的优势在于中文理解好、响应快、网页版和客户端都能用。我对比过几个同类工具豆包在处理中文长文本时的摘要质量明显更稳尤其是对行业术语的识别。而且它的指令跟随能力不错你让它输出 JSON它基本不会跑偏成散文。飞书多维表格的 API 是我用过最顺手的之一。字段类型丰富支持附件、人员、日期、单选多选Webhook 触发也简单。飞书机器人发送表格这个功能省去了自己写前端展示的功夫。云电脑的引入是因为我需要一个 24 小时在线的环境跑定时任务。本地电脑会关机、会休眠云电脑可以一直挂着。这里不展开具体品牌思路就是找一个能长期在线、能跑 Python 脚本、能访问外网的环境。Agent 的概念在这里体现为“自动化决策”。不是简单的 if-else而是让豆包根据内容判断优先级、决定是否推送、生成什么样的推送文案。API 则是把这些环节串起来的胶水。2. 核心细节解析与实操要点2.1 豆包指令的写法与调优豆包用得好不好八成看指令。我踩过的坑包括指令太模糊导致输出格式不稳定、指令太长导致模型忽略部分要求、没有给示例导致分类标准不一致。一个经过验证的指令模板长这样你是一个信息处理助手。请对以下内容进行处理 1. 提取核心观点输出 3 个要点每个要点不超过 30 字 2. 判断分类只能从以下选项中选择技术动态、产品更新、行业新闻、观点评论、工具推荐 3. 评估重要程度1-5 分5 分最重要 4. 输出格式为 JSON字段为summary数组、category字符串、importance数字 待处理内容 {{content}}这个模板的关键在于约束输出格式、限定分类选项、明确评分标准。不给约束豆包会自由发挥后面解析就麻烦了。还有一个技巧是分步处理。对于特别长的内容先让豆包做一次粗筛把无关内容去掉再做精细摘要。一次性丢一万字进去输出质量会下降。注意豆包的输出偶尔会带 markdown 代码块标记解析前记得先 strip 掉json 和这两行。2.2 飞书多维表格的字段设计字段设计决定了后面能不能高效筛选和推送。我的表结构是这样的字段名类型说明标题文本原始标题来源单选如 RSS、群消息、手动投递原文链接URL可点击跳转摘要多行文本豆包生成的要点换行分隔分类单选与技术动态等选项对应标签多选自由打标如“大模型”“前端”重要程度数字1-5入库时间日期自动填充处理状态单选待处理、已推送、已归档推送时间日期推送后回填处理状态这个字段是流程控制的核心。采集脚本只写入“待处理”的记录推送脚本只读取“待处理”且重要程度大于等于 3 的记录推送后把状态改成“已推送”。这样就避免了重复推送。飞书多维表格的 API 调用需要注意两点一是 access token 有有效期需要定时刷新二是批量写入有频率限制建议每批不超过 100 条间隔 1 秒以上。2.3 云电脑环境的配置要点云电脑上要跑的东西不多一个采集脚本、一个处理脚本、一个推送脚本再加一个定时任务调度。环境配置上Python 3.9 以上、requests 库、飞书 SDK、豆包的 API 调用封装基本就够了。定时任务我用的是 crontab简单可靠。采集脚本每 30 分钟跑一次处理脚本每 10 分钟跑一次推送脚本每天早上 8 点和晚上 8 点各跑一次。这个频率可以根据自己的信息量调整。提示云电脑的时区要设置对否则定时任务会在奇怪的时间触发。我一开始没注意结果凌晨三点收到推送。网络稳定性方面建议加一个重试机制。API 调用失败是常态尤其是批量操作的时候。我的做法是封装一个带指数退避的请求函数失败后等 2 秒、4 秒、8 秒再试最多试三次。2.4 Agent 化改造的关键步骤从“脚本”到“Agent”的升级核心是让系统具备一定的自主决策能力。具体来说我做了这几件事第一让豆包判断内容是否需要人工确认。有些内容分类模糊或者重要程度评分在 3 分左右系统会标记为“待确认”推送到一个专门的群由我手动决定是否入库。第二让豆包生成推送文案。不是简单地把摘要贴出来而是根据内容类型生成不同的推送格式。技术动态会带上原文链接和关键代码片段行业新闻会带上影响分析。第三加入反馈循环。我可以在飞书表格里修改分类和重要程度这些修改会被记录下来定期喂给豆包做 few-shot 示例让它的判断越来越准。这套 Agent 化的改造不需要多复杂的框架核心是把决策逻辑从硬编码转移到模型判断上。代价是增加了 API 调用量但换来的灵活性是值得的。3. 实操过程与核心环节实现3.1 采集脚本的完整实现采集脚本的核心逻辑是读取配置好的信息源列表逐个抓取解析出标题、链接、正文然后写入飞书表格。import requests import feedparser from datetime import datetime def fetch_rss(url): feed feedparser.parse(url) items [] for entry in feed.entries[:10]: items.append({ title: entry.title, link: entry.link, content: entry.get(summary, ) }) return items def write_to_feishu(items): token get_feishu_token() url https://open.feishu.cn/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records/batch_create headers {Authorization: fBearer {token}} records [] for item in items: records.append({ fields: { 标题: item[title], 原文链接: {link: item[link], text: item[title]}, 来源: RSS, 处理状态: 待处理, 入库时间: int(datetime.now().timestamp() * 1000) } }) resp requests.post(url, headersheaders, json{records: records}) return resp.json()这段代码里get_feishu_token需要自己实现逻辑是用 app_id 和 app_secret 换 tenant_access_token。注意 token 有效期是 2 小时建议缓存起来不要每次调用都重新获取。采集源的管理我放在一个 YAML 文件里方便增删sources: - name: 某技术社区 type: rss url: https://example.com/feed - name: 某行业媒体 type: rss url: https://example.org/rss3.2 豆包处理环节的对接豆包网页版没有公开的 API但可以通过客户端或者网页版的接口做自动化。我的做法是用云电脑上的浏览器自动化工具模拟人工操作打开豆包网页版、粘贴内容、发送指令、等待回复、复制结果。这个环节的稳定性是关键。我试过几种方案最后用的是 Playwright因为它对等待和重试的支持比较好。from playwright.sync_api import sync_playwright def process_with_doubao(content): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(https://www.doubao.com) page.wait_for_selector(textarea) page.fill(textarea, build_prompt(content)) page.keyboard.press(Enter) page.wait_for_selector(.response-content, timeout60000) result page.inner_text(.response-content) browser.close() return resultbuild_prompt就是前面提到的指令模板。wait_for_selector的超时时间设长一点因为长文本处理可能需要几十秒。注意浏览器自动化有被识别为异常流量的风险建议控制频率不要短时间内大量请求。另外豆包的页面结构可能会变选择器需要定期检查。如果觉得浏览器自动化太重也可以考虑用豆包客户端配合一些自动化工具思路类似。3.3 飞书机器人的推送实现推送环节用飞书自定义机器人 Webhook 就够了。支持文本、富文本、卡片等多种消息类型。def send_to_feishu_bot(records): webhook https://open.feishu.cn/open-apis/bot/v2/hook/xxxxx elements [] for r in records: elements.append({ tag: div, text: { tag: lark_md, content: f**{r[title]}**\n{r[summary]}\n[原文]({r[link]}) } }) elements.append({tag: hr}) card { msg_type: interactive, card: { header: {title: {tag: plain_text, content: 今日情报速递}}, elements: elements } } requests.post(webhook, jsoncard)卡片消息的好处是排版清晰链接可点击手机上阅读体验也好。如果内容特别多可以分页推送每页 5 条。推送时间的选择也有讲究。我试过早上 8 点推一次晚上 8 点推一次。早上那次是“昨夜今晨”的汇总晚上那次是“今日新增”的精选。周末会降低频率只推重要程度 4 分以上的。3.4 完整流程的串联与调度把上面几个环节串起来整个流程是这样的定时任务触发采集脚本抓取各信息源写入飞书表格状态为“待处理”处理脚本读取“待处理”记录逐条调用豆包做摘要和分类回写表格推送脚本读取“待处理”且重要程度大于等于 3 的记录生成卡片发送到飞书群更新状态为“已推送”我手动处理“待确认”的记录修改分类或重要程度这些修改作为反馈数据积累调度用 crontab 配置*/30 * * * * /usr/bin/python3 /home/user/collect.py */10 * * * * /usr/bin/python3 /home/user/process.py 0 8,20 * * * /usr/bin/python3 /home/user/push.py这个配置的意思是采集每 30 分钟一次处理每 10 分钟一次推送每天 8 点和 20 点各一次。提示脚本的日志要保留方便排查问题。我用的是 Python 的 logging 模块输出到文件按天切割。4. 常见问题与排查技巧实录4.1 API 调用失败的排查思路API 调用失败是最常见的问题表现五花八门。我整理了一个速查表错误现象可能原因解决方法401 Unauthorizedtoken 过期或错误重新获取 token检查 app_id 和 app_secret429 Too Many Requests请求频率超限降低频率加 sleep批量操作分批400 Bad Request参数格式错误检查字段类型日期用时间戳链接用对象超时无响应网络问题或服务端慢加重试机制设置合理超时时间返回结果为空选择器失效或内容未加载检查页面结构增加等待时间429 这个错误我遇到最多。飞书多维表格的 API 限制是每秒 20 次左右批量写入时很容易超。解决办法是每批 50 条批间 sleep 1 秒。4.2 豆包输出不稳定的处理豆包有时候会不按格式输出比如该输出 JSON 的时候输出了一段散文或者分类选项超出了预设范围。这种情况的处理策略是第一在指令里加一句“如果无法判断分类填‘其他’”给模型一个兜底选项。第二解析前做一次校验如果 JSON 解析失败就把原始输出存下来标记为“解析失败”人工处理。第三定期检查“解析失败”的记录看看是不是指令需要调整。我大概每两周会 review 一次根据失败案例优化指令模板。还有一个技巧是温度参数。如果豆包支持调整把温度调低一点输出会更稳定。不过网页版一般没有这个选项只能通过指令约束来弥补。4.3 云电脑环境的稳定性保障云电脑跑久了会遇到各种问题内存泄漏、磁盘满了、进程挂了。我的应对措施是每个脚本加上异常捕获出错时记录日志并发送告警到飞书定期清理日志文件保留最近 7 天用 supervisor 或者 systemd 做进程守护挂了自动重启每周重启一次云电脑清理内存注意云电脑的磁盘空间通常不大日志和临时文件要定期清理。我设置了一个定时任务每天凌晨清理 7 天前的日志。4.4 信息源质量下降的应对信息源不是一成不变的。有些 RSS 会停更有些网站会改版导致抓取失败有些源的内容质量会下降。我的做法是每月做一次信息源审查统计每个源的采集量、采用率重要程度大于等于 3 的比例、推送打开率。采用率低于 10% 的源考虑移除抓取失败的源检查原因。这个审查也可以半自动化用飞书表格的统计视图按来源分组看数量和平均重要程度。数据不好的源果断砍掉。信息站的价值在于精不在于多。4.5 实操心得与避坑清单最后分享几条踩坑换来的经验不要追求大而全。一开始我只放了 5 个信息源跑顺了再慢慢加。一上来就搞几十个源调试成本太高。指令要迭代。第一版指令肯定不完美根据实际输出不断调整。我现在的指令模板是改了七八版之后的成果。留人工入口。全自动的系统遇到意外情况会卡住留一个手动投递的入口关键时刻能救急。数据要备份。飞书表格虽然稳定但定期导出 CSV 备份是个好习惯。我每周导出一次存到云电脑的另一个目录。关注 API 调用量。豆包和飞书的 API 都有配额跑之前先算一下每天的调用量别超了。超了要么升级套餐要么降低频率。这套系统我跑了大半年从最初的每天手动整理一两个小时到现在每天花十分钟 review 推送就够了。信息获取的效率提升是实实在在的。后面打算把反馈循环做得更细一点让豆包的分类和评分越来越贴合我的偏好。这个方向上的探索空间还很大有兴趣的可以一起交流。