我开始把个人电脑当成 AI 基础设施，而不只是开发机

最近我处理项目时，开始更经常地想一件事：这项工作应该在哪台机器上发生？以前我的默认答案是当前打开的开发机。写代码、装依赖、跑实验和检查结果，都堆在同一台电脑上。现在，MacBook、运行本地模型的 Mac mini，以及承载网站和应用的云服务器，已经让我面对三种不同的工作环境。

我还没有做出一套三机统一调度系统，也没有证明它们已经能长期无人值守。变化更朴素：我开始把某些机器当成有明确职责的节点，而不只是多一台能打开编辑器的电脑。最近这次远程读取本地 AI 记录，就让我碰到了这种变化里的实际问题。

开发机仍然是工作发生的入口

MacBook 对我最重要的作用，仍然是随时开始和检查工作。我在这里查看项目、调整内容、使用 Codex、看浏览器里的结果，也在这里验收文章和视频。它适合承接人的交互：我能及时改判断，看到问题后直接修正，而不必先把每一个动作都设计成远程任务。

但交互入口与全部计算都留在本机，是两种不同的安排。电脑离开桌面、网络切换，或者我需要把注意力交给别的项目时，某些实验是否应该跟着当前开发环境一起变化？我开始希望，编辑和验收可以继续轻便，部分计算环境则有自己的位置。

这还不是“所有后台任务都迁到另一台机器”的决定。一次很短的本地检查，没有必要因为有了 Mac mini 就增加远程往返。只有当环境需要保留，或者任务确实适合在另一处运行时，拆分才可能减少干扰。

我目前给 Mac mini 的位置，是本地 AI 运行与实验节点。oMLX 的应用和服务进程、模型配置、调用统计，以及语音测试文件，已经能在这台机器上找到。它提供了一个独立于当前编辑窗口的计算环境，云端模型也不因此退出我的工具组合。

我把它称为“长期节点”，首先是在描述想让它承担的职责，还不是经过长期运行验收的承诺。这次观察到服务在运行，并不能回答休眠、重启、断网或者一段时间不维护后会怎样。模型缓存能保留，也不等于任务队列、自动恢复和数据备份都已建立。

因此，我不想一开始就把个人 AI 环境做成一个平台。先理解现有进程由谁启动、资料落在哪里、什么任务真正值得留在这里，比先增加统一调度和管理界面更接近当前的问题。本地模型有什么用途，我另外写在这次本地 AI 实践记录里；这里更关心机器的职责怎样变得清楚。

云服务器已经承载个人网站和应用接口。它面对的是外部访问：域名、HTTPS、服务配置和发布后的可达性，都需要有稳定的管理方式。这里的变更会影响已经在使用的入口，不能只按一次临时实验的方便来安排。

Mac mini 上换一个实验模型，与服务器上更新一个对外服务，后果并不一样。我希望保留这种差别：尝试新能力的位置可以允许试错，对外服务的位置则需要更明确的发布、验证和恢复路径。分成两台机器，不会自动产生这些保障；但职责分开以后，我更容易判断一项改动究竟影响谁。

这次整理资料时，先通过屏幕共享连到了 Mac mini，解锁后才看到桌面。随后改用 SSH 读取记录，又遇到一个具体差别：我能在终端里手动登录，不等于另一个执行进程已经拥有相同的认证条件。服务可达、用户已登录和自动化能执行命令，不能混成一件事。

后来把免密访问配置好，当前客户端才实际读到了模型、统计和日志。这段经历没有证明 SSH 的长期稳定性，却提醒我：当机器开始承担持续计算职责，访问方式就不只是方便自己操作的快捷入口，也是任务能否落到正确环境里的条件。

我希望终端负责可明确表达的检查，屏幕共享保留给需要看界面的场景。远程连接也不应该顺手扩大成公开暴露模型服务。地址、账号和认证材料只用于访问，不需要进入公开文章；是否允许某个客户端操作，应由实际权限说明，而不是凭它“属于我的设备”就忽略。

现在这三个位置形成的是一组开始清晰的职责：MacBook 负责交互开发与验收，Mac mini 留下本地 AI 的运行环境，云服务器承载对外服务。它们之间还没有完整的任务迁移、故障接管或统一监控，我也没有一份能证明全天可靠运行的记录。

我觉得 Personal AI Infrastructure 可能成为自己的基础能力，是因为越来越多工作不只产生代码，还会留下模型、缓存、音频、渲染文件和持续运行的服务。知道这些东西在哪里发生、如何访问、何时需要人检查，开始与写出功能本身一样影响使用体验。

这不是继续添置机器的理由。我更想先让现有设备在一两个实际任务里配合起来，观察是否省去了重复准备环境的工作，是否增加了网络和维护负担。如果分工没有带来明确帮助，就应该调整。把个人电脑当成基础设施，对我目前意味着开始认真安排它承担什么，以及哪些可靠性问题仍然没有答案。