在无法访问外网的环境中部署 Dify 时，插件安装是最大的障碍之一。本文记录了从打包到成功安装的完整过程，以及途中遇到的三个关键问题和解决方案。

背景

Dify 1.0 引入了插件系统，插件以 .difypkg 格式分发。在线环境下，可以直接从 Marketplace 一键安装。但在离线（air-gapped）环境中，plugin daemon 无法联网下载 Python 依赖，安装必然失败。

社区提供了 dify-plugin-repackaging 工具，可以将插件重打包为带有全部 Python 依赖的离线包。但实际操作中，我踩了三个坑，花了不少时间才最终搞定。最后我自己用 Claude 临时修改了一个版本的重打包脚本：dify-plugin-repackaging。

本地环境

• Dify 通过 Docker Compose 部署
• Plugin daemon 镜像：langgenius/dify-plugin-daemon:0.5.3-local
• 容器环境：Ubuntu 24.04, Python 3.12.3, uv 0.9.26
• 目标插件：langgenius/openai_api_compatible:0.0.35

离线打包基本流程

使用 plugin_repackaging.sh 脚本，三种输入方式：

# 从 Marketplace 下载并重打包
./plugin_repackaging.sh market langgenius openai_api_compatible 0.0.35

# 从 GitHub Release 下载并重打包
./plugin_repackaging.sh github langgenius/dify-plugin-xxx v0.0.1 xxx.difypkg

# 从本地已有包重打包
./plugin_repackaging.sh local ./langgenius-openai_api_compatible_0.0.35.difypkg

脚本的核心逻辑（repackage() 函数）：

1. 解压 .difypkg（实际是 zip）
2. pip download 把 requirements.txt 中的所有依赖下载到 ./wheels/
3. 将 sdist 格式的包编译为 wheel
4. 在 requirements.txt 头部插入 --no-index --find-links=./wheels/
5. 用 dify-plugin CLI 重新打包为 *-offline.difypkg

安装时，在 Dify 控制台的插件管理页上传这个离线包即可。

环境配置

离线包通常未经 Marketplace 签名，且体积较大，需要调整 .env：

# 允许安装未签名插件
FORCE_VERIFYING_SIGNATURE=false

# 放大包体限制到 500MB
PLUGIN_MAX_PACKAGE_SIZE=524288000

# Nginx 上传限制也要放大
NGINX_CLIENT_MAX_BODY_SIZE=500M

改完后 docker compose up -d 重启。

坑一：daemon 用的是 uv，不是 pip

现象

上传离线包后，daemon 报错：

error: Request failed after 3 retries
Caused by: Failed to fetch: `https://pypi.org/simple/setuptools/`
Caused by: dns error: failed to lookup address information: Name or service not known

明明 wheels 都打进了包里，为什么还在联网？

原因

打包脚本在 requirements.txt 头部加了 --no-index --find-links=./wheels/，这是 pip 的语法。但 Dify 的 plugin daemon 使用的是 uv（日志可见 uv 0.9.26），它通过 uv sync 读取 pyproject.toml 来解析依赖，完全忽略 requirements.txt 中的 pip 选项。

解决

在 pyproject.toml 中添加 [tool.uv] 配置，告诉 uv 使用本地 wheels：

[tool.uv]
no-index = true
find-links = ["./wheels/"]

同时修改 plugin_repackaging.sh，在打包流程中自动注入这段配置（新增 inject_uv_offline_config() 函数）。

坑二：Python 版本不匹配

现象

加了 [tool.uv] 配置后，不再联网了，但报新错误：

gevent==25.5.1 cannot be used.
And because dify-plugin==0.7.1 depends on gevent==25.5.1,
your project's requirements are unsatisfiable.

原因

我本机是 Python 3.13，pip download 下载的 wheel 都是 cp313 标签的（如 gevent-25.5.1-cp313-cp313-manylinux_2_17_x86_64.whl）。但 daemon 容器里是 Python 3.12.3，cp313 的 wheel 无法在 3.12 上使用。

解决

两种方式：

1. 用 Python 3.12 执行打包脚本（推荐），下载的 wheel 标签就是 cp312
2. 指定平台参数：./plugin_repackaging.sh -p manylinux_2_17_x86_64 local xxx.difypkg

坑三：uv 的 universal resolution 与离线模式冲突

现象

换成 Python 3.12 后，wheels 标签正确了，但还是报错：

Because only cffi{platform_python_implementation == 'CPython' and
sys_platform == 'win32'}<1.17.1 is available and gevent==25.5.1 depends
on cffi{...sys_platform == 'win32'...}>=1.17.1,
we can conclude that gevent==25.5.1 cannot be used.

补上 cffi 后，又冒出来：

Because there are no versions of colorama{sys_platform == 'win32'}
and tqdm==4.67.1 depends on colorama{sys_platform == 'win32'},
we can conclude that tqdm==4.67.1 cannot be used.

原因

这是 uv 和 pip 的核心行为差异：

uv 为了生成跨平台通用的 lock 文件，会同时为 Linux、Windows、macOS 等所有平台解析依赖。在有网络的情况下这没问题，但在 no-index 离线模式下，wheels 目录里当然只有 Linux 的包，Windows-only 的依赖（cffi、colorama 等）自然找不到。

解决

在 [tool.uv] 中加上 environments 配置，限定只为 Linux 解析：

[tool.uv]
no-index = true
find-links = ["./wheels/"]
environments = ["sys_platform == 'linux'"]

这样 uv 就不再尝试解析 Windows-only 的依赖了。

对重打包脚本的修改

解决上面三个坑的关键，是修改 plugin_repackaging.sh，让它在打包时自动将 uv 离线配置注入 pyproject.toml。下面详细说明修改过程。

原始脚本的问题

原始 plugin_repackaging.sh 的 repackage() 函数核心流程如下：

repackage(){
    # ... 解压 ...
    pip download -r requirements.txt -d ./wheels  # 下载依赖到 wheels/
    build_wheels_from_sdists                       # 编译 sdist → wheel
    cleanup_wheels_non_whl                         # 清理非 .whl 文件

    # 在 requirements.txt 头部插入 pip 离线选项
    sed -i '1i\--no-index --find-links=./wheels/' requirements.txt

    # 处理 ignore 文件、重打包 ...
}

问题在于：脚本只修改了 requirements.txt，加入的 --no-index --find-links=./wheels/ 是 pip 的参数语法。但 Dify plugin daemon 内部使用 uv sync，它只读 pyproject.toml，完全忽略 requirements.txt 中的 pip 选项。所以虽然 wheels 打进了包里，daemon 安装时依然去联网下载。

修改一：新增 inject_uv_offline_config() 函数

我们需要一个函数，在打包时将 [tool.uv] 配置注入 pyproject.toml。这段配置告诉 uv：不访问远程索引，从本地 ./wheels/ 目录查找包。

第一版只解决了坑一（离线下载）的问题：

inject_uv_offline_config(){
    if [ ! -f "pyproject.toml" ]; then
        return 0
    fi

    python - <<'PY'
from pathlib import Path
import re

path = Path("pyproject.toml")
content = path.read_text(encoding="utf-8")

uv_block = """
[tool.uv]
no-index = true
find-links = ["./wheels/"]
"""

# Remove any existing [tool.uv] section to avoid duplicates
content = re.sub(r'\n?\[tool\.uv\][^\[]*', '', content, flags=re.DOTALL)
content = content.rstrip("\n") + "\n" + uv_block.lstrip("\n")
path.write_text(content, encoding="utf-8")
PY
    echo "Injected [tool.uv] offline config into pyproject.toml"
}

这里用内嵌 Python 而非纯 shell 来操作 TOML，是因为需要先用正则删除可能已存在的 [tool.uv] 段（避免重复注入），再追加新配置。纯 sed 处理多行 TOML 段落很容易出错。

修改二：加入 environments 约束

解决坑三后，我们在 uv_block 中加入了一行：

 uv_block = """
 [tool.uv]
 no-index = true
 find-links = ["./wheels/"]
+environments = ["sys_platform == 'linux'"]
 """

这行告诉 uv 只为 Linux 平台解析依赖，不再尝试寻找 Windows-only 的包（如 cffi; sys_platform == 'win32'、colorama; sys_platform == 'win32'）。

修改三：在 repackage() 中调用

在 repackage() 函数中，紧跟 sed 修改 requirements.txt 之后，加入一行调用：

  # sed 修改 requirements.txt（保留 pip 兼容性）...
  sed -i '1i\--no-index --find-links=./wheels/' requirements.txt

+ # Patch pyproject.toml so that uv also uses local wheels (offline)
+ inject_uv_offline_config

  # 处理 ignore 文件 ...
  IGNORE_PATH=.difyignore

这样在原有的 pip 离线配置基础上，同时为 uv 生成了对应的离线配置，两个工具都能正确使用本地 wheels。

最终注入效果

经过修改后的脚本，打包出的离线插件中 pyproject.toml 会自动带上：

[tool.uv]
no-index = true
find-links = ["./wheels/"]
environments = ["sys_platform == 'linux'"]

三个配置项各自解决一个问题：

完整的离线安装操作步骤

# 1. 确保使用 Python 3.12（与 daemon 容器一致）
python3 --version  # 应输出 3.12.x

# 2. 打包
cd dify-plugin-repackaging
./plugin_repackaging.sh local langgenius-openai_api_compatible_0.0.35.difypkg

# 3. 调整 Dify 的 .env
#    FORCE_VERIFYING_SIGNATURE=false
#    PLUGIN_MAX_PACKAGE_SIZE=524288000
#    NGINX_CLIENT_MAX_BODY_SIZE=500M

# 4. 重启
cd dify/docker
docker compose up -d

# 5. 在 Dify 控制台 → 插件管理 → 上传本地包
#    选择 langgenius-openai_api_compatible_0.0.35-offline.difypkg

总结

核心教训：uv ≠ pip。uv 的 universal resolution 设计在在线场景下很优雅，但在离线场景下会产生意想不到的问题。理解工具链的实际行为比盲目排错重要得多。

看完了？说点什么呢

最近科室接到个需求，需要给 Win7 的电脑上安装上豆包。对于这些基于新版 Electron 开发的应用来说，在 Windows 7 上运行时肯定会遇到兼容性问题，本文记录一下完整的处理方法。

问题一：应用无法启动

在 Windows 7 上直接安装并启动豆包，会立刻遇到“不是有效的 Win32 应用程序”的报错。这是典型的因为程序依赖了更高版本 Windows 系统 API 导致的兼容性问题。

解决方案：安装 VxKex-Next

这个问题现在非常好解决，只需要安装兼容层工具 VxKex-Next 即可。

安装 VxKex-Next 后，在豆包的应用程序快捷方式上右键，选择“属性”，可以看到新增了“VxKex-Next”选项卡。勾选“为此程序启动 VxKex Next”，然后应用即可。

此时再次启动豆包，会发现程序已经能够正常运行了。不过，事情还没完全解决。

问题二：资源管理器反复重启

启用 VxKex-Next 并运行豆包后，只需要稍作等待，或者进行一些文件操作，就会发现系统的资源管理器（explorer.exe）开始反复崩溃并重启，严重影响系统使用。

问题排查与解决

1. 查看事件日志

   打开 Windows 事件查看器，在“Windows 日志” -> “应用程序”中，可以找到大量关于 Explorer.EXE 的错误报告。错误详情如下：

   错误应用程序名称: Explorer.EXE，版本: 6.1.7601.17514，时间戳: 0x4ce7a144
   错误模块名称: shellextcore.dll_unloaded，版本: 0.0.0.0，时间戳: 0x67eba3f2
   异常代码: 0xc0000005
   错误偏移量: 0x000007fee13a8310
   错误进程 ID: 0x1124
   错误应用程序启动时间: 0x01dc0da9f9e2d422
   错误应用程序路径: C:\Windows\Explorer.EXE
   错误模块路径: shellextcore.dll
   报告 ID: 9f798622-799d-11f0-9d49-00155d6bc901

   从日志中可以明确看到，导致崩溃的错误模块是 shellextcore.dll，这是豆包安装的右键菜单扩展。推测是 VxKex-Next 在兼容豆包主程序时，未能完美兼容其注入到 explorer.exe 的外壳扩展（Shell Extension），从而导致了资源管理器的崩溃。

2. 禁用外壳扩展

   既然定位到了问题模块，解决方案就是将其禁用。这里需要用到一个小工具 ShellExView。

   运行 ShellExView 后，为了方便查找，可以先在菜单栏的“Options”中勾选“Hide All Microsoft Extensions”，隐藏所有微软官方的扩展。

   然后在列表中找到名为 Doubao Context Menu 的条目（其关联的 .dll 文件正是 shellextcore.dll），右键单击并选择“Disable Selected Items”。

   禁用后，资源管理器会立刻停止崩溃并恢复正常。至此，豆包也可以在 Windows 7 上稳定使用了。

注意：本文部分内容在 AI (Gemini 2.5 Pro) 的辅助下编写完成，旨在确保语言流畅与结构清晰。如有任何疑问，欢迎评论交流。

看完了？说点什么呢

补觉，本周的核心就是补觉

感觉每天都睡不醒，中午睡，晚上回来吃完饭又睡着，成了这一周的主旋律。周末去看了一下《喜羊羊与灰太狼之异国破晓》和《浪浪山小妖怪》，强烈推荐浪浪山，确实很好看。

本周完成

本周尝试了一下完成 NJU OS 2023 课程的第一个作业，是一个 PSTree 命令行工具，不过因为在补觉所以还没写完，准备用 CPP 来完成这个作业。

• 回顾南大操作系统课【5/30】
• 学习 UE5 C++ 教程【9/169】

下周寄划

完成 NJU OS 2023 课程的第一个作业，是时候再推进一下 UE 这边的项目迁移进度了，不过我是想跟教程跟得差不多了再弄，会好一些，现在还不是很熟悉 UE5。

看完了？说点什么呢

干不动了，值班

本周在本部值班，每天晚上都还能接到一两个电话，也是很罕见了，周六周日连续两天的晚上都出现了机房的空调漏水停机的事故，导致两天晚上都是2点起床，4、5点才重新上床睡觉，着实是难搞。下周一我准备直接请假在家里躺一整天，希望能稍微缓过来。

本周完成

本周值班，基本上 0 进度。

下周寄划

下周希望能好好休息，把这周欠的觉都补回来，然后继续推进学习计划。周一利用空闲的时间把明末也是成功推进到了真武观，目前感觉还不算很难，目前卡得最久的 Boss 还是红岚，其他感觉都能在 1 小时内解决。

看完了？说点什么呢

上班，人什么时候才能不上班

这一周都在医院的分院度过，每天跑上跑下的检查网络，修打印机，属实是纯牛马的生活了。怀念每天只需要在座位上一坐，戴上耳机，打开音乐，开始码代码的程序员生活。

不过本周还是略微推进了一下学习进度。也算是稍微内卷了一下吧，真的还能卷的动吗。

本周完成

• 完成视频教程学习 UE5【9/9】
• 开始回顾南大操作系统课【4/30】
• 给之前 Rust 写的小玩具加了点新功能【虽然是用 Cline 直接写的】

下周寄划

下周是真的只有寄了，下周值班了，7*24 小时的待命工作，即便已经过去了 1 年我也还是没有习惯，怀念码代码的生活，下班后我的大脑是真的纯放松，还能做一些想做的其他事情，这个工作回到家只能说，身心俱疲，只想躺着刷抖音了，哈哈。

最近打打刚出的明末吧，CDK 都买了，也退不了款，不得不打下去了，你别说，玩着还是有那么点感觉。

看完了？说点什么呢

休息，人活着就是为了休息

这周的事情比较少，主要是整理和调整了一下上周部署的 AI 法规助手，现在是根据 Qwen3-8b 来生成关键词，用关键词去知识库中检索，然后 DeepSeek-R1 8B 模型生成答案。感觉效果还不错，然后对问题进行了分类，代码问题我还是用的 32B 来处理。

本周完成

• 调整上线部署的 AI 法规助手
• 开始回顾南大操作系统课【2/30】
• 观看视频教程学习 UE5【4/9】

下周寄划

• 上班，无止尽的上班
• 继续学习操作系统课
• 继续将 Unity 做的项目迁移到 UE 继续开发
• 看看有没有空开始看 ROS 2

随笔

寄，好多事情都没弄，买的竹子的玩具 CyberBrick 都还没有开始装，感觉没啥时间，这个早8晚6的工作每天下班就只想躺着看看抖音然后睡觉，实在是消磨人的精神。每天也只是干一些打螺丝的事情，只能说是干了一年技术水平 0 增长。

看完了？说点什么呢

好久没更新了，最近有工作需求需要用 DeepSeek 搭建一个用来做文档法律合规审查的 AI 助手，正好需要用到知识库，想了想最后还是放弃了原有的 Open-WebUI 方案，直接转为用 Dify 实现。因为需要在内网中部署所以也是踩了一些坑，写个文章顺带记录一下。

搭建环境

由于需要在内网环境部署，整个过程需要离线进行。Dify 的部署依赖于 Docker 和 Docker Compose，因此首先要确保服务器上已经离线安装好了这两个工具。

Docker 的离线安装

本人使用的是 Ubuntu 22.04，因此本文只介绍 Ubuntu 22.04 中 Docker 的离线安装方法。整个过程分为两步：首先在有网络的机器上准备离线安装包，然后将安装包拷贝到目标服务器上进行安装。

一、 在有网络的机器上准备离线包

1. 更新软件包列表并安装依赖

   sudo apt update
   sudo apt-get install -y ca-certificates curl

2. 添加 Docker 的官方 GPG 密钥

   sudo install -m 0755 -d /etc/apt/keyrings
   sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
   sudo chmod a+r /etc/apt/keyrings/docker.asc

3. 设置 Docker 的 APT 仓库

   echo \
     "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
     $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
     sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
   sudo apt-get update

4. 下载 Docker 及其依赖的离线包

   首先，创建一个专门用于存放离线包的目录：

   mkdir ~/docker-offline-packages
   cd ~/docker-offline-packages

   然后，使用 apt 命令下载所有依赖文件：

   apt-get download $(apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin | grep "^\w")

二、 在离线服务器上安装 Docker

1. 拷贝离线包

   将整个 docker-offline-packages 文件夹通过 U 盘或其他方式拷贝到离线服务器上。

2. 安装 Docker

   在离线服务器上，进入 docker-offline-packages 目录，然后使用 dpkg 命令进行安装：

   cd ~/docker-offline-packages
   sudo dpkg -i *.deb

3. 验证安装

   运行以下命令查看 Docker 是否安装成功：

   sudo docker --version

Dify 离线安装

Dify 的离线安装过程主要分为两步：首先在有网络的机器上准备好 Dify 的源代码和所需的 Docker 镜像，然后将这些文件拷贝到目标离线服务器上进行部署。

一、 在有网络的机器上准备资源

1. 下载 Dify 源代码

   # 克隆 Dify 仓库
   git clone https://github.com/langgenius/dify.git
   
   # 进入 dify 目录并切换到最新的稳定 release 版本
   cd dify
   git checkout $(git describe --tags `git rev-list --tags --max-count=1`)

   提示: 切换到最新的稳定 release 版本比直接使用 main 分支更可靠，可以避免遇到一些意想不到的 bug。

2. 打包 Dify 所需的 Docker 镜像

   Dify 依赖多个 Docker 容器来运行。我们可以利用 docker-compose.yml 文件来自动拉取并打包所有必需的镜像。

   # 进入 Dify 的 Docker 配置目录
   cd docker
   
   # 1. 提取所有镜像名称
   # 这条命令会解析 docker-compose.yml 文件，找到所有服务的 image 定义，并提取出镜像名和标签
   docker compose config | grep "image:" | awk '{print $2}' > image-list.txt
   
   # 2. 拉取所有镜像
   # 使用 xargs 配合 docker pull 命令，批量拉取 image-list.txt 中列出的所有镜像
   cat image-list.txt | xargs -I {} sudo docker pull {}
   
   # 3. 将所有镜像打包成一个 tar 文件
   # 这样就可以方便地将所有镜像一次性迁移到离线服务器
   sudo docker save -o dify-images.tar $(cat image-list.txt | tr '\n' ' ')

   执行完毕后，你会在 dify/docker 目录下得到一个 dify-images.tar 文件，同时 dify 整个文件夹也需要被打包。

二、 在离线服务器上部署 Dify

1. 拷贝资源

   将准备好的 dify 整个项目文件夹和 dify-images.tar 文件通过 U 盘或其他方式拷贝到离线服务器上。

2. 加载 Docker 镜像

   在离线服务器上，使用 docker load 命令加载镜像包：

   sudo docker load -i dify-images.tar

3. 启动 Dify 服务

   进入 dify/docker 目录，直接使用 Docker Compose 启动所有服务：

   cd /path/to/your/dify/docker
   sudo docker compose up -d

4. 验证安装

   等待几分钟让所有服务完全启动后，可以通过 docker ps 命令查看所有 Dify 相关的容器是否都处于 Up 状态。如果一切正常，你就可以通过 http://<服务器IP>:80 访问 Dify 的 Web 界面了。

Dify 插件离线安装

Dify 的插件生态为其增添了强大的扩展能力，但在离线环境下安装插件则需要一些额外的步骤。

离线安装的挑战

官方的插件包 .difypkg 本质上是一个 zip 压缩文件，其中包含了插件的元数据和代码。然而，这个包并不包含插件运行所需的所有 Python 依赖。当你在 Dify 中上传并安装一个插件时，Dify 会尝试连接到 pypi.org 来下载这些依赖项。在严格的离线环境中，这个过程自然会失败，导致插件无法使用。

解决方案：重新打包插件

为了解决这个问题，我们需要在有网络的机器上，将插件及其所有依赖项预先下载并打包到一个新的、完全离线的 .difypkg 文件中。

根据这篇文章：Dify 实战：纯内网dify插件离线安装解决 找到了一个非常实用的工具：dify-plugin-repackaging。这个脚本可以自动化地完成以下工作：

1. 解压原始的 .difypkg 文件。
2. 分析 requirements.txt 文件，找出所有 Python 依赖。
3. 从 PyPI 下载这些依赖包。
4. 将插件代码和所有依赖包重新打包成一个全新的、可离线安装的 .difypkg 文件。

我 Fork 并修改了原仓库的代码，使其更便于批量处理多个插件。我的版本可以在这里找到：lebenito030/dify-plugin-repackaging。

操作步骤

整个过程同样分为“在线准备”和“离线安装”两步。

1. 在线准备

   1. 克隆我修改后的仓库：

      git clone https://github.com/lebenito030/dify-plugin-repackaging.git
      cd dify-plugin-repackaging

   2. 将你从 Dify 商店或其他地方下载的、需要离线安装的 .difypkg 插件包全部放入 _temp 文件夹中。

   3. 运行打包脚本：

      ./plugin_repackaging.sh local _temp

      脚本会自动遍历 _temp 文件夹中的所有插件包，并生成新的离线包存放在 _output 文件夹中。

2. 离线安装

   1. 登录 Dify 的 Web 界面。
   2. 进入 插件 -> 安装插件 -> 本地插件。
   3. 直接上传重新打包的（.difypkg） 文件，Dify 会自动安装。

ps：目前发现的问题有，有一部分插件是要求网络连接的，这些插件就无法安装，或者比如一些插件启动的时候要连接网络，会导致 Dify 的其他插件需要等待一段时间才能启动成功。

创建 AI 应用

1. 准备法律法规数据

搭建一个法律法规助手，高质量、全面的知识库是核心。我的数据来源是国家法律法规数据库。

为了方便地从该数据库获取数据，我使用了 LawRefBook/Laws 这个开源项目。该项目提供了一系列脚本，可以自动化地爬取和整理法律法规条文。

然而，在实际使用中，我发现有些部门规章或地方性法规是以 .doc 格式提供的，而原项目默认只处理 .html 和 .docx。为了能够全面地将这些法规纳入知识库，我对原仓库的代码进行了修改，增加了对 .doc 文件的解析和支持。

并且，为了提高后续知识库父子分段的效果，我在章节的结尾和小节的结尾都添加了 *章节结束* 和 *小节结束* 标记。用于在知识库建立的时候，将这些标记作为分段依据。

我的修改版本可以在这里找到：lebenito030/Laws。当 scripts/request.py 中的 req.request.params 参数为空值时，脚本将下载全部当前有效的法律法规并保存到 Laws/__cache__/out 文件夹下。

通过运行修改后的脚本，爬取到的所有法律法规文件（包括 .doc 格式）将统一转换为纯文本（.md）格式。这样做的好处是：

1. 格式统一：便于 Dify 的知识库进行索引和处理。
2. 内容纯净：去除了复杂的格式，只保留核心的文本内容，可以提高检索的准确性。
3. 切分优化：Dify 在处理长文本时会自动进行切分，纯文本格式能让切分效果更好，避免因格式混乱导致语义被割裂。

完成数据准备后，就可以将这些 .md 文件批量上传到 Dify 中创建的知识库里了。

2. 搭建知识库

Dify 中创建知识库可以选择父子分段的方式，我们的数据通过脚本已经预处理生成了两级标记：*章节结束* 和 *小节结束*，因此这里只需要像下图一样填入对应的分段标识符就行。Rerank 设置使用推荐的混合检索。

此时知识库会在后台处理文本，不过这里我推荐一次性少传入太多文本，不然可能会出现错误，比如一直卡在索引中。

3. 编排 Chatflow

回到 Dify 的工作室页面，点击左上角的创建空白应用，这里我使用的是创建 Chatflow 应用。

创建完成后会自动进入应用的页面，应该是一个能够直接对话的 LLM 应用，如下图：

接下来按照以下步骤操作：

1. 在开始和 LLM 之间加入知识检索节点
2. 知识检索节点中添加创建的法律法规知识库
3. LLM 节点设置上下文为知识检索
4. 在系统提示词中加入上下文内容

这个时候就创建完成了，你可以通过发布应用然后使用 Dify 提供的应用页面来直接访问。

这里我提问：未成年人标准是什么。AI 助手回答如下图：

我使用的提示词：

# 角色
你是一个严谨、专业的法律知识问答助手，具备两种工作模式。

# 任务
你的任务是根据用户提出的问题 `{{#sys.query#}}`，优先在下面提供的法律知识库 `{{#context#}}` 中寻找最相关的条款和信息。
- 如果 `{{#context#}}` 中包含能回答问题的信息，则生成一份基于知识库的、清晰准确的回答（**模式A**）。
- 如果 `{{#context#}}` 为空或不包含能回答问题的信息，则利用你自己的通用法律知识库生成一份参考性回答，并明确告知用户该信息并非来自其提供的知识库（**模式B**）。

# 工作流程
1.  **分析问题**: 仔细理解用户问题 `{{#sys.query#}}` 的核心诉求。
2.  **检索与判断**: 分析 `{{#context#}}` 的内容。
    * **如果 `{{#context#}}` 提供了相关信息**：则遵循“**核心规则A**”，并使用“**输出格式A**”生成回答。
    * **如果 `{{#context#}}` 未提供相关信息**：则遵循“**核心规则B**”，并使用“**输出格式B**”生成回答。

# 核心规则
### 核心规则A (当在知识库中找到信息时)
-   **绝对封闭**: 你的回答必须**完全且仅限于** `{{#context#}}` 中提供的信息。严禁使用任何你自己的内部知识或进行任何形式的推测。
-   **引用原文**: 在解释时，必须明确引用 `{{#context#}}` 中的相关法律条款原文，并注明来源。
-   **忠实原文**: 你的解释不能曲解或过度引申 `{{#context#}}` 中原文的含义。

### 核心规则B (当在知识库中未找到信息时)
-   **明确声明来源**: 你必须在回答的**最开始**就清晰地告知用户，提供的信息来源于你的通用知识库，而非其指定的知识库。
-   **提供通用知识**: 基于你的通用法律知识，为 `{{#sys.query#}}` 提供一个有帮助但非决定性的、一般性的解答。
-   **强调局限性**: 你的回答应侧重于一般性原则和概念，并主动说明缺少具体法律依据。

# 输出格式
### 输出格式A (基于知识库的回答)
请严格按照以下Markdown格式输出你的回答：

**1. 核心结论**
[在这里用一两句话直接回答用户的核心问题]

**2. 相关法条引用**
> [在这里完整引用`{{#context#}}`中最相关的一条或多条法律条款原文]
> 来源：[如果知识库中有来源信息，请填写，如《xxx法》第xx条]

**3. 详细解读**
[在这里基于引用的法条，对用户的具体问题进行详细解释和分析]

---
**免责声明**: 本回答仅基于您提供的知识库生成，不构成任何形式的法律意见或建议。在做出任何决策之前，请务必咨询具备执业资格的专业律师。

### 输出格式B (基于AI通用知识的回答)
请严格按照以下Markdown格式输出你的回答：

⚠️ **重要提示：在您提供的知识库中未能找到与您问题“{{#sys.query#}}”直接相关的信息。**

以下回答是基于我的通用知识库生成的，**并非法律意见，知识库准确性可能有偏差，仅供您参考**。

**1. 一般性解答**
[在这里根据通用的法律原则，对用户的问题提供一个概括性的解释。你需要明确指出这只是一个普遍情况下的理解]

**2. 关键考虑因素**
[在这里列出一些处理此类问题时通常需要考虑的通用因素，例如：证据的重要性、诉讼时效、可能的法律程序等。这有助于引导用户思考，但不是提供解决方案]

---
**强烈建议**: 法律问题高度复杂，且每个案件的具体情况都有极大差异。为了保障您的合法权益，我们**强烈建议**您携带所有相关文件，向具备执业资格的专业律师进行详细咨询，以获得针对您个人情况的正式法律建议。

注意：本文部分内容在 AI (Gemini 2.5 Pro) 的辅助下编写完成，旨在确保语言流畅与结构清晰。如有任何疑问，欢迎评论交流。

看完了？说点什么呢

你别说 Dify 还挺好用的

这周弄完了用 Dify 搭建的法律法规 AI 助手，其实主要是在国家法律法规数据库下载文献上花了很多时间，推荐一个开源项目 Laws，可以直接下载全部数据库上的法律法规文件，并且都是 Markdown 格式，非常方便后续的知识库处理。

我也 Fork 了一份修改了一下，在内容上添加了给知识库用来做分段的标记 *章节结束* 和 *小节结束*，非常适合用在父子分段的知识库上。

基座模型用的是 DeepSeek-R1 8B 模型，Embedding 用的是 bge-large-zh-v1.5，Rerank 用的是 bge-reranker-v2-m3。Temperature 是 0.6，Top-P 是 0.95。

这周还看了一下 UE 的教程，感觉逐渐理解一切，整个 Actor 感觉就和 Godot 的 Node 是一样的。

OS 这块这周没看，下周看一下吧，ROS 也没学，感觉弄不过来了。寄！

以后还是写周寄吧，日寄已经寄不过来了。

看完了？说点什么呢

很急啊，很急

最近感觉很急，总想一天就把全部事情弄完，结果又没弄完，就逐渐焦虑。

今天测试了一下 MCP Agent，在 Dify 上部署了一个能够调用高德地图的 MCP Agent。用的 DeepSeek-R1 0528 的 Qwen3 8B 模型，结果还不错，我甚至感觉这个 8B 模型比 70B 的版本中文要更好。然后试了一下添加知识库，把知识库里放了一个民法典，用上了 Embedding 和 Rerank，确实能准确的找到对应位置，不过我不知道知识库里的内容如果更多的话会不会还是这么稳定。Embedding 和 Rerank 用的是 bge-large-zh-v1.5 和 bge-reranker-v2-m3。

不过为了更快一点部署，我的模型是用的硅基流动的 API，明天还是得把 Embedding 和 Rerank 切换到本地运行，现在为了腾出更多显存，模型的输入已经被我砍到 34K 上下文长度了，不过感觉仍然是足够用的。

今天大概就干了这些，UE 和 QT 项目完全没有开展，哈哈，晚上回来头有点晕，直接躺了，醒了就开始玩 PEAK。也是爬到火山了，很完美。

就用这张图结束这一天吧。

看完了？说点什么呢

新的一天从睡眠不足开始

今天又是在工位上打瞌睡的一天，昨晚雷雨交加，直接给干失眠了，导致睡眠又是只有四个小时不到。

不过今天在家里 PC 上用 VLLM 部署了 DeepSeek-R1 0528 的 Qwen3 8B 模型，整个上下文长度可以到 48k，然后下了个 Dify，准备打通一下用 DeepSeek 来做法律文书审核的工作流。不过我不太确定，需要上 RAGFlow 吗？

回到家里也不知道干什么，就看看 Bilibili 刷刷抖音，感觉时间又浪费了一两个小时，不过也是很开心的，这才是懒人日寄里面应该充斥的内容，然后开始干活，看看 UE 的教程，准备试着用 UE 做一个 TopDown 的射击游戏。

睡了睡了，今天的日寄就到此结束，明天又是当社畜的一天。

看完了？说点什么呢