Linux开机卡在Loading driver?dracut重建initramfs驱动修复指南

发布时间:2026/10/22 9:43:53

Linux开机卡在Loading driver?dracut重建initramfs驱动修复指南 1. 问题现象与初步判断1.1 开机卡在“Loading driver”到底发生了什么我先复述一下典型场景某台服务器或者台式机换了新硬盘控制器、新网卡或者安装系统时选错了驱动源重启之后卡在启动阶段的“Loading driver…”提示或者干脆直接进入 dracut 提示符dracut:/#系统拒绝继续引导。我第一次遇到这种情况时第一反应是“引导坏了”后来才发现真正的原因是 initramfs 里没有包含对应硬件的驱动模块。把整个启动流程拆开看引导阶段系统先加载的是 initramfs初始内存文件系统这个文件系统承担的任务非常纯粹把根文件系统挂载起来之前先把必要的内核模块、驱动、挂载工具都准备好。如果 initramfs 里缺了磁盘控制器驱动、网卡驱动或者文件系统模块系统就找不到根分区自然无法继续。很多人在这个问题上容易绕弯路因为它的表象和真正原因经常不对应。比如我之前遇到过一台机器启动时报错信息看起来是文件系统损坏但实际排查后确认根分区是完好的问题出在 initramfs 打包时漏掉了特定驱动。这里有个很重要的判断技巧如果系统能进入 dracut 提供的 rescue shell就是那个dracut:/#提示符说明内核本身没问题缺少的是驱动或挂载所需的模块。反过来如果连内核都起不来那就不是 dracut 能解决的范畴了。1.2 为什么 initramfs 会缺驱动这个问题往往不是“碰巧没装上”而是有明确的触发路径我总结下来大致有这几类系统从一个环境制作镜像然后迁移到另一个硬件平台。比如在虚拟机里做好的系统镜像直接拿去物理机启动硬件差异导致 initramfs 里没有目标机器的磁盘控制器驱动。安装系统时选择的是最小化安装或定制化安装某些非默认驱动没有强制写入 initramfs。更新内核后没有同步重新生成 initramfs。内核版本更新后原有的 initramfs 往往需要重新生成但很多人只更新了内核包忽略了这一步。自编译内核或自编译驱动模块模块已安装到/lib/modules/下但 initramfs 打包时没有被拾取。从 Linux 系统的设计角度看initramfs 是根文件系统和内核之间的“过渡层”它不需要包含所有驱动只需要包含从引导到根分区挂载这一阶段所需的模块。这个“够用就好”的设计在大多数时候没问题但一旦硬件环境发生变化或者根文件系统所在设备比较特殊就很容易出现“驱动不在 initramfs 里”的尴尬局面。2. dracut 的工作原理与排查思路2.1 dracut 到底是干什么的dracut 在我看来更像一个“定制化打包工具”。它读取系统当前的配置、内核版本、模块依赖关系然后按照一定的规则把内核模块、udev 规则、挂载工具、文件系统驱动组装进 initramfs 镜像文件。打个比方initramfs 就像是一个“紧急救援包”里面装了从开机到挂载根分区这一路上可能用到的东西。dracut 就是这个救援包的打包员它根据你指定的规则决定往包里塞什么。默认情况下dracut 会扫描/lib/modules/$(uname -r)/下所有已安装的内核模块但“扫描”不等于“全部打包”它有自己的取舍逻辑。这个取舍逻辑非常关键。dracut 默认会按照主机当前的硬件配置来生成 initramfs也就是说它倾向于打包“当前这台机器启动所需”的模块而不是“所有可能用到的模块”。这就是为什么把系统盘拆下来插到另一台机器上或者换了主板之后经常会遇到找不到根设备的原因。2.2 产生 dracut rescue shell 的核心触发机制当系统进入 initramfs 后会依次执行一系列任务加载模块、创建设备节点、等待设备就绪、尝试挂载根分区。任何一个环节失败导致根分区挂载不了dracut 就会进入交互式 rescue shell并给出一个错误信息。最常见的错误提示包括ERROR: Failed to mount the real root device挂载根分区失败。ERROR: Unable to detect root device找不到根设备。Waiting for 10 seconds...这类等待设备超时的提示。出现这些提示时先不要急着重新制作 initramfs。在 rescue shell 里可以先执行一些诊断命令看看当前系统到底能不能识别到硬盘。比如在dracut:/#提示符下执行ls /dev/sd*如果能看到类似/dev/sda、/dev/sdb这样的设备节点说明内核已经发现了磁盘问题可能出在设备路径不对或者根分区参数不正确。如果ls /dev/sd*什么都看不到而你的磁盘是 NVMe 的那就需要检查是不是缺少 NVMe 驱动。我曾经遇到一个很有意思的情况ls /dev/sd*能看到设备但根分区始终挂载失败。后来在 rescue shell 里执行blkid才发现根分区的文件系统是 XFS而 initramfs 里没有 XFS 模块。这种“驱动在、文件系统驱动不在”的情况很容易被忽视。3. 一步步解决“驱动无法加载”问题3.1 常规修复流程重新生成 initramfs这是最直接的修复方式。在系统还能正常启动的情况下或者通过 live 环境挂载根分区进入 chroot 后重新生成 initramfs 就能解决问题。具体步骤如下# 查看当前内核版本 uname -r # 重新生成 initramfs dracut -f /boot/initramfs-$(uname -r).img $(uname -r)这里解释每个参数的含义-f强制覆盖已有文件。如果不加这个参数当目标文件存在时dracut 会拒绝覆盖。/boot/initramfs-$(uname -r).img指定输出文件名。$(uname -r)指定要生成 initramfs 对应的内核版本。如果有多内核版本并存最好直接查看/boot目录确认每个内核版本对应的 initramfs 文件名格式。有些发行版用的是/boot/initramfs-xxx.img有些用的是/boot/initrd.img-xxx操作前先确认一下避免把文件弄乱。对于 RHEL/CentOS 系发行版可以直接用dracut -f不接参数时dracut 会默认为当前运行的内核版本重新生成 initramfs 并覆盖原文件但为了行为明确我习惯还是把文件名和内核版本写全。3.2 场景一系统还能启动但升级内核后驱动加载异常这种情况最常见于内核小版本升级后。系统能正常启动但某个硬件功能异常比如网卡不工作、磁盘性能异常此时可以按上面命令重新生成 initramfs然后重启验证。如果重新生成之后问题依旧就要考虑是不是模块本身没装全。可以执行# 查看内核模块目录 ls /lib/modules/$(uname -r)/ # 查看某个模块是否存在 find /lib/modules/$(uname -r) -name *.ko* | grep 模块名如果模块文件不存在说明是内核模块没安装不是 initramfs 问题。这时候需要安装对应的内核模块包或者确认是不是内核版本和设备驱动不兼容。3.3 场景二系统无法启动卡在 dracut 提示符这种情况下你需要在 rescue shell 里做紧急处理或者用 live 环境进行修复。如果只是临时想验证一下是不是驱动问题可以试试在 rescue shell 里手动加载模块# 在 dracut rescue shell 中尝试加载模块 modprobe 模块名 # 加载完之后看看磁盘设备是否出现 ls /dev/sd*如果能通过modprobe手动加载模块并看到磁盘设备那么下一步就是退出 shell让引导流程继续。但这里有个技巧直接执行exit可能不会重试挂载根分区需要手动执行# 退出 rescue shell 并重试 exit如果exit后仍失败说明 dracut 生成的 initramfs 没有包含该模块这只能通过重新生成 initramfs 来解决。在 rescue shell 里还有一种方法可以尝试直接编辑引导参数中的root参数。比如你的根分区实际是/dev/sda2但引导参数里写的是/dev/mapper/xxx这类逻辑路径而对应的 device mapper 模块又没加载就会失败。可以临时修改引导参数把root改为实际设备路径或者用rootUUIDxxx的方式指定根分区。# 在 rescue shell 中查看可用设备 blkid记录下根分区对应的 UUID然后在引导参数里设置rootUUID你的UUID这种方法只适合临时验证重启后参数不会保留。要彻底解决还得回到重新生成 initramfs 的路子上来。3.4 场景三镜像迁移后驱动不匹配把系统迁移到不同硬件平台上使用时最稳妥的方式是在迁移前就准备好目标平台的驱动。但实际中很多人是直接迁移启动失败后才开始修。这时候的修复思路是用 live 环境启动挂载原系统的根分区。chroot 进入原系统。确保网络可用或驱动包已准备好。安装目标平台所需的驱动包。重新生成 initramfs。这套流程要注意 chroot 环境的准备。很多人挂载完根分区后直接chroot /mnt结果发现 dracut 命令找不到或者模块安装后 initramfs 生成报错。正确做法是把必要目录都绑定挂载进去# 挂载根分区 mount /dev/sdX2 /mnt # 挂载 /boot 分区如果独立分区 mount /dev/sdX1 /mnt/boot # 绑定挂载虚拟文件系统 mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys # chroot 进入系统 chroot /mnt /bin/bash绑定挂载不是仪式感而是因为 chroot 环境里的设备节点、进程信息、内核接口都需要依赖宿主机的/dev、/proc、/sys。如果只挂载根分区不绑定这些目录后续执行dracut时很可能会因为设备节点缺失而报错或者扫描模块时行为异常。在 chroot 环境下重新生成 initramfs# 在 chroot 环境中 dracut -f /boot/initramfs-$(uname -r).img $(uname -r)生成完毕后退出 chroot卸载分区重启验证。3.5 场景四不想重新生成整个 initramfs只追加驱动模块有时候你只是临时需要一个驱动进 initramfs不想因为生成整个镜像而更改其他东西可以使用 dracut 的--add-drivers参数dracut -f --add-drivers 驱动模块名 /boot/initramfs-$(uname -r).img $(uname -r)要注意--add-drivers后面的模块名不需要写.ko后缀也不需要写完整路径dracut 会自动在/lib/modules/$(uname -r)/下查找。如果模块依赖其他模块dracut 会自动分析依赖关系一并加入。这一点在实战中很省心比如你添加网卡驱动时它可能依赖底层总线驱动dracut 会通过模块间的depends关系自动补齐。4. 使用 dracut 的核心配置与机制4.1 通过配置文件统一管理驱动dracut 的配置目录是/etc/dracut.conf.d/这个目录在很多发行版上默认就存在。如果你的机器经常需要处理“驱动无法加载”的问题或者有多台硬件配置相近的机器需要统一管理建议不要每次都敲命令行参数而是写一个配置文件。新建一个配置文件比如/etc/dracut.conf.d/add-drivers.conf# 指定需要强制加入 initramfs 的模块 add_drivers xfs nvme 这里的写法有一点讲究add_drivers xfs nvme 的表示在现有配置基础上追加内容字符串前后加空格是为了避免和已有内容粘连。如果直接写add_driversxfs nvme会覆盖 dracut 自带的一些默认配置可能影响生成结果。配置完成后执行一次完整的生成操作即可dracut -fdracut 读取配置的优先级是/etc/dracut.conf.d/下的.conf文件高于/etc/dracut.conf多个.conf文件之间按文件名排序顺序读取。所以如果你发现某个配置没生效可以先看看目录下是否有其他配置文件起了冲突。4.2 常用 dracut 参数与用途参数用途说明使用建议-f强制覆盖现有 initramfs 文件每次生成都建议加上防止文件存在导致生成失败--add-drivers强制添加指定驱动模块用于补充特定硬件驱动--omit-drivers移除指定驱动模块一般不常用特殊场景调试用到--hostonly仅为主机当前硬件生成最小 initramfs默认行为之一迁移系统时需要谨慎-v显示生成过程中的详细信息排查问题时强烈建议加能看到每个模块的处理过程--rebuild触发强制重建即使配置未变化在 initramfs 损坏或配置被误改时使用--hostonly这个参数值得单独强调。很多发行版安装系统的默认行为就是 hostonly 模式生成的是“刚好够当前机器启动”的最小 initramfs。这种模式比全量模式启动更快、镜像更小但代价是可移植性差。如果你确定这台机器之后不会变更硬件hostonly 没问题如果机器可能换硬件或者要作为模板复制到多台机器建议用非 hostonly 模式重新生成一次 initramfs。4.3 dracut 生成 initramfs 的关键过程很多人以为 dracut 就是把模块文件打包到一起实际上它的工作远比“打包”复杂。一个完整的生成过程大致分这几个阶段收集模块扫描/lib/modules/$(uname -r)/下的模块依赖关系生成模块树。安装钩子脚本initramfs 里有多个执行阶段cmdline、pre-mount、mount、pre-pivot、cleanup等dracut 会把对应的钩子脚本安装进去。生成 udev 规则initramfs 里的设备管理依赖 udevdracut 需要把必要的 udev 规则文件复制进去。安装二进制工具比如mount、blkid、modprobe、lvm等这些工具在 initramfs 阶段就需要可用。打包压缩最终生成 cpio 格式的 initramfs并通常会用 gzip 或 xz 压缩。如果加-v参数运行 dracut可以看到它在每个阶段输出了大量信息。正常生成时输出的末尾会出现类似/boot/initramfs-xxx.img is created的提示。如果生成过程中某个环节报错输出信息里会直接指明缺失了什么排查效率比事后瞎猜高得多。4.4 initramfs 损坏后的紧急恢复有一种特殊情况initramfs 文件本身损坏或误删了。这时候系统会直接提示找不到/boot/initramfs-xxx.img根本无法进入 dracut rescue shell。处理方法也很直白用安装镜像或 live 环境启动挂载根分区和 boot 分区chroot 后重新生成 initramfs。如果 boot 分区是独立分区注意先挂载 boot 分区再执行生成命令否则生成的文件会写到根分区的 /boot 目录但引导时加载的却是独立 boot 分区里的旧文件。在这个场景下我曾经犯过一个低级错误根分区和 boot 分区都是独立的我只挂载了根分区就 chroot 进去执行dracut -f后提示成功重启后仍然找不到 initramfs。后来才意识到 boot 分区没有挂载生成的文件根本没写在引导读取的位置。这种“提示成功但实际无效”的情况在排查时要格外留意。5. 驱动加载失败的进阶排查与解决5.1 不仅仅是存储驱动网卡驱动也会导致类似问题在通过 PXE 或网络引导安装系统的场景里网卡驱动缺失导致的启动失败并不少见。系统在 initramfs 阶段需要加载网卡驱动才能从网络上下载根文件系统镜像或远程存储资源。如果网卡型号太新而 initramfs 里的驱动太旧就会卡在“找不到网络设备”这一步。同样可以先用 dracut 的--add-drivers把网卡驱动强制加进 initramfs也可以把网卡固件文件一并补充进去。有些网卡的驱动模块和固件是分离的模块加载时还要找到对应的.bin固件文件。这时候如果只加模块不加固件驱动加载依然会失败。判断固件缺失的方法很简单dracut 生成过程中如果出现无法找到固件文件的警告日志里会明确提示。也可以在系统启动后用dmesg | grep firmware查看固件加载情况。5.2 怎么快速定位缺失的驱动模块定位缺失模块最直接的方法是看启动时的错误日志但 dracut rescue shell 环境下日志不一定完整保留。实际操作中我更推荐反推法在 rescue shell 里确认根设备是什么类型然后反推需要哪些模块。例如根分区在 NVMe 硬盘上就需要nvme模块。根分区在 LVM 逻辑卷上就需要dm-multipath、lvm2等模块。根分区使用的是 XFS 文件系统就需要xfs模块。根分区做了 RAID就需要对应的 RAID 驱动模块。如果无法确认可以先用 live 环境启动原系统在 chroot 环境下手动执行模块加载测试# 测试某模块能否正常加载 modprobe 模块名 # 查看模块信息 modinfo 模块名modinfo输出的信息里可以看到模块依赖、授权协议、描述信息对于确认模块是否匹配当前内核很有价值。如果模块和内核版本不兼容modinfo会直接报错这种问题就不是 dracut 能解决的了。5.3 特殊文件系统模块缺失的坑这里我要特别提一下 ZFS 这类特殊文件系统。由于 ZFS 模块往往不是随内核自带的而是通过 DKMS 或手动编译安装重装或者升级内核后很容易出现安装好的 ZFS 模块在 initramfs 生成时没有被拾取的情况。处理方案有两种在配置文件中显式添加 ZFS 模块。确认 ZFS 模块的 DKMS 状态正常并且/lib/modules/$(uname -r)/extra/或对应目录下能看到.ko文件。# 确认模块文件位置 find /lib/modules/$(uname -r) -name *zfs*如果模块文件存在但 dracut 生成时没包含进去可以手动指定dracut -f --add-drivers zfs /boot/initramfs-$(uname -r).img $(uname -r)生成完成后可以用lsinitrd工具检查 initramfs 内部文件列表确认模块是否真的打进去了。5.4 验证 initramfs 内容lsinitrd 的使用lsinitrd是排查这类问题的一个利器它会直接列出 initramfs 镜像里的模块文件。用法很简单# 查看 initramfs 内所有内容 lsinitrd /boot/initramfs-$(uname -r).img # 只查看内核模块 lsinitrd -k /boot/initramfs-$(uname -r).img | grep \.ko # 检查某个具体模块是否存在 lsinitrd /boot/initramfs-$(uname -r).img | grep 模块名我习惯在生成 initramfs 之后、重启之前先跑一次lsinitrd确认关键模块都在。这一步虽然多花几秒钟但能避免反复重启测试实际效率反而更高。另外有一个小技巧如果你不确定 initramfs 里缺少什么可以先看看当前系统“需要什么”。在正常的系统环境下执行# 查看当前内核加载了哪些模块 lsmod对比lsinitrd里的模块列表和lsmod的输出能快速发现差异。这个对比法在迁移机器时特别有用。5.5 grub 引导参数中的 root 指定方式dracut 并不是唯一需要检查的环节引导参数里root的指定方式也会直接影响根分区能否挂载。常见的问题是在迁移磁盘后用旧的/dev/sdX路径指定根分区但设备的枚举顺序变了原来的 sda 变成了 sdb引导自然失败。推荐的做法是在安装系统后尽快记录根分区的 UUID并且在 grub 配置里用rootUUIDxxx的方式指定。UUID 是基于文件系统本身的唯一标识不依赖设备枚举顺序比/dev/sdX可靠得多。# 查看根分区 UUID blkid /dev/sda2grub 配置中就是rootUUIDxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx如果引导参数里的 root 用了 UUID但 initramfs 里没有对应的文件系统驱动也会失败。所以“引导参数指定 root 的方式”和“initramfs 里包含的驱动”是两套独立因素排查时不要混为一谈。6. 典型问题排查速查表与个人经验6.1 问题排查速查表下表是我在工作中总结的“驱动无法加载”问题快速定位方式适合在紧急情况下逐条对照故障现象可能原因快速验证方法处理方案rescue shell 中ls /dev/sd*为空缺少磁盘控制器驱动执行modprobe ahci或对应驱动名重新生成 initramfs 并强制添加驱动blkid能识别分区但挂载根分区失败缺少文件系统驱动modprobe xfs/modprobe ext4重新生成 initramfs 并添加文件系统模块引导提示找不到initramfs-xxx.imginitramfs 文件缺失或损坏检查/boot目录chroot 环境重新生成 initramfs更换硬件后卡在 Waiting for deviceinitramfs 按旧主机硬件生成用 live 环境对比lsmod和lsinitrd非 hostonly 模式重新生成 initramfs网卡无法识别网络安装失败缺少网卡驱动或固件检查固件加载日志添加驱动模块及对应固件6.2 常见但容易被忽略的问题在处理 initramfs 相关问题时有几个细节容易被忽略我踩过坑之后特别在意这几件事检查/boot分区空间是否充足。initramfs 文件虽然不大但生成过程需要临时空间如果/boot空间已满生成会在最后阶段失败且错误信息有时并不直观。建议执行生成操作前先df -h /boot看一下。注意内核版本一致性。dracut -f默认对应当前运行的内核版本如果你要修复的是另一个内核版本的 initramfs需要显式指定内核版本否则修完之后启动的还是旧文件。这一点在系统里有多个内核版本并存时特别容易出问题。不要忽略模块依赖。手动用--add-drivers添加模块时dracut 会自动分析依赖但如果模块依赖链中有固件文件缺失dracut 只会生成警告而不会强制报错。重启后驱动加载失败时日志里才会暴露真正的固件缺失问题。6.3 最后的实用建议个人经验是在生成 initramfs 之前先明确系统根分区所在的设备类型和文件系统类型然后有意识地把驱动列表过一遍。不用背太多参数记住“先确认模块是否已安装再确认初始化镜像是否包含它”这个排查顺序就能避免大部分问题。另外如果你在一个需要频繁拆盘迁移的工作环境里强烈建议把 dracut 的生成配置固定下来把常用驱动写进/etc/dracut.conf.d/的配置文件里同时在换硬件平台后第一时间刷新 initramfs。这不是什么高深技巧但能省掉大量踢机柜的体力活。
延伸阅读

更多相关文章

2026/10/22 9:43:53

手把手教你从零实现自定义Gym环境

1. 为什么非得自己写一个 gym 环境?——从“调包失败”到“动手造轮子”的真实动因你是不是也经历过这样的时刻:在复现某篇强化学习论文时,兴冲冲地 pip install gym,import gym,然后 gym.make(CartPole-v1) —— 行&a…

2026/10/22 9:38:51

Docker Swarm标签管理实战:节点约束与调度策略全解析

1. 先搞清楚:Swarm 标签到底管什么,为什么值得单独写一篇 做过集群运维的朋友都有体会,节点一多,最头疼的不是部署,而是“把任务放到它该去的地方”。Docker Swarm 自带的策略调度虽然省心,但一旦涉及异构节…

2026/10/22 11:50:06

从爬虫到智能体:搜索引擎技术演进中的百度发展史

“百度发展史”这五个字,摊开看就是一部中文互联网信息获取方式的历史。我见过不少人想把它当公司编年史来查资料,但真正值得细细拆解的,是这家公司在几个关键节点上的技术选型和产品决策:从关键词检索到内容生态,从搜…

2026/10/22 11:50:06

Mesh组网性能分析:回传、漫游与信道规划实战指南

简介:无线Mesh网络关键技术及组网性能分析文档,面向无线通信方向工程师、高校通信/网络专业学生以及需要评估Mesh组网方案的运维人员。内容围绕Mesh网络自组织、自管理特性展开,系统梳理Mesh AP、Root AP构成的组网结构,细致讲解自…

2026/10/22 11:50:06

捷顺停车场管理系统实施要点:拓扑、计费与现场故障

简介:捷顺停车场管理系统使用说明文档,面向停车场管理员、操作员及系统维护人员,涵盖从软件启动登录到车辆出入管理、收费查询、数据上传等全流程操作指引,是一份可直接对照上手的系统操作手册。文档为PDF格式,共1个文…

2026/10/22 11:50:06

工程化评分:把主观打分变成可部署的系统能力

1. 项目概述:当任务评分变成工程化流水线,谁在真正扛压?“能逐步打分的工程任务里,承重的是工具池而非调度者”——这句话初看像一句技术圈的玄学箴言,但在我带过十几个跨团队协作项目、亲手搭建过5套不同规模的任务评…

2026/10/22 11:50:06

LangGraph持久化执行全解:Checkpointer与Thread状态管理实战

第一次把 LangGraph 应用从“能跑”推到“生产可用”的时候,我碰到的第一道硬墙就是持久化执行。光把图跑通谁都会,但 Agent 跑着跑着进程一重启,或者用户会话一断开,整个对话状态连渣都不剩,那前面做的一切交互设计都…

2026/10/22 11:45:05

插件化架构实战:knowledge-work-plugins 核心设计与落地避坑指南

1. 从"知识工作插件"这个命名说起:它到底想解决什么问题第一次看到"knowledge-work-plugins"这个命名,我的直觉是:这不是一个具体工具,而是一类架构思路的统称。它指向的是把知识工作者的日常操作——写文档、…

2026/10/22 11:29:28

金融AI落地指南:从调研报告到技术选型与工程实践

简介:这份PDF报告聚焦2025年金融服务业中国AI现状与趋势,面向金融科技从业者、AI战略规划人员及关注行业数字化转型的研究者,帮助读者把握生成式AI在银行、支付、交易等场景中的落地路径与投资方向。资源包内含1个PDF文件,大小约1…

2026/10/22 0:01:49

电商智能运营体系从0到1:架构设计、落地步骤与避坑指南

前两年我们团队接了一个电商平台的运营中台项目,目标很直白:把过去靠运营拍脑袋做的选品、定价、发券、推活动这些事,逐步用数据算法和自动化流程代替。项目名字内部就叫“电商智能运营体系”。最近有不少朋友问我当时是怎么设计的、踩过哪些…

2026/10/22 0:01:49

若依框架AI代码生成不稳定?用Agent Skill三层结构+五步法搞定

最近一段时间,我一直想把后台管理系统里那些机械重复的增删改查代码交给AI去写。框架用的是若依,按理说这类业务代码模式非常固定,应该是AI最擅长的事情。可真试下来却不是那么回事——你让AI生成一个用户管理模块,它给出的Contro…

还想了解更多?直接咨询顾问

免费诊断 + 免费方案 + 透明报价。

全国咨询热线400-8866-253
免费获取方案
☎咨询二维码 ☎ ↑