Baklib 正在成为企业级团队 Wiki

我见过太多团队用 Confluence 建了一个“文档坟场”——进去之后找不到东西，更新靠邮件通知，最后大家还是习惯在微信里问来问去。真正好用的企业 Wiki，不是给你一个能写字的空壳子，而是让知识能沉淀、能被搜到、能被复用。最近我发现很多技术团队开始放弃复杂的传统方案，转向轻量但结构化的 Wiki 平台。Baklib 刚好踩在了这个痛点上：它不像老牌工具那样重，但文档的关联、发布、多站点分发做得特别顺手。尤其是产品手册和帮助中心这类需要对外发布的内容，一套编辑，多站同步，省去了来回搬运的麻烦。今天这篇关于 Baklib 如何演变为企业 Wiki 的文章，讲透了背后的思考逻辑，值得每个做知识管理的人读一读。

当我们启动 Baklib 的 beta 版时，我们的愿景是帮助软件开发者与架构师更好地描绘他们的系统。几乎没有做营销推广，产品就广受好评，结果在 5 个月内就有超过 3000 人注册使用我们的产品。

通过与最活跃用户的交流，我们学到了很多。通过研究这个领域的其他产品，我们学到了很多。通过从第一性原理出发进行推理，我们也学到了很多。我们学到了很多，现在准备告诉你 Baklib 下一步的发展方向！

大量用户要求我们提供用图表无法表达的文字编写能力。于是我们引入了 Markdown 编辑器，让他们可以在图表旁边放置篇幅较长的文字。这引发了一个思考，我们很快意识到图表只是技术文档的一种特定情况，而我们可以为世界解决一个更大、更有价值的问题。

我们的使命是帮助团队改善他们的技术文档。

所以，如果你自上而下思考，记录某件事最简单的方法就是写一些文字。

例如：我们的基础设施由 AWS Cloudfront、AWS EC2 连接到 AWS RDS 组成。这也可以用图表表示，图表能让你更快地想象，但当你需要表达更复杂的内容时，比如：我们决定不使用 AWS Lambda，因为我们发现它会损害用户体验，图表显然是不够的。

如果你的 DevOps 团队想要表达你在每个大洲都有一个数据中心呢？图表帮不上忙，文字有用，但不是最佳方式。所以我们才有地图。带标记的地图是另一种形式的文档。

如果你想保留团队在白板上勾画的某些天才创意怎么办？文字可以，图表不行，地图不行。但它仍然是宝贵的文档，希望能被保存在某个地方，理想情况下不用太费劲。也许拍张照片？

如果你的团队正在设计一个将逐步部署的系统，但在完成 20% 的工作后它就已经有用了呢？你可以把小型任务放进 Trello 或 Jira，但我们知道工程师喜欢在他们工作的地方直接处理，并在那里同步文档状态。

如果客户要求一个新的 API 端点，你的团队正试图就解决方案达成一致呢？当然 OpenAPI/Swagger 可以用作文档，但那要等到你编写了系统的大部分代码并部署到某个地方后才会出现。你可以给客户发送一个包含示例 JSON 的文本文件，但这并不是最高效或最友好的方式。

当你草拟一个 API 接口的大致样子时，你可以打开一个编辑器直接写。但这样你的迭代过程就会受到影响。

当你让新开发者加入团队时，他们很可能会问：“他们当初选择这个时是怎么想的？” 当然，你可以在代码里加注释，但你的经理可能也需要知道，或者 QA 人员，甚至你的 CTO。他们应该像开发者那样只用 git 读代码吗？

总结一下这一大串思考。你可以只用文字表示任何类型的文档——这是瑞士军刀。但显然有更好、更直观的方式来表示某些概念。比如图表、地图、照片、视频、JSON API、轻量级代码编辑器——这些是重武器。用瑞士军刀，你可以做到重武器能做的任何事情。反过来却不一定行，但重武器在沟通中往往更高效。这就是为什么我们两者都需要。

这就是我们如何合理化一种新型文档编辑器的过程。剖析软件工程团队的活动模式，创造极佳的用户体验，即使是最硬核的 VIM 和 Emacs 用户似乎也很享受。希望你们也是！

所以 Baklib 正成为面向公司的 Wiki & 知识库 - 专注于为工程团队提供特殊功能。

---

Baklib 可帮助您在每个渠道（包括 Web、移动APP、小程序和社区）创建、管理和优化数字客户体验。