tweet-insight

name	tweet-insight
description	从推文出发，深度阅读关联内容，整理成原创分享帖。不是翻译，而是学习后用自己的话讲出来。Use when user provides tweet URL(s) and wants to create an original post based on the content. Triggers on "帮我整理这条推", "写一条分享帖", "tweet insight", "digest this tweet", or when user provides x.com/twitter.com URLs and asks to write about them.

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: 呈现结果

输出最终文字，并附上：

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

多条推文场景

当用户提供多条推文时：

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

注意事项

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