为什么要用 GitHub 作为 AI Native 时代的知识协作底座

我想把公司里一部分需要长期沉淀的知识，尤其是我自己的工作日志、文档和文章，逐步从传统文档系统 Confluence 和飞书迁到 GitHub。这个选择看起来有点反直觉：GitHub 对普通人并不友好，Git 本身也有很高的学习和使用门槛。别说非技术同事，即使是程序员，真正把 Git 协作流程用明白、用顺手的人也并不多。

但这恰恰是我认为它在 AI Agent 时代变得更有价值的原因。

过去 Git 的门槛在于，人要亲自理解 branch、commit、PR、review、merge 这些概念，还要遵守一整套写 commit、开 PR、处理冲突、维护历史的协作习惯。这些事情对大多数人来说都不轻松，包括我自己也一样。因此在过去，GitHub 更像是面向少数技术人员的专业工具，很难真正成为公司范围内的通用知识协作系统。

现在情况变了。那些难理解的概念，可以交给 AI 去理解；那些难坚持的规则，可以交给 AI 去遵守。人不需要亲自学习 Git，也不需要亲自处理 GitHub 的复杂流程。人只需要用自然语言表达想法和需求，Agent 可以负责整理、保存、提交、审查、同步和呈现。

所以我选择 GitHub，并不是因为它是一个更好的文档编辑器，而是因为它更适合作为 AI Agent 操作的知识基础设施。

1. 知识是共同资产，不是私有文档

我们一直希望公司内部形成更公开、更透明的知识协作方式。知识应该是大家的共同资产，而不是被困在权限墙后面、只属于有编辑权限的少数人。这并不是说所有信息都没有边界，也不是所有人都可以随便修改正式内容，而是在合适的权限范围内，信息默认可见，问题可以被指出，改进可以被提出，正式结论由明确的流程确认。

传统文档系统的协作方式，经常围绕「谁有编辑权限」展开。一篇文档默认是私有的——默认不可查看、不可编辑，要有权限才能看、被加进编辑组才能改。没权限的人只能评论、申请，或者另开一篇文档。知识因此天然带着「私有」的属性，别人即使有更好的想法，也很难直接动手。

GitHub 的默认姿态正好相反：放进仓库的内容默认是公开的、默认是可以编辑的。任何人都可以把仓库 clone 到本地，自由修改、整理、扩展，本地内容怎么阅读、怎么索引、怎么让自己的 AI Agent 使用，都可以由自己决定。但 Git 的版本管理让这种「默认可编辑」是受控的——是否进入公司共同维护的正式版本，由 owner、review 和规则决定。上游管理者对主线的掌控力度，反而比传统文档系统更强。这就是「开放贡献，受控合并」：贡献的门槛被打开，合并的责任仍然清楚。

在这种机制下，知识不再是某个人私有的文档，而是一个仓库里的共同资产。大家可以围绕它提出改进，而正式内容仍然有清晰的责任边界。这比简单地给某些人编辑权限更适合长期协作：它鼓励更多人参与，也避免正式知识被随意改乱。

2. GitHub 是 AI 模型天然熟悉的协作语言

GitHub 有一个很多第三方文档系统不具备的优势：AI 模型本身非常熟悉它。

GitHub 上有全世界最好的开源项目，也沉淀了大量成熟的协作案例。这些内容天然已经进入大模型的训练语料里。也就是说，AI 不只是知道 GitHub 是什么，而是已经从大量真实项目中学习过怎样组织内容、怎样提出修改、怎样讨论问题、怎样形成共识，以及什么样的协作方式更清晰、更高效。

也就是说，GitHub 的很多规则、规范和协作礼仪，对 AI 来说不是一个需要从零学习的新系统，而是已经内化在模型能力里的工作方式。我们不需要先为它写一整套「怎么使用 GitHub 协作」的手册，它通常就能比较自然地按照这套范式工作。

这和很多第三方文档系统完全不同。比如让 AI 去使用飞书文档，它往往需要先接工具、接 MCP、查文档、查手册，再去理解飞书的页面结构、知识库结构、权限限制、评论方式、更新方式和 API 返回格式。对 AI 来说，这些系统更像一个外部黑盒。它需要通过工具调用一点点探索，在日常使用中也更容易因为权限、格式、接口和上下文不足而出错，效率也会更低。

还有一层更硬的优势：Git 本身的接口极其稳定。命令行、文件树、diff、blame 的语义几十年没变。富 UI 文档系统的界面和 API 一年改十次，外部工具和 MCP 都在追着打补丁；而 Git 不需要追。对依赖工具长期可靠运行的 AI Agent 来说，这种稳定性是基础设施级的优势。

所以 Git / GitHub 不是 AI 唯一能用的工具，但它是 AI 模型最熟悉、最标准化、最容易理解的协作范式之一。把公司知识放到这种结构里，相当于让 AI 用它已经很熟悉的方式来管理知识，而不是让它不断适配一个个私有文档系统。

3. 本地仓库能让 AI 获得完整上下文

GitHub / Git 还有一个很关键的优势：仓库可以完整同步到本地。

这对 AI Agent 非常重要。如果知识存在飞书、Confluence 这类云文档系统里，AI 往往只能通过搜索接口、MCP 工具、API 分页、HTML 或富文本解析，一点点获取内容。它看到的是一段段查询结果，而不是完整的知识库。每一次搜索、阅读和编辑，都要依赖工具调用，也容易被权限、接口和搜索质量限制。

现在的 AI Agent 编程就是一个很好的例子。做 AI 编程时，我们一定希望代码库在本地。哪怕是很大规模的项目，只要经过本地索引、结构整理和上下文编排，AI Agent 对项目内容的掌握率也会非常高。我们很难想象一个大型程序项目的代码和文件是分散在飞书文档里的：每一次查询都要调用飞书接口，每一次阅读都要靠搜索结果，每一次修改都要跨过文档系统的权限和格式限制。那样的效率会非常低。

代码是这样，公司知识也是一样。

如果未来 AI Agent 要真正理解和维护公司的工作日志、项目复盘、产品思考、技术方案和决策记录，它也需要面对一个完整、本地、结构清晰的知识库。Git 仓库可以让 Agent 看目录结构、搜索所有文件、建立索引、查看历史、比较 diff、发现重复和冲突，并且直接提出修改。

这不是简单的「搜索文档」，而是让 AI 能够理解整个知识空间。

本地化还带来一个常被忽视的好处：所有 AI Agent 都可以同时使用同一份知识，互不冲突。今天用 Claude Code 整理一篇日志，明天用 Codex 跑分析，Cursor 同时直接编辑同一个仓库——所有 Agent 读的是同一份本地文件，没有谁占着接口、谁需要重接 MCP 的问题，多个 Agent 也可以并行工作而不互相干扰。这不是「从一个 Agent 迁到另一个 Agent」的问题，而是「所有 Agent 同时共用同一份知识」。绑在飞书或 Notion 里的内容做不到这点。

4. GitHub 是原始信息层，不是最终展示层

我并不认为 GitHub 要成为最好的文档编辑器，也不认为所有人以后都要直接打开 GitHub 看文档。

更合理的理解是：GitHub 负责保存最原始、最干净、最容易被工具读取、最容易追溯的信息。至于大家用什么工具来编辑、阅读和展示，并不需要统一。

这也是为什么 GitHub 里的知识通常是 Markdown、YAML、JSON、MDX 这类结构化文本。它们不一定是人类最舒服的最终阅读形态，但作为底层信息源非常合适——相比复杂富文本、HTML、页面 block 和编辑器状态，它们更容易被搜索、切片、引用、压缩、总结、重组和转换。对 AI 来说，底层信息越干净，理解和使用效率越高，token 的浪费也越少。人不一定要直接写 Markdown，Agent 可以帮人整理成合适的格式。

有人可以用 Obsidian 阅读和整理，有人可以用 Codex 或 Claude Code 让 Agent 修改，用 Slack bot 分发更新，用 AI Agent 生成摘要、PPT、交互 demo 甚至最终产品。

GitHub 不是替代所有工具，而是让所有工具围绕同一份可信原始数据协作。只要底层信息准确、清晰、可追溯，展示层就可以根据不同人、不同场景、不同需求灵活生成。

5. 文档和代码的边界会变得越来越模糊

还有一个更长期的变化是：随着 AI Agent 的能力提升，代码和文档之间的边界会越来越不清晰。

过去，写文档和写代码是两件完全不同的事。文档是给人看的，代码是给程序运行的。背后的原因并不只是工具不同，更重要的是人的能力和分工有边界：程序员和非程序员长期以来是两种完全不同的职业，能写想法的人不一定能把想法变成工具，能写代码的人也未必最理解业务和需求。

但在 AI Agent 时代，这个边界会被逐渐打破。很多时候，一个人不需要自己会写代码，也可以通过自然语言让 Agent 修改脚本、调整工具、生成 demo，甚至把一个文档里的想法直接变成一个可以运行的原型。

对 AI Agent 来说，完成一件事所需要的上下文，本来也不应该被人为拆成「文档在一个地方、代码在另一个地方」。文档、代码、配置、Prompt、脚本、Demo、数据结构，往往都是同一个任务的不同表达。如果它们放在同一个仓库或相近的上下文里，Agent 就更容易理解目标、修改实现、更新说明，并保持内容一致。

这也意味着，公司内部未来会有越来越多的工具以类似开源项目的方式存在。大家不只是可以提意见，也可以在自己的本地环境里直接尝试修改这些工具，再把有价值的改进提交回来。

这背后其实是一种更直接的协作文化：

Talk is cheap, show me the code.

这里的「code」不一定只是传统意义上的程序代码，也可以是文档、配置、Prompt、脚本、Demo、数据结构，或者任何能被 Agent 理解和执行的原始信息。

Lizi 最近在做的 XD Maker，应该就是我们在这个方向上的一个尝试：让更多人不只是描述想法，而是可以更直接地把想法推进成可运行、可修改、可协作的东西。

从这个角度看，GitHub 不只是文档存储工具，而是一个同时容纳文档、代码、Prompt、Demo 和工具的协作环境。它适合承载这种边界逐渐模糊的新工作方式。

6. 权限和安全会有代价，也需要新的治理方式

这个选择也不是没有代价。

传统云文档系统有一些中心化管理能力。例如文档都存在云端，平台可以记录谁读了哪篇文档、读了多少、什么时候读的；一些系统还可以检测某人短时间大量读取内容，并触发安全警告。

如果知识通过 Git 仓库本地化，这类能力会变弱。因为仓库一旦被 clone 到本地，内容就已经在本地了。之后用户或本地 AI Agent 如何读取、读取多少、建立什么索引，中心化平台未必都能知道。

这是我们需要明确承认的代价。

但换来的价值也很大：本地 AI 可以更高效地获得完整知识，不需要每次都通过查询接口一点点调用；可以建立自己的索引；可以更低延迟、更低成本地检索和整理；也可以获得更完整的上下文。

这个取舍是否值得，取决于我们如何设计治理方式。我的判断是，这个代价是值得的，但前提是我们要更清楚地设计边界：公开知识、部门知识、项目知识、高敏知识要分仓库管理；高敏内容不进入普通可 clone 的仓库；Agent 写入要按风险分级 review；公司正式知识要有 owner；重要内容要通过 PR、review 或 approve 进入主线。

AI Agent 时代也会提高对同事专业性和责任感的要求。大家需要更自觉、更专业地为自己能访问的数据负责。

7. 这是逐步演进，不是替代所有日常工具

选择 GitHub 作为知识底座，不强求大家立刻改变日常工具。但当一段信息开始有长期价值、需要复用、需要被 AI 理解时，它就应该落到 GitHub。GitHub 可以逐步成为每个人自己的 AI Agent 的本地信息检索入口，Agent 从这里出发，再连接到 Slack、飞书等各种第三方系统和工具，反之亦是如此。

所以这不是一次性替换，而是一个逐步向 AI Native 方式演进的过程。

最终，我希望建立的不是另一个文档系统，而是一种新的公司知识协作方式：重要知识不再散落，大家可以更容易贡献，正式内容有清晰边界，AI Agent 能够高效参与，公司也能逐步形成更可维护、更可复用的共同知识。