企业官网建设流程全解析

GitHub Profile Analyzer 是一款面向开发者的 GitHub 个人主页分析器，它用确定性评分引擎对 GitHub Profile 打分，而不是让 AI 每次编一个不同版本的故事。本文带你拆解它的核心原理：43 条采样规则如何做到同一份 Profile 永远得到同一个分数，且每个分数都能逐项追溯得分来源。

为什么“可复现”才是评分工具的命门

大多数主页分析器只有两种做法：要么甩出一堆原始数字却没有任何解读，要么把结果交给大模型，跑三次能出三个故事。GitHub Profile Analyzer 选择了第三条路：

• 确定性设计：同一个 Profile 永远产出同一组分数
• 可解释评分：把鼠标悬停在任意分数上，就能看到因子拆解——测了什么、采了多少仓库、得了几分、满分是多少，低分时还会附上具体改进建议
• 不瞎猜：凡是公开数据算不出来的规则（比如分支保护、粉丝增长历史），直接标记为“不可用”，而不是编一个数

这套设计写在 README.md 中：“The same profile always produces the same scores.”——同样的 Profile，永远同样的分数。

评分引擎总览：一次采集，纯函数计算

整个引擎的入口是 engine.ts，一次“Deep dive（深潜）”分析的流程非常清晰：

1. 校验用户名并选择认证层（用户 OAuth 或 Token 池）
2. 查 Redis 缓存：命中则直接返回 15 分钟内缓存的结果
3. 批量采集：约 30 次 GitHub API 请求拉取全部数据（预算上限 REST 34 / GraphQL 10 / Search 2）
4. 顺序执行四类规则：基线指标 → 异常信号 → 评分 → 图表，全程零额外 API 调用
5. 生成解读：等级、原型、工作节奏、趋势，全部由规则结果推导
6. 写入缓存并返回完整 JSON 报告

关键在第 4 步：数据采集和规则计算被彻底分离。规则函数拿到的是一份只读快照（EngineData），它们不调用网络、不掷骰子、不依赖随机数——相同的输入必然推出相同的输出，这就是“100% 可复现”的根基。

43条采样规则是什么：一个“诚实的取样器”

“采样（Sampled）”指的是：引擎不会把一个人的全部 500 个仓库、上万条 commit 都翻个底朝天，而是按公开的固定上限取样，并在报告里如实标注。

这些上限定义在 types.ts 的AnalysisModeProfile中：

采样上限是写死在配置里的常量，而不是“看心情取几个”。这意味着无论谁在什么时候运行，取到的都是同一批数据边界——取样本身也是确定的。

每条规则执行后都会带一个状态标签，定义见 types.ts 中的RuleStatus：

• ok：数据完整，直接可算
• sampled：基于固定上限的样本计算，附sampleSize和注意事项
• unavailable：公开数据无法计算，如实上报而非猜测
• requires_oauth：需要用户登录授权

引擎还会根据状态给每条规则打置信度分（ok94 分、sampled72 分起，样本小于 5 再扣 12 分），让你在参考分数时知道“这个数有多硬”。

规则全家桶：基线、信号与评分三层结构

引擎的规则库分布在 rules/ 目录下的四个文件中：

其中“43 条采样规则”是官方对参与核心评估的采样型规则的统称（见 README.md 的 “43 sampled rules”），它们覆盖了账号年龄、贡献模式、仓库质量、发布纪律、安全姿态、社区健康等维度。信号层是“观察员”而非“裁判”：它只标记统计模式并附上采样免责声明，永远不会直接下结论。

分数怎么算出来的：固定权重 + 乘法阻尼

总分计算逻辑全部公开在 scoring.ts 的SCORE_WEIGHTS常量里：

• 13 个维度各占固定权重：贡献量（2.1）、协作（2.3）、影响力（2.4）、维护度（2.8）各占 10%，一致性、文档、贡献回馈各占 8%……
• 第 2.7 条“真实性乘数”不占权重，而是做乘法：每有一条真实性信号被标记，总分就乘 0.94（即减 6%），最低不会低于总分的 40%
• 最终分 = 加权和 × 真实性乘数，四舍五入后落在 0–100 区间

为什么这样设计？因为“扣在某一个维度”和“整体打折”表达的是两种不同信号——前者是“这项能力弱”，后者是“整份履历的可信度要打折”。

再看评分内部的确定性细节。所有分数都来自固定的数学工具（shared.ts）：中位数、标准差、Gini 系数、Jaccard 相似度，以及一个饱和函数——100 × (1 - e^(-kx))，让“提交数 10 万”不会碾压“提交数 1000”，曲线参数 k 也是写死的常量。没有模糊匹配，没有“酌情加分”。

每个低分还会附带补救建议。比如维护度低分会直接列出沉睡超过一年的仓库名：“Archive or refresh dormant repositories: xxx”——告诉你具体该修哪几个仓库。

复现性的最后三道保险

除了“纯函数计算”，项目还用工程手段锁死了可复现性：

1. 15 分钟 Redis 缓存：同一用户、同一模式、同一认证层，15 分钟内重复分析直接返回缓存副本，缓存键里甚至包含 Token 指纹以防跨用户串号
2. 结果落库可对比：每次扫描的总分、字母等级、原型都会存入 deterministic_scans 表，支持快照历史与并排对比
3. 单元测试锁死边界：deterministic.test.ts 用固定的 mock 数据（now被钉死在某个时间戳）反复验证——真实性乘数 0.88 就是 0.88，总分必须落在 [0, 100]，A+/A/B/C/D/F 的分数线一分不能漂

一句话总结

GitHub Profile Analyzer 的可复现性不是口号，而是四件小事叠加的结果：固定采样上限、固定权重与数学曲线、采集与计算彻底分离、测试锁死边界。规则跑完之后，你得到的不是一个无法质疑的黑盒分数，而是一份可以逐条核对、随时重放的证据链。

想了解完整功能列表与本地部署方法（Node.js 22+、npm install后npm run dev），可参考项目根目录的 README.md。