Mac 负责处理、转写与创作，NAS 负责存储、归档和媒体服务。真正影响体验的往往是共享协议和文件路径稳定性。
Mac 和 NAS 应该各做擅长的事
我的 Mac 不是服务器，NAS 也不是创作工作站。
我更习惯让它们各自承担最合适的任务：
- Mac：剪辑、转写、翻译、建模、渲染预览、浏览器工具和日常生产力
- NAS：文件归档、媒体库、Docker 服务、长期备份和多设备访问
这样做避免了两个极端：
- 把所有工作文件都堆在 Mac 内置硬盘
- 试图让性能有限的 NAS 承担大量实时处理
文件路径稳定比“理论速度”更重要
在实际使用 MacWhisper 处理 NAS 上的媒体文件时，我遇到过 SMB 连接不稳定的问题。
有时文件已经选中，处理过程中却提示文件找不到；有时网络共享重新连接后，应用看到的路径已经变化。这种问题不一定是带宽不够，而更像是共享挂载和路径稳定性的问题。
后来我使用 AFP 访问 NAS 文件，在我的工作流里反而更稳定。
这不是说 AFP 对每个人都一定更好，而是提醒我：
对需要长时间读取源文件的应用来说，稳定的挂载路径比协议名称更重要。
如果一个任务要运行几十分钟，传输速度快一点但中途断开，体验反而更差。
我会把文件分成三类
为了避免 Mac 和 NAS 来回同步时混乱，我倾向于这样分：
01 Inbox
新下载、待处理、临时素材
02 Working
当前在 Mac 上频繁编辑的项目
03 Archive
已完成项目、原始素材、长期媒体和最终输出其中：
Inbox可以放 NAS 或 Mac，根据任务大小决定Working尽量在本地 SSD 上，保证应用响应Archive放 NAS，并有额外备份策略
例如一个字幕项目，我会把待转写的视频放入 Inbox；在 Mac 本地生成中间文件；最后把字幕、原文件和最终视频归档到 NAS。
Apple Silicon 对本地转写的意义
Mac 对语音转写这类任务很合适。
MacWhisper 可以利用 Apple Silicon 的本地计算能力处理音频转写，避免每次都把视频上传到云端。对于较长的视频或敏感内容，这种本地优先的方式很有价值：
- 不受上传带宽限制
- 不需要为每次转写支付 API 费用
- 源文件不离开本地与 NAS 体系
- 可以在后台慢慢处理
当然，本地转写不一定适合所有任务。需要高质量翻译、术语统一或批量处理时，我仍然会使用 API 工具补充。
Homebrew 和小工具
Mac 上的很多效率提升并不来自大型软件，而是一些足够明确的小工具和脚本。
我会用 Homebrew 安装命令行工具、媒体处理工具和网络工具，但不会为了“什么都能装”无限扩展环境。
一个实用原则是：
- 经常用的工具才安装
- 关键工具记录安装命令
- 定期清理不用的服务
- 配置文件放进可备份目录
- 不要把唯一配置只留在某个终端历史里
最后
Mac 与 NAS 的组合最舒服的状态，是你不必每次都思考“文件到底在哪”。
Mac 用于当前工作，NAS 用于长期保存；共享路径稳定，目录结构简单；任务完成后能归档，出现问题后能恢复。