技能介绍

问题：团队知识库要么太简陋，要么被锁定

很多团队维护文档的方式停留在「一个 Git 仓库 + 一堆 Markdown 文件」，靠手工写目录、手工管权限、手工合并冲突。时间一长，目录结构混乱、版本对不上、谁能看谁能改全靠口头约定。另一边，成熟的商业维基系统要么按席位收费，要么把你的内容锁在它的服务里，迁移成本高得离谱。Wiki.js 这个基于 Node.js 的技能要解决的正是这个夹缝：把版本化的 Markdown 内容当一等公民，同时给工程师熟悉的扩展空间。

核心能力与工作方式

Wiki.js 运行在 Node.js 之上，工作流围绕三个环节展开：

内容创作：支持 Markdown 源码与可视化编辑器，作者可以按自己习惯选择，不必为排版工具付费。
存储与版本：内容以 Git 为后端存储，每一次修改都落在 Git 仓库里。这意味着历史记录、分支、回滚都是 Git 的原生能力，不依赖平台私有格式。
对外集成：通过 GraphQL API 暴露内容访问能力，上层可以自建前端或接入自动化脚本；内置多语言内容管理，同一篇文档可以维护多个语言版本；访问控制细化到具体页面和角色，并能对接主流身份认证提供商，权限模型不用从头造轮子。

典型使用路径是：初始化一个 Git 仓库 → 配置认证提供商 → 按团队结构建群组和权限 → 通过 Web 界面或 API 写文档。

适用边界与注意点

需要留意的是，这份资料没有给出可自动提取的安装与使用说明，规范里明确建议在敏感流程中运行前先审查上游项目。也就是说，它更适合愿意花时间读源码、自己确认依赖与配置的工程师团队，而不是开箱即用的托管服务。另外，Git 存储意味着备份策略要自己规划——仓库安全、私钥管理、分支保护这些运维责任并没有被外包出去。