sugarforever/tweet-insight

Tweet Insight

从推文出发，深度研读所有关联内容，然后用自己的话写一条原创分享帖。

核心理念

这不是翻译，不是摘要，而是"学习并分享"。就像读完一篇论文后跟朋友讲你学到了什么 - 你消化了内容，形成了自己的理解，用自己的方式讲出来。

具体步骤：

• 读原推 → 读引用推 → 读关联文章/论文 → 整理信息 → 确定主题和角度 → 成文 → 复审

工作流

Step 1: 收集推文

用户提供一条或多条推文 URL。

首选方案：Playwright MCP（推荐，能获取完整结构化内容）

1. 用 browser_navigate 打开推文 URL
2. 用 browser_snapshot 获取页面快照，从中提取：
   • 推文全文
   • 作者、发布时间、互动量（replies, reposts, likes, bookmarks, views）
   • 引用推文（quoted tweet）区块 - 注意：引用推文的完整 URL 不会直接出现在快照中
3. 如果有引用推文：点击引用推文区块的 link 元素，页面会跳转到引用推文页面，此时从 Page URL 获取完整链接，再用 browser_snapshot 获取引用推文的完整内容
4. 提取推文和引用推文中的所有外部链接（t.co 短链接指向的实际 URL）

备选方案：WebFetch + r.jina.ai（无 Playwright 时使用）

• 使用 WebFetch（URL 加 https://r.jina.ai/ 前缀）抓取推文内容
• 注意：r.jina.ai 能获取推文文字和引用推文内容片段，但可能无法返回引用推文的完整 URL
• 如果引用推文 URL 缺失，请用户手动提供

Step 2: 深度阅读关联内容

推文里往往链接到更重要的内容。这一步是关键。

• 提取推文中所有外部链接（论文、博客、公告页、系统卡等）
• t.co 短链接必须先解析再使用：用 Playwright browser_navigate 跟随跳转，从跳转后的 Page URL 获取完整真实 URL。推文快照中显示的链接文本（如 github.com/unslothai/unsl …）是被截断的，绝不能直接用于输出
• 用 WebFetch（可加 r.jina.ai 前缀）逐一抓取链接内容
• 对于 PDF：如果 WebFetch 无法获取或内容过大，提示用户下载后提供本地路径，用 Read 读取
• 对于长文档：重点关注摘要、结论、关键数据、惊人细节，不需要逐字复述
• 有价值的链接要收集起来：如果关联内容中有对读者有用的资源链接（指南、GitHub、notebook 等），记录其完整 URL，在最终输出中附上

Step 3: 整理信息

读完所有材料后，梳理：

1. 这件事的本质是什么？ - 用一句话概括核心事件或发现
2. 关键数据和事实 - 提取最有冲击力的数字和对比
3. 令人意外的细节 - 那些让你"等一下，真的吗？"的部分
4. 实际影响 - 这对普通人/开发者/行业意味着什么
5. 上下文和背景 - 为什么这件事现在发生，跟之前有什么不同

Step 4: 确定角度并成文

不要试图覆盖所有信息。选一个角度切入，像讲故事一样展开。

写作原则

• 开头直击要害 - 第一句话就让人知道发生了什么，并且想继续读
• 用具体数据说话 - 不说"大幅提升"，说"从 42% 跳到 97%"
• 细节是灵魂 - 惊悚的、有趣的、反直觉的细节让内容有血有肉（比如"研究员当时正在公园里吃三明治"）
• 结构用内容传达，不用编号 - 可以用分段、空行来组织，但避免教科书式的"一、二、三"
• 说人话 - 写给聪明但不一定了解这个领域的朋友看，不是写给专家
• 适当加入自己的判断 - 这个东西好不好、重要不重要、可信不可信，读者想听你怎么看

格式

• 默认输出为单条推文
• 引用链接放在开头文字之后 - 先用一两句话引入，然后放链接（这样既自然又能生成卡片），不要放在最前面（太突兀）也不要放在最后面（不生成卡片）
• 结构随内容而定 - 不要总是 1/ 2/ 3/ 4/ 的固定模式。有的内容适合分点，有的适合连续叙事，有的适合先讲故事再给数据。让内容本身决定形式
• 中文内容为主（除非原推是英文且用户未指定语言）
• 数据和专有名词保留英文原文
• 如果内容确实很长，建议用户考虑发 X Article

Step 5: 复审

成文后自查：

• 事实准确性 - 每个数据点都能在原始材料中找到出处吗？没有凭印象瞎编的数字？
• 没有过度解读 - 原文说"可能"的地方，你没有写成"一定"？
• 关键信息没有遗漏 - 最重要的 2-3 个点都覆盖了？
• 语气自然 - 读出来不像机器翻译，也不像新闻稿？

如果发现问题，修正后再呈现给用户。

Step 6: 应用个人写作风格

调用 personal-chinese-writing-style skill，对生成的文字做最后一轮润色：

• 标点符号（破折号用 -，省略号用 ......，引号用 ""）
• 文章结构（结构隐于文中，用散文连接而非硬切）
• 整体语感

Step 7: 呈现结果

输出最终文字，并附上：

• 原始推文链接（作为参考来源）
• 如果内容分成推文串，标注每条推文字数
• 问用户：直接用，还是要调整？

多条推文场景

当用户提供多条推文时：

• 先逐条阅读和研究
• 判断这些推文之间的关系：是同一个话题的不同角度？还是不同话题？
• 同一话题 → 合并成一条综合性的分享帖
• 不同话题 → 分别生成，或问用户想怎么处理

注意事项

• 绝不自动发布，只输出文字
• 不要简单翻译原推 - 如果原推是英文的，你的输出不应该读起来像翻译体
• 保留原始数据和术语的准确性，但用自己的话重新组织
• 如果原始材料中有你无法验证的说法，标注出来让用户知道