MrDoc v1.1.0 面向需要私有化部署的团队提供了一种直接选择：以文档为核心，在自己的基础设施上管理知识，并通过浏览器覆盖桌面端与移动端。它基于 Python 和 Django 开发并开源，支持 Markdown 与富文本，产品形态接近语雀、看云、为知笔记、飞书文档和 GitBook。
版本标题将其定位为“AI 知识库系统”，但现有摘要没有列出具体 AI 模型、检索链路或接口。因此，部署前应把两个问题分开评估：一是文档系统能否稳定承载团队知识，二是 AI 能力是否满足模型接入、权限隔离和数据合规要求。
文档优先，而不是文件优先
很多内部资料最初散落在 Word 文件、聊天记录、代码仓库和个人笔记中。文件服务器只能保存这些内容，却很难建立持续维护的知识结构。MrDoc 以“文档”为主要承载形式，更适合形成项目、目录、文档之间的组织关系。
Markdown 适合研发和运维团队：内容可以复制到代码仓库，代码块、命令和配置也容易维护。富文本则降低了产品、运营和行政人员的编辑门槛。两种编辑方式并存，意味着团队不必为了统一工具而强迫所有成员改变写作习惯。
跨终端也不等于为每个平台维护一个独立客户端。基于 Web 的系统通常只需要统一升级服务端，用户即可从不同设备访问同一份内容。真正需要验证的是移动端编辑体验、附件上传、表格展示和长文档导航，而不能只检查首页是否能打开。
私有部署的价值在数据边界
私有部署最明显的收益是控制数据存储位置。研发设计、客户交付材料、内部制度和事故复盘不必默认进入第三方 SaaS。团队还可以把访问入口放在 VPN、零信任网关或内网反向代理之后，并沿用现有的备份、监控和审计体系。
但“部署在内网”不自动等于安全。至少要明确以下边界：
- 数据库、上传附件和应用配置分别存放在哪里。
- 文档权限能否覆盖项目、目录及单篇文档等实际场景。
- AI 功能是否会把正文发送到外部模型服务。
- 删除文档后，数据库、附件和备份中的数据如何过期。
- 升级失败时，是否可以同时回滚应用代码与数据库。
如果接入外部大模型，还要把模型供应商视为新的数据处理方。敏感知识库可以采用本地模型，或者在发送请求前实施脱敏、分类和权限检查。仅仅隐藏模型 API Key，无法解决正文外发带来的合规问题。
可以这样搭建 Django 生产运行骨架
下面是一个可改造的生产部署示例，而不是对 MrDoc 官方配置项的复述。假设你已经取得项目源码，并确认其中存在 manage.py 和可安装的依赖文件。镜像启动命令、静态文件策略以及环境变量名称需要按实际仓库调整。
先在源码根目录创建 Dockerfile：
FROM python:3.11-slim
ENV PYTHONDONTWRITEBYTECODE=1 \
PYTHONUNBUFFERED=1
WORKDIR /app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt \
&& pip install --no-cache-dir gunicorn
COPY . .
RUN python manage.py collectstatic --noinput
EXPOSE 8000
CMD ["gunicorn", "MrDoc.wsgi:application", "--bind", "0.0.0.0:8000", "--workers", "3", "--timeout", "120"]
其中 MrDoc.wsgi:application 是示例模块路径。运行前应查看项目中的 wsgi.py，将它替换为真实的 Python 包名。接着可以用 Compose 管理应用与 PostgreSQL：
services:
db:
image: postgres:16-alpine
restart: unless-stopped
environment:
POSTGRES_DB: mrdoc
POSTGRES_USER: mrdoc
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- db_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U mrdoc -d mrdoc"]
interval: 10s
timeout: 5s
retries: 5
web:
build: .
restart: unless-stopped
depends_on:
db:
condition: service_healthy
environment:
DJANGO_SETTINGS_MODULE: ${DJANGO_SETTINGS_MODULE}
DATABASE_URL: postgresql://mrdoc:${POSTGRES_PASSWORD}@db:5432/mrdoc
SECRET_KEY: ${SECRET_KEY}
ports:
- "127.0.0.1:8000:8000"
volumes:
- media_data:/app/media
volumes:
db_data:
media_data:
再创建 .env，不要把它提交到版本库：
POSTGRES_PASSWORD=replace-with-a-long-random-password
SECRET_KEY=replace-with-at-least-50-random-characters
DJANGO_SETTINGS_MODULE=MrDoc.settings
确认变量名与项目配置一致后，执行：
docker compose build
docker compose run --rm web python manage.py migrate
docker compose run --rm web python manage.py createsuperuser
docker compose up -d
docker compose ps
示例只把服务绑定到本机 127.0.0.1:8000，生产环境应在前面配置 Nginx、Caddy 或企业网关，统一处理 HTTPS、访问控制和上传大小限制。不要直接把 Django 或 Gunicorn 端口暴露到公网。
上线前不要省略恢复演练
知识库的关键资产不只是数据库。图片、附件、导出文件以及可能存在的搜索索引都要纳入备份范围。可以每天导出 PostgreSQL，并对附件卷执行文件级备份：
mkdir -p backups
docker compose exec -T db \
pg_dump -U mrdoc -d mrdoc -Fc \
> "backups/mrdoc-$(date +%F).dump"
docker run --rm \
-v mrdoc_media_data:/data:ro \
-v "$PWD/backups:/backup" \
alpine:3.20 \
tar -czf "/backup/media-$(date +%F).tar.gz" -C /data .
Compose 创建的卷名可能带有项目名前缀，可以先运行 docker volume ls 确认真实名称。备份完成并不代表数据可恢复；至少应在隔离环境中定期执行一次数据库还原和附件解压，检查文档、图片及权限关系是否完整。
采用建议：先验证知识流，再扩展 AI
对小团队而言，可以先选一个边界清晰的知识域试运行，例如运维手册、产品规范或客户交付文档。迁移一批 Markdown 与富文本内容，验证搜索、权限、附件、移动端阅读和备份恢复，再决定是否扩大范围。
上线检查可以压缩为六项：确认许可证与版本升级路径；使用独立数据库和持久化附件卷；通过 HTTPS 或内网网关访问；关闭调试模式并妥善保存密钥；实际演练恢复流程；核对 AI 请求是否离开私有网络。
MrDoc 的吸引力不只在于“能部署”，而在于团队可以把文档组织方式、运行环境和数据边界掌握在自己手中。代价也很明确：补丁、数据库、备份、监控和权限治理都将成为内部责任。先把这些基础能力做稳，再接入问答、摘要或检索增强生成，知识库才不会变成一个只有演示效果、缺乏运维保障的 AI 入口。