缘起#
在第一篇中，我介绍了重新使用NixOS的原因。其中很重要的一点，就是现在可以让AI帮忙查资料、写配置和处理报错，减少自己从头找选项的时间。
经过这段时间的迁移和维护，几台电脑的配置已经放进同一个flake，用户环境、服务和操作记录也逐渐整理起来。不过，用AI之后，仍然会遇到配置放错位置、构建失败、服务没有按预期运行等问题。只是这些工作有了一个可以一起查文件和修改代码的助手。
前面几篇介绍了具体工具和使用方法，这里回头整理一下哪些工作适合让AI帮忙，以及我现在怎样检查它的修改。例子来自这段时间的维护和写作，不展示私人配置，也不把所有遇到的问题都当作AI造成的。
AI适合做的工作#
查找选项与解释报错#
NixOS有很多模块和选项，自己刚接触一个服务时，通常要先找文档，再确认当前版本支持什么。AI可以先读已有配置，找到相应模块，解释报错里提到的文件和选项，给出一个修改起点。
我觉得这种帮助最有用的地方，是减少在不同文件之间来回找的时间。例如，配置冲突可能来自公共模块和主机模块，AI可以帮忙找到两处定义，再说明各自的用途。之后仍要决定应该修改默认值、调整导入，还是确实需要覆盖，具体方法在第六篇里介绍过。
选项名和示例需要对应当前锁定的版本。有些网上配置来自不同发行版或不同时间，直接拼起来未必能用。让AI查看当前模块源码，通常比仅凭记忆写一个看起来合理的选项更方便检查。
整理重复配置#
多台电脑都会使用的工具和用户设置，可以让AI帮忙找出重复内容，整理到公共模块。硬件、显示器和主机用途不同的部分，则继续分别保存。
这也是我使用一个flake管理几台电脑的原因。不过，文件看起来相似，不代表它们应该全部合并。例如，服务器与桌面的服务需求不同，某台电脑的驱动设置也可能只适合它自己。修改之后，最好看看每个主机实际导入了哪些模块。
准备检查与维护记录#
AI可以执行已经明确的检查，整理构建日志，也可以根据命令结果更新操作说明。对于Git同步、子模块更新和重复的部署步骤，这能省去一些手工工作。
记录需要跟着实际结果写。源码同步、构建完成、应用配置和重启，是不同的事情；只有文档变化时，也不会产生新系统代际。上一篇介绍了怎样分别处理这些步骤。
任务说明的写法#
我一般会先说明想达到什么效果，再补充这次可以做到哪一步。软件名只是其中一部分。例如，远程桌面可能是分享已经登录的桌面，也可能是没有显示器时远程使用电脑，配置方法并不一样。
对于一项配置修改，可以这样描述。下面是为了说明写法而整理的示例，不是原始对话：
给这台电脑添加一个仅本机访问的演示网页。先读现有服务配置，检查有没有端口冲突，把修改放到合适的模块里。先构建，不要应用或重启。告诉我改了哪些文件，应用后怎样检查网页。
这里说明了用途、访问范围和是否应用配置。和每次写很长的提示词相比，我更习惯把重复约定放在维护说明中，这次任务只补充不同的地方。维护说明的组织方法可以参考第四篇。
还有一些事情不适合让AI自行猜测，例如是否可以中断正在运行的任务、删除哪份数据、要把服务迁移到哪里。需要这些信息时，应先说明清楚，再继续操作。
检查AI的修改#
查看文件变化#
先看Git里的修改：
| |
这里主要看修改是否符合需求，放进了哪个模块，以及有没有顺便改动其他内容。已有未提交的工作要保留；检查完以后，再明确选择这次需要提交的文件。
对于不熟悉的Nix写法，可以让AI解释相应选项的类型、默认值和模块来源。解释仍需要能在当前源码或文档里找到依据，尤其是修改服务权限、启动顺序和数据目录时。
构建与实际使用#
对于已有flake，可以先检查并构建一个示例主机：
| |
laptop需要替换成自己的输出。这里没有应用配置，--no-build也不会运行那些需要构建的检查。构建成功以后，才按任务安排决定何时应用，具体步骤见第五篇。
应用之后，还要试实际功能。服务可以看看启动状态，再从需要的位置访问；桌面设置可以重新登录后检查；驱动修改则要测试对应设备。AI如果只有SSH访问，可以完成其中一部分，但屏幕显示、触摸或笔等功能，往往还需要在电脑前试一试。
维护中遇到的问题#
主机输出选择#
早期配置一台电脑时，用过一个兼容输出名称，它实际指向另一台电脑的配置，因此把不属于这台电脑的硬件设置也带了过来。维护记录里后来改成了正确的主机输出。
从这个例子看，命令能运行，不代表选中了正确的电脑。让AI构建或应用之前，应检查flake中的输出，以及它会导入的硬件和主机模块。主机名称最好明确写出来，不依赖容易混淆的别名。
构建时间与磁盘空间#
还有一次内核构建因为空间不足失败，后续处理空间后重新构建才完成。Nix配置看起来只是几行修改，实际需要编译的内容却可能很大。
所以我现在会在大型更新前检查空间和已有构建引用，并留出足够时间。AI可以帮忙看日志和解释原因，但反复重新执行同一条命令，并不能解决磁盘不足。清理时也要先确认哪些旧代际是准备保留用于恢复的。
服务状态与数据#
有些问题要等程序运行后才能发现。容器的配置文件生成了，还要应用Compose；服务启动了，还要检查访问入口；跨主机同步任务运行了，还要确认需要的目录确实复制过去。
实际整理数据时，发现过服务目录的来源登记不正确，导致同步规则跳过它。因此，仅看任务运行成功，不足以确认预期数据都已经保存。数据库还需要自己的备份与恢复方法，普通文件同步不能代替这些检查。
迁移服务时，我会先停止原位置的写入，再准备配置、机密和一致的数据，检查新位置正常后才切换访问。AI可以帮忙执行这套安排，但需要明确哪份数据是当前来源，不能让旧副本反过来覆盖新数据。相关经验在第十篇和第十一篇里整理过。
用AI整理文档与博客#
这组博客本身也有类似的问题。让AI按提纲写，很容易得到一篇完整的教程，但其中选择的工具和例子，未必就是我在电脑上采用的方式。
后来回头核对时，就需要补上实际使用的机密管理、Compose部署和数据同步方法，把另外的教学例子说明白。例如，restic练习可以帮助理解历史备份，但不能写成现有电脑已经采用了那套备份。文章中的实际经验和可选方法，需要分别解释。
写作风格也是一样。即使开头写了“缘起”，正文仍可能像操作记录，反复强调检查和验证，读起来和以前的文章不太一致。于是我又拿之前的Python、Docker等文章作参考，调整段落和标题，用平时讲解工具的方法重新整理。
这也让我觉得，AI适合帮忙整理材料和准备初稿，但自己的经验、取舍和表达方式，仍然需要自己看一遍。真实配置、密钥和日志也要在分享前检查，通用方法可以公开，私人内容则继续留在自己的环境中。
推荐的使用方法#
对于NixOS维护，我更愿意让AI从一项明确的小改动开始：先读相关文件，解释要怎么改，再检查和构建。确认这次修改正常之后，再处理下一项，比一次把多台电脑的很多设置都改掉更容易理解。
常用约定和已经解决的问题，保存在仓库文档中。下一次维护时，AI和自己都可以重新读，不必靠记住上一段对话。软件能重新构建，数据、机密和恢复方法也仍然需要另外保存。
对我来说，AI让继续使用NixOS方便了不少，但也没有让我省掉理解配置和尝试功能的过程。这十三篇先把目前常用的概念和方法整理下来，后面有新的硬件支持或服务迁移经验，再写成补充文章。