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": f"Bearer {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, headers=headers, 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/rss"3.2 豆包处理环节的对接
豆包网页版没有公开的 API，但可以通过客户端或者网页版的接口做自动化。我的做法是用云电脑上的浏览器自动化工具，模拟人工操作：打开豆包网页版、粘贴内容、发送指令、等待回复、复制结果。
这个环节的稳定性是关键。我试过几种方案，最后用的是 Playwright，因为它对等待和重试的支持比较好。
from playwright.sync_api import sync_playwright def process_with_doubao(content): with sync_playwright() as p: browser = p.chromium.launch(headless=True) 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", timeout=60000) 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, json=card)卡片消息的好处是排版清晰，链接可点击，手机上阅读体验也好。如果内容特别多，可以分页推送，每页 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 Unauthorized | token 过期或错误 | 重新获取 token，检查 app_id 和 app_secret |
| 429 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 推送就够了。信息获取的效率提升是实实在在的。后面打算把反馈循环做得更细一点，让豆包的分类和评分越来越贴合我的偏好。这个方向上的探索空间还很大，有兴趣的可以一起交流。
