Codex 自动帮我搭完 sub2api 之后，我基本就不再研究手动部署了。
这不是一句泛泛的 AI 提效感慨。这个 sub2api 现在就是我们团队共用的中转服务。今天我又指导别人搭 sub2api、newapi 这类中转服务，更确定了一件事：
很多部署事务，已经不值得人从头研究一遍。
如果你还在为自己用的中转服务查教程、翻 README、试命令、搜报错，我会很直接地说：这件事大概率应该交给 Codex 跑完，而不是继续消耗你的注意力。
手动部署贵的不是时间过去我们说“搭一个服务”，听起来只是花点时间。
但真实成本不是那半小时、一小时。
真实成本是你要把脑子切进去：先判断哪个仓库可信，再读安装说明，再猜环境变量，再处理端口、权限、日志、重启。中间任何一个小报错，都可能把你的注意力切碎。
这类工作最尴尬的地方在于：它重要，但不值得你亲自研究每一步。
sub2api 对我们来说不是一个“研究对象”，它是团队工作流里的一个中转服务。我要的是它能跑起来、能稳定用、来源别错、配置别乱。
至于中间那些查资料、拉包、启动、排错、确认日志的过程，本来就可以交给 AI。
AI 编程工具真正先接走的，不是人的判断，而是这些低杠杆但高打断的事务。
Codex 适合做这种闭环我自己用的是桌面版 Codex。
当时搭 sub2api 的时候，我甚至没有先去找 GitHub 地址。Codex 会自己把这部分补上，继续往下处理部署，遇到问题再自己排。
但这不代表人完全不管。
为了避免安装来源出错，我现在会明确建议使用这个 release 地址：
https://github.com/Wei-Shaw/sub2api/releases
这就是边界。
我不再研究手动部署，不等于我不管来源、不管安全、不管结果。
我只是把自己从“执行每一步”里抽出来，改成管三件事：目标是什么，来源是否可信，最后能不能用。
这类任务和开发核心软件不一样。
如果你让 AI 改业务逻辑、动生产数据、设计权限边界，那当然要谨慎。但搭 sub2api 这种中转服务，目标非常清楚：拉起来，配好，能访问，能给团队用。
结果能不能验收，一眼就知道。
不是不会做，是不该亲自做很多人还停在旧习惯里：我得自己研究一遍，才算真的会。
这个想法以前有道理，因为工具不够强，你不亲自研究，事情就推不动。
但现在问题变了。
当 Codex 可以自己查资料、跑命令、处理常见报错，并把服务搭起来时，人继续亲自啃部署流程，就不一定是在负责了。
有时候只是舍不得放掉旧的掌控感。
会手动部署，不代表每次都应该手动部署。
真正应该训练的是另一种能力：把任务描述清楚，把边界讲清楚，把验收标准讲清楚。
比如你要告诉 AI：
• 我要搭的是 sub2api，不是随便找个类似项目。
• 安装来源优先用官方 release。
• 这是给团队共用的中转服务，不是本地玩具。
• 凭据和配置不能乱放。
• 最后必须确认服务真的能访问。
这些才是小团队负责人该盯的东西。
人要站到验收位今天再看 sub2api/newapi 这类中转服务，我的判断很简单：
如果只是自己用，甚至是团队内部用，且目标清楚、路径公开、结果可验证，那就别再把精力耗在手动研究部署上。
让 Codex 跑。
人站在旁边验收。
这不是偷懒，而是把人的注意力从事务里拿回来。
AI 工作流的关键，不是让人消失，而是让人从执行位移到验收位。
以后小团队要搭的东西只会越来越多：中转服务、内部工具、后台、脚本、自动化任务。
如果每一个都靠人从头查教程、试命令、排错，团队的注意力很快会被消耗在一堆不产生判断增量的事务里。
Codex 自动搭完 sub2api 之后，我改变的不是一个部署方法。
我改变的是一个习惯：能让 AI 闭环的事务，不再先用人的注意力去填。
说明：本文基于本人真实使用经历与团队工作流观察整理，AI 参与文字梳理、润色与排版。
你现在搭开源服务或内部工具时，最不敢交给 AI 的是哪一步：找来源、跑命令、排错，还是最后验收？