企业官网建设流程全解析

本地跑大模型这件事，我从最早拿一台旧笔记本硬扛 7B 量化模型开始，到现在手头常备两三台机器做不同规模的推理测试，中间踩过的坑基本能写一本小册子。最开始那阵子，我的做法特别原始：装个推理框架，命令行里run一下模型，然后对着黑框框聊天。能跑通是能跑通，但一旦想让它干点正经活——比如接个知识库、挂几个工具、做个多轮任务编排——就发现光有模型根本不够，你还得自己写调度、写提示词管理、写会话状态维护，写着写着就变成了在造一个残缺的智能体框架。

后来我意识到一个很现实的问题：本地部署大模型的价值，不在于"能对话"，而在于"能作为一个可编排的智能体底座"。模型只是发动机，真正让车跑起来的是底盘、传动和方向盘。AIFlowy 加 Ollama 这套组合，恰好补上了"底盘"这一环——Ollama 负责把模型跑起来并且暴露成标准接口，AIFlowy 负责把模型、提示词、工具、知识库、工作流串成一个能用的智能体平台。整套东西可以完全跑在本地，不依赖外部服务，对数据敏感、想自己掌控链路的场景非常合适。

这篇内容我打算把整套搭建过程拆开讲透，从环境准备、模型拉取、平台部署，到工作流编排、工具接入、性能调优，再到我实际踩过的那些坑。适合两类人看：一类是刚接触本地大模型、想找个能快速上手的智能体平台的新手；另一类是用过 Ollama 但觉得"只能聊天不够用"、想往智能体方向走一步的开发者。全程我会把"为什么这么做"讲清楚，而不是只丢一堆命令让你照抄。

1. 先想清楚：为什么是 Ollama 加 AIFlowy 这个组合

1.1 本地智能体平台到底难在哪

很多人对"本地部署大模型"的理解停留在下载模型、跑起来、能对话就完事了。但只要你真的想把它用起来，马上会遇到三个绕不开的问题。

第一个是模型服务化。你从网上下一个模型权重，它本质上就是一堆参数文件，怎么把它变成一个能接受 HTTP 请求、能并发处理、能管理显存的服务？自己用推理框架写一套服务层，工作量不小，而且要考虑批处理、显存回收、超时控制这些细节。Ollama 把这一层全包了，一条命令拉起模型，自动暴露兼容标准协议的服务接口，省掉了大量重复劳动。

第二个是编排能力。一个能用的智能体，往往不是"问一句答一句"，而是要能调用工具、查询知识库、按流程走多步。比如你让它"帮我查一下这个季度的销售数据并生成一份简报"，它得先识别意图、调用数据查询工具、拿到结果、再组织语言输出。这套编排逻辑如果全靠手写代码，维护成本极高。AIFlowy 这类平台的价值就在于把编排可视化、配置化，让你用拖拽和表单就能搭出一条工作流。

第三个是可观测与可迭代。智能体跑起来之后，你得知道它每一步在想什么、调用了什么、耗时多少、哪里出了问题。没有这套观测能力，调优基本靠猜。平台化的方案通常自带会话记录、执行链路追踪，这对持续迭代至关重要。

1.2 Ollama 在整条链路里扮演什么角色

Ollama 的定位很清晰：本地模型运行时 + 标准化服务网关。它做了几件关键的事。

一是模型管理。它有自己的模型仓库格式，拉取、加载、卸载模型都是一条命令的事，还能自动处理量化版本的选择。你不需要关心 GGUF 文件放哪、怎么加载，ollama pull之后ollama run就能用。

二是服务暴露。Ollama 默认在本地起一个 HTTP 服务，提供对话、生成、嵌入等接口，接口格式和主流云端服务高度相似。这意味着任何支持标准协议的上层应用，几乎不用改代码就能接上本地模型。AIFlowy 正是通过这个接口和 Ollama 通信的。

三是资源调度。它会根据你的硬件自动决定模型加载到显存还是内存，支持模型常驻和按需加载。对于显存有限的机器，这个自动调度能省不少心。

提示：Ollama 的服务默认只监听本地回环地址，这是出于安全考虑。如果你需要让同一局域网内的其他设备访问，需要显式修改监听配置，但请务必评估网络环境的安全性，不要随意暴露到公网。

1.3 AIFlowy 补上了哪块拼图

如果说 Ollama 是发动机，AIFlowy 就是整车。它提供的是智能体的"应用层"能力：模型接入管理、提示词模板、工具注册、知识库检索、工作流编排、会话管理。这些能力单独看都不算新鲜，但整合在一起并且能和本地模型无缝对接，就构成了一个完整的本地智能体平台。

我特别看重它的一点是低代码编排。很多智能体框架要求你写 Python 代码来定义流程，对非专业开发者不友好，而且改起来麻烦。AIFlowy 把流程节点可视化，改一个环节不用动整个代码库，调试效率高很多。对于想快速验证想法、做原型的人来说，这个特性价值很大。

2. 环境准备：别急着装，先把这几件事理清楚

2.1 硬件门槛到底在哪

本地跑大模型，硬件是绕不过去的坎。我见过太多人上来就问"我 8G 内存的笔记本能跑吗"，答案取决于你想跑多大的模型、用来干什么。

先给一个粗略的参考，这是我在多台机器上实测下来的经验值：

这里的关键是量化等级。Q4 指的是 4 位量化，模型体积和内存占用大约是原始精度的四分之一，但效果损失通常在可接受范围内。如果你硬件紧张，优先选 Q4 甚至 Q3 的量化版本，别硬上高精度。

还有一个容易被忽略的点：内存和显存是两回事。有独立显卡的机器，模型优先加载到显存，速度快很多；没有独显或者显存不够，模型会加载到内存用 CPU 推理，速度会慢一个数量级。所以如果你打算认真用，一块显存够大的显卡比堆内存更划算。

2.2 操作系统与依赖环境

Ollama 支持主流桌面和服务器操作系统，Windows、macOS、Linux 都有对应版本。我的建议是：如果你只是体验，用你日常的操作系统就行；如果打算长期跑，优先考虑 Linux。原因是 Linux 下资源调度更可控，服务常驻更稳定，出问题排查也方便。

Windows 用户有个常见选择是在 WSL2 里装 Ollama。这么做的好处是能享受 Linux 环境的稳定性，同时保留 Windows 的桌面体验。但要注意 WSL2 的内存分配是动态的，默认可能只给一半物理内存，跑大模型前记得在配置文件里调高内存上限，否则模型加载到一半就 OOM 了。

macOS 用户相对省心，尤其是 Apple Silicon 芯片的机器，统一内存架构让显存和内存的界限模糊，跑中等规模模型体验不错。但要注意 macOS 下 Ollama 的模型存储路径和 Linux 不同，磁盘空间要留够。

依赖方面，AIFlowy 通常需要容器运行时或者对应的运行时环境。如果你用容器方式部署，提前装好容器引擎；如果直接跑二进制或者源码，按官方文档准备对应的运行时和数据库。数据库这块，很多平台默认用轻量级数据库，本地单机场景够用，不用一上来就上重型数据库。

2.3 磁盘空间：一个被严重低估的坑

我必须单独把磁盘空间拎出来说，因为这是新手最容易翻车的地方。

一个 7B 的 Q4 模型，文件大小大约 4-5GB。听起来不大，但你要考虑：你可能想试好几个模型，每个都占几 GB；模型加载时可能产生临时文件；平台的容器镜像、数据库、日志也都要空间。我见过有人 C 盘只剩 10GB 就开始装，结果模型下到一半磁盘满了，前功尽弃。

我的做法是：专门划一个数据盘或者目录给模型和平台数据。Ollama 支持通过环境变量指定模型存储路径，把它指到大容量磁盘上。这样即使系统盘紧张也不影响。另外，模型下载是断点续传的，磁盘满了之后清理出空间可以继续下，不用从头再来，这点比某些下载工具友好。

注意：如果你在 Windows 上把 Ollama 装到了非系统盘，记得同时确认模型存储路径也改过去了。默认路径往往在用户目录下，还是在系统盘，很多人只改了安装路径没改数据路径，结果系统盘照样爆。

3. 把 Ollama 跑起来：从安装到第一个模型

3.1 安装 Ollama 的几种方式与选择逻辑

Ollama 的安装方式主要有三种：官方安装包、包管理器、容器镜像。选哪种取决于你的使用场景。

官方安装包最省事，下载对应系统的安装程序，双击或者执行脚本，它会自动完成安装并注册为系统服务。适合想快速上手、不想折腾的人。安装完成后，Ollama 服务会自动在后台运行，你直接就能用命令行操作。

包管理器适合 Linux 用户，通过系统的包管理工具安装，升级和卸载都更规范。但要注意仓库里的版本可能不是最新的，如果你需要新特性，可能得手动装。

容器镜像适合已经有容器环境的场景，好处是环境隔离干净，不污染宿主机。但模型数据要通过卷挂载持久化，否则容器一删模型就没了。另外容器里访问 GPU 需要额外的运行时配置，比裸机装麻烦一些。

我的建议：第一次接触就用官方安装包，跑通之后再考虑要不要换成容器方式。先降低上手门槛，别一上来就给自己加难度。

3.2 模型下载慢的应对思路

模型下载慢是几乎所有人都会遇到的问题，因为模型仓库的服务器在境外，网络状况不稳定。这个问题的本质是网络链路问题，不是工具本身的问题。

应对思路有几个方向。一是选择合适的时间段下载，网络拥堵时段速度会明显下降，错峰下载体验好很多。二是利用支持断点续传的特性，下载中断了不用慌，重新执行拉取命令会从断点继续。三是关注模型的分片机制，大模型通常分成多个文件分片下载，某个分片失败只需要重下那个分片。

还有一个思路是选择体积更小的量化版本。同样是 7B 模型，Q4 版本比 Q8 版本小一半，下载时间和磁盘占用都大幅降低，效果差距在日常使用中往往感知不明显。对于只是想跑通流程的场景，先下小版本验证链路，确认没问题再考虑换大版本。

提示：下载过程中如果长时间卡住不动，可以先中断再重新拉取，断点续传机制会保留已下载的部分。不要反复删除重下，那样反而浪费时间。

3.3 验证模型服务是否正常

模型拉下来之后，别急着接平台，先在命令行里验证一下服务是否正常。这一步能帮你排除掉大部分基础问题。

最直接的方式是用命令行和模型对话，看它能不能正常响应。如果能正常对话，说明模型加载和服务暴露都没问题。然后可以进一步测试接口，用简单的请求工具向本地服务发一个请求，确认接口返回格式正确。

这里有个细节：首次加载模型会比较慢，因为要把模型文件读进内存或显存。如果你发现第一次请求卡了很久，别急着以为出问题了，等一会儿通常就好了。后续请求会快很多，因为模型已经常驻了。

验证的时候还要留意上下文长度。不同模型支持的上下文长度不一样，如果你发的请求超出了模型的处理能力，可能会报错或者被截断。在平台里配置模型时，这个参数要填对，否则会出现"明明模型能跑，但一接平台就出错"的情况。

4. 部署 AIFlowy：让模型变成真正的智能体平台

4.1 部署方式的选择与取舍

AIFlowy 的部署方式通常有几种：一键脚本、容器编排、源码编译。选择逻辑和 Ollama 类似，但我更倾向于推荐容器编排方式，原因是智能体平台往往依赖多个组件——后端服务、前端界面、数据库、可能还有向量库——用容器编排能把依赖关系理清楚，一键拉起整套环境。

一键脚本适合快速体验，但可定制性差，出问题不好排查。源码编译适合需要深度定制的人，但环境依赖多，编译过程容易卡在某个依赖上。

容器编排的代价是需要先有容器环境，而且对机器资源有一定要求。如果你的机器内存紧张，跑容器编排可能会比较吃力，这时候可以考虑精简部署，只跑核心组件。

部署前要确认几件事：端口有没有被占用、数据卷挂载路径是否正确、环境变量里的模型服务地址是否指向了 Ollama 的地址。这几项任何一项错了，平台都起不来或者连不上模型。

4.2 把 Ollama 接入 AIFlowy 的关键配置

平台起来之后，第一件事是配置模型接入。这一步的核心是告诉 AIFlowy：模型服务在哪、叫什么名字、怎么调用。

在模型配置界面里，你需要填模型服务的地址。如果 AIFlowy 和 Ollama 跑在同一台机器上，地址就是本地回环地址加端口；如果跑在不同机器上，要填 Ollama 所在机器的可达地址。这里有个坑：如果 AIFlowy 跑在容器里，容器内的"本地"和宿主机的"本地"不是一回事。容器里访问宿主机服务需要用特定的主机名或者宿主机网络地址，直接写回环地址会连不上。

模型名称要和你实际拉取的模型名一致。Ollama 里模型名是带标签的，比如模型名:版本标签，配置时要写全。填错了平台会报找不到模型。

还有一个容易忽略的参数是模型类型。平台通常要区分对话模型和嵌入模型，因为它们的调用方式不同。对话模型用于生成回复，嵌入模型用于把文本转成向量做检索。如果你要用知识库功能，两个都得配。很多人只配了对话模型，结果知识库检索一直失败，就是漏了嵌入模型。

4.3 第一次对话测试与常见报错

配置完模型，建一个最简单的对话应用测试一下。这一步的目的是验证"平台到模型"这条链路是通的。

如果对话正常返回，恭喜你，最核心的链路打通了。如果报错，按错误类型排查：

我遇到最多的是连接超时，十有八九是地址问题。特别是容器部署场景，容器网络和宿主机网络是隔离的，地址写法不对就连不上。排查的时候先在容器里用请求工具测一下能不能访问到 Ollama 地址，能通再去看平台配置。

5. 从"能对话"到"能干活"：智能体能力搭建

5.1 提示词模板：智能体的性格与边界

模型接进来只是第一步，真正决定智能体好不好用的，是提示词。同一个模型，提示词写得好和写得烂，效果天差地别。

AIFlowy 里通常有提示词模板管理功能，你可以为不同的应用配置不同的系统提示词。系统提示词的作用是设定智能体的角色、能力边界、输出格式。比如你要做一个客服助手，提示词里就要明确它的职责范围、不能回答什么、遇到不确定的情况怎么处理。

我写提示词的经验是：把规则写具体，别写空话。"你是一个专业的助手"这种话基本没用，模型不知道该专业到什么程度。要写成"你是一个电商客服助手，只回答订单、物流、退换货相关问题，其他问题引导用户联系人工客服，回答时语气友好，每次回复不超过三句话"。规则越具体，模型的行为越可控。

还有一个技巧是用示例约束输出格式。如果你需要模型输出结构化数据，在提示词里给一两个示例，比单纯描述格式要求有效得多。模型对示例的模仿能力很强，给例子能大幅提升格式稳定性。

5.2 工具调用：让智能体长出"手脚"

光会聊天不算智能体，能调用工具才算。工具调用的本质是：模型根据用户意图，决定调用哪个工具、传什么参数，平台执行工具并把结果返回给模型，模型再组织语言输出。

在 AIFlowy 里配置工具，通常要定义工具的名称、描述、参数结构。这里的关键是工具描述要写清楚，因为模型是靠描述来判断什么时候该调用这个工具的。描述模糊，模型就不知道该不该用。

举个例子，你有一个查询天气的工具。如果描述只写"查询天气"，模型可能在你问"今天适合出门吗"的时候不知道该不该调用。如果描述写成"根据城市名称查询该城市当前天气状况，当用户询问天气、温度、是否下雨、是否适合出行时使用"，模型就能准确判断调用时机。

工具的参数定义也要严谨。参数类型、是否必填、取值范围都要写清楚，否则模型可能传错参数导致调用失败。我见过因为参数没定义必填，模型有时候传有时候不传，导致工具执行时好时坏的情况。

5.3 知识库检索：给智能体装上"记忆"

大模型的知识有截止日期，而且不知道你的私有数据。知识库功能就是解决这个问题的：把你的文档切分、向量化、存进向量库，用户提问时先检索相关片段，再连同问题一起交给模型生成回答。

这套流程叫检索增强生成，核心环节有三个：文档切分、向量化、检索。每个环节都有讲究。

文档切分不是随便切，切得太碎会丢失上下文，切得太大检索精度下降。常见做法是按语义段落切，每段几百字，段之间留一点重叠，避免关键信息被切断。AIFlowy 里通常有切分参数可调，默认值不一定适合你的文档，要实际测。

向量化依赖嵌入模型，这就是前面说的为什么嵌入模型也要配。嵌入模型的质量直接决定检索效果，选一个在中文上表现好的嵌入模型很重要。

检索环节要调的是返回条数。返回太少可能漏掉关键信息，返回太多会超出模型上下文还引入噪声。一般从 3-5 条开始调，根据实际效果增减。

注意：知识库的效果高度依赖原始文档质量。如果文档本身排版混乱、信息重复，检索效果很难好。花时间整理文档，比反复调参数更有效。

6. 工作流编排：把零散能力串成完整任务

6.1 什么场景该用工作流

不是所有任务都需要工作流。如果只是简单问答，一个对话应用就够了。工作流的价值在于多步骤、有条件分支、需要多个能力协作的场景。

判断标准很简单：如果你的任务可以描述成"先做 A，根据 A 的结果决定做 B 还是 C，最后汇总输出"，那就该用工作流。比如"接收用户问题，先判断问题类型，如果是数据类问题查数据库，如果是知识类问题查知识库，最后统一格式输出"，这就是典型的工作流场景。

用工作流的好处是流程显式化，每一步做什么、怎么流转都看得见，调试和优化都有抓手。坏处是灵活性下降，遇到流程外的输入可能处理不好。所以设计工作流时，要留一个兜底分支处理意外情况。

6.2 节点设计与数据流转

工作流由节点和连线组成。节点是执行单元，连线定义流转方向。设计工作流的核心是想清楚数据怎么在节点之间流动。

每个节点有输入和输出。上游节点的输出会作为下游节点的输入。这里要注意数据格式的匹配：上游输出的是文本，下游期望的是结构化数据，中间就得加一个转换节点。很多工作流跑不通，问题就出在节点之间的数据格式对不上。

条件分支节点是工作流里最需要小心的地方。分支条件写得不严谨，可能导致某些输入走进死胡同。我的做法是：每个条件分支都配一个默认分支，处理所有不满足明确条件的情况，保证流程不会卡住。

循环节点要慎用。循环次数没控制好可能导致无限循环，把资源耗光。如果确实需要循环，一定要设最大循环次数作为保护。

6.3 调试工作流的实用方法

工作流调试比单节点调试麻烦，因为问题可能出在任何一个环节。我的调试思路是分段验证。

先把工作流拆成几段，每段单独测。比如一个三段式工作流，先测第一段能不能正常输出，再接上第二段测，最后接第三段。这样出问题能快速定位到是哪一段。

平台通常有执行日志，能看到每个节点的输入输出。这是排查问题的关键工具。看日志的时候重点看：节点有没有被执行、输入是什么、输出是什么、耗时多少。如果某个节点没执行，说明上游流转条件没满足；如果执行了但输出不对，说明节点配置有问题。

还有一个技巧是用固定输入测试。调试阶段别用随机输入，用几个固定的、有代表性的输入反复测，这样问题更容易复现，也方便对比修改前后的效果。

7. 性能与稳定性：让平台真正能长期用

7.1 响应速度的优化方向

本地模型的响应速度受几个因素影响：模型大小、硬件性能、并发量、上下文长度。优化要从瓶颈入手。

如果单次响应就慢，先看模型是不是走了 CPU。显存够的话模型应该在 GPU 上跑，速度差好几倍。确认方法很简单，跑推理的时候看显卡占用，占用高说明在用 GPU，占用低说明在跑 CPU。

如果并发一上来就慢，那是资源竞争问题。单张显卡同时处理多个请求会排队，响应时间线性增长。解决办法要么限制并发数，要么上多卡。本地场景一般并发不高，限制一下并发数就能缓解。

上下文长度对速度影响也很大。上下文越长，每次推理要处理的内容越多，速度越慢。如果业务不需要长上下文，把配置调小能明显提速。

7.2 模型常驻与按需加载的权衡

Ollama 支持模型常驻内存，也支持按需加载。常驻的好处是响应快，不用每次加载；坏处是占资源，多个模型常驻可能把显存占满。

我的策略是：常用的模型常驻，不常用的按需加载。比如你日常就用一个 7B 模型，那就让它常驻；偶尔测试的大模型，用完就卸载，把资源让出来。

Ollama 有参数可以控制模型在空闲多久后自动卸载。设得太短，频繁加载卸载反而慢；设得太长，资源一直占着。一般设个几分钟比较合理，具体看你的使用频率。

7.3 日志与监控：出问题时你能看到什么

平台长期运行，日志和监控是必须的。没有这些，出问题只能靠猜。

要关注的日志有几类：模型服务的日志，看模型加载、推理有没有报错；平台服务的日志，看请求处理、工作流执行的情况；系统资源日志，看 CPU、内存、显存的使用趋势。

监控方面，至少要能看到显存占用和请求响应时间。显存占用持续走高可能是内存泄漏，响应时间突然变长可能是资源竞争。这些指标能帮你在问题变严重之前发现苗头。

我习惯定期看一眼资源占用曲线，如果发现某个指标有异常趋势，提前处理，别等它崩了再救火。

8. 我踩过的那些坑与对应的解法

8.1 容器网络导致的连接失败

这个坑我在不同项目里踩过好几次。AIFlowy 跑在容器里，Ollama 跑在宿主机，配置里填了本地回环地址，结果一直连不上。

原因是容器有自己的网络命名空间，容器里的回环地址指向容器自己，不是宿主机。解决办法是用宿主机在容器网络里的可达地址，或者让容器使用宿主机网络模式。不同容器运行时的具体写法不一样，但思路是一样的：先确认容器能不能访问到目标地址，再去配平台。

排查方法是在容器里执行一个简单的网络请求，看能不能通。能通说明地址对，问题在平台配置；不能通说明地址本身就不对，先解决网络连通性。

8.2 模型名带标签引发的找不到模型

Ollama 的模型名是带标签的，比如默认标签是latest。你在命令行里run的时候可以省略标签，但平台配置里如果省略了，有些平台会找不到。

我遇到过配置里写模型名，平台报找不到，加上:latest就好了。所以配置模型名的时候，最好把完整名称带上标签，别偷懒省略。

8.3 上下文长度配置不当导致的截断

这个问题比较隐蔽，因为模型能正常返回，只是内容不完整。表现是长文档问答时，回答只覆盖了文档前半部分。

原因是平台配置的上下文长度小于实际输入长度，超出部分被截断了。解决办法是根据模型能力和业务需求，把上下文长度配够。但也不能无限大，超出模型本身支持的上限会报错。要查清楚你用的模型支持多长的上下文，在这个范围内配置。

8.4 知识库检索效果差的排查顺序

知识库效果差是高频问题，排查要有顺序，别乱调。

先看文档切分是否合理。把切分后的片段拿出来看，如果片段语义不完整，说明切分参数不对。再看嵌入模型是否合适，中文场景要用中文表现好的嵌入模型。然后看检索条数，太少漏信息，太多引噪声。最后才看提示词，提示词里要明确告诉模型基于检索内容回答，不要自己编。

按这个顺序排查，大部分问题都能定位到。我见过有人一上来就改提示词，改了半天没用，其实是文档切分就错了。

8.5 显存不足时的降级策略

显存不足是硬件限制，没法凭空变出来，但可以降级。

第一选择是换更小的模型，7B 换 3B，效果有损失但能跑起来。第二是换更低的量化等级，Q4 换 Q3，体积更小。第三是缩短上下文长度，减少显存占用。第四是限制并发，避免多个请求同时占用显存。

这几个策略可以组合使用。我的经验是优先换小模型，因为量化等级降太多效果损失明显，而小模型在特定任务上经过提示词优化，效果可能比预期好。

9. 后续可以怎么扩展

平台跑通之后，能做的事情还有很多。我列几个我实际做过或者正在做的方向。

一是接入更多工具。除了内置工具，可以自己写工具接进来，比如接内部系统的 API、接文件处理能力、接代码执行环境。工具越丰富，智能体能干的活越多。

二是多模型协同。不同模型擅长不同任务，可以配一个路由逻辑，简单任务用小模型，复杂任务用大模型，兼顾速度和效果。

三是做领域微调。如果通用模型在你的领域表现不够好，可以拿领域数据做微调，再把微调后的模型接进平台。Ollama 支持加载自定义模型，微调完转成对应格式就能用。

四是加缓存层。高频重复的问题可以缓存答案，减少模型调用，提升响应速度也省资源。

五是做多租户隔离。如果团队多人使用，可以做用户隔离，每个人的会话、知识库、配置互不干扰。

这些扩展不是必须的，按需选择。我的建议是先把基础链路跑稳，再逐步加能力，别一上来就堆功能，那样出问题都不知道是哪块引起的。

最后分享一个我自己的习惯：每次搭完一套环境，我都会写一份自己的部署笔记，记录版本号、配置项、踩过的坑。过几个月再回来维护的时候，这份笔记能省下大量重新摸索的时间。本地部署这套东西，版本迭代快，配置细节多，好记性不如烂笔头。