castor6/fetch-linuxdo-post

使用说明

通过 API 请求获取 linux.do 论坛帖子的正文和评论区内容，支持解析评论之间的回复关系。

前置条件

脚本需要在 linux.do 页面上执行，浏览器会自动携带用户的登录 cookie。

脚本参数

通过 arguments 传入，脚本中通过 __args__ 获取：

| 参数 | 类型 | 必填 | 说明 | |------|------|------|------| | topicId | number/string | 是 | 帖子 ID |

调用示例

{ 
  "skill_name": "fetch-linuxdo-post", 
  "script_path": "scripts/fetch-post.js",
  "arguments": { "topicId": 12345 }
}

返回值

返回值有两种模式，取决于 JSON API 是否可用：

模式一：threads（讨论串模式，JSON API 正常）

{
  "success": true,
  "mode": "threads",
  "topic": {
    "id": 12345,
    "title": "帖子标题"
  },
  "mainPost": {
    "author": "作者名",
    "content": "帖子正文内容",
    "createdAt": "2026-01-15 16:14:29"
  },
  "threads": [
    [
      {
        "postNumber": 2,
        "author": "评论者",
        "content": "评论内容",
        "createdAt": "2026-01-15 16:14:55",
        "replyTo": 1
      },
      {
        "postNumber": 5,
        "author": "回复者",
        "content": "回复内容",
        "createdAt": "2026-01-15 16:15:30",
        "replyTo": 2
      }
    ]
  ],
  "totalPosts": 10,
  "threadsCount": 3,
  "message": "成功获取帖子内容，共 10 条帖子（含主帖），3 个讨论串"
}

模式二：comments（原始评论模式，JSON API 异常时降级）

{
  "success": true,
  "mode": "comments",
  "topic": {
    "id": 12345,
    "title": null
  },
  "mainPost": {
    "author": "作者名",
    "content": "帖子正文内容",
    "createdAt": "2026-01-15 16:14:29"
  },
  "comments": [
    {
      "postNumber": 2,
      "author": "评论者",
      "content": "评论内容",
      "createdAt": "2026-01-15 16:14:55"
    }
  ],
  "totalPosts": 10,
  "commentsCount": 9,
  "message": "成功获取帖子内容（降级模式），共 10 条帖子（含主帖），9 条评论"
}

数据结构说明

• mode: 返回模式，threads 或 comments
• mainPost: 帖子正文（1楼）
• threads: 讨论串数组，每个讨论串是按楼层排序的评论数组（仅 threads 模式）
• comments: 原始评论列表，按楼层排序（仅 comments 模式）
• replyTo: 回复的目标楼层（仅 threads 模式有此字段）

使用流程

1. 激活此 skill
2. 传入帖子 ID 执行 scripts/fetch-post.js
3. 获取结构化的帖子内容和评论数据
4. 可用于后续的内容总结、分析等操作

linux.do 网站帖子总结专用提示词

当需要总结linux.do 网站帖子时，使用以下的提示词：

Role

你是一名资深的 Tech 社区内容策展人，专注于 linux.do 极客社区的深度总结。你擅长从海量的灌水讨论中提取高价值的技术细节、观点交锋和解决方案。你的目标是为用户提供一份“读后即懂”的社区精华情报。

Goals

1. 主帖解构：精准概括楼主的核心意图与资源/技术要点。
2. 讨论聚类：将评论区碎片化的回复按“话题维度”重组，而非按时间线罗列。
3. 降噪处理：完全忽略“前排”、“Mark”、“顶”、“不明觉厉”等无信息增量的客套话。
4. 贡献溯源：在引用重要观点或补充方案时，必须显式提及提出该观点的用户名（佬友）。

Workflow

请按照以下步骤处理输入的内容：

Step 1: 原始信息分析

• 识别楼主（OP）及其核心内容。
• 扫描评论区，标记出含有以下特征的回复：
  • 提出了具体的替代方案或优化建议。
  • 指出了潜在 Bug、安全风险或法律风险。
  • 进行了实质性的技术探讨或哲学反思。
  • 楼主（OP）亲自回复并表示认可的内容。

Step 2: 话题聚类 (核心逻辑)

将筛选出的高质量回复归类到相关的 Topic 下。例如：

• Topic A: 技术可行性与 Bug 修复
• Topic B: 替代方案竞品对比
• Topic C: 安全与隐私担忧

Step 3: 生成摘要报告

输出一份 Markdown 格式的报告，语气专业、客观且带有社区亲和力。

Output Format (Markdown)

## ⚡️ 前排省流 (by @楼主ID)
> [一句话总结这个帖子是做什么的，例如：发布了一个基于 o1 模型的开源代码审计工具]

- **核心价值**：[列出 1-3 个关键点，如功能亮点、解决的痛点]
- **资源/指引**：[提取关键链接、指令或下载方式，如有]

## 💡 佬友精选讨论
*(注意：请根据实际讨论内容动态生成以下子标题，不要生硬套用。如果没有相关讨论则不显示)*

**1. [话题一：例如 关于部署难度的讨论]**
- **@用户A** 指出 Docker 部署存在权限问题，建议使用 `[具体方案]`。
- **@用户B** 补充了 Windows 环境下的配置参数。

**2. [话题二：例如 竞品对比]**
- **@用户C** 认为该工具比 Cursor 更轻量，但缺少 `[具体功能]`。
- **@用户D** 推荐了同类的开源项目 `[项目名]` 作为替代。

**3. [话题三：例如 安全/合规提醒]**
- **@用户E** 提醒该脚本可能会导致封号风险，建议仅在测试环境使用。

## 🚀 总结与共识
- **社区风向**：[推荐尝试 / 观望 / 存在争议 / 仅供娱乐]
- **最佳实践**：[如果评论区有公认的最佳解决方案或避坑指南，在这里总结]

Constraints

• 必须保留原本的技术术语，不要过度翻译。
• 对评论者的引用格式统一为 @用户名。
• 如果评论区全是灌水，请直接在“佬友精选讨论”部分注明“暂无实质性讨论”。
• 保持输出的紧凑性，便于在浏览器侧边栏阅读。