第一章：理念
瓶颈不在于 AI 的能力——而在于你的工具和工作流。我们已经有了能写代码、能调 bug、能做复杂推理的模型，但大多数研究者仍然是 SSH 到服务器、启动脚本、然后祈祷。AI 能做到的事和研究者实际在用它做的事之间，存在着巨大的鸿沟。这份指南，就是为了弥合这个鸿沟。
— 受 Andrej Karpathy 启发
GPU 保姆问题
你一定经历过这样的日常。
周四傍晚，你调了一整天超参，终于找到一组看起来有戏的配置。你启动了训练。预估时间：14 小时。也就是说，如果一切顺利，周五早上就能看到结果。
你想回家。你想和家人吃顿饭，看场电影，睡个好觉。但你没走。或者你走了，整个晚上都在看手机，刷 WandB，窝在沙发上用笔记本 SSH 进去，确认 loss 还在下降。
朋友约你周六出去玩。你犹豫了。三个不同 seed 的 ablation 实验正在跑。万一其中一个崩了呢？万一 data loader 在第 40 个 epoch 碰到了一个损坏的样本然后抛异常呢？你见过这种事。你取消了计划。
这就是 GPU 保姆问题。它不是技术问题——你的代码没问题，服务器没问题，数据也没问题。它是工作流问题。整个流程依赖一个人类时刻在场、保持警觉、随时准备介入。你就是监控系统。你就是崩溃检测器。你就是错误处理器。而你在这三个角色上都很糟糕，因为你还需要睡觉、吃饭、思考、读论文，偶尔还得想起来实验室之外还有生活。
每个有经验的深度学习研究者都已经内化了这种代价。他们甚至不再抱怨了。就是这样的。你启动一个任务，你去检查它，你祈祷一切顺利。那种焦虑变成了背景噪音——始终存在，却从未被正视。
但事情不必如此。
静默失败
真正伤人的场景是这样的。
周二晚上，你离开实验室前启动了一个大规模训练——4 块 GPU，一个你花了两周预处理的数据集，一个你迭代了一个月的新架构。你回家时心情不错。明天早上就能看到第一批真正的结果了。
早上七点，你醒了。SSH 进去。tmux session 还在，但进程已经死了。你往上翻输出，看到了：CUDA out of memory，epoch 3。时间戳显示 23:47。这意味着你的四块 GPU 已经完全空转了超过七个小时。七个小时的算力，浪费了。不是因为实验失败了——失败没关系，失败是信息——而是因为没有人在那里发现、诊断、重启。
还有更惨的版本。你在开会。或者在探亲。或者难得休了个假。午夜时分你心里莫名不安，掏出手机看了一眼。你可以用 Termius SSH 进去，你也看到训练崩了，你甚至能读到错误日志。但修复需要改一个配置文件、调整 batch size、重启脚本。用手机。用大拇指。凌晨一点。在酒店房间里。所以你没修。你告诉自己明天再处理。又是八个小时的 GPU 空转。又是一天白白浪费。
静默失败最残忍的地方不在于浪费的算力，而在于浪费的时间。你的 GPU 小时确实很贵，但你的日程表更贵。那个训练本来应该在周五组会前给你结果。现在你落后了一天。而落后一天意味着你在压力下做决策，在下一个实验上偷工减料，在分析时赶进度。一次静默失败会像多米诺骨牌一样冲击你整个研究时间线。
如果有人一直在盯着呢？
现在想象一个不同的场景。
还是周二晚上。同样的训练，同样的 4 块 GPU，同样的新架构。你回家了。23:47，训练因为同样的 OOM 错误崩了。但这一次，有些事情发生了。
一个 AI agent——运行在你的本地机器上，通过 SSH 连接到服务器——检测到 GPU 利用率跌到了零。它读了错误日志。它定位了问题：在那个特定的层深度，batch size 对于 activation memory 来说太大了。它修改了配置，缩小了 batch size，调整了梯度累积步数来补偿，然后重启了训练。整个过程花了九十秒。23:49，训练重新开始运行。
早上七点，你醒了。掏出手机，打开 Termius，输入："status？"AI 回复：训练在 23:47 因 OOM 崩溃一次，已用 batch size 16 替换 32 重启，当前 epoch 27，loss 正常。你点了点头，放下手机，去泡咖啡。
这就是这份指南的承诺。
不是通用人工智能。不是一个替你做研究的系统。是一个务实得多的东西：一个 AI 助手，它 24 小时盯着你的训练，检测崩溃，读错误日志，修复明显的问题，然后重启。它帮你同步代码、管理环境、让你的 GPU 保持忙碌。你需要的只是一部手机，偶尔看一眼。
你依然是那个研究者。你来做决策——跑哪些实验、验证哪些假设、哪些结果重要。但你不再是保姆了。午夜的闹钟检查、被取消的周末、焦虑地刷新页面——这些都变成了别人的工作。而这个"别人"从不睡觉，从不分心，从不忘记检查。
架构概览
这个系统有三个节点。这份指南的每一部分都连接着这个架构，所以现在就值得好好理解。
你的手机（Termius） 这是你进入系统的窗口。无论你在哪里——咖啡馆、会场、凌晨两点的床上——你都可以 SSH 到本地机器，和 Claude Code 对话。你查看状态，给出高层指令，做出决策。你不在手机上写代码，不在手机上调 bug。你告诉 AI 该做什么，它就去做。
你的本地机器（Claude Code） 这是大脑。Claude Code 在这里运行，在一个持久的 tmux session 里。它管理你的 git 仓库，编辑代码，把文件同步到服务器，协调一切。它通过 SSH 连接到 GPU 服务器并执行命令。当服务器上出了问题，Claude Code 是那个发现、诊断、修复问题的角色。你的本地机器不需要 GPU——它只需要稳定的网络连接和运行 Claude Code 的能力。
为什么本地机器在中间？因为 Claude Code 需要一个持久的、始终在线的环境来运行，而你的手机提供不了。手机连了又断，笔记本开了又合。但一台台式机或者小型家用服务器，跑着 tmux，始终在那里。它是整个系统的锚点。
你的 GPU 服务器（训练） 这是实际计算发生的地方。训练在 tmux session 里运行。一个轻量级的 watchdog 脚本监控 GPU 利用率和进程健康状态。Conda 环境管理你的依赖。服务器不知道也不关心 Claude Code 的存在——它只接收 SSH 命令并执行。所有的智能都在你的本地机器上。
数据流是这样的：你通过手机和 Claude Code 对话。Claude Code 通过 SSH 和 GPU 服务器通信。当训练崩溃时，watchdog 检测到，Claude Code 读日志修问题，而你下次打开手机时看到一行状态更新。
三个节点。手机负责控制。本地机器负责智能。服务器负责算力。简洁、稳健，无论你在实验室还是在海边，都能正常工作。
你将在这份指南中构建什么
这份指南将带你从零开始搭建整个系统，一步一个章节。
第二章：远程访问 — 你将配置 SSH 密钥、设置连接、安装 Tailscale 组网，并用 Termius 从手机连接到服务器。完成后，你可以从任何地方访问你的机器。
第三章：持久会话 — 你将学习 tmux，它是让后面一切成为可能的工具。你的进程不会因为断开连接而终止，你的会话可以跨重启保持，你再也不会因为 SSH 连接中断而丢失一个训练任务。
第四章：网络与代理 — 你将配置 SSH 多路复用，让多个连接共享一条隧道，并为需要代理才能访问外网的服务器设置端口转发。
第五章：Claude Code 安装 — 你将安装 Claude Code，完成 API 认证，了解使用成本，并让它在 tmux 里运行，确保随时可用。
第六章：教会你的 AI — 你将编写 CLAUDE.md 文件，教 Claude Code 认识你的具体服务器、GPU 配置、conda 环境和研究习惯。这一章，一个通用的 AI 会变成你的研究助手。
第七章：自动化 — 你将配置 hooks、watchdog 监控和定期健康检查。这一章之后，Claude Code 从一个你和它对话的工具，变成一个能自主行动的系统。
第八章：研究工作流 — 你将看到完整的流程：从想法到代码、到训练、到结果，Claude Code 全程调度。这是一切汇聚的地方。
第九章：第一个实验 — 你将端到端地跑一个真实实验。Claude Code 写训练脚本，同步到服务器，启动训练，监控过程，最后把结果呈现给你——而你全程通过手机观看。
检查点
拿一张纸画出三节点架构。标注每个节点：手机、本地机器、GPU 服务器。写下每个节点的职责。画出它们之间的数据流箭头。
如果你能解释为什么本地机器在中间——为什么手机不直接连接 GPU 服务器来做 AI 辅助研究——你就理解了这个系统。接下来的八个章节，你将亲手搭建它。