用提示词安装 Linux：四部曲系列
第一部分：选择发行版 → 第二部分：存储与加密 → 第三部分：手动安装 → 第四部分：服务与 GPU
我安装 Linux 的次数多到数不清。每一次，选择发行版都靠直觉，或者沿用上次用过的那个。问题在于：如果你要构建某个特定用途的系统，光靠直觉是不够的。一台需要运行 Docker、PostgreSQL、本地 AI 模型，并跨三块加密磁盘进行数据包捕获的安全核心节点？这是一个架构问题，不是凭感觉就能解决的问题。
本章将告诉你如何构建对话框架，让 AI 给出真正的架构建议，而不是维基百科式的摘要。你将把真实的工作负载告诉它，获得有条理的推理分析，将硬件映射到存储方案，并在固件问题耗费你数小时之前提前发现它们。读完本章，你将掌握一套可复用的方法，适用于任何构建、任何硬件、任何发行版。
第一个提示词最关键
大多数人在考虑安装 Linux 时，会在 ChatGPT 里输入这样的问题：
"我应该安装哪个 Linux 发行版？"
然后得到的回答正如你所料：一份发行版清单，配上浅尝辄止的描述。Ubuntu 适合新手。Fedora 的软件包更新。Arch 是给喜欢折腾的人用的。谢谢，毫无帮助。
问题不在于 AI，而在于提示词。你问的是泛泛的问题，得到的自然是泛泛的答案。一旦你从"我该装什么"转变为"这台机器需要做什么"，整个对话就会截然不同。
以下是真正有效的提示词模式：
1I'm setting up a Linux machine for [specific role].
2My requirements are: [list workloads].
3The machine needs to support: [list services].
4What distribution should I consider and why?结构简单，输出质量却大相径庭。你给了 AI 足够的上下文来进行推理，而不仅仅是背诵信息。
你的构建究竟需要什么
在发出那个提示词之前，先把用途说清楚。不要说"一台 Linux 服务器"，而要说明它具体做什么。对于安全核心节点（本系列贯穿始终的构建案例），工作负载清单如下：
- Docker 容器，运行多种安全工具和服务
- PostgreSQL 和 Redis，用于结构化数据存储和缓存
- Ollama，用于运行本地 AI 模型（不依赖云端）
- 未来的 NVIDIA GPU 直通，用于加速推理
- 攻击痕迹存储，具备完善的证据链隔离
- 加密多磁盘存储，横跨 NVMe、SSD 和 HDD
- 长期稳定性，避免因激进更新导致频繁故障
这已经不再是"选哪个发行版"的问题了，而是一个架构问题。当你以这种方式来描述需求时，AI 就会开始思考软件包生态、内核支持周期、驱动可用性以及社区工具链。你的职责是提供约束条件，AI 的职责是对这些条件进行推理。
推理过程是如何展开的
把这样一份工作负载清单交给 AI，你得到的不只是一个答案，还有每个选项背后的推理逻辑。以下是你可以期待的内容：
Kali Linux 获得最强推荐。它基于 Debian，意味着稳健的包管理和广泛的兼容性。安全工具要么预装，要么一条 apt install 就能搞定。滚动发布让工具保持最新，同时又不像 Arch 那样不稳定。而且其社区专注于这台机器所要完成的工作类型。
Ubuntu Server 位居第二。Docker 支持出色，社区庞大，有 LTS 版本。但对于以安全为核心的构建，你前两天都会花在安装 Kali 默认就带的工具上。它是通用基础，而你需要的是专用基础。
Debian Stable 过于保守。软件包版本落后于 Ollama 和较新 NVIDIA 驱动的需求，你会不断与反向移植包较劲。
Arch Linux 的软件包最新，但在运行生产数据库和 Docker 服务的机器上使用滚动发布，无异于自找麻烦。一次糟糕的 pacman -Syu 就能让你的 PostgreSQL 实例宕机。
Fedora Server 有其亮点，但引入了基于 RPM 的工具链，与大多数安全工具所针对的 Kali/Debian 生态不一致。
核心洞见
你不会只得到一个发行版名称。你会得到每个选项的推理过程、每个发行版在你特定工作负载下的短板，以及足够的上下文让你自己做出明智的判断。这就是"问选哪个发行版"和"描述你在构建什么"之间的区别。
对于这个构建，选择是 Kali。不是因为它流行，也不是因为某个 YouTube 视频这么说，而是因为工作负载特征与 Kali 的设计目标高度契合，而 Debian 基础又为 Docker 和 PostgreSQL 提供了所需的稳定性。你的构建也许会指向不同的方向，这正是让 AI 进行推理而非靠猜测的全部意义所在。
硬件探查对话
确定发行版之后，先别急着下载 ISO。首先，弄清楚你手头的硬件究竟是什么。这正是 AI 对话真正发挥威力的地方。
试试这个提示词：
1You are a security expert and are setting up a clean Kali Linux
2install. I'm sitting in front of the terminal. What commands do
3you want me to run to get you all the specs and hard drives
4available to plan this?再读一遍。你不是在问"怎么查看我的 CPU"，而是在让 AI 根据规划所需，自行设计整个探查流程。这是一种本质上不同的交互方式。你把调查的主导权交给 AI，由你来执行命令并反馈结果。
这种分工之所以有效，是因为 AI 处理密集技术输出的速度远超大多数人的阅读速度。
AI 要求获取的信息（以及每类信息的重要性）
你会得到一份按类别分组的命令清单，不是随机命令，而是一套经过深思熟虑的探查协议。以下是你可以期待的内容：
固件模式（ls /sys/firmware/efi 或检查 BIOS 设置）：这决定了你的整个引导策略。UEFI 意味着 GPT 分区表和 ESP 分区，传统 BIOS 则意味着 MBR 和不同的引导加载程序配置。搞错这一点，你就得重新安装。
CPU 和内存（lscpu、free -h）：核心数和内存大小决定了你能同时运行多少个 Docker 容器、本地 AI 模型能否装入内存，以及 PostgreSQL 配置可以有多激进。
磁盘清单（lsblk -o NAME,SIZE,TYPE,ROTA,TRAN,MODEL、fdisk -l）：每块磁盘的大小、接口类型（NVMe、SATA）和是否为机械盘。这是存储架构的基础。
控制器模式（BIOS 设置、dmesg | grep -i ahci）：AHCI、RAID 还是 IDE 模式会影响磁盘性能和 Linux 兼容性。某些处于 RAID 模式的控制器会对安装程序隐藏单独的磁盘。
GPU 硬件（lspci | grep -i vga、lspci -nn | grep -i nvidia）：这有两个关键原因。第一，NVIDIA GPU 如果处理不当可能导致安装程序崩溃；第二，了解确切的 GPU 型号可以确定后续需要哪个版本的驱动。
网络设备（ip link、lspci | grep -i net）：安装过程中需要网络访问来下载软件包。了解你使用的是 Intel、Realtek 还是 Broadcom 网卡，可以判断是否需要额外的固件包。
现有分区表（fdisk -l、blkid）：在清除任何数据之前，必须先了解现有的数据和分区方案。
SMART 健康状态（smartctl -a /dev/sdX）：磁盘健康数据可以告诉你哪些驱动器适合长期存储，哪些在高负载工作下可能会出现故障。
工作流程模式
实际操作中，流程是这样的：
- AI 给出一批命令
- 你在终端中执行这些命令
- 将输出结果粘贴回对话中
- AI 解读结果并提出后续问题
- 重复上述步骤，直到完整画面浮现
你不需要理解 lspci 输出的每一行含义。AI 会读取它，标记出相关内容，并告诉你这对你的构建意味着什么。可以把这理解为协作式排查：你是执行者，AI 是分析师。这种分工之所以有效，是因为 AI 处理密集技术输出的速度远超大多数人的阅读速度。
AI 解读你的硬件
完成所有发现命令后，你将得到如下硬件清单（这是本系列构建所用的实际硬件）：
- NVMe 固态硬盘，1TB：三星 970 EVO Plus，顺序读取速度约 3,500 MB/s
- SATA 机械硬盘，1TB：西部数据蓝盘，5400 RPM，机械式
- SATA 固态硬盘，128GB：较旧的金士顿，性能尚可但容量偏小，SMART 数据显示存在温度异常事件
- GPU：Intel 集成显卡 + NVIDIA GeForce（混合/Optimus 配置）
- 内存：32GB DDR4
- CPU：Intel i7，8 核 / 16 线程
原始规格只是数字，关键在于 AI 如何将其映射到你的工作负载。将硬件输出粘贴回对话框，看它如何根据你之前描述的需求，推导出一套存储架构，将每块磁盘的特性与对应要求相匹配。
三层存储架构
对于多磁盘构建，AI 会提出一套分层系统，让每块磁盘承担最适合它的工作负载：
第一层：NVMe（主力盘） 负责所有需要高速访问的任务。操作系统、Docker 容器存储、PostgreSQL 数据库、Redis 数据以及 Ollama AI 模型都放在这里。这些工作负载会产生大量随机 I/O，NVMe 应对起来毫不费力。该磁盘配合 LVM 使用 LUKS 加密，以实现灵活的分区管理。
第二层：SATA 固态硬盘（热工作区） 用于活跃分析。处理案例时，你需要快速访问提取的样本、临时工具输出和进行中的数据。128GB 固态硬盘提供固态速度的访问，同时避免用临时文件污染主 NVMe。同样采用 LUKS 加密，挂载为专用工作区。
第三层：SATA 机械硬盘（冷存档） 用于长期保留。数据包捕获、取证导出、证据归档，以及所有需要保存但无需快速访问的内容。机械硬盘在这里恰到好处：容量大、成本低，顺序写入可靠。使用独立密钥进行 LUKS 加密。
"不要把数据库放在机械硬盘上，也不要把 NVMe 带宽浪费在一年只打开两次的文件上。让存储层级与访问模式相匹配。"
为何小容量固态硬盘不适合作为根磁盘
这里有一个你可能会踩的坑：用较小的固态硬盘作为根磁盘，把 NVMe 留给数据使用。听起来合乎逻辑，但 AI 会强烈反对，原因如下。
仅 Docker 镜像和容器卷在安全工作站上就可能占用 40 到 60GB。再加上 PostgreSQL 数据目录、Ollama 模型文件（每个可达 4 到 8GB）以及系统软件包，根分区至少需要 80 到 100GB 才能舒适运行。在 128GB 的磁盘上，几乎没有任何增长空间。拉取一个大型 Docker 镜像，容量占用就可能达到 95%。
SMART 数据还带来另一个隐患。如果固态硬盘已记录过热节流事件，它虽然没有故障，但也不是你希望用作系统根盘的那块磁盘。
NVMe 显然是首选主盘。速度更快、容量更大、健康状况更好，而且正是为根分区上 Docker 和数据库所产生的那种混合随机/顺序工作负载而生。不必过度纠结。
节省数小时的固件检查
这正是发现流程在第一个字节写入磁盘之前就体现价值的地方。
早期的某条发现命令可能会揭示你的机器正运行在 Legacy BIOS 模式下。机器在传统模式下运行正常，但对于加密多磁盘构建而言，这是错误的选择。这正是 AI 会捕捉到而你可能不会想到去检查的那类问题。原因如下：
Legacy BIOS + MBR 将每块磁盘限制为四个主分区。对于使用 LVM 的三磁盘加密构建，这是一个实实在在的约束。你最终不得不以增加不必要复杂性的方式使用扩展分区和逻辑卷。
UEFI + GPT 消除了分区数量限制，原生支持更大的磁盘容量，并提供更简洁的启动流程。对于加密多卷构建，GPT 才是正确的基础。
如果 AI 标记出这个问题，你的下一步是在安装前进行三项固件更改：
- 在 BIOS 设置中切换到 UEFI 模式
- 禁用安全启动（Kali 的安装程序可以处理安全启动，但在初始设置和驱动安装期间会增加摩擦，尤其是涉及 NVIDIA 时）
- 确认 AHCI 模式已为 SATA 控制器启用（可能已经设置，但需要确认）
这类问题你往往不知道需要去查，直到它真的咬了你一口。在发现阶段就捕捉到它，在 USB 启动盘还没有制作之前，能节省大量时间和挫败感。在 BIOS 设置中切换固件只需五分钟。而在安装过程中途才发现问题，则意味着从头再来。
你的可复用方法论
整个流程归结为一套方法论，适用于任何构建、任何硬件、任何发行版。收藏备用。
第一步：用具体性描述你的目标。 不是"我想要 Linux"，而是"我需要一个运行这些服务、处理这些工作负载、存储这类数据的系统。"你越具体，AI 就能越好地推理你的选项。
第二步：让 AI 设计发现流程。 不要逐条谷歌命令，告诉 AI 它扮演的角色，让它设计调查方案。它会要求检查你自己不会想到的内容。
第三步：执行并反馈结果。 运行命令，粘贴输出。你是执行者，AI 是分析师。这种分工之所以有效，是因为 AI 处理密集技术输出的速度比大多数人阅读的速度更快。
第四步：让 AI 结合你的目标进行解读。 脱离上下文的原始规格毫无意义。128GB 固态硬盘用作媒体服务器根分区完全没问题，但对于 Docker 密集型安全工作站而言则危险地偏小。AI 将硬件映射到工作负载需求，并标记出你可能忽略的不匹配之处。
第五步：反复迭代直到全貌清晰。 发现过程很少只需一轮。AI 会提出后续问题，比如"那块旧固态硬盘的 smartctl 显示什么？"或者"NVIDIA GPU 是主显示适配器吗？"每一轮都会让方案更加精准。
"你不需要记住 Linux 命令，你需要知道自己在构建什么。AI 负责在目标与实现之间做翻译。"
无论你是在搭建家庭媒体服务器、开发工作站、网络设备还是渗透测试平台，这套方法论都同样适用。命令会变，模式始终如一。
现在你已经确定了发行版、完成了完整的硬件清单、制定了分层存储方案，并完成了固件设置。从这里开始，一切都是执行。第二部分将把所有这些转化为实际的分区方案：加密卷、LVM 布局、挂载点，以及在安装程序接触磁盘之前验证一切的准备脚本。那才是构建真正开始的地方。
下一篇：第二部分：存储与加密 涵盖加密卷设计、LVM 布局，以及在安装开始前验证硬件的安全检查脚本。带上你的终端。
