为保证阅读良好的效果，建议先阅读 README，再以复赛 PDF 作为主要浏览目标( GitHub 上 PDF 可在线浏览)。也为了方便您浏览，文件夹首页和复赛文件夹我都上传了复赛内容，择一浏览即可。
项目工程代码存放在 Time-Series-Library-main 文件夹中供参阅。
开源仓库活跃度评估与分析系统
Step 1: 准备环境 🛠️
打开 Time-Series-Library-main 文件夹后，先运行一下命令安装好必须的包：
pip install -r requirements.txt
Step 2: 训练模型 🏋️♂️
请确保你的设备已准备好 CUDA 环境 🟢。 接着，去 scripts 文件夹里找到对应的脚本，通过 bash 运行，生成所需的离线数据。
Step 3: 启动系统 🖥️
准备好数据后，把系统跑起来！进入 Frontend-system 文件夹：
首先，运行 init_db.py 来初始化数据库 📂，然后，运行 main.py，大功告成！🎉
本项目构建的时序集成框架图
上下文感知的集成时序预测框架，用于刻画开源仓库的长期活跃趋势
选择一个开源项目，本质上是一项 长期投入决策。 但现实中，我们往往只能看到：
⭐ Star、🍴 Fork 等静态指标
或者某一时间窗口内的短期活跃，或基于经验的主观判断。
而开源社区真正的挑战在于：热度是瞬时的，协作是时序的，生态是演化的。
今天看起来活跃的项目，未必能持续； 今天看起来普通的项目，可能正处在爆发之前。
仓库活跃度不是一个标签，而是一条时间轨迹。
本项目不仅仅试图回答：
“这个仓库现在活不活跃？”
而是聚焦于：
“它在未来一段时间内，会如何演化？”
不同开源仓库呈现出截然不同的行为模式：
有的趋势近似线性，有的波动剧烈、非线性明显，有的存在阶段性爆发或衰退因此，本项目引入多种互补的时序预测模型：
模型类型 擅长能力
DLinear 线性趋势建模
PatchTST 非线性与局部模式
其他模型 结构多样性补充
👉 不押注单一模型，而是让“专家”协同决策。
通过对历史序列进行编码，模型能够捕捉：
-
长期依赖关系
-
仓库特有的行为模式
-
历史变化对未来预测的影响
这些上下文信息将直接参与后续的融合决策。
构建门控网络，在预测窗口的每一个时间步：
动态评估各模型的可信度
自适应调整模型权重
最终预测结果不是简单平均， 而是一次多模型之间的动态协商。
预测的不是热度，而是协作行为本身。
我们从 GitHub 的真实协作流程出发，预测以下五类活动指标：
OpenIssue
IssueComment
OpenPR
PRReviewComment
MergePR
它们共同覆盖了开源协作的完整生命周期：
需求提出 → 问题讨论 → 代码贡献 → 代码审查 → 成果合并
基于预测得到的未来活动序列，本项目构建了 DTA（Dynamic Trend-based Activeness）：
-
显式引入未来趋势信息
-
结合可解释的权重设计（AHP）
-
对不同规模仓库进行统一放缩
大仓库不会因规模被高估， 小仓库也不会因起点被低估。
🧪 案例验证：2017 年的选择题
以 2017 年的 React 与 Vue 为例：
仅使用当时可见的历史数据
对未来活跃趋势进行评估
React 的 DTA 显著高于 Vue
从随后的多年发展来看，该结果与真实演化趋势高度一致。
这不是回顾历史，而是提前做出判断。
🧑💻 开源参与者：选择更值得长期投入的项目
🏢 企业 / 基金会：优化资源配置与技术选型
🧭 仓库维护者：监测活跃趋势，提前预警
📚 开源生态研究：提供统一、可复用的分析框架
⚙️ 基模型 / 元模型可插拔 支持多种基模型与元模型的灵活接入与替换，架构高度模块化，便于快速实验与持续优化
🎯 动态集成，非静态加权 根据数据特征与时间变化自适应调整模型贡献度，实现真正的动态融合，而不是固定权重的简单叠加
📊 强调可解释性，而非黑箱评分 关注模型决策过程与贡献分析，能够清晰说明“为什么这样预测”，提升结果的可信度与可分析性
🔹 可迁移至其他时序预测任务 方法具备良好的通用性，可平滑迁移应用于金融、能源、流量等多种时序预测场景
开源的未来，应该是可以被理解的，而不是偶然发生的。
本项目希望为：
更理性的开源参与
更健康的社区治理
更可持续的软件生态
更具趋势性的量化视角。