9 月 18 日，ClewWiki 还没有发布过任何版本。我写页面 claim 那篇文章的时候，还没有镜像，也没有 npm 包，只能从源码构建。十七天之后，0.9.0 发布了。这是连续的第十个 tag，镜像已经在 GHCR 上，MCP 服务器用 npx 就能装好。
这篇文章写给正在为团队挑选 wiki、又希望把它放在自己基础设施上的人。这里不谈 agent，也不谈 MCP，它们有单独的一篇。这里只讲人需要的东西：怎么部署，怎么把同事拉进来，怎么迁移已有页面，以及这个项目和那些用了很多年的工具相比还弱在哪里。
部署需要什么#
带 Compose 插件的 Docker、git 和 openssl。就这些。不需要 Redis，不需要邮件服务器，也不需要第三方登录服务商的账号。整个技术栈就是应用本身加 PostgreSQL 16。
git clone https://github.com/Dodecaidr/clewwiki.git
cd clewwiki
cp .env.example .env && chmod 600 .env
sed -i "s|^POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=$(openssl rand -hex 32)|" .env
sed -i "s|^BETTER_AUTH_SECRET=.*|BETTER_AUTH_SECRET=$(openssl rand -base64 48)|" .env
docker compose up -d
docker compose logs web | grep "setup token"在 macOS 上要把 sed -i 写成 sed -i ''。然后打开 http://localhost:3000，填入日志里的 setup token，创建第一个管理员。没有默认密码，所以也没什么可猜的。
在服务器上还需要两样东西：把 BETTER_AUTH_URL 设成公开的 https:// 地址，以及在应用前面放一个反向代理。应用说的是普通 HTTP，端口只发布在 127.0.0.1 上，所以 TLS 由你负责。docs/deploy.md 里有 Caddy、Traefik 和 nginx 的示例。
依赖少是有意为之。小团队里，搭 wiki 的往往是一个既没时间也没兴趣维护四个服务的人。每多一个容器，周六就多一样可能宕掉的东西。
没有邮件服务器，怎么把人拉进来#
没有开放注册。一个人进入 wiki 只有三条路。
邀请链接。 管理员在 Members 里填好地址和角色，拿到一条链接。它只显示一次，只能用一次，有效期七天。系统不发邮件：链接由你自己交给对方，发消息或当面都行。所以没有 SMTP 的实例同样是完整的。数据库里只保存链接的哈希。
加入申请。 如果管理员开启了这个功能，登录页会出现 Ask to join。申请人留下姓名、地址、密码和一段说明，在管理员以某个具体角色批准或拒绝之前，只能看到“等待审批”。没有人能自己放自己进来。每个客户端地址每小时最多五次申请。
通过 OpenID Connect 单点登录。 只要三个变量（OIDC_ISSUER、OIDC_CLIENT_ID、OIDC_CLIENT_SECRET），登录页上就会出现一个按钮。密码登录照常可用，所以身份提供方宕机时管理员不会被关在门外。身份提供方决定一个人是谁，而不决定能不能进：没有 email_verified 的资料会被拒绝，OIDC_ALLOWED_EMAIL_DOMAINS 可以按域名收窄范围，而在你显式开启 OIDC_SIGN_UP 之前，成员资格始终由管理员决定。
角色有三种。管理员管理成员、agent 令牌和空间。编辑者编写页面、参与讨论、审阅 agent 的修改。0.6 加入的 viewer 是给 wiki 的读者用的：产品经理、测试工程师、客户方的工程师。viewer 能读到自己可见的一切（页面、讨论、历史、搜索、导出），但什么都改不了。这条限制和只读 agent 令牌放在同一个地方：需要更多权限的请求会得到 403。最后一个管理员既不能被降级，也不能被移除。
以前忘记密码只能把人删掉再重新邀请，结果是一个新账号。现在管理员可以生成重置链接：一次性、24 小时有效、以哈希保存，使用后会结束该账号的所有会话。
一台服务器上的多个团队#
0.8 加入了组织。一个实例可以容纳多个组织，每个组织都有自己的成员、空间、agent 令牌、管理员和设置。一个账号可以属于多个组织，用 logo 旁边的菜单切换；每个组织都有自己的入口 /o/<地址>。
组织内部按项目划分空间，也可以有受限空间，只有其成员能看到。把某人从一个组织移除后，他的账号和在其他组织中的成员资格都会保留。
对于同时为多个客户维护文档的工作室或外包团队，这正是以前只能给每个客户单独搭一套 wiki 的场景。
迁移已经写好的内容#
没人会选一个搬不进去的 wiki。导入 ClewWiki 总要经过一个中间步骤：你能看到将要生成的页面树、每个页面的路径、它的 Markdown，以及哪些内容没能转换的说明。在你按下按钮之前，什么都不会创建。
可以从这些地方迁移：
- Confluence 空间：Cloud 通过 REST API v2，自建的 Server 或 Data Center 通过 v1。层级、标题、列表、表格、带语言标注的代码块、信息面板、折叠块、导入页面之间的链接和图片都会迁移过来。开启文件功能后，附件也会连同历史版本、日期和备注一起迁移。
- Notion 导出和 Markdown 归档，包括页面所链接的图片和文件。
- 最大 200 MB 的 PDF。
出口同样宽敞：页面可以导出为 Markdown 或 HTML，空间可以导出为 ZIP，需要时连同文件一起。页面以 Markdown 存储，所以离开 ClewWiki 就是下载一个归档。
这里的限制很重要，我直接说清楚。Confluence 的评论、标签、权限和页面历史不会被读取。没有 Markdown 对应物的宏（Jira 列表、页面树、包含、图表）会变成一条写着其名称的可见说明，而不是可用的内容。从 Server 和 Data Center 导入已经在一个真实的公开实例和测试数据上验证过，但背后没有多年的使用经验。如果你的 wiki 依赖宏和 Marketplace，迁移不会轻松，仓库里的 docs/compare.md 也是这么写的。
为什么现在要谈这个：Atlassian 将在 2029 年 3 月 28 日终止 Data Center，此后这类部署变为只读；从 2026 年春天起就已经不再向新客户出售。那些出于安全或法规原因把 wiki 留在内部的团队，原因依然存在。离开的是产品。
文件就放在文档旁边#
从 0.7 开始，页面可以附带任意类型的文件：构建产物、安装包、规格说明。这个设计参考的是团队实际发布版本的方式。
上传一个与页面已有文件同名的文件，就会在同一个链接后面生成下一个版本。链接总是返回最新版本，所以你可以把它贴进 release notes 一次，然后再也不用管；?version=3 可以固定到某个具体版本。第二次上传相同的字节不会新增任何东西。Restore 会把旧版本作为新版本追加，使其成为最新，因此别人下载过的版本永远不会改变。
关注了页面或空间的人，会在收件箱里看到新版本。文件存放在本地磁盘或任意兼容 S3 的存储桶中。构建流水线用一条命令就能发布文件：
curl -fsS -X PUT --data-binary @dist/app-2.4.1.apk \
-H "Authorization: Bearer $CLEWWIKI_TOKEN" \
"https://wiki.example.com/api/v1/pages/$PAGE_ID/files/app-2.4.1.apk?note=Signed%20build"令牌只需要 pages:write 这一个 scope。重复同一个请求会返回 200 而不是 201，也不会创建新版本，所以 CI 里的重试是安全的。
页面里的工单和表格#
在 0.8 里，wiki 学会了向外看。
工单系统。 YouTrack、Jira，以及任何使用 KEY-123 形式键值的系统。组织管理员填写地址、项目键，以及存放只读令牌的环境变量名。令牌本身不会进入数据库。此后，正文里的工单键会变成链接，页面会列出其中提到的工单及其状态和负责人。在编辑器里，可以把一个工单连同描述和评论整条插入，也可以按 YouTrack 查询或 JQL 插入一张工单表。
有一点我不打算隐瞒：YouTrack 和 Jira 的客户端只在录制的 API 响应上测试过，还没有在真实实例上跑过。如果你有测试项目，非常欢迎反馈。
表格。 Import table or document 对话框接受 Excel 工作簿（.xlsx）、CSV 和 TSV，包括俄语或德语版 Excel 保存的分号分隔文件，并把各个工作表作为表格插入。单元格按显示的样子迁移：公式取其结果，日期仍是日期，隐藏的工作表会被跳过。以“知道链接的任何人”共享的 Google 表格或 Google 文档链接同样可用。反过来，含有表格的页面可以导出为 .xlsx：每个表格一张工作表，名称取自其上方的标题，表头加粗并冻结。这些全部由项目自己的代码实现，没有使用表格库。旧的二进制 .xls 无法读取。
团队在哪里看到要发布什么#
10 月 5 日发布的 0.9.0 给每个空间加了一个 Development 栏目。它回答的是小团队每次开会都要问的问题：“这个已经进发布了吗？”
这个栏目读取与空间关联的 git 仓库，为每个分支维护一条工作线：最近一次提交、相对默认分支领先和落后多少、是否已合并、是否已删除。每条工作线都挂着目标、带状态的工单、一个文档页面，以及“问题”，也就是关于阻碍因素的讨论。问题解决后，决定会以页面形式写进这条工作线的文档。
我觉得最有用的是已合并但未发布的高亮列表：已经进入默认分支、却没有被任何计划中的发布收录的改动。日后冒出“那个我们到底发没发？”的，正是这类东西。只要发布里还有未合并的工作线，它就拒绝被标记为已发布。你仍然可以强行发布，但这件事会连同被落下的内容一起记入审计日志。
还没有的东西#
一份诚实的清单，和 README 里的一样：
- SAML 和 LDAP。 单点登录只支持 OpenID Connect，没有目录同步。
- 移动应用。 Web 界面在手机上可以用，但没有原生客户端。
- 生产环境的年头。 第一个 tag 是 2026 年 9 月 18 日。
docs/compare.md里的其他工具有三年到二十多年的历史。0.x 版本之间的数据库迁移目前还很频繁，升级前备份数据库不是走形式。 - 背后的社区或公司。 这是一个作者一个人的开源项目。如果你需要带 SLA 的供应商，现在的 ClewWiki 不适合你。
作为交换，你得到的是：AGPL-3.0 下的唯一版本，上面列出的一切都免费，没有藏在按席位收费的套餐后面；一条命令就能拉起的技术栈。界面支持英语和俄语。
从哪里开始#
用上面的命令在笔记本上起一个实例，导入一个小空间，看看中间那一步的界面。十分钟就能知道你的 wiki 是能搬过来，还是会撞上宏的墙。代码、文档和工单都在 GitHub 仓库里，项目概览在 ClewWiki 页面。
如果你的团队已经或即将把 AI agent 接入 wiki，下一篇文章讲的是它们在 0.9 里能得到什么。
