杭州团队的周五修复：通过 SSH 与编码智能体远程结对

周五下午，登录错误只在远程环境出现

假设你在杭州的一支小团队工作，周五下午要修复一个登录错误。项目已经部署在远程开发机上，本地却缺少相同的依赖环境。与其重新搭建，不如通过 SSH 登录开发机，让编码智能体在那里协助定位问题。

这就是一种远程结对编程方式：你负责目标、判断和授权，智能体负责阅读代码、提出修改并执行获准的操作。这里的“结对”不是把任务交出去就不管了，而是有人持续掌舵。

SSH 管连接，智能体管代码协作

SSH 是安全连接远程计算机的工具。连接成功后，你在笔记本终端里输入的命令，实际由远程机器执行。编码智能体则是能够调用工具的编程助手；根据权限，它可以搜索文件、修改代码、运行测试。

本文采用最直观的布置：项目和智能体都在远程开发机上，你通过 SSH 操作它们。模型通常通过网络 API 提供推理能力。因此，SSH、智能体和模型服务是三个不同环节，不是一条连接解决所有事情。

先准备独立分支和最小权限账户

第一次尝试，请使用开发机或隔离的测试环境，不要直接操作生产服务器。远程账户只需要访问项目目录，不必拥有管理员权限。

• 准备 SSH 地址、用户名和密钥，私钥留在自己的电脑上。
• 确认远程机器已经安装项目依赖，以及你选择的智能体工具，例如 Claude Code。
• 检查工作区是否有未提交修改，再创建独立分支，例如 git switch -c fix/login-timeout。
• 确认测试使用专门的测试数据库，没有指向生产数据。

首次连接时，应通过团队可信渠道核对服务器主机密钥指纹，不要为省事关闭主机校验。

把终端会话留在远程开发机上

在本地终端输入 ssh dev@devbox.example.com。这里的账户和地址是示例，需要替换为自己的信息。连接后先运行 pwd 和 git status，确认自己站在正确的项目目录。

如果远程机器安装了 tmux，可以运行 tmux new -s login-fix，再启动智能体。网络断开后，重新通过 SSH 登录，运行 tmux attach -t login-fix，即可返回仍在运行的会话。它能减少断线带来的中断，但不能替代保存文件和提交代码。

让远程智能体连上模型服务

按照所用工具的官方配置方式，在远程机器设置认证信息和服务地址。不同工具对自定义服务的配置方式不同，不能把某个 SDK 的环境变量直接当成所有工具的通用设置。配置后先做一次简短请求，确认认证与模型选择有效。

如果希望按实际用量支付模型调用费用，可以考虑 RelayVano；它支持 Claude Code、Codex、Gemini CLI 和 OpenAI 兼容 SDK，API 基础地址为 https://api.relayvano.com。你可以注册账户，先用一个小任务验证连接和开销。

密钥不要写进代码仓库或提示词。远程运行也不代表代码完全留在服务器：智能体可能把代码片段和工具输出发给模型服务，应先确认团队的数据使用规则。

把登录修复拆成可核对的小步

第一条指令可以这样写：“请先阅读登录处理逻辑和相关测试，找出超时后返回错误状态码的原因。暂时不要修改文件，也不要安装依赖；先列出证据和修复计划。”

看过计划后，再允许它修改明确的文件，并运行对应测试。如果工具提供逐次审批功能，保留对命令执行的确认，尤其注意删除文件、安装依赖和访问外部网络的操作。

• 先复现：记录失败输入、错误输出和现有测试结果。
• 再修改：要求最小改动，不顺手重构无关模块。
• 后验证：补充回归测试，并检查相邻登录路径。

合并前，由人检查差异和测试结果

智能体说“已修复”不等于任务完成。运行 git diff，逐处检查修改是否符合预期；阅读测试的真实输出，而不只看它给出的摘要。测试失败时，先判断是环境问题还是代码问题，不要直接要求它“改到通过”。

最后由你决定是否提交、发起评审和合并，不让一次登录修复自动变成生产部署。远程结对的价值，是把搜索、试验和验证做得更顺畅，同时让每一步仍然可见、可控、可撤回。