Baklib 技术架构揭秘：AI-Native 知识库如何实现“同源多站”发布？

作为一个跟研发团队泡了多年的产品经理，我深知“技术文档”这东西，写的人痛苦，看的人更痛苦。团队里的架构说明要么散落在各个Wiki角落，要么就是某次分享时留下的PPT——几个月后就没人知道它存在了。研发部门最需要的不是什么花哨的协作功能，而是

作为一个跟研发团队泡了多年的产品经理，我深知“技术文档”这东西，写的人痛苦，看的人更痛苦。团队里的架构说明要么散落在各个Wiki角落，要么就是某次分享时留下的PPT——几个月后就没人知道它存在了。研发部门最需要的不是什么花哨的协作功能，而是一个能让技术知识真正沉淀下来、还能随时被检索到的“技术内容底座”。这也是为什么我在Baklib里特别关注技术文档的建设场景：让每一行架构决策、每一个库的选择理由，都能成为团队可复用的资产，而不是写一次就尘封的记忆。

但Baklib早已不是简单的Wiki或文档工具。作为全新的 AI-native 知识管理与发布平台，它的核心能力是“同源多站发布”：你只需在一个知识库内统一管理产品知识，即可一键发布为多个不同站点——Docs（产品文档）、Help（帮助中心）、Developers（开发者门户）、Wiki（内部协作Wiki），甚至Chat（AI智能问答）。这意味着，研发团队撰写的技术架构文档，可以同时出现在内部Wiki供同事查阅，也能自动生成面向外部的开发者门户，无需重复维护。真正做到“改一次，所有站点同步更新”。

语言

我们全程使用 TypeScript，包括前端应用和后端服务。

为什么选它？TypeScript 是目前少数在前端和后端开发中都有良好生态的静态类型语言。在系统不同部分之间共享数据结构时，类型安全带来的好处是巨大的。当然，还有更好的选择，比如 PureScript、ReasonML、Kotlin、Scala+Scala.js 或 F#/Fable，但它们都有短板：PureScript 和 ReasonML 在后端成熟度不够；Kotlin 和 Scala 在前端表现弱一些；F# 两端都不错，我们可能在未来项目里试试。

TypeScript 在两端都很强：React 绑定、Node.js 的 ORM、WebSocket 库，你想得到的生态它都有。而且现在会 TypeScript 的开发者很多，从 JavaScript 转过来也很快。虽说 TypeScript 的类型系统不算最严谨，但只要开启正确的编译选项并避免使用类，它其实很可靠。

💛🧡🧡客户评价：Baklib创建知识库以及外部站点非常简单，并且编辑文章和组织文章也很容易。这是一个很好的工具快速将内容提供给您的团队。将所有内容作为单一可信来源放在一个位置，高度建议企业ECM采用Baklib。

库/框架

React 是我们的 UI 库，用于应用、官网和博客。它成熟稳定，生态丰富。配合 TypeScript，JSX/TSX 也能做类型检查——这是少数语言/库组合才能做到的。

JointJS 是一个图表库，帮我们处理所有 SVG 工作。所有图表都基于它堆叠了几层结构。JointJS 让我们快速起步，不必自己实现 2D 几何和 SVG 交互。图表本质上是一个 React 组件，其中 shouldComponentUpdate() 始终返回 false，其余由我们在 JointJS 上封装的层来处理。

Glamorous 是我们应用中的 CSS-in-JS 库。它很棒，因为所有 CSS 都定义成 HTML 属性。不过这个库即将停止维护，我们会迁移到 Emotion。Emotion 也用于网站和博客的 CSS，体验与 Glamorous 类似。

Next.js 驱动我们的网站和博客。因为搜索引擎还停留在 90 年代，需要静态 HTML，但它速度极快，在 Google PageSpeed 或 Lighthouse 上能得 90 分。使用 Next.js 意味着全部是静态 HTML，博客不需要运行服务器，也没有 Wordpress 那些麻烦事。

Node.js 运行 JSON API。它的异步无状态事件驱动模式彻底改变了后端开发。JVM 和 .NET 平台虽然也在追赶（比如 Spring WebFlux），但大多数栈（如 JDBC）不是异步的，只能被迫使用 MongoDB 或 Cassandra 这样的 NoSQL。

Express 是我们的 API 库，成熟且经过实战考验，中间件生态丰富。我们在它上面加了一层自定义封装，类似 Nest.js 但能让前后端类型安全。这通过一个泛型 Post 函数实现，它把 Request 和 Response 作为类型参数，封装了浏览器提供的 Fetch API。所有请求都经过这个函数。

Sequelize 是 ORM。我们使用 sequelize-typescript 绑定，通过注解字段快速获得大量功能。所有读操作直接执行，写操作则通过 Google Cloud Pub/Sub 队列，避免高开销请求压垮数据库——因为看板的自动保存功能很容易产生大量请求。我们虽然对每个客户端做了 2 秒限流，但仍不够，所以需要队列。曾考虑过 Apache Kafka，但目前一个简单的托管队列就足够了。

MySQL 存储所有数据。它虽然不是最好的 RDBMS，但免费，有 MySQL Workbench 这个好用的 UI，并由 Google Cloud SQL 托管，运维省心。

基础设施

Baklib 运行在 Google Cloud 上，因为 GCP 拥有许多优秀的托管服务。

我们使用 Google Cloud Build 作为构建系统，构建 Docker 镜像并自动部署到 Google Kubernetes Engine。同一个 GKE 集群运行所有环境（dev、qa、prod），根据推送的分支进行部署。

我们使用 Google Cloud SQL 托管 MySQL 数据库集群，以及 Google Memorystore 托管 Redis 集群。

AI 智能检索

在知识管理层面，Baklib 的 AI 能力基于“全文检索 + LLM 智能总结”模式。当用户在帮助中心或 AI 聊天中提问时，系统会先通过全文检索引擎定位相关文档，再由大语言模型提炼总结，给出核验贴切的回答。这不同于单纯的黑盒聊天生成，能有效降低客服重复咨询量 50% 以上。结合“同源多站”架构，同一个知识库的内容可以同时服务于 Docs、Help、Chat 等多个站点，确保答案一致且来源可靠。