Docker部署私人旅行规划工具，通过互动地图、预算管理和实时同步一站式协同规划旅行

前言

随着 AI 的快速发展，旅游攻略写起来也越来越容易了——一句话丢给某包、某问，就能生成一篇相当详细的攻略。但真用过的朋友应该都有体会：AI 写的攻略很难直接拿来就用，很多细节（具体路线怎么串、预算够不够、每个人口味偏好）都得自己改和补。

更要命的是，当你把攻略分享给一起出游的同伴后，大家想各自提意见、改行程，就很不方便了——聊天记录翻半天，版本还对不上。这时候就特别需要一个类似线上协同办公平台的"旅游版"。

TREK 就是为解决这个痛点而生的：它是一款开源、可自托管的实时协作旅行规划工具。它不是一张简单的"行程清单"，而是一套覆盖旅行全周期的管理系统：前期筛选景点、规划路线，中期追踪预算、管理预订，后期撰写日志、归档文档——所有环节都在同一个平台完成。很适合经常旅游、又愿意记录的人群。项目地址：https://github.com/mauriceboe/TREK

它解决的是"协作"，不只是"排行程"

先把定位说清楚，免得你部署完觉得"这不就是个行程表吗"。

普通的行程笔记（备忘录、Excel、在线文档）能解决"记录"，但解决不了多人同时改这件事。典型的翻车场景是这样的：

• 三个人各自在聊天里提了改法，没人知道谁的意见生效了；

• 攻略文档在某个人的手机里，别人只能看不能改；

• 改到第 5 版之后，谁都说不清哪份是最新的。

TREK 的做法是把整个行程变成一个可以被多人同时进入的在线空间——谁加了景点、谁调了路线，其他人刷新就能看到。"版本"这个概念在这里被取消了，因为大家操作的是同一份数据。

这也是它比"AI 生成一篇文章"更值钱的地方：AI 负责给你一个起点，TREK 负责让一群人把它改到能出发。

Docker Compose 部署

TREK 支持 Docker Compose 一键部署。官方提供的 Compose 文件功能比较全（含健康检查、安全验证等），我这里给一个精简过、够用的版本：

services:
  trek:
    image: mauriceboe/trek          # 使用官方镜像
    container_name: trek            # 容器名称
    ports:
      - "3777:3000"                 # 端口映射，可修改冒号左边的端口
    environment:
      ENCRYPTION_KEY: c9dbc707c127fa237ea497f16977e17ef7173c034d03ab3d566641c0865dee1f  # 加密密钥，可自己用 OpenSSL 生成一个32字节的随机十六进制数
      COOKIE_SECURE: "false"        # 使用 HTTP 必须设为 false
    volumes:
      - ./data:/app/data            # 数据持久化目录
      - ./uploads:/app/uploads      # 文件上传目录
    restart: unless-stopped

几个参数说明：

• 端口：3777:3000 中，冒号左边的 3777 是你外部访问的端口，可按需修改；右边 3000 是容器内部端口，不用动。

• ENCRYPTION_KEY：加密密钥。示例里这个可以直接用，更稳妥的做法是自己生成一个 32 字节的随机十六进制数（Linux 下可用 openssl rand -hex 32 生成）。

• COOKIE_SECURE：如果你是走 HTTP（未配 HTTPS），必须设成 false，否则 Cookie 无法正常读写，登录会出问题。

• 两个挂载目录：data 和 uploads 分别持久化数据和上传文件，升级容器不会丢数据。

这两行环境变量，值得单独解释

上面两个环境变量是最容易配错、也最容易被忽略的，展开说一下：

① ENCRYPTION_KEY 到底加密了什么

它不是用来加密你登录密码的（那是哈希），而是用于加密需要被还原的敏感数据——比如你在行程里填的预订信息、账号备注这类字段。因为这些数据需要"存下去、以后读出来原文"，所以必须可逆加密，而可逆加密就需要一把密钥。

由此推出两条硬规矩：

• 密钥一旦更换，之前用它加密的数据就解不开了（不是报错，是读出乱码/丢失）；

• data 目录和这个密钥必须一起备份。只备份数据不备份密钥，等于备份了一堆打不开的保险箱。

所以正确的做法是：部署时就把 ENCRYPTION_KEY 生成好并记到密码管理器里，之后永远不要改。

② COOKIE_SECURE 为什么跟 HTTPS 绑定

这个参数控制的是：登录凭证（Cookie）是否只在加密连接下发送。

先内网 HTTP 试用的话，保持 false 就对了。等你配好 HTTPS 再改成 true，这是顺序问题，不是"哪个更好"的问题。

开始使用

1. 部署完成后，浏览器打开 http://NAS的IP:3777（端口改成你自己的）。

2. 第一次运行时会自动生成默认的用户名和密码。

3. 怎么拿到账号密码？查看项目运行日志就能找到（在 Docker 日志里）。

4. 用默认账号登录后，系统会要求你修改密码。注意新密码要满足大小写字母 + 符号的组合要求。

5. 进入主界面后，先做一些基本设置，比如界面语言、天气显示、单位等，让它更贴合你的习惯。

6. 设置好后，就可以创建行程了。

7. 创建时可以选择封面、设置出行时间等基础信息。

8. 创建好之后，初始的行程页面是空白的，需要往里添加各种信息。

高效玩法：AI 生成攻略后导入

新建好的行程是空白的，需要手动往里填各种信息，会有点费劲。这里分享一个高效的起步方式：

1. 先让 AI（如豆包、DeepSeek）帮你生成一份攻略，并让它导出成 gpx 格式（一种通用的地理轨迹文件）。

2. 把导出的 gpx 文件导入到 TREK 里，再手动调整细节。这样比从零开始逐个加景点快得多。

3. 导入后，所有景点都会自动标到地图上，你可以把它们拖到左边的行程栏里，按天/按时段排好，非常直观。

为什么是 GPX 这个格式

这里插一句原理，能帮你理解为什么这条路走得通。

GPX（GPS Exchange Format） 是一套基于 XML 的地理信息交换标准，本质就是一份"带坐标的清单"：每个点有经纬度、可选名字和描述。因为它是开放的通用格式，所以在 AI、地图软件、运动手表、轨迹记录 App 之间都能互相认。

换成别的格式就未必通：AI 给你一段自然语言的行程，TREK 没法解析；给你一张表格，你得手工一个个查坐标。GPX 刚好同时满足"AI 能生成"和"工具能读入"，所以成了这条链路里最顺的中间格式。

实操时提示词可以这么说：

把下面这份行程整理成 GPX 格式，每个景点包含：
- 名称（中文）
- 经纬度坐标
- 一句话说明（开放时间/门票/亮点）
按天分组，同一天的景点按游览顺序排列。

有一点要提醒：AI 生成的坐标存在偏差（尤其是小众地点），导入后一定要在 TREK 地图上逐个核对位置，别直接照着导航开——把景点标到河里或者相反方向的事，实测是发生过的。

协作与分享

行程排得满意后，就可以分享给同行的小伙伴了——大家可以实时共同查看、修改、完善所有行程，谁改了路线、加了景点，其他人马上能看到，彻底告别"攻略在谁的微信里"这种混乱。如果想让出门在外也能访问，可以给它配一个反代地址或内网穿透。

关于"分享到公网"这件事，给两个实在建议：

• 仅同行的人用，就别公开。TREK 有用户体系，把同行的人加成账号比把地址发到群里安全得多——行程里可能带着你出发的日期、住哪家酒店，这些信息没必要让所有人看见。

• 必须配 HTTPS，并顺手把上面那个 COOKIE_SECURE 改成 true。这是自托管工具暴露到公网的基本动作。

还能玩出什么花样

TREK 的扩展性比看上去强，几个方向可以自己试：

• 地图源替换：默认地图源可以换成 Google 地图（适合境外行）或其他瓦片源，看你主要在哪跑；

• MCP 集成：支持接入 MCP 智能生成行程和旅行日志——也就是说，可以让 AI 直接读写你的行程数据，而不只是"导入一次 GPX"；

• 预算追踪：把机票、住宿、门票填进去，出行前就能看出预算超没超，比临时记账省心。

小结

TREK 这套系统很有意思，非常适合个人博主（边旅行边记录）或组队出游的小伙伴（实时协同规划）使用，而且自托管意味着数据都在自己手里，隐私有保障。我还没展示的功能还有很多：比如地图可以替换成 Google 地图、还能接入 MCP 智能生成行程和旅行日志等，可玩性相当高。如果你也常为"多人一起做旅行攻略"发愁，很值得自己部署一套试试。

顺便一提，它和我之前推荐过的另一类自托管应用是同一个思路——把"日常得靠第三方平台完成的事"搬回自己机器上：

• 如果你更常需要的是"一堆小工具随手能用"，可以看 自建在线工具站 tools-web；

• 如果你关注的是"盯着某个东西的价格变化"，那 二手商品价格监控 是同类结构。

三个加起来，NAS 就不只是存文件的地方了。