cuipengfei GitHub 仓库情报研究
给定一个或一组 GitHub 仓库，产出带证据分级的情报简报。单个仓库出完整档案，多个仓库加横向对比。证据撑到哪，话说到哪。
核心原则（先于一切步骤）
- 结论强度匹配证据层级。筛查不是判决；「未发现异常」不等于「star 是真的」；实测强于 README 声明强于自评论文。
- 仓库与工具用全名。不造缩写，不造新词——领域已有名字就用既有名。
- 引用 issue 必核当前状态：open、closed、已标修复版本、复现失败后关闭——状态随引用写出。复现失败后关闭的 issue 不得当作现存问题。
- 「已核实」只能在读完正文后说。搜索摘要、目录页、README 前几行，都不算核实。
- 对他人仓库下判断的三条边界：只读公开数据，不要授权，能少要权限就少要；打星者的账号名等个人信息不写进报告，报告里只放统计数；仓库维护者给出的解释（比如「那波 star 是发布会带来的」），核实后跟原信号并排放着，不删原信号，也不静默吞掉解释。
五步流程
第一步：身份与机制
- 读目标仓库 README 正文，取能力边界和核心架构。照 README 的措辞写，不替作者拔高。
- 查同名撞车：引用 npm / PyPI 包数据前，先看包的 repository 字段是不是指向目标仓库。不是就弃用那个包的数据。
第二步：硬指标快照
- 有 gh CLI 就用 gh（已登录、配额高）；没有再退回 curl + token。动手前先查实际剩多少配额，翻页的活每页存进度，配额不够就停下，报告查到哪了。
- GraphQL 查：stars、pushedAt、watchers、issues（open 和 closed 分开数）、discussions、forks、贡献者分布（近年 commit 主要落在几个人手里——看清是几个人在扛，不要求算出精确数字）。单点快照，写明日期。
- 数字只摆出来，不解释。解释留到第四步和选型段。
第三步：社区口碑
- 来源执行时再定，不提前列清单。先搜一圈看这个仓库的讨论实际集中在哪几个平台，哪里有讨论去哪里，没有的不要硬凑。
- 正面负面分开记。每条带：观点 + 完整 URL + 日期 + 来源类型。
- 官方自述不算口碑：README、官网、厂商博客都不算；作者自己发的帖和普通用户的评价分开列，不混在一起。
- 必须搜反方：要写下一条正面结论，就搜它的具体反命题（比如「X 比 Y 慢的实测」），把搜索词和结果记进报告。搜不到反证就写「未发现反证」，不给结论加分。
- 多个仓库时按仓库拆给并行的调研子任务，每个仓库一份，交压缩简报，不倒原文。
第四步：证据分级核验
每条关键结论标一档：
| 标记 | 条件 |
|---|---|
[verified] |
3 个以上独立来源且含高可信源；必须能给完整 URL |
[likely] |
2 个来源，不够上一档 |
[single-source] |
只有 1 个来源 |
[conflicting] |
来源实质矛盾，把各方都列出来，不硬消解 |
[unknown] |
没找到证据 |
三种证据形态分开写：实测 / 文档声明 / 推断。作者测自己系统的论文不算独立验证。同一内容多处转载按 1 个来源算。
置信度和分数分开写，三条规则（数字是参考例子，用的时候按场景自己校准，不是硬规则）：
- 样本太小提示置信度低：样本量三十上下的，降一档并写明告诫；一百上下的，降半档
- 多个信号合成一个结论时，整体置信度取所有参与信号里最低的那个，不做平均——薄数据不许被平均掉
- 某个信号数据不够就标
[unknown]并写清缺什么，不许静默跳过后照常给精确结论
第五步：三块轻量筛查
第一块：star 真实性
- 用 GitHub 官方周级 star 序列端点
/repos/{owner}/{repo}/stargazers/history拉增长曲线。端点的返回形状、分页、权限都是执行时现场验证，不靠记忆。需要时可以只看历史某段（比如发布初期），不必总看最近。 - 算：峰值周增量、突发比（峰值周 ÷ 中位数周）、前三周占比；有条件时用带滞后的滚动基线代替全期中位数——防老仓库自然衰减期拉低全期基线造成假峰值。
- 事件对照：峰值和已知公开事件对时间——大 V 推文、Trending、Show HN、发布会、目录站收录，类型不限于这些。对得上 → 信号降级；对不上 → 别下结论，记「已查的来源里没找到解释」。
- registry 下载量当参考（周下载 ÷ star），只作辅助——下载里有 CI、镜像、重复安装，不是真实用户数。
第二块：活跃健康
push / release 节奏、issue 首次响应的中位时长。判断「还活着吗」要按生态校准——一个稳定多年的小工具库安静下来是正常的，别按「最近没 commit」一刀切判死。
第三块：维护者集中度
看清是几个人在扛这个项目。集中度低是选型风险，但不参与 star 档位判定，写进选型段。
star 档位（只这四档，不发明新档）：
- 基准：没有异常信号
- 观察：只有一个异常信号，或者 star 数太小导致比值不可信——不够升级
- 数据不足：关键数据拿不到或样本太小——连观察都给不了，写清缺什么
- 升级取证：两个互相独立的异常信号同时出现才给这档——只有一个信号再扎眼也停在观察，因为单一极端指标区分不了病毒传播和购买。
「两个独立信号同时命中才升级」和样本量数字都是参考框架，用的时候按实际校准，别输出成硬规则。
逐个 star 账号的取证受 GitHub 端点权限限制；没权限就写「本轮拿不到」，不绕，也不拿别的数据冒充。
反模式清单
- 不用没有明确权重或依据的单一分数代替分项证据——watchers、issues、discussions 含义不同，等权加成一个「讨论度」是假的。真要合成，权重要写明、置信度要分开、每个成分能单独复查；本流程不产出综合总分。
- 不把筛查写成真伪判决。「掺水」「star 是假的」这类话超出筛查证据，禁写。
- 不引用没核过状态的 issue。
- 不把下载量叫真实采用。
- 不预设口碑来源。
- 不把一次性会话事实（失效日期、限速数字、撞包实例）写进结论——现场验证，现场记录在报告里。
- 不假设装了别的 skill。本 skill 自成一体。
输出契约
每个仓库七节，缺一不可：
- 身份与机制——它是什么、核心架构、能力边界。写成段落，别一句话打发。
- 硬指标表——stars / watchers / issues / discussions / forks / 最近 push，标快照日期。
- 口碑正面清单——观点 + URL + 日期 + 来源类型。
- 口碑负面清单——同格式；issue 类附当前状态。
- star 真实性档位——四档之一 + 依据 + 拿不到的信号标注 + 每个信号的置信度。
- 活跃与维护者健康——节奏、响应、集中度，按生态校准后的判断。
- 选型含义——值不值得用、什么场景用、已知风险。
多个仓库时加横向对比表 + 全局边界声明：哪些验证过、哪些是推断、哪些 unknown。
报告开头放图例（五个分级标记 + 四个档位各一句白话）；结尾放验证边界（一手直读 / 文档声明 / 推断各占多少）、整体置信度（取参与信号里最低的）和判停依据。
升级取证路径
出了「升级取证」档才考虑这些，而且先向用户报成本：
- 逐个 star 账号的质量分析——要管理员权限或历史事件数据，可能拿不到，也可能要花钱
- 深挖传播事件——峰值周前后的全平台历史检索、目录站收录时间
- 放弃并标注——老实写「本轮定不了」比硬凑一个结论强