MrDoc v1.1.1 面向需要私有化知识管理的团队与企业。它用“文集 + 文档”组织知识，支持 Markdown、富文本、Office 文档、表格和图表等内容形态，并通过权限与协作能力，把聊天记录、个人笔记和散落文件转化为可管理、可复用的组织资产。
来源摘要没有给出 v1.1.1 的逐项变更日志，因此本文不推断具体新增接口或部署参数，而是聚焦这个版本所代表的使用方向：如何围绕 MrDoc 建立一套真正可落地的内部知识库，并为 AI 检索与问答准备可靠的数据基础。
“文集 + 文档”不只是目录结构
很多知识库失败，并不是因为编辑器不好用，而是因为内容没有明确边界。文档全部堆在同一个空间里，半年后就会出现重复方案、过期规范和无人负责的页面。
MrDoc 的“文集 + 文档”模型适合映射真实业务边界。例如，可以按下面的方式规划：
| 文集 | 典型内容 | 建议负责人 |
|---|---|---|
| 研发规范 | 编码规范、发布流程、故障处理手册 | 研发效能团队 |
| 产品知识 | 需求说明、功能边界、版本记录 | 产品负责人 |
| 客户支持 | 常见问题、排障步骤、服务话术 | 支持团队 |
| 企业制度 | 入职流程、安全制度、报销规范 | HR 或行政团队 |
文集最好代表一个长期存在的知识域，而不是一次性的项目阶段。文档则承担具体主题，并至少包含负责人、适用范围、更新时间和状态等信息。即使系统没有强制这些字段，也可以在团队模板中约定：
# 服务发布检查清单
- 负责人：平台工程组
- 适用范围：生产环境 Web 服务
- 最近复核：2025-03-01
- 状态：有效
## 发布前
- [ ] 数据库变更已完成评审
- [ ] 回滚脚本已验证
- [ ] 监控告警已配置
## 发布后
- [ ] 核心接口探测正常
- [ ] 错误率没有明显上升
- [ ] 发布记录已归档
这种模板比单纯增加目录更有价值，因为后续无论是人工搜索还是 AI 问答，都需要判断内容是否仍然可信。
多种内容形态解决“能不能迁入”，权限决定“敢不敢迁入”
团队的知识不会只存在于 Markdown 中。产品部门可能使用 Office 文档，运营团队依赖表格，架构讨论又需要图表。MrDoc 支持多种内容形态，降低了迁移门槛，也避免为了统一格式而损失原有表达能力。
但私有知识库能否真正投入使用，关键还在权限设计。建议不要逐篇文档临时授权，而是先定义角色，再把角色映射到文集：
- 平台管理员：负责系统配置、账号和备份，不默认参与业务内容维护。
- 文集管理员：管理某个知识域的目录、成员和发布规则。
- 编辑者：创建及更新文档，但不能随意扩大访问范围。
- 只读成员：查询已授权内容，不能修改原文。
- 外部协作者：仅访问明确开放的文集或文档。
涉及人事、财务、客户数据或安全配置时，还应遵循最小权限原则。AI 能检索到的内容范围也不应大于当前用户本身可访问的范围；否则，即使原始页面设置了权限，问答结果仍可能造成越权泄露。
私有部署可以这样接入现有基础设施
具体安装方式应以 MrDoc v1.1.1 的官方发行包和部署说明为准。假设应用已经监听在服务器的 127.0.0.1:8000，可以用 Nginx 提供 HTTPS 入口。下面是一个可直接改造的反向代理配置；运行前请替换域名、证书路径和实际端口。
server {
listen 80;
server_name docs.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name docs.example.com;
ssl_certificate /etc/letsencrypt/live/docs.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/docs.example.com/privkey.pem;
client_max_body_size 100m;
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 300s;
}
}
保存为 /etc/nginx/conf.d/mrdoc.conf 后，可以检查并重载配置：
sudo nginx -t
sudo systemctl reload nginx
curl -I https://docs.example.com
client_max_body_size 应结合 Office 文件和附件的实际大小调整。若系统只供内网使用，还可以在 Nginx 前增加 VPN、零信任网关或企业统一身份入口，而不是直接暴露到公网。
知识库还必须进入正式备份体系。下面是一段通用备份脚本，用于打包附件目录和数据库导出文件。路径是示例值，执行前必须根据实际部署方式修改；数据库本身应先使用对应引擎的工具导出一致性快照。
#!/usr/bin/env bash
set -euo pipefail
BACKUP_ROOT="/srv/backups/mrdoc"
DATA_DIR="/srv/mrdoc/data"
DB_DUMP="/srv/mrdoc/db-backup.sql"
STAMP="$(date +%Y%m%d-%H%M%S)"
TARGET="${BACKUP_ROOT}/mrdoc-${STAMP}.tar.gz"
mkdir -p "$BACKUP_ROOT"
test -d "$DATA_DIR" || { echo "Missing data directory: $DATA_DIR" >&2; exit 1; }
test -f "$DB_DUMP" || { echo "Missing database dump: $DB_DUMP" >&2; exit 1; }
tar -czf "$TARGET" "$DATA_DIR" "$DB_DUMP"
find "$BACKUP_ROOT" -type f -name 'mrdoc-*.tar.gz' -mtime +30 -delete
sha256sum "$TARGET" > "${TARGET}.sha256"
echo "Backup created: $TARGET"
只生成压缩包还不算完成备份。团队应定期在隔离环境做恢复演练，并确认文档正文、附件、账号、权限和文集关系都能恢复。
AI 知识库的质量取决于源文档
“接入 AI”并不会自动消除脏数据。重复文档、冲突规则和过期内容进入检索范围后，模型只会更快地给出不可靠答案。正式开放 AI 问答前，可以建立一组固定测试题：
- 答案是否引用了当前有效的文档？
- 同名制度存在多个版本时，系统能否优先使用最新版本？
- 没有权限访问原文的用户，是否也无法从回答中获得敏感信息？
- 找不到依据时，系统是明确说明未知，还是编造答案？
- 删除或更新文档后，检索结果多久能够同步？
对于薪酬、法务、安全响应和生产操作等高风险场景，AI 回答应作为检索辅助，而不是最终审批意见。最好让结果携带来源文档、更新时间和责任人，用户才能快速核验。
升级与落地检查清单
准备采用或升级到 MrDoc v1.1.1 时，可以按以下顺序推进：
- 阅读与当前版本对应的发布说明，确认数据库、运行环境和依赖要求。
- 在测试环境恢复一份脱敏备份，验证文档、附件、权限和搜索功能。
- 先设计文集边界与角色模型，再批量迁移历史资料。
- 为核心文档增加负责人、有效状态和复核日期。
- 将 HTTPS、访问日志、监控、备份及恢复演练纳入运维流程。
- 验证 AI 检索严格继承用户权限，并为高风险问题保留人工确认。
- 分批开放给研发、产品或支持团队，根据真实查询记录调整目录和内容。
私有知识库的价值不在于存入了多少文件，而在于员工能否在需要时找到可信答案。MrDoc 提供了结构化内容、多形态文档、权限与协作基础；真正决定成效的，则是团队持续维护知识边界、内容质量和安全规则的能力。