企业官网建设流程全解析

目 录

一、成立时间：2008 年 4 月上线Git 缺一个社交层

二、成立原因：把难用的 Git 变成能协作的产品四个人的真实痛点

三、成立目的：让协作本身成为基础设施从托管到平台

四、用户分布与使用情况1.8 亿开发者、6.3 亿仓库

五、取得的成果规模、生态与商业价值

六、孵化的软件项目从 Copilot 到 Electron

七、实际案例：Linux 内核在 GitHub 上的十年torvalds/linux

八、对 LinkTokenView 的启示从工具到默认工作台

关于 LinkTokenView一个密钥，接入你所有的大模型

附、数据来源与说明全部数字标注出处

阅读提示：本文所有数字均标注来源，分为三类——微软官方新闻稿、GitHub 官方 Octoverse 2025 报告、GitHub REST API 实时抓取。涉及「成立原因」的部分属于公开史料与产品定位的综合叙述，已在正文中区分。

一 成立时间：2008 年 4 月上线

GitHub 是一家美国公司，由 Tom Preston-Werner、Chris Wanstrath、PJ Hyett 与 Scott Chacon 四人于 2007 年开始动手开发，2008 年 4 月正式对外上线。它最初的产品形态非常朴素：一个把 Git 仓库放到网上、并且能让人看见彼此工作的网站。

公司层面的时间坐标可以这样记：2008 年成立并上线；2018 年 6 月微软宣布以 75 亿美元收购；2023 年开发者数量突破 1 亿；到 2025 年 10 月，官方口径已经是 1.8 亿以上开发者与 6.3 亿个仓库。

Git 本身并不是 GitHub 发明的。2005 年，Linus Torvalds 为了管理 Linux 内核开发，用十天左右写出了 Git 的第一个版本。它解决的是分布式协作与性能问题，能力很强，但形态是纯命令行的：没有网页界面，没有账号体系，也没有「把仓库放到一处、大家互相看得见」的地方。

2008 年前后，主流代码托管仍以集中式的 SVN 为主。Git 的能力领先，体验却落后。GitHub 恰好补在这个缝隙上：保留 Git 的分布式内核，外面套一层网页化的协作界面。这个组合在当时并不显眼，却决定了后面十几年的走向。

二 成立原因：把难用的 Git 变成能协作的产品

如果只用一句话概括 GitHub 的成立原因，那就是：Git 的强能力和开发者的实际使用体验之间，存在一道很宽的沟，而这道沟是可以被产品填平的。

▪第一，降低操作门槛。Git 上手成本高。分支、合并、rebase 这些概念对当时的开发者是陌生词汇，一旦出错很难自己修回来。GitHub 用网页把这些操作变成按钮和列表。

▪第二，让代码可以被看见。在 GitHub 之前，读别人的代码并不方便。GitHub 用公开仓库、关注、星标和 fork，让「看别人的代码」变成一件顺手的事。

▪第三，给协作一个动作。fork 加 Pull Request 这套流程，把「我想改你的项目」变成了一个可以讨论、可以逐行评论的动作。这是 GitHub 对协作方式最大的贡献，它后来成了行业默认姿势。

值得注意的是，这三件事都不需要新的算法。GitHub 的成立原因不是技术突破，而是对「开发者到底卡在哪里」的判断准确。这一点对今天做 AI 工具的人同样成立：能力已经有别人提供，真正稀缺的是把能力接到具体动作上的那层设计。

三 成立目的：让协作本身成为基础设施

GitHub 官方对自身定位的表述一直是「开发者的公司」：让开发者更容易做开发者。落到具体目的上，可以拆成三层。

表 1 GitHub 目的的三层演进

第三层是关键转折。当 CI、环境、依赖、安全扫描都长在同一个平台上之后，GitHub 就不再是「一个放代码的地方」，而是开发流程本身。2025 年的数据能说明这种绑定有多深：全年 81.5% 的贡献发生在私有仓库里，43.2 百万次 PR 每月被合并——这些不是个人练手，而是组织的日常生产。

四 用户分布与使用情况

截至 2025 年 10 月，GitHub 上有 1.8 亿以上开发者。2025 年一年新增 3620 万人，同比 +23%，平均下来每秒超过一位新开发者注册。作为对比，2018 年微软宣布收购时，这个数字是 2800 万——七年翻了六倍多。

从新增开发者来源看，亚太地区每分钟约新增 25 人，欧洲约 12 人，非洲与中东约 6.5 人，拉美约 6 人。国别上，印度 2025 年一年新增超过 500 万开发者，占全球新增账号的 14% 以上，开发者总量约 2190 万，位居全球第二；官方预计到 2030 年，每三个新开发者里就有一个来自印度。

2025 年是 GitHub 历史上最活跃的十二个月。仓库总数 6.3 亿，一年新建 1.21 亿；公开与开源项目收到 11.2 亿次贡献；每月合并 4320 万个 PR；全年提交 9.86 亿次。写代码的速度与频率都在明显上升。

更值得关注的是工作方式的变化。近 80% 的新开发者在注册后第一周就用上了 Copilot；超过 110 万个公开仓库引入了 LLM SDK，同比 +178%；AI 相关仓库已超 430 万个。换句话说，AI 辅助编码不再是「进阶功能」，而是新人的默认体验。

2025 年 8 月，TypeScript 同时超过 Python 与 JavaScript，成为月活贡献者最多的语言，达到 263.6 万人，同比增加 105 万。背后的逻辑并不神秘：类型系统能在合并之前接住相当一部分由模型生成的编译错误，而这恰恰是 AI 辅助编码最需要的那层护栏。Python 依然牢牢占据 AI 与数据方向，近十二个月新建的 AI 仓库里有近一半是 Python。

五 取得的成果

衡量 GitHub 的成果，可以从四个维度看：规模、生态、商业与产业影响力。

表 2 GitHub 的成果概览

还有一个更直观的指标：星标最多的仓库。星标并不等于质量，但它确实是「有多少人愿意把这件事放进书签」的直接信号。生成本报告当日通过 GitHub API 检索，星标超过 15 万的公开仓库共 62 个，排名靠前的既有学习清单，也有 Linux 内核这样的重量级工程。

六 孵化的软件项目

GitHub 自己孵化或主导了一批项目，它们基本沿着「开发者还缺什么」这条线长出来：缺自动化就做 Actions，缺环境就做 Codespaces，缺 AI 就做 Copilot，缺桌面客户端就做 Desktop 和 CLI。

表 3 主要孵化项目的定位

七 实际案例：Linux 内核在 GitHub 上的十年

如果要挑一个能同时说明「GitHub 能承载什么」和「它不能替代什么」的案例，Linux 内核最合适。torvalds/linux 是 Linux 内核源码在 GitHub 上的镜像仓库，2011 年 9 月创建，用 C 语言写成，仓库体积约 6.4 GB。

▪第一，平台可以只承担一部分职能。内核的主线仍然在 kernel.org，GitHub 上的是镜像。也就是说，GitHub 在这个项目里承担的是「让更多人看得见、看得方便」的角色，而不是取代原有的治理结构。这是超大型项目使用 GitHub 的常见形态。

▪第二，规模不是障碍，流程才是关键。单仓库 6.4 GB、六万多次 fork、上千名维护者，这套协作能跑起来，靠的是 Pull Request 审查流程、持续集成与维护者梯队，而不是某个人的个人能力。评论、审批、签署记录都被留下来，让「这段代码是谁、在什么依据下合进来的」可追溯。

▪第三，规范写进文件，比写在人脑里可靠。内核的提交规范、Signed-off-by 约定、子系统维护者制度，都以文档形式写在仓库里。新贡献者不需要认识谁，照着规则做就能进流程。这和「把流程写成 Skill」是同一个思路：把可复用的判断沉淀成文件。

作为对照，同样由企业在 GitHub 上公开开发的还有 VS Code 与 Electron。前者 2015 年 9 月创建、194,226 星，后者 2013 年 4 月创建、123,489 星。两个项目都选择了开源仓库 + 公开议题列表的开发方式，把产品路线图的一部分交给社区讨论。

八 对 LinkTokenView 的启示

把这些事实放在一起，能提炼出三条对做 AI 工具的平台同样适用的判断。

▪工具的价值在界面，不在内核。GitHub 赢的不是 Git，是「把 Git 接进具体动作」。同理，聚合多种大模型本身不是壁垒，把模型接进用户真实动作的那层设计才是。

▪定义一个动作，比堆十个功能有用。GitHub 用 Pull Request 给协作定义了一个动作。对 AI 平台来说，对应的动作是「一次提问之后，结果能不能直接变成可用的产出」。

▪把规范写成文件。Linux 内核把提交规范写进仓库，任何人都能照着做。LinkTokenView 的 Skill 机制是同一逻辑：把「怎么做」写成文件放在仓库里，模型在需要时自己去读，而不是每次重新解释一遍。