你刚在群里发了一条消息：”酒店我定了，你们看看行程还有什么要调的。“然后就是漫长的沉默。三个小时后有人回了一句”第三天那个博物馆周二不开门”。你翻回聊天记录，发现三天前已经有人提过这件事了。
这就是小组出行的日常。你在微信群里协调行程、在备忘录里管预算、在另一个 App 里列打包清单、还得另外找个地方存电子票。TripIt 能解决一部分问题，但它的免费版不支持多人实时编辑。Notion 模板够灵活，但谁都不想到了机场还要在笔记软件里翻地图。
TREK 把这些分散的需求打包进了一个自托管的 Docker 容器里。交互地图、费用分摊、打包清单、AI 自动导入预订信息，全部标配。截至 2026 年 7 月，项目已经积累了超过 6,600 个 Stars，96 个版本发布，在 GitHub Trending 上也出现过不止一次。它不是那种红极一时然后沉寂的网红项目，迭代节奏很稳。
TREK 的产品逻辑是线性的：规划行程、多人协作敲定、分摊预算、检查打包清单，最后出发。四个环节在商业竞品里通常被拆成四个独立 App，TREK 把它们串在了一条线上。但光说产品逻辑没用，真正有意思的是每个环节是怎么做的。
打动我的几个地方
真正让 TREK 和其他旅行工具拉开距离的，不是某一个大杀器功能，而是一套组合拳。它把地图、协作、预算、清单四个维度的需求全部打通了，而不是像大多数替代方案那样只覆盖其中一两个。
先说地图。TREK 用的是 Leaflet 和 MapLibre 双渲染器，支持标记聚类、GPS 定位、路线自动适配地图边界。你可以拖拽调整地点顺序，给每个停留点设置起止时间和备注。和 TripIt 那种自动从邮件抓取行程的方式不同，TREK 偏向手动规划。这意味着你需要多花几分钟创建行程，但换来的是完全的控制权：想去的地方不需要有标准地址，山里的野餐点、没注册在 Google Maps 上的民宿，一个坐标就能搞定。
AI 功能的设计思路也值得琢磨。TREK 不是那种”你告诉它目的地它就帮你排好三天行程”的 AI 旅行助手。它的 LLM 集成做了一件更实在的事：从酒店确认邮件、航班 PDF 这些非结构化文件里自动提取预订信息。支持 Ollama 本地模型和 OpenAI 兼容 API，推荐 Qwen3-8B。解析结果会逐条列出来让你审核后才保存，不是黑箱自动化。这个设计比那些试图用 AI 取代你判断的旅行工具要克制得多，也更实用。
费用分摊是另一个让我觉得”终于有人做对了”的模块。它支持均分、自定义份额和票据三种模式，可以把费用关联到预订记录上自动生成条目。TripIt 根本没有这个功能，Splitwise 只能管钱不管行程，TREK 是第一个把两者真正融在一起的开源产品。多币种支持在实测中覆盖了 JPY 等亚洲货币，对于跨国行程来说不是锦上添花，是刚需。
打包清单看起来像一个小功能，但 TREK 把它做成了三级共享模式：公共池的物品所有人都能看到，私人物品只有所有者可见，还可以指定某物品由特定人员共享。这比 Notion 模板里勾选 checkbox 要细腻得多——你不会想让旅伴看到你带了什么药，但确实需要让室友知道你带了一把瑞士军刀。
PWA 和离线支持也做到了让我意外的深度。不只是把网页添加到主屏幕就是 PWA 了，TREK 有选择性离线同步，你可以按行程和地图瓦片粒度选择缓存哪些数据，还有冲突检测和解决队列。出门玩的时候网络时断时续是常态，在高铁上、山里头、国外没买流量包的咖啡馆里，这个离线能力不是摆设，是实打实能救急的。
但光说功能不说坑，那是在忽悠人。东西到底能不能跑起来？
跑起来看看
部署门槛是真的低。一条 Docker 命令就能看到界面：
docker run -d --name trek \
-p 3000:3000 \
-v ./data:/app/data \
-v ./uploads:/app/uploads \
--restart unless-stopped \
mauriceboe/trek
有 Docker Compose 的环境更省事，克隆仓库后一行命令拉起：
git clone https://github.com/liketrek/TREK.git
cd TREK
docker compose up -d
第一次启动后访问 http://localhost:3000 注册账号就能用。支持 OIDC SSO 对接企业身份系统，也支持 Passkeys 无密码登录和 TOTP 两步验证。但有两个点必须提前提醒：
-
反向代理的 WebSocket 透传：TREK 依赖 WebSocket 做实时协作，Nginx 或 Caddy 没配透传的话，协作功能在公网环境直接断连。仓库文档里有配置示例，别跳过。 -
加密密钥：敏感数据用 ENCRYPTION_KEY加密，部署前必须生成强随机密钥。升级时需要跑scripts/migrate-encryption.ts做密钥迁移，脚本会先备份数据库。
PWA 安装不需要应用商店。通过 HTTPS 访问后，iOS 用”分享到主屏幕”，Android 用菜单里的”安装应用”，就能获得一个接近原生 App 的全屏体验。
话说回来，能跑起来和能用好是两回事。到底什么人该用，什么人该绕道？
适合谁，不适合谁
在隐私可控性上 TREK 是碾压级的，但在开箱即用体验上它确实不如商业 App。下面的表格把这几条线理清楚。
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| 小组自由行 | 三五好友或家庭出行 | 实时协作，费用分摊，无需注册账户即可参与 | 需要有人维护服务器 |
| 隐私敏感出行 | 不想把行程数据交给商业平台的用户 | 数据完全自托管，AGPL 协议透明可控 | 自托管有运维成本 |
| 企业内部差旅管理 | 需要 SSO 和权限控制的小团队 | OIDC 单点登录，行程所有权可转让 | 不适合大型企业的审批流需求 |
| 个人长期旅行记录 | 背包客、数字游民 | Atlas 模块可视化访问过的国家地区，收藏夹复用 | 移动端只有 PWA，没有原生通知 |
不适合的也很明确：不想维护任何服务器的用户，Wanderlog 或 TripIt 的免费版更省心；严重依赖航班和酒店 GDS 系统深度集成的商务出行，TREK 是规划工具不是预订工具；对 AGPL 协议敏感的团队，如果打算基于 TREK 提供商业服务就必须开源修改部分。
场景都说清楚了，但我更关心的一个问题是：这个项目能活多久？
维护靠不靠谱
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | ~6,600+ | 截至 2026 年 7 月，持续增长 |
| 核心维护者 | 1 人（jubnl） | Bus Factor = 1，这是最大的风险点 |
| 版本迭代 | 96 个 tag，v3.4.0 | 1,333 次提交，发布频率稳定 |
| 测试覆盖 | 前后端 6,900+ 用例 | 分支覆盖率门槛 80% |
| 协议 | AGPL-3.0 | 自托管免费，对外提供服务需开源 |
这个维护者数据是我对 TREK 最有保留的一栏。96 个版本标签、1,333 次提交、6,900 多个测试用例，这些数字说明 jubnl 是一个极其勤奋且工程质量意识很强的开发者。但 Bus Factor = 1 意味着如果这个唯一的维护者因为任何原因放缓节奏，整个项目就会进入维护真空。
让我稍微放心一点的是测试覆盖率。前后端各有一套完整的测试套件，分支覆盖率门槛设在 80%。对于一个单人维护的项目来说，这意味着接手的人不需要从零开始理解代码的行为边界，测试本身就是最好的文档。
社区方面，我在 HackerNews 上找到一条让我印象深刻的评论：“Finally a trip planner that doesn’t want my data or my money. The MCP integration is what made me switch from Wanderlog.” MCP 这件事后面会详细说，但这个用户精准地指出了 TREK 和商业竞品的根本差异：它不是要你的数据来做增长模型，它只是一个工具。
我的真实看法
TREK 现在处在一个很有意思的位置。它不是最易用的旅行规划工具——Wanderlog 的自动行程导入、移动端原生 App 都比它更顺畅。它不是功能最全的——TripIt 的 GDS 集成和机票价格追踪它做不了。但它的核心竞争力来自一个商业产品天然做不到的事：你的数据 100% 在你自己的服务器上。
旅行数据是极其敏感的。你去过哪、什么时候去、和谁一起去、花了多少钱、下一站要去哪，把这些信息交给一个 SaaS 公司，等于把自己未来几个月的行踪暴露给了广告商、政府数据请求和潜在的数据泄露。对于隐私敏感的人来说，TREK 自托管的特性不是锦上添花，而是唯一选择。
MCP 服务器是 TREK 被低估的一个模块。它暴露了 150 多个工具，AI Agent 可以直接操作你的旅行计划：添加地点、调整时间、查询费用、生成总结。这意味着你可以用 Claude Code 或任何支持 MCP 的 Agent 来辅助旅行规划，而不是在一个封闭 App 里点点点。在 Agent 化浪潮席卷整个工具链的 2026 年，这个设计比很多”AI 原生”标签挂了一堆的创业公司更有远见。
那社区和趋势呢？这两个问题的答案会决定你敢不敢把明年的旅行都押在这个项目上。
趋势上，我的判断是谨慎看好。从 v1.0 到 v3.4.0 的迭代节奏来看，96 个版本标签的密度意味着这个项目不是心血来潮的个人 Demo。Stars 增速在 2026 年上半年有过一波爆发，上了 GitHub Trending 之后进入了一个更平稳的增长期。版本发布速度没有放缓的迹象，v3.4.0 在 7 月 19 日刚刚发布。但 Bus Factor = 1 是最需要持续观察的风险点。如果有第二个核心贡献者加入 maintenance rotation，我会把谨慎改为明确看好。
有一点必须要说清楚：TREK 不是 Immich。Immich 在自托管照片领域几乎垄断了心智，TREK 在旅行规划领域还远没到这个位置。但两者的设计哲学惊人地相似：都是用 NestJS 写的后端，都是 AGPL 协议，都强调隐私和自托管，都有活跃的单人维护者。如果你已经在跑 Immich，TREK 会是一个很自然的扩展。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/liketrek/TREK |
| 在线 Demo | https://demo.liketrek.com |
| Docker 镜像 | mauriceboe/trek |
| 公开路线图 | https://kanban.pakulat.org/shared/I4wxF6inOOMB0C6hH6kQm3efyNxFjwyI |
链接都摆在这了，但你真正想问的应该是：我到底要不要用？
先用 Docker 跑起来
如果你已经在用 Docker 部署 Immich 或 Home Assistant，TREK 的部署成本接近于零。从 docker run 开始，先跑着看看能不能融入自己的出行习惯。一个月用一两次的场景不值得折腾部署，但对每年出国两三次、经常组队出行的用户来说，数据自主权是个不能妥协的事。
如果你还在观望，关注两个指标：是否有第二个核心贡献者加入 maintenance，以及 MCP 工具的社区生态是否开始有人在上面搭东西。第一个指标决定项目的长寿，第二个指标决定它能不能从一个好用的个人工具变成 Travel Agent 时代的前端基础设施。
在旅行这件事上，工具本来就不该比目的地更复杂。TREK 刚好做到了这一点。