StockSight 有几个版本？三个同名仓库一次分清
搜「stocksight」，你会同时撞到 2017 年的 Elasticsearch 舆情平台和 2026 年的两个 Agent Skill。它们只共享名字：语言都是 Python，但依赖、产出物、许可与维护状态没有任何交集。
本页按官方文件逐项对照，先帮你确认手上的是哪一个，再决定往哪走。
三个 StockSight 仓库的硬指标怎么对照
下表全部取自 GitHub API 与仓库内文件，采集日期 2026-09-30。Star 数会变，仓库属性不会。
| 观察项 | shirosaidev/stocksight | gaaiyun/stocksight-skill | GearVoid/StockSight-Skill |
|---|---|---|---|
| Star / Fork | 2,541 / 494 | 0 / 0 | 0 / 0 |
| 创建时间 | 2017-09-25 | 2026-03-01 | 2026-05-18 |
| 最后推送 | 2023-12-05 | 2026-05-30 | 2026-06-11 |
| 默认分支 | master | master | main |
| 许可证字段 | Apache-2.0 | null（无 LICENSE 文件） | MIT |
| 仓库文件数 | 24 个条目 | 14 个文件 | 105 个条目 |
| 运行依赖条数 | 8 条（仅 elasticsearch 钉版本） | 4 条 | 1 条 |
| 测试目录 | 无 | 2 个测试文件 / 24 个用例 | 16 个测试文件 / 160 个用例 |
| CI 配置 | 无 | 有（GitHub Actions） | 有（CI + Release 两条工作流） |
| 本机可否跑通 | 依赖链已断 | 主流程可跑 | 快照路径 exit 0 |
| 是否需要联网 | 需要（抓推文/新闻/行情） | A 股取数需要 | 快照路径完全离线 |
| 是否需要 API Key | 需要 Twitter 四项凭据 | 公开源不需要；NewsAPI 可选 | 免费公开源够用；Tavily/SerpAPI 可选 |
| 文档语言 | 英文 | 中文 | 中英文双语 README |
「运行依赖条数」这一行最值得记住：8 条 vs 4 条 vs 1 条，直接决定了你能不能在十分钟内看到第一个结果。
三个仓库的时间线是什么？从舆情平台到 Agent Skill
不是版本迭代，而是同名的三次独立尝试。这条时间线也解释了为什么中文资料口径混乱。
2017-09：老项目立项
shirosaidev/stocksight创建。当时的思路是「Twitter 情绪 + 新闻标题 + Elasticsearch + Kibana」，一套完整的舆情数据平台。2020-06：老项目最后一个 CHANGELOG 条目
0.1-b.12，内容是「移除 --noelasticsearch 命令行参数」。此后代码层面没有新的版本记录，仓库最后一次推送停在 2023-12。2026-03：第二个仓库出现
gaaiyun/stocksight-skill创建，定位是面向 OpenClaw 的「新闻情绪分析 Skill」。它把老项目的情绪思路搬到 Skill 形态，并补上了 A 股数据源与中文模型。2026-05：第三个仓库出现
GearVoid/StockSight-Skill创建，走的是另一条路：不做新闻情绪，做量价异动检测 + 报告渲染 + 快照回放，面向 Codex / Agent。2026 年：三个仓库并存
三者之间没有 fork 关系、没有依赖关系、没有引用关系。搜索时混在一起，是命名而非代码造成的。
shirosaidev/stocksight 称为 A 路线（老版舆情平台），gaaiyun/stocksight-skill 称为 B 路线（新闻情绪 Skill），GearVoid/StockSight-Skill 称为 C 路线（异动分析 Skill），全站统一。三条路线各自的最小验证路径是什么
下面每一段都写明「本机是否实测过」，没有实测的一律标注。
| 路线 | 最小验证命令 | 预期看到什么 | 本机实测状态 |
|---|---|---|---|
| A 老版舆情平台 | python sentiment.py --help | 一整屏命令行参数说明 | 失败：ImportError: cannot import name 'StreamListener' |
| A 老版舆情平台 | docker-compose build && docker-compose up | 三个容器起来，ES 监听 9200、Kibana 监听 5601 | 未验证：本机没有 Docker |
| B 新闻情绪 Skill | python __main__.py list-backends | 5 行 backend 清单 | 成功：exit 0，列出 vader / textblob / snownlp / finbert / auto |
| B 新闻情绪 Skill | python __main__.py sentiment "…" --backend vader | 一行 JSON：label + polarity + confidence | 成功：exit 0 |
| B 新闻情绪 Skill | pytest tests/ | 24 个用例通过 | 先失败后成功：只装 requirements.txt 缺 pandas；补装后 24 passed |
| C 异动分析 Skill | python scripts/report.py --from-snapshot … --html | 生成 HTML 报告 + Markdown | 成功：exit 0，HTML 73,498 字节 |
| C 异动分析 Skill | python -m unittest discover -s tests -v | 测试全部通过 | 失败：14 个模块 ModuleNotFoundError（缺 -t .） |
| C 异动分析 Skill | python -m unittest discover -s tests -t . | 160 个用例通过 | 成功：Ran 160 tests in 12.842s OK |
注意第 6 行与第 8 行的差别：官方 README 写的是 discover -s tests，实测 14 个模块全部导入失败；加上 -t . 把仓库根纳入搜索路径后，160 个用例全部通过。报错不是你的环境问题。
三个仓库的许可证为什么口径不一致
这是最容易被忽略、但会影响能不能商用的一节。B 路线的三处口径互相矛盾。
| 仓库 | GitHub 许可证字段 | 仓库内文件 | README / 文档里写的 | 结论 |
|---|---|---|---|---|
| A 老版舆情平台 | Apache-2.0 | LICENSE 全文 11,345 字节 | Apache 2.0（源码文件头也写了） | 一致 |
| B 新闻情绪 Skill | null | 没有 LICENSE 文件 | README 写 MIT，SKILL.md 写 Apache 2.0 | 三处冲突：无文件、两种声明、API 字段为空 |
| C 异动分析 Skill | MIT | LICENSE 1,065 字节 | 徽章标注 MIT | 一致 |
A 路线的 Apache-2.0 清晰可依，但要注意它内含的依赖各自许可不同（例如 elasticsearch-py 为 Apache-2.0、newspaper3k 为 MIT），商用前仍需逐项核对。
什么场景该用哪一条路线？
按你手上的任务选，不按 Star 数选。
| 你的任务 | 建议路线 | 理由 | 要接受的限制 |
|---|---|---|---|
| 研究「推文 + 新闻怎么变成可查询的情绪库」 | A 老版舆情平台 | 索引结构、字段设计、Kibana 面板三件套齐全，是少见的完整样本 | 依赖链已断，需要自己修；Twitter 侧凭据现状需自行确认 |
| 想直接看一套 Kibana 情绪面板长什么样 | A 老版舆情平台 | 仓库自带 7 个 saved object 导出文件，可直接导入 | 要先有能跑的 Kibana 5.6 环境 |
| 只要「这只 A 股最近新闻偏正还是偏负」 | B 新闻情绪 Skill | 只装 4 个依赖即可运行，自带 A 股数据源与中文模型路由 | 许可口径不明；测试需要额外装 pandas |
| 要让 Agent 输出一份带来源链的报告 | C 异动分析 Skill | 报告渲染、快照回放、可信度标签都是现成的 | 它不做新闻情绪；样例报告存在空表与数值格式问题 |
| 想对比「自建平台」和「本机技能」两条思路 | 看对比页 | 两者不是替代关系，适合放在同一张表上比能力与前置条件 | 本项目与本机技能路线无已证实集成 |
把它们当成同一个项目会踩哪些坑
下面每一条都来自三仓库文件的实际差异。
坑一：拿着压缩包去找 sentiment.py
B 与 C 路线都没有这个文件。B 的入口是 __main__.py，C 的入口在 scripts/ 下。教程里出现的命令不一定属于你下载的那个仓库。
坑二：用 A 的依赖清单去装 B 或 C
A 需要 Elasticsearch、tweepy、newspaper3k 等 8 项；C 只需要 requests。装错之后出现的报错会完全对不上号。
坑三：以为三者功能可以互相替代
一个存数据做仪表盘、一个给新闻打分、一个做量价异动报告。把它们当成「不同版本」会导致按错误的期望验收。
坑四：用 A 的 Star 数为 B / C 背书
2.5k Star 属于 2017 年那个仓库。B 与 C 的 Star 都是 0，社区验证接近于零，出问题时基本只能自己读源码。
一个实用动作：打开仓库首页，先看 文件列表第一屏。有 sentiment.py + docker-compose.yml 的是 A；有 __main__.py + scripts/ 的是 B；有 core/ + formatter/ + examples/ 的是 C。三秒就能分辨。
还有一个更省事的判据：看你手上的教程里出现的是哪条命令。写着 docker-compose up、sentiment.py -s TSLA、config.py.sample 的属于 A 路线；写着 python __main__.py news 600519、--backend snownlp 的属于 B 路线；写着 scripts/report.py、--from-snapshot、--strategy swing 的属于 C 路线。命令对不上仓库，后面的报错排查会完全跑偏——这也是本站把三条路线的命令行入口单独列出来的原因。
关于 StockSight 版本辨析的常见问题有哪些
三个仓库之间是 fork 关系吗？
不是。gaaiyun/stocksight-skill 的 SKILL.md 里写了「基于原 stocksight 项目简化」，指的是思路来源，仓库内没有任何对 A 路线代码的引用或依赖，也没有 GitHub 的 fork 标记。三个仓库的代码彼此独立，以各自仓库文件为准。
为什么两个 Skill 仓库的 Star 是 0？
它们分别在 2026-03 与 2026-05 创建，最后推送在 2026-05 与 2026-06。按 GitHub 的公开数据，确实没有获得 Star 与 Fork。这不代表代码质量差（C 路线有 160 个通过的单元测试），但意味着没有社区验证，遇到问题只能自己读源码。
B 路线到底能不能用于商业项目？
无法从仓库本身得到明确答案：没有 LICENSE 文件、README 写 MIT、SKILL.md 写 Apache 2.0、GitHub API 的许可证字段为空。本站不替你选一个，建议直接向作者确认后再决定。以仓库实际文件与作者答复为准。
老项目还值得学吗？毕竟已经停更了。
看你学什么。如果学「一个舆情数据平台怎么组织索引、字段与仪表盘」，它的结构依然清晰可读；如果指望它今天开箱可用，会卡在依赖链上。本机实测的结论是：pip install -r requirements.txt 在当前环境直接失败，需要按自己的顺序重装。
有没有可能三者将来合并？
从仓库现状看不出任何合并迹象：三个仓库没有互相引用，也没有共同的维护者可见信息。本站只陈述当前状态，不做预测。判断依据是各仓库的提交记录与文件清单，以官方仓库为准。
C 路线的 160 个测试真的能跑通吗？
能，但要改一个参数。官方 README 写的 python -m unittest discover -s tests -v 会因仓库根不在 sys.path 而报 14 个 ModuleNotFoundError；加上 -t . 后本机实测 Ran 160 tests in 12.842s OK。以官方测试文件为准。