上个月我把团队的项目管理数据从一家商业看板工具里导了出来导出的 CSV 压完还有 80 多 MB。真正让我下决心的不是导出麻烦而是那家工具突然改了定价策略免费版几乎砍掉了全部看板功能团队 12 个人一个月光协作席位就要多掏两百多美元。老板只问了一句能不能部署在我们自己的服务器上。我开始系统地找开源自托管的项目管理平台试了一圈最后留在生产环境里的是 TomiHub而且它新发布的 AI Brain 扩展模块也已经下载跑起来了。这篇文章把整个选型、部署、接入 AI Brain 的过程原样记下来如果你也在纠结“要不要自托管”“AI 到底能帮到什么程度”可以参考我这套操作。1. 项目协作数据搬到自托管之前我到底在纠结什么1.1 商业 SaaS 看板工具的三个硬伤先交代背景。我们团队做的是软硬件结合的产品日常管理既有研发任务也有供应链跟进、客户反馈、内部审批这类事务型工作。过去几年我一直用商业看板工具表面上看功能齐全但用久了有三个问题越来越明显。第一个是成本模型僵硬。商业工具基本按“席位 高级功能”收费团队过十个人之后费用非线性上涨。老板不是不愿意花钱而是觉得为看板、列表、日历这种基础功能按人按月付费性价比太低。我们真正用到的功能其实一双手数得过来。第二个是数据主权问题。这里不是说要做什么特殊数据而是业务过程中沉淀的排期逻辑、客户上下文、历史决策记录全都存在别人的服务器上。一旦平台调整策略、合并收购或者停止运营迁移成本非常高。去年就有同事发现我们的“已归档项目”在某次平台改版后被静默清理了那种失控感很糟糕。第三个是功能碎片化。我们想要的不是更多花哨视图而是能自定义工作流状态、能按项目空间隔离权限、能通过 API 和内部系统打通。商业工具要么这些能力要加钱开企业版要么藏在多级菜单里配置起来非常难受。1.2 为什么挑中 TomiHub开源、自托管、还有 AI 扩展位在这个背景下我给自己列了一个选型清单必须开源、必须能完全自托管、权限模型要够用、最好有 Restful API 或 Webhook最后是部署方式不能太重。TomiHub 进入视野是因为它在“项目管理平台”这个定位里选择了更宽的边界——它除了管项目也把任务、工单、审批这类事务流纳入了同一个数据模型。你不必同时维护 Jira、工单系统和内部流程表三套工具一个 TomiHub 就能把这些东西统一起来。技术上的几个特点也是我决定留下它的原因后端是 Go 写的单二进制内存占用比一堆 Node 或 Java 服务小得多前端是 React 构建的部署时由服务端托管静态资源不需要单独配 Nginx 来伺候前端数据层支持 PostgreSQL视图层做了看板、列表、日历、甘特图四种模式权限体系区分系统级、项目级和任务级适合多人多团队隔离官方的 AI Brain 模块可以单独下载不影响主程序的升级路径这点很关键。我还特意确认了它对外部依赖少不依赖任何第三方登录服务也能完整运行。对一个要放进内网环境的系统来说这是很大的优势。2. 部署 TomiHub一次干净的 Docker Compose 落地过程2.1 服务器准备不用太豪华但硬盘和备份要留足我在部署前翻遍了官方文档又参考了一些社区里的部署案例最后用了最稳妥的 Docker Compose 方式。你不需要一台怪兽级服务器我们的实际体量20 人以下团队、日均新增几十个任务用 2 核 4G 能跑但我建议起步给 4 核 8G因为后面要挂 AI Brain内存敏感。服务器方面有几个容易被忽视的点系统盘和数据盘分开TomiHub 的数据卷最好挂到独立数据盘上避免系统盘写满导致整个服务器卡死域名提前解析到服务器 IP后面申请 HTTPS 证书时要验证域名防火墙只放行 80/443 和 SSH 端口应用端口不需要对公网开放如果不方便用云服务器内网 NAS 上装 Docker 也可以但建议用一台专门虚拟机别跟其他业务容器混跑。这里多说一句为什么要用 Docker Compose。TomiHub 虽然支持裸机二进制部署但它的依赖包括 PostgreSQL 和 Redis裸机安装需要自己管理这几个服务的版本、配置、数据目录和开机自启。用 Compose 可以把整个环境声明式地管起来升级的时候只改镜像版本回滚也快。对自托管场景来说越容易重建的环境越安全。2.2 编写 docker-compose.yml核心服务与关键环境变量我先创建一个专用目录比如/opt/tomihub然后编写docker-compose.yml。下面这份配置我自己实测过可以直接抄version: 3.8 services: postgres: image: postgres:16-alpine restart: unless-stopped environment: POSTGRES_DB: tomihub POSTGRES_USER: tomihub POSTGRES_PASSWORD: ${DB_PASSWORD} volumes: - pg_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U tomihub] interval: 10s timeout: 5s retries: 5 redis: image: redis:7-alpine restart: unless-stopped command: [redis-server, --appendonly, yes] volumes: - redis_data:/data healthcheck: test: [CMD, redis-cli, ping] interval: 10s timeout: 5s retries: 5 tomihub-app: image: tomihub/server:latest restart: unless-stopped ports: - 127.0.0.1:8080:8080 volumes: - app_data:/app/data environment: APP_SECRET: ${APP_SECRET} DB_HOST: postgres DB_PORT: 5432 DB_USER: tomihub DB_PASSWORD: ${DB_PASSWORD} DB_NAME: tomihub REDIS_URL: redis://redis:6379/0 BASE_URL: ${BASE_URL} STORAGE_PATH: /app/data depends_on: postgres: condition: service_healthy redis: condition: service_healthy ai-brain: image: tomihub/ai-brain:latest restart: unless-stopped environment: BRAIN_LOG_LEVEL: info BRAIN_INDEX_PATH: /brain/index AI_PROVIDER: ${AI_PROVIDER} AI_BASE_URL: ${AI_BASE_URL} AI_API_KEY: ${AI_API_KEY} AI_MODEL: ${AI_MODEL} volumes: - brain_data:/brain/index depends_on: - tomihub-app volumes: pg_data: redis_data: app_data: brain_data:这份配置里我特意把密码和密钥都用${}占位符引用了实际值放在同目录下的.env文件里。好处是docker-compose.yml可以提交到内部 Git 仓库而.env留在服务器本地不会被误传出去。.env内容大概是这样DB_PASSWORD换成一个足够长的随机字符串 APP_SECRET用 openssl rand -hex 32 生成 BASE_URLhttps://tasks.example.com AI_PROVIDERopenai-compatible AI_BASE_URLhttps://你的模型服务地址/v1 AI_API_KEY你的模型服务密钥 AI_MODELgpt-4o-mini2.3 数据卷、反向代理与 HTTPS 证书TomiHub 的三种数据要分开备份PostgreSQL 里的结构化业务数据、app_data里的附件与文件、brain_data里 AI Brain 的向量索引。PostgreSQL 备份我用定时任务每天凌晨做一次docker compose exec -T postgres pg_dump -U tomihub tomihub | gzip /backup/tomihub_$(date %F).sql.gz备份文件再同步到另一台机器或对象存储这是我的底线。自托管最怕的不是服务器挂而是服务器挂的时候备份也没有。反向代理这层我用了 Caddy理由是它默认自动申请和续期 HTTPS 证书配置极简tasks.example.com { reverse_proxy 127.0.0.1:8080 }如果你更熟悉 Nginx也可以自己配证书关键点是必须把长连接、上传文件大小限制这些参数调好尤其是要传大附件的时候。2.4 首次启动的检查清单第一次启动不要急着录数据按这个顺序过一遍执行docker compose up -d等所有服务变成 healthy查看日志确认没有数据库连接错误docker compose logs -f tomihub-app浏览器访问http://服务器IP:8080看到初始化页面说明主程序起来了创建管理员账号进入后台把BASE_URL改成正式域名开着浏览器开发者工具手动创建一条任务看 Network 请求是否都落在自己的域名上跑一次恢复演练把刚才的备份文件恢复到一台临时容器里确认能读出来。我见过很多自托管翻车案例都是跳过第 6 步觉得“备份了就行”。真到要恢复那天才发现备份命令写错了或者备份文件不完整那才是最惨的。3. AI Brain 模块比预想中更实用的下载与接入3.1 AI Brain 是什么和主程序是什么关系说实话一开始我对项目管理工具里的 AI 功能是持怀疑态度的。市面上很多产品的 AI 按钮就是个聊天框跟知识库不打通也不能操作业务数据用两次就腻了。TomiHub 的 AI Brain 思路不太一样。它是一个独立扩展模块跟主程序通过内部接口通信主要做几件事把用户输入的自然语言解析成结构化任务包括标题、描述、截止时间、优先级、标签对已存在的任务做摘要方便你快速了解一件事卡的进展和下一步识别相似或重复任务减少团队里“同一件事提了两遍工单”的情况根据任务属性和紧急程度给出优先级建议汇总某段时间内的任务进展自动生成周报草稿。它的定位不是“替你做项目管理”而是“帮你把琐碎的信息整理成可执行的决策”。这个定位比较务实。3.2 下载 AI Brain 的具体步骤AI Brain 的下载入口在项目 Release 页面压缩包里有完整的部署说明。我这里记的是我实际操作的一条完整路径。我先把压缩包下载到服务器解压后看到了docker-compose.ai.yml、tomi-ai-brain二进制文件和一个config.example.yaml。因为我上面用了 Docker 方式部署主程序所以 AI Brain 也建议用镜像方式跑而不是直接跑裸二进制。实际操作中我做了几步cd /opt/tomihub curl -L -o ai-brain.zip https://github.com/tomihub/tomihub/releases/download/v0.1.0/ai-brain-0.1.0.zip unzip ai-brain.zip -d ai-brain cp ai-brain/config.example.yaml .env.ai # 编辑 .env.ai填入模型服务地址和密钥 docker compose -f docker-compose.yml -f ai-brain/docker-compose.ai.yml up -d如果你下载速度慢也可以先下载到本地再通过 SFTP 传上去。关键是不要让下载流程卡住AI Brain 的压缩包本身不大里面的大头是几个预置 prompt 模板和少量依赖库。3.3 配置模型接口OpenAI 兼容接口和本地模型我都试了AI Brain 的模型接口设计成兼容 OpenAI 的格式这意味着任何提供/v1/chat/completions接口的服务都能接。我第一轮配置用的云上模型服务在.env.ai里这样写AI_PROVIDERopenai-compatible AI_BASE_URLhttps://你的模型服务地址/v1 AI_API_KEYsk-xxxx AI_MODELgpt-4o-mini注意AI_API_KEY只放在.env.ai里文件权限设为 600。别图省事写进 docker-compose.yml那会把密钥留在版本历史里。第二轮我试了本地部署的开源模型用 Ollama 起了一个服务ollama run qwen2.5:14b然后把AI_BASE_URL指向${OLLAMA_HOST}:11434/v1模型名改成qwen2.5:14bAI Brain 同样能跑起来。效果方面云模型在指令遵循和摘要质量上明显更好本地模型胜在离线、数据不出内网。如果团队对数据敏感度极高本地模型是最稳妥的路线但要接受生成速度慢和效果打折扣。3.4 实测自然语言建任务、摘要和优先级建议我不太相信宣传所以接入后第一件事是拿真实业务测试。我输入了这样一句话“下周准备客户演示资料重点强调自动化报表功能提醒我把设计稿提前定稿。”AI Brain 解析后生成的任务结构让我有点意外标题准备客户演示资料描述重点强调自动化报表功能设计稿需提前定稿截止时间自动设置为下周五按当时上下文推断标签客户演示、市场部优先级中高它还自动关联到了项目下已有的一篇“自动化报表需求说明”提示我“检测到相似文档可以在任务描述中引用”。这个功能对信息碎片化的团队非常实用。任务摘要的生成也靠谱。我选了一个跨度三周、有 27 条评论的任务AI Brain 生成的摘要把“方案变更”“客户确认”“等待采购报价”三个关键节点都抓住了还列出了下一步建议。团队的同事看完说这比自己翻评论记录省了至少十分钟。当然失败案例也有。有一次我把一句话里塞了三层含义还用了很多团队内部缩写AI Brain 生成的优先级明显偏高。后来我在配置里加了一条自定义指令“如果不确定优先级默认按中等级处理不要猜测。”问题就缓解了。这说明 AI Brain 是可引导的不是黑盒。4. 权限体系与多团队协作最容易被低估的配置项4.1 角色与权限矩阵很多自托管项目管理项目死在权限上——要么是管理员全知全能要么是成员权限控制太粗导致团队不敢真正用它。TomiHub 的权限分三层我整理成一张表供参考角色创建项目编辑任务删除任务管理成员查看其他项目导出数据管理 AI Brain系统管理员允许允许允许允许允许允许允许项目负责人允许允许允许项目内仅自己参与项目内仅本项目成员仅被邀请时允许仅自己创建无仅自己参与项目内无只读访客无只读无无按授权无无实际使用中我们让每个项目负责人都能独立管理自己的项目成员避免了所有权限变更都要找管理员的瓶颈。这对十几人团队特别友好。4.2 跨项目隔离与共享视图多团队协作最大的矛盾是既要隔离又要互通。我把研发、市场、供应链分成三个独立项目空间数据天然隔离。但管理层需要看全局进度如果让他们挨个进项目看效率太低。TomiHub 的办法是“共享视图”。我先在各个项目的任务里统一维护“目标”这个自定义字段然后创建一个只读的跨项目视图按目标和截止时间聚合。只读访客只需要一个只读链接不需要登录就能看到这份视图方便发给外部协作方。这个设计比我之前用的商业工具还灵活因为商业工具的跨项目报表和外部共享往往要企业版才能开。4.3 我踩过的两个权限坑第一个坑是 AI Brain 的权限边界。最初我以为 AI Brain 只是个后台服务不会涉及权限。结果发现它默认能够读取系统内的所有项目数据用来做跨项目去重和关联分析。这在单团队场景没问题但如果我们有外部供应商的项目也在同一实例里就有数据泄露风险。解决办法是在 AI Brain 的配置里加上项目过滤白名单让它只索引指定的项目 ID。这个参数在配置文件里叫BRAIN_PROJECT_WHITELIST官方文档没有放在最显眼的位置不仔细看很容易漏掉。第二个坑是权限变更缓存。有一次我把某位外包同事的角色从“成员”改成“只读访客”他那边还继续能编辑任务持续了几分钟。我一度以为权限没生效排查后发现是服务端会话缓存了旧权限。这是因为 TomiHub 的权限验证结果会缓存一段时间不是 bug但如果是敏感操作记得可以在后台手动清缓存不需要重启整个容器。5. 跑了两周后的资源占用、性能与放弃商业工具的底气5.1 资源占用实测数据自托管平台最怕一件事功能挺好但服务器天天告警。我记录了两周的数据给打算部署的人一个参考。测试环境4 核 8G 云服务器系统是 Debian 12Docker 环境。实例里共 3 个项目空间、86 个任务、523 条评论、41 个附件AI Brain 每天处理大约 20 次生成请求模型用的云端小模型。空闲状态下三个服务的资源占用大致如下服务内存占用CPU 占用说明postgres约 190 MB基本为 0工作负载很低redis约 15 MB基本为 0缓存任务队列tomihub-app约 120 MB波动小于 5%静态资源服务ai-brain约 260 MB请求时飙升加载模型 prompt 模板高峰时10 个人同时在线更新任务、AI Brain 跑摘要单核 CPU 偶尔到 40%但整体很平稳。因为 AI 生成请求是异步排队处理的不会阻塞主程序的页面操作。如果你想压缩资源可以只在需要时启动 ai-brain 容器毕竟它不是所有操作都依赖的组件。5.2 和 Jira、Linear、Trello 的横评感受我不是说 TomiHub 能完全取代所有商业工具但至少对我们这个规模的团队它比之前用的组合方案舒服得多。横向对比下我的个人感受Jira功能最全但配置复杂度和资源占用也最顶。让非研发团队用 Jira学习成本偏高。Linear交互非常流畅适合纯研发团队但事务流和自定义审批能力偏弱。Trello上手快看板体验好但深度管理、权限和自动化能力有限。TomiHub定位像是“Jira 和 Trello 之间的中间层”研发能用市场、供应链、审批流也能用。最大的优势是数据完全在自己的服务器里出问题可以用备份恢复。价格方面我们现在每个月只需要为云服务器和模型 API 付费团队席位费用为零。半年下来省下的订阅费基本可以覆盖一台更高级的服务器。5.3 后续扩展方向Webhook 与内部工具打通自托管平台真正的威力在于可以随便接内部系统。TomiHub 支持 Webhook我拿它对接了内部的企业微信群机器人规则只有一句话“当任务状态变为‘待验收’且负责人是当前用户时推送提醒到企微群。”配置起来比商业工具还要直白。下一步我打算做的是把 TomiHub 的附件存储接到内部对象存储替代本地卷用它的 API 把工单系统里的客户反馈自动同步成项目任务把 AI Brain 的周报模板改成更符合我们汇报习惯的格式尝试把本地模型换成更大参数的版本进一步减少对外部模型服务的依赖。这个项目目前还是我自托管清单里维护最省心的一个。它在主流商业工具和完全自研之间找到了一个平衡点该有的协作功能都有又不会像一批半成品开源项目那样三天两头 break 兼容性。如果你正准备从商业 SaaS 迁移到自托管我的建议是先在小团队试点两到三周重点测权限和备份恢复然后再把全量数据迁过去。TomiHub 的迁移路径足够平滑但每一步操作之前先把备份做好这句话值得写在所有部署文档的第一页。