企业官网建设流程全解析

简介：面向内网环境的DeepSeek离线部署实战指南，专为政企单位IT运维人员及技术爱好者编写，解决无互联网条件下引入大模型、构建RAG知识库的难题，兼顾国产化适配与安全加固需求。资源为单个PDF文档，体积5.28MB，便于内部网络分发查阅。内容系统覆盖离线资源准备（模型、Ollama安装包、客户端及可选RAG依赖的获取与导入方式）、Windows/Linux/macOS多平台部署步骤、两种RAG数据投喂方案（其中Cherry Studio方式尤其适合新手），以及Ollama API、Lobe Chat和宝塔面板的访问控制与权限管理实践。针对内网常见痛点，还补充了文件完整性校验、大文件分割合并、国产操作系统与CPU架构兼容性等细节，可帮助读者规避部署中的典型坑点。目前已有1372人学习/浏览，无论作为教学手册还是运维排错参考，都具备较强的实用价值。

1. DeepSeek 离线部署：内网 AI 知识库的水远比想象深

我第一次在内网部署 DeepSeek 时，以为 U 盘一插、安装包双击就能跑，结果模型文件几百个 G，光导入就折腾了一下午。真正想搭一个可用的内网 AI 知识库，核心是离线资源这条链路：GGUF 文件怎么导入 Ollama、OLLAMA_HOST 怎么暴露给内网机器、RAG 数据怎么喂、API 怎么防未授权访问。这套环境在政企内网出镜率极高，可网上的教程大多默认你有外网权限，pip install、git clone 一条龙，内网用户根本走不通。这篇按“装什么、怎么装、坏了怎么救”的顺序写，覆盖 Windows Server、Linux（含国产系统）和 macOS，适合正在做内网 AI 知识库落地的运维人员。照着一路走完，你得到的不是一个能聊天的模型，而是一套可用的内网知识库。

2. 离线资源准备：模型包、Ollama 与客户端的选择

2.1 模型离线包：GGUF 格式、SHA256 校验与内网导入

离线部署的第一步是拿到模型文件。DeepSeek 这类模型在推理框架里最常用的格式是 GGUF，由 llama.cpp 项目定义，Ollama 可以直接读取。不要去找 .bin 或 .safetensors 的原始权重，那个格式 Ollama 玩不转，还得自己转，纯属给自己加戏。下载 GGUF 文件时，优先看官方发布的版本，再根据硬件条件选量化档位。

同一个模型会有 q4_k_m、q5_k_m、q8_0 等不同量化精度，q4 体积最小、精度损失可接受，q8 体积最大、效果更接近原版。我的经验是：7b/8b 参数级别选 q4_k_m，内网办公机器普遍带得动；32b 以上选 q5 或 q8 就得先算清楚内存，模型文件加 KV Cache，内存建议不小于模型文件大小的 1.5 到 2 倍。选模型时按这个对照表先圈定范围，再决定下载哪一档：

文件到手之后，第一件事不是导入，是校验。模型文件在下载、拷贝、传输过程中损坏的情况我见过太多次，GGUF 文件损坏后 Ollama 不一定报“文件损坏”，它可能直接加载失败，日志里只有一句 failed to load model，非常难查。

# Linux / macOS 校验模型文件 sha256sum deepseek-r1-7b-q4_k_m.gguf

# Windows PowerShell 校验 Get-FileHash .\deepseek-r1-7b-q4_k_m.gguf -Algorithm SHA256

计算出来的哈希值要和下载页面给出的官方哈希比对，一致才说明文件完整。这一步虽然是玄学重灾区，但一旦跳过，后面导入失败、推理崩溃会花掉你成倍的时间去排查。校验通过后就是物理搬运，U 盘、移动硬盘、内网共享文件夹都可以；如果模型文件大到几百 G，内网文件共享是比 U 盘靠谱得多的方式。更极端的场景可以用安全网闸做数据交换，不过大多数内网项目没这个条件，我一般直接用共享文件夹加 sha256sum 双重保险。文件超过单盘容量时，Linux 用 split 分割、cat 合并，Windows 用 7-Zip 做分卷压缩，分卷合并后要重新校验一次哈希。

2.2 Ollama 与客户端离线包：跨平台安装与镜像搬运

Ollama 本身是个轻量级程序，离线准备相对简单。Windows 直接在外网机器下载安装包拷进内网；Linux 更常见的做法是在有网的机器上执行官方安装脚本，装好后从 /usr/bin 或 /usr/local/bin 把 ollama 二进制文件拷走，这个二进制是自包含的，不需要额外带依赖库。macOS 同样是拿安装脚本产物或 Homebrew 缓存里的包，拷到内网后装在同一路径即可。

客户端的离线准备要看选哪种连接方式。内网部署 DeepSeek 最常见的两条客户端路线：Cherry Studio 这类桌面客户端，直接从官网下安装包，不需要容器；Lobe Chat 这类 Web 界面，走 Docker 部署，因为支持用户管理和访问码控制，多人共用一台服务器时更合适。两条路线的取舍我列在下面：

# 在外网机器拉取 Lobe Chat 镜像并保存为 tar 文件 docker pull lobehub/lobe-chat docker save -o lobe-chat.tar lobehub/lobe-chat

这里 docker save 会把镜像打包成单个 tar 文件，之后把 lobe-chat.tar 拷到内网服务器，再执行 docker load -i lobe-chat.tar 导入。离线环境没有镜像仓库可用，tar 包是最直接的搬运方式。需要注意 save 和 load 是配套的，不要混用 docker export 和 docker import，那是对容器的操作，导出的东西启动时会缺镜像元数据，容易翻车。

2.3 Modelfile 导入：从裸权重到 ollama list 可见

模型文件和 Ollama 都备齐了，接下来就是把 GGUF 导入到 Ollama 里。导入操作依赖一个叫 Modelfile 的文本文件，它的作用类似 Dockerfile，告诉 Ollama“用哪个基础文件、起什么名字”。先把模型目录整理成下面这样：GGUF 文件和 Modelfile 放在同一个目录，Modelfile 里写一行 FROM，指向 GGUF 文件名。文件名是什么，FROM 就写什么，不要写绝对路径到别的目录，否则 ollama create 会一直找不到文件。

# Modelfile 内容，和模型文件同目录 FROM ./deepseek-r1-7b-q4_k_m.gguf

然后在模型目录里执行：

cd /path/to/model/dir ollama create deepseek-r1:7b -f Modelfile ollama list

ollama create 的 -f 参数指定 Modelfile 路径，deepseek-r1:7b 是给模型起的名字，冒号后面是 tag，可以按量化档位或参数规模区分。导入完成后 ollama list 里能看到这个条目，说明模型已经进了 Ollama 的模型仓库。RAG 需要的文本向量模型（比如 nomic-embed-text、bge 系列）也用同样的方式导入，只是 Modelfile 的 FROM 指向对应的 GGUF 文件。

提示：Modelfile 里还可以追加 TEMPLATE、PARAMETER 等配置项，比如上下文长度 num_ctx、温度 temperature。但离线部署第一步不要加任何额外参数，先让模型能跑起来，再逐个加，出问题才好定位是哪一行配置引起的。

3. 多平台部署：Windows Server 与 Linux 的细节差异和国产化适配

3.1 Windows Server：OLLAMA_HOST 环境变量与防火墙入站

Windows Server 上装 Ollama 是最直观的：双击安装包，下一步，完成。但装完之后有个最大的坑——默认情况下 Ollama 只监听 127.0.0.1，也就是只有本机能访问。你在服务器上把模型聊得飞起，内网其他同事一访问就连接拒绝，原因十有八九就是 OLLAMA_HOST 没改。

打开“此电脑 → 属性 → 高级系统设置 → 环境变量”，在系统变量里新建 OLLAMA_HOST，值填 0.0.0.0:11434。这一步必须建在“系统变量”而不是“用户变量”，因为 Ollama 服务是以系统服务方式运行的，读的是系统级配置。同时再新建一个 OLLAMA_MODELS，把模型目录指到你放 GGUF 文件的位置，避免默认把几个百 G 的文件塞到 C 盘。

配置完环境变量后，重启 Ollama 服务让配置生效。在 PowerShell 里执行：

Restart-Service Ollama Get-Service Ollama Get-Process -Name ollama

Get-Service 确认服务状态是 Running，Get-Process 确认进程存在。如果服务起不来，去 Windows 事件查看器里翻应用程序日志，Ollama 启动阶段的错误通常都会记录在里面，比在命令行干瞪眼有用得多。环境变量只是让 Ollama 开始监听所有网卡，Windows 防火墙默认还会拦外部访问。在“Windows Defender 防火墙 → 高级设置 → 入站规则”里新建一条规则，放行 TCP 11434 端口，或者用命令一行搞定：

netsh advfirewall firewall add rule name="Ollama API" dir=in action=allow protocol=TCP localport=11434

我一般在 Windows Server 2019/2022 上这么操作，都验证过。装完这台服务器的同事用 Cherry Studio 连 http://服务器IP:11434 就能直接访问，不用再折腾客户端。

3.2 Linux：systemd 服务、bashrc 与防火墙放行（含国产系统差异）

Linux 部署比 Windows 多一个选择题：用 nohup 后台跑，还是用 systemd 托管。我的建议是直接上 systemd，原因很简单——内网服务器一重启，nohup 进程不会自动拉起来，到时候人不在现场，服务挂了你都不知道。先把 ollama 二进制放到 /usr/local/bin 并赋执行权限：

sudo cp ollama /usr/local/bin/ sudo chmod +x /usr/local/bin/ollama

然后写 systemd 服务文件。这里有个很容易被忽略的点：OLLAMA_HOST 环境变量如果只写在 ~/.bashrc 里，systemd 启动的服务是读不到的，因为 systemd 有自己的环境上下文。所以要么写在服务文件里，要么写在 /etc/profile 里。

# /etc/systemd/system/ollama.service [Unit] Description=Ollama Service After=network-online.target [Service] User=ollama Group=ollama WorkingDirectory=/data/ollama ExecStart=/usr/local/bin/ollama serve Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/data/ollama/models" Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

sudo systemctl daemon-reload sudo systemctl enable --now ollama systemctl status ollama

ExecStart 指向 ollama serve，OLLAMA_MODELS 路径要确保目录存在且属主是 ollama 用户，否则服务启动时在模型目录上直接栽跟头。Restart=always 是给服务买的“后悔药”，进程意外退出后 10 秒自动拉起，内网环境没有人在旁边盯着，这个参数务必保留。如果你只是临时测一下，不想写 systemd，也可以在 ~/.bashrc 里加 export OLLAMA_HOST="0.0.0.0:11434"，然后 source ~/.bashrc，再手动 ollama serve 前台跑。但这不是长期方案，测试归测试，生产环境一律 systemd。

防火墙部分按发行版区分。CentOS/RHEL 系用 firewall-cmd，Ubuntu/Debian 系用 ufw：

# CentOS / RHEL sudo firewall-cmd --permanent --add-port=11434/tcp sudo firewall-cmd --reload # Ubuntu / Debian sudo ufw allow 11434/tcp

适配国产 Linux 发行版时，先别急着照搬命令，看它继承的是 apt 系还是 yum 系的包管理。大部分国产发行版都能直接跑上面的 systemd 配置，个别的会启用 SELinux，导致 Ollama 无法读取模型目录。处置方式不是关 SELinux，而是给它放行，先执行 getenforce 看当前状态，再按下面的方式设置：

sudo semanage fcontext -a -t textrel_shib_t "/data/ollama/models(/.*)?" sudo restorecon -Rv /data/ollama/models

这一步报错就去查 SELinux 的 avc 拒绝日志，别一上来就 setenforce 0，内网环境的安全策略不能被一个模型服务带偏。

3.3 macOS：LaunchAgents 与客户端连接

macOS 上装 Ollama 最简单，官方脚本或 Homebrew 二选一：

brew install ollama # 或者 curl -fsSL https://ollama.com/install.sh | sh

装完同样要改 OLLAMA_HOST，编辑 ~/.zshrc 写入 export OLLAMA_HOST="0.0.0.0:11434"，然后 source ~/.zshrc。macOS 上如果只想本机用，保持默认 localhost 就好，不用暴露。需要开机自启的，用 launchctl 注册一个 LaunchAgent，plist 文件放到 ~/Library/LaunchAgents/ 下，内容如下：

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.ollama.serve</string> <key>ProgramArguments</key> <array> <string>/usr/local/bin/ollama</string> <string>serve</string> </array> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/> </dict> </plist>

这一步不是必须的，但如果你把 Mac mini 当内网服务器用，没有它每次重启后都要手动起服务。系统设置里的防火墙需要允许 ollama 接受传入连接，否则内网机器一样连不上。客户端连接方式跟 Windows/Linux 一致，把服务器地址填成 http://mac主机IP:11434 即可。

4. 离线数据投喂：从文本解析到 Cherry Studio 的 RAG 落地

4.1 文档预处理：DOCX/PDF 解析与中文分块

模型跑起来只是第一步，做内网 AI 知识库，核心是把单位里的文档变成模型能检索的知识。离线环境里没有在线 API 可用，所以数据投喂这步得自己把文档解析、分块、向量化做完。这里的两条路线，我建议按团队情况选：想完全可控、后期要自定义检索逻辑的走 Python 链路；文档量不大、想快速见效的用 Cherry Studio，两条路的对比后面会说。

先处理文档。最常见的格式是 DOCX 和 PDF，分别用 python-docx 和 pdfminer.six 解析，中文分词用 jieba。这几个库在内网装起来比较费劲，提前在外网机器把 wheel 包装好拷进去，pip install 本地文件。代码逻辑很直白：

from docx import Document # 读取 DOCX 全部段落 doc = Document("公司制度.docx") text = "\n".join(p.text for p in doc.paragraphs)

# PDF 提取为纯文本 pdf2txt.py 产品手册.pdf -o output.txt

DOCX 解析用 paragraph 拿段落文本，注意不要用 doc.text 这种属性，python-docx 没有这个接口；PDF 用 pdf2txt.py 命令，-o 指定输出文件。解析出来的文本先清洗，把多余换行、特殊符号和表格里的碎片去掉，再按固定大小分块。分块是 RAG 效果的关键，块太小检索时语义不完整，块太大向量化后内容被稀释，既费资源又容易召回无关内容。

def chunk_text(text, size=500, overlap=50): """按字符切分，相邻块保留重叠""" chunks = [] for i in range(0, len(text), size - overlap): chunks.append(text[i:i + size]) return chunks

常见做法是按 500 个字符左右切一块，相邻块之间重叠 50 字符，保证跨块语义不断裂。中文本就按字符切，不需要数 token，这是离线 RAG 方案里最容易理解也最稳的参数。如果你的文档本身以章节为主，可以先把段落按标题拆开，再套用 chunk_text，效果会比直接全文硬切好很多。

4.2 向量化与向量库：sentence-transformers 与 ChromaDB

分好的文本块要转成向量，才能在提问时做相似度检索。离线环境没有在线 embedding 服务，用 sentence-transformers 加载本地模型，中文场景推荐 bge 系列的中文向量模型，比如 bge-large-zh-v1.5。模型文件提前下好放进内网，加载时直接指本地路径。

from sentence_transformers import SentenceTransformer model = SentenceTransformer("/data/models/bge-large-zh-v1.5") sentences = ["这是第一段知识内容", "这是第二段知识内容"] embeddings = model.encode(sentences)

encode 返回的是每个句子的向量数组，bge 模型输出维度通常是 1024，这个维度后面存 ChromaDB 时会用到。向量模型 GGUF 归 GGUF，这里是 sentence-transformers 格式的目录，别把两者搞混。向量数据库我用 ChromaDB，默认本地文件存储，适合内网单机环境。创建集合后把 embedding、原文、元数据、ID 一起塞进去：

import chromadb client = chromadb.Client() # 默认本地存储 collection = client.create_collection("knowledge_base") collection.add( embeddings=embeddings, documents=["这是第一段知识内容", "这是第二段知识内容"], metadatas=[{"source": "doc1"}, {"source": "doc2"}], ids=["id1", "id2"] )

documents 里存的是可读原文，检索命中后可以展示给用户；metadatas 存来源信息，便于追溯；ids 是唯一标识，重复导入会覆盖。ChromaDB 的本地存储目录默认为 ./chroma，生产环境建议把路径指到大磁盘，别默认放系统盘。查询时把用户问题也过一遍向量模型，然后到 collection 里找最接近的块：

question_emb = model.encode(["备份策略是什么"]) results = collection.query( query_embeddings=question_emb, n_results=5 ) print(results["documents"])

4.3 新手推荐：Cherry Studio 投喂知识库与 RAG 配置

上面这套 Python 链路，老手可控性最高，但对新手不太友好：要处理离线依赖、要写脚本、要管向量库。如果单位里没有人专门维护这套流程，我更推荐用 Cherry Studio 客户端直接投喂。它把文档解析、分块、向量化、检索全部封装了，你只需要做两件事：把文档拖进去，把模型地址配上。

打开 Cherry Studio 设置，添加 Ollama 服务，地址填 http://内网服务器IP:11434，模型选 deepseek-r1:7b。然后在设置里导入文本向量模型，Cherry Studio 支持连接 Ollama 上的 nomic-embed-text，导入后才能做知识库的向量化。最后新建知识库，把本地文档直接拖进去，客户端自动完成分块和索引。这一步适合大多数业务场景：文档不是特别多、不需要自定义分块策略、没有严格的权限要求。Cherry Studio 的方案能让你跳过 4.1 和 4.2 的所有代码，把精力留在业务数据梳理上。等知识库文档量上来、检索效果不满意时，再退回 Python 链路做精细调优。

5. 安全加固与常见问题排查：Ollama 访问控制与内网部署翻车记录

5.1 Ollama API 访问控制：从 0.0.0.0 到可信网段

OLLAMA_HOST 设为 0.0.0.0:11434 之后，Ollama 的 API 就完全裸露在内网里了。任何能访问这个端口的人都可以拉走模型列表、发起推理请求，更严重的还可以下载模型文件。内网不是绝对安全，这个口子必须收住。第一个做法是防火墙白名单，11434 端口只放行指定的可信终端 IP，而不是对所有网段开放。

sudo firewall-cmd --permanent --remove-port=11434/tcp sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.10.0/24 port port=11434 protocol=tcp accept' sudo firewall-cmd --reload

先用 remove-port 把之前放行的全量端口规则删掉，再通过 rich-rule 精确到来源网段。这样只有 192.168.10.0/24 网段的机器能访问 11434，其他网段一律拒绝。第二个做法是前置认证。如果多人共用服务器、且需要通过 Web 界面访问，优先用 Lobe Chat 这类带访问码的客户端，启动时把访问码和 Ollama 地址一起传进去：

docker run -d -p 3210:3210 \ -e ACCESS_CODE=你的访问码 \ -e OLLAMA_BASE_URL=http://内网服务器IP:11434 \ -e OLLAMA_API_MODEL=deepseek-r1:7b \ --name lobe-chat \ lobehub/lobe-chat

ACCESS_CODE 是 Lobe Chat 的访问认证码，配好后没输入正确代码的人连页面都打不开；OLLAMA_BASE_URL 让 Web 服务作为唯一入口，外部不直接接触 11434。如果用服务器管理面板（比如宝塔）来管这台机器，面板的安全功能里也能做同样的事：放行端口时限定来源 IP，或者在面板里建反向代理，把 Ollama API 挂在带 Basic Auth 的路径后面，然后把 11434 端口对公网关闭，所有请求强制走代理认证。面板能做的是把防火墙规则、反向代理、访问认证集中到一个界面，省得每条规则都敲命令。

提示：不管用哪种方式，部署完一定要从内网另一台机器用 curl 测一下未授权访问是否已被拦截。我见过太多以为配了认证、实际防火墙没生效的情况，这个验证动作放在第 6 章，别跳过。

5.2 现象：Ollama 服务起不来，systemctl 显示 failed

原因：最常见是 OLLAMA_MODELS 指向的目录不存在或属主不对，其次是 11434 端口被占用，偶发在国产系统上是内核版本与二进制不兼容。解决：先看日志，systemctl status ollama 和 journalctl -u ollama -n 50 会给出最直接的报错；确认模型目录已创建，chown 给 ollama 用户；用 ss -lntp | grep 11434 查端口占用，有进程占着就换端口或停掉冲突服务。如果是内核版本太老，需要换用官方针对旧系统的兼容版本或改用源码自编译。

5.3 现象：内网其他机器访问不了 11434，curl 超时

原因：OLLAMA_HOST 仍然默认 127.0.0.1，或者防火墙没放行。这两个原因经常同时存在，只改一个必然还是不通。解决：先确认 OLLAMA_HOST 已改成 0.0.0.0:11434 并重启服务；再在服务器本机执行 curl http://127.0.0.1:11434/api/tags 确认服务正常；最后从其他机器 curl http://服务器IP:11434/api/tags。本机通、其他机器不通，就是防火墙，回 5.1 改规则。还有一个隐蔽场景：服务器上有多个网卡，Ollama 监听到了 0.0.0.0，但客户端访问的是内网里不通的地址，这种情况要查路由而不是查端口。

5.4 现象：Modelfile 导入时报错或 ollama list 为空

原因：Modelfile 和 GGUF 不在同一目录，或 FROM 写的是绝对路径但文件已被移动；也可能 ollama create 执行时当前目录并不是模型目录。解决：检查 Modelfile 内容，FROM 后面只写同目录下的文件名；执行 ollama create 前先 cd 到模型目录；如果之前用绝对路径创建过，重新用正确路径再 create 一次。ollama list 为空还有一个常见原因：OLLAMA_MODELS 环境变量被改过，新模型写到了另一个模型仓库，而 ollama list 读的是当前生效的路径。把环境变量对齐，重新导入一次即可。

5.5 现象：国产系统部署异常与知识库问答答非所问

国产系统部署异常的原因多出在架构选错。Ollama 有 x86_64 和 arm64 两套二进制，先确认 CPU 架构，用 uname -m 查看，再选择对应版本。把 x86 的二进制拷到 arm64 机器上，启动时会直接报 Exec format error。另外部分国产系统自带 SELinux，模型目录没有放行会导致读取拒绝，按 3.2 的 semanage 命令处理。知识库问答答非所问，先不要怀疑模型，内网模型一旦跑起来生成能力基本是稳定的，问题大多在 RAG 链路。500 字符的分块对长文档可能太碎，尝试调到 800 到 1000 字符并增加重叠量；检索时如果返回的候选太少，调大 n_results 或 top_k；embedding 模型如果是中文文档却用了英文向量模型，语义匹配会非常差，换 bge 中文模型重新向量化。按这个顺序调一轮，绝大多数“答非所问”都能缓解。

6. 装完怎么验证跑通：从模型问答到 RAG 检索的全链路检查

部署完成不等于能用，我每次在内网把 DeepSeek 这套环境装完，都会强制按下面四步走一遍，全部通过才敢交付。第一步验证服务：Linux 执行 systemctl status ollama，Windows 执行 Get-Service Ollama，服务状态必须是 running。第二步验证模型：执行 ollama list，确认 deepseek-r1 和向量模型都在列表里。第三步用 curl 直接打 API，这一条能同时验证模型加载和推理链路：

curl http://127.0.0.1:11434/api/generate \ -d '{"model": "deepseek-r1:7b", "prompt": "你好，请回复收到", "stream": false}'

返回 JSON 里有 response 字段说明模型推理正常。前两步都通过、这一步失败，问题基本锁定在模型文件或显存、内存不足。接下来从内网另一台机器用 http://服务器IP:11434/api/tags 访问一次，能返回模型列表说明网络链路和防火墙都通了。

第四步验证 RAG。打开 Cherry Studio 或 Lobe Chat，在知识库界面提问一个只有你上传文档里才有答案的问题，比如“根据刚上传的《运维手册》，备份策略是什么”。如果回答内容引用了文档里的原话，说明 RAG 链路完整。这里有个小技巧：提问时限定“根据资料回答”，能逼着客户端走检索而不是让模型自由发挥。四步验证做完，再把安全项过一遍：从非白名单机器访问 11434 应被拒绝，访问 Lobe Chat 页面应弹出访问码输入框。

从那以后，我每次在内网部署完这套环境，都会强制走一遍“服务状态 → ollama list → curl generate → 知识库提问”四步验证，宁可多花三分钟，也不交付一个带着暗伤的黑匣子。这四步做完，你手里的内网 AI 知识库才算真正跑通，希望帮到你。

本文还有配套的精品资源，点击获取