AI怎么用？

更新时间：2026-07-09。
主要讲 AI 的基本分类、Codex、Claude Code、opencode、中转站、拼车、代理协议和机场。

先说重点
#

这篇主要讲平时真会碰到的一串东西：

text
代码工具（Codex / Claude Code / opencode）
  -> 模型能力（OpenAI / Claude / GLM / MiniMax / Kimi / Qwen / DeepSeek）
  -> API 形态（模型官方 API / NewAPI / sub2api / 中转站）
  -> 账号与额度（订阅 / API Key / 拼车 / 资源池）
  -> 网络环境（机场 / 住宅 IP / 海外电脑系统 / 代理协议）

Codex、Claude Code、opencode 和普通聊天机器人不一样。它们不是只回答一句话，而是要读仓库、改代码、跑命令、看日志、修测试，连续干很多步。所以它们对模型、API、网络、账号、本地环境都更挑。

在中国大陆用这些东西，可以记住一句话：国内模型已经不弱，海外代码 Agent 也确实好用；真正影响体验的，经常不是模型会不会写代码，而是账号、额度、API、网络和设备环境能不能稳定配起来。

0. 先分清 AI 到底是哪一类
#

平时说“AI”，其实可能在说很多不同层级的东西。它们都叫智能算法，但能力边界、本地性能要求、部署方式完全不一样。下面每类都放一个开源方向和一个商用/云服务方向，方便先建立概念。

类型	主要解决什么	典型输入/输出	开源例子	商用/云服务例子	本地性能要求
传统机器学习模型	分类、预测、排序、风控、推荐	表格特征 -> 类别/分数/预测值	scikit-learn、XGBoost、LightGBM	阿里云 PAI、Amazon SageMaker、Azure Machine Learning	通常较低，CPU 就能跑很多推理场景，训练才更吃资源
传统深度学习模型	图片分类、目标检测、语音特征、NLP 分类	图片/音频/文本 -> 固定任务结果	PyTorch、TensorFlow、YOLO、ResNet	百度 EasyDL、腾讯云 TI、AWS Rekognition 自定义模型	推理中等，常用 GPU/AI 加速；模型越大越吃显存
OCR	从图片或 PDF 里识别文字	图片/扫描件 -> 文本和坐标	Tesseract OCR、PaddleOCR	百度 OCR、阿里云 OCR、腾讯云 OCR、Azure AI Vision	轻量 OCR 可 CPU 跑，批量高精度识别更适合 GPU 或服务端
语音识别 ASR	把语音转文字	音频 -> 文本	Whisper、FunASR、Vosk	讯飞开放平台、阿里云智能语音交互、Azure Speech、Google Speech-to-Text	小模型可本地 CPU/普通 GPU，大模型实时转写更吃算力和显存
语音合成 TTS	把文字转语音	文本 -> 音频	Piper、Coqui TTS、ChatTTS	Azure Speech、阿里云智能语音交互、讯飞语音合成、ElevenLabs	普通合成要求中等，高质量克隆音色和实时合成更吃 GPU
多模态大模型	同时理解文字、图片、音频、视频和工具结果	多种输入 -> 文本/代码/结构化结果	Qwen2.5-VL、InternVL、LLaVA、MiniCPM-V	GPT-4o、Claude、Gemini、豆包视觉理解、通义千问 VL	本地要求最高，通常需要大显存 GPU；多数人直接用云端 API
代码 Agent	让模型读仓库、改代码、跑命令、修测试	需求 + 项目文件 + 工具结果 -> 可落地改动	opencode、Aider、Continue	Codex、Claude Code、Cursor、GitHub Copilot	本地主要要求是开发环境稳定；真正大算力通常在云端模型侧

可以粗暴记成三层：传统 AI 更像“专门干一个任务的模型”，OCR/语音识别是成熟的专用能力，大模型/多模态/代码 Agent 更像“能理解上下文并调用工具的通用能力”。

OCR 和语音识别并不等于多模态大模型。OCR 的核心目标是把图里的字读出来，语音识别的核心目标是把声音转成文字；多模态大模型是在读懂文字、图片、语音、视频之后继续推理、总结、写代码或调用工具。前两者可以作为大模型的输入前处理，也可以单独使用。

从本地部署角度看，传统模型和轻量 OCR/ASR 最容易本地化；多模态大模型和强代码模型最难本地化。普通程序员日常最现实的路线通常是：本地保留开发环境、脚本、缓存和轻量工具，把大模型推理交给云端 API 或公司统一网关。

1. 先说代码 Agent
#

1.1 普通 Chatbot 与代码 Agent 的区别
#

普通 Chatbot 一般是这样：

text
用户提问 -> 模型回答 -> 用户复制结果

代码 Agent 一般是这样：

text
用户描述目标
  -> Agent 读取项目文件
  -> Agent 制定计划
  -> Agent 修改多个文件
  -> Agent 运行测试或命令
  -> Agent 根据报错继续修
  -> Agent 给出 diff、测试结果和解释

所以，代码 Agent 更像一个能进项目干活的助手，不是普通代码问答机器人。它主要吃这几样东西：

模型能力：能不能理解大型代码库、跨文件修改、修复杂 bug。
工具权限：能不能读文件、改文件、运行命令、访问浏览器或外部工具。
上下文窗口：能不能容纳足够多的代码、日志、需求和历史对话。
流式与稳定性：任务过程中连接不能频繁断，输出不能乱停。
本地环境：依赖、测试、构建、Git 状态、系统权限都要配合。

1.2 为什么总有人提 Codex 和 Claude Code
#

到 2026 年 7 月，程序员聊得比较多的代码 Agent 大概是这三类：

Codex：OpenAI 的代码 Agent，重点是与 ChatGPT、OpenAI 模型、CLI、IDE、桌面 App、本地项目和云端任务协作。
Claude Code：Anthropic 的代码 Agent，重点是复杂代码理解、长任务、终端工作流、测试修复和大上下文代码推理。
opencode：开源、模型无关的代码 Agent，重点是让同一套 Agent 外壳可以接 OpenAI、Claude、Gemini、Qwen、DeepSeek、Kimi、本地模型等不同后端。

它们其实是三种路线：

路线	代表工具	关键特点
官方工具路线	Codex	和 OpenAI 账号、模型、客户端绑得更紧
终端工具路线	Claude Code	擅长读大项目、修复杂问题、跑终端任务
开源工具路线	opencode	工具开源，后面的模型可以换，方便接国产模型和本地模型

理解这三条路线以后，后面的 NewAPI、sub2api、中转站、拼车、机场、海外家宽就好理解了：这些东西都是在解决“模型从哪里来、账号额度怎么分、网络怎么走、环境怎么保持稳定”。

1.3 国内模型放在哪里
#

国内模型这里不展开太多，知道大概放哪就行：

GLM-5.2 / GLM-5：适合作为国产默认强模型，偏代码、Agent 工程、复杂工具调用和长任务。
MiniMax M3：适合长上下文、多模态、复杂 Agent、大仓库理解。
Kimi K2.6 / K2.7 Code：适合开放权重、代码 Agent、本地或私有化路线。
Qwen Max / Qwen 开放模型：适合阿里云体系和本地部署。
DeepSeek：适合便宜批处理、普通问答、推理备用和 OpenAI 兼容接入。
豆包：适合火山/字节体系、中文内容、多模态和国内业务。

简单说，国内模型不是这篇文章的主角，但它们很适合接到 opencode、自建 NewAPI、本地推理服务、批处理脚本后面。

1.4 后面按什么顺序讲
#

后面按这个顺序讲：

先说几个基本概念：LLM、Token、API、Agent、OpenAI 兼容 API。
再说 ChatGPT、Codex、Claude Code、opencode 分别是什么。
再说为什么会有中转站、NewAPI、sub2api，把不同模型和账号统一成一个 API。
再说拼车、海外信用卡、海外家宽、服务器、海外电脑系统。
最后说代理协议、GFW、机场，因为这些会直接影响海外 AI 产品和代码工具能不能稳定用。

2. 先把几个词说清楚
#

LLM / 大语言模型
#

LLM 是 Large Language Model，大语言模型。它可以接收文本、图片、音频、代码、工具返回结果，然后继续生成内容。现在的大模型不只是聊天，还能调用工具、写代码、改代码、抽取信息、做简单计划。

Token
#

Token 是模型处理文本的基本单位。它不完全等于汉字、英文单词或字节。API 计费、上下文窗口、输出长度一般都按 token 计算。

API
#

API 是程序调用模型的接口。ChatGPT 网页版是给人用的；OpenAI API、Claude API、DeepSeek API、阿里百炼 API 是给程序调的。很多人会把“订阅账号”和“API 额度”混在一起，其实它们不是一回事。

OpenAI 兼容 API
#

很多模型服务会说自己支持“OpenAI 兼容接口”。意思是它的 URL、请求字段、流式返回格式尽量模仿 OpenAI。这样很多客户端、SDK、Agent 工具不用为每家模型单独写适配。

Agent
#

Agent 不是某一个模型，而是一种用法：模型可以读上下文、做计划、调用工具、看结果，再继续下一步。代码 Agent 一般能读文件、改文件、运行命令、跑测试、提交 diff。

API 网关 / 聚合器 / 中转站
#

它们一般夹在客户端和模型服务中间：

text
客户端/Agent/业务系统
        |
        v
AI API 网关 / 中转站 / 聚合器
        |
        +--> OpenAI
        +--> Anthropic Claude
        +--> Google Gemini
        +--> DeepSeek
        +--> Qwen
        +--> Kimi
        +--> 本地模型

它们做的事就是统一入口、分配 Key、限流、计费、记日志、选模型、失败重试、格式转换。

3. ChatGPT 是什么
#

ChatGPT 就是 OpenAI 给人用的 AI 助手。可以聊天、写东西、翻译、总结、问代码、看图片、分析文件、联网搜索、做数据分析，也能生成图片、调用工具。

这里要分清三件事：

ChatGPT 产品
网页、桌面、手机 App 里的聊天助手，主要给人直接用。
OpenAI API
给程序调用模型用，一般单独计费，也单独管理 Key。
OpenAI Codex
这是写代码、改代码用的 Agent，后面单独讲。

在国内用 ChatGPT，很多时候不是网页本身复杂，而是环境复杂：账号地区、手机号、支付卡、出口 IP、浏览器指纹、系统时区、语言、Cookie、网络质量，哪一层不稳都可能出问题。

4. Codex 是什么
#

Codex 是 OpenAI 的代码 Agent。现在说 Codex，一般不是指早期那个代码补全模型，而是指能围着一个代码仓库干活的工具。

它可以做这些事：

根据需求修改代码；
阅读和解释陌生代码库；
做代码审查，找 bug、边界条件和逻辑问题；
调试失败测试；
运行命令、测试、构建、迁移脚本；
在 CLI、IDE、桌面 App、云端任务等不同界面中协作。

简单说，ChatGPT 更像聊天助手，Codex 更像会进仓库干活的助手。它的重点不是给你一段代码，而是看懂项目结构，改多个文件，跑验证，再把 diff、日志、测试结果交给你看。

在国内用 Codex，主要看三层：OpenAI 账号和订阅、网络质量、本地项目。它比普通聊天更怕断，因为它要连续读文件、改文件、跑命令、看结果。

5. Claude Code 是什么
#

Claude Code 是 Anthropic 做的代码 Agent，背后用 Claude 模型。常见用法是在终端、IDE、GitHub 或网页里让它处理代码任务。

一般用法是：在终端进入项目目录，用自然语言说要改什么，然后它读文件、改代码、跑命令、看测试结果，再继续修。

它的特点大概是：

强项是复杂代码理解、重构、测试修复、长任务；
与命令行工具结合紧密，可以使用 git、测试框架、构建工具、MCP 服务器；
运行在本地终端时，工具在本机执行，但模型请求仍会发往 Anthropic 或配置的上游；
官方称其在修改文件或运行命令前会请求权限；
Claude.ai、Anthropic API、Claude Code 的可用性与账号地区、网络出口、订阅形态和 API 额度强相关。

Claude Code 比普通 Claude 聊天更吃环境：终端权限、仓库大小、测试命令、依赖安装、网络出口、长任务会话，都会影响体验。

6. opencode 是什么
#

opencode 是一个开源代码 Agent。它最大的特点是模型可以换：可以接 OpenAI、Claude、Gemini、GitHub Copilot、很多第三方模型，也可以接本地模型。

与 Codex、Claude Code 相比：

Codex 主要跟 OpenAI 账号和模型绑定；
Claude Code 主要跟 Anthropic Claude 绑定；
opencode 更像一个开放外壳，后面的模型可以换；
如果想接国产模型、本地模型、自建网关，它会更灵活。

它适合这些场景：

团队希望用同一个代码 Agent UI 尝试多个模型；
想接 Qwen、DeepSeek、Kimi、本地 Ollama/vLLM 等；
想审计或改造 Agent 工具链；
想减少对单一模型服务商的绑定。

不过只要一个工具能读代码、改文件、跑命令，就要认真管权限、密钥、命令审批和日志。

7. 什么是“中转站”
#

“中转站”不是官方叫法，是中文圈子的俗称。意思是你不直接调 OpenAI、Claude、Gemini、DeepSeek，而是调一个第三方给你的 Base URL 和 Key，它再帮你转到上游。

它流行主要是因为这些事：

某些境外 AI 服务在中国大陆不可直接使用或不稳定；
账号、支付、团队购买流程复杂；
多模型切换麻烦；
团队希望统一额度、统一账单、统一 Key；
有些人希望把订阅账号“转成 API”给工具使用；
国内外模型价格差异大，开发者想做成本优化。

一个中转站大概有这些模块：

入口层：提供 OpenAI 兼容 Base URL、API Key、流式响应、模型列表。
鉴权层：识别用户、套餐、额度、并发数、调用频率。
路由层：把 gpt-5、claude-sonnet、gemini-pro、deepseek-chat 等模型名映射到实际上游。
账号池/Key 池：维护多个上游 API Key、OAuth token、订阅账号或自建模型实例。
计量层：记录 token、请求数、错误率、延迟、余额和账单。
转换层：在 OpenAI、Anthropic、Gemini、Claude Code、Codex、Responses API、Chat Completions 等格式之间做适配。

所以中转站并不神秘，就是模型 API 反向代理 + 账号池调度 + 计费系统。

8. NewAPI 是什么
#

NewAPI 是一个开源的模型网关，来自 One API 这一路。简单说，它把很多模型服务商放到一个后台里管理，再对外给一个统一接口。

它常见功能有：

多家模型渠道管理；
Token、用户、分组、可用模型控制；
用量统计、额度管理、成本核算；
OpenAI、Claude、Gemini 等格式之间的部分转换；
渠道权重设置、失败重试、限流；
Web 管理后台；
自己部署。

可以把 NewAPI 理解成“模型 API 网关 + 计费后台 + 路由器”。如果手里有很多模型 API，不想每个项目都单独配一遍，它就有用。

NewAPI 更适合自建网关：接多个模型，然后给不同人、不同项目分配 Key、额度、可用模型。

9. sub2api 是什么
#

sub2api 也是一个开源网关，但更偏“把订阅账号、多账号资源变成一个 API 入口”。它会生成自己的 Key，做鉴权、计费、负载分配、转发、并发控制和用量统计。

它和 NewAPI 的区别可以粗略这么看：

NewAPI 更像“多模型 API 聚合与管理平台”；
sub2api 更强调“订阅账号、多账号、OAuth/API Key 资源池、统一转发和额度分发”；
sub2api 的 README 中明确提到它用于分发和管理 AI 订阅中的 API 配额，并支持 Claude、OpenAI、Gemini、Grok 等统一接入。

sub2api 更像“订阅资源池”。把多个账号、OAuth token、API Key 接进来，再对外给一个 API 平台式入口。主要看多账号调度、sticky session、OAuth 刷新、额度分配、并发控制、异常账号摘除、请求重试、用量统计。

10. 拼车是什么
#

“拼车”就是多人共用一份订阅、额度、账号或 API 资源。说白了，就是有人把资源买好，再拆成几个“车位”分给别人用。

常见拼车对象包括：

ChatGPT Plus / Pro / Team；
Claude Pro / Max / Team；
Cursor、Windsurf、GitHub Copilot、Perplexity、Midjourney；
OpenAI、Anthropic、Google、DeepSeek、Qwen、Kimi 等 API 额度；
海外代理订阅、机场流量、住宅代理流量；
海外手机号、邮箱、支付卡、云服务器、远程桌面。

常见拼车方式有几种：

拼车形态	实现方式	体验
人工共享账号	同一账号多人登录	最简单，体验接近原版产品，但容易互相影响会话和设备状态
远程浏览器 / 远程桌面	车主维护海外浏览器环境，车友远程使用	浏览器、Cookie、IP、时区、系统环境更统一
API Key 分发	车主购买 API，再给车友分发子 Key	最适合接入代码工具、Bot、Agent 和内部脚本
中转站拼车	用 NewAPI、sub2api 或自研网关统一额度	用户只拿一个 Base URL 和 Key，不关心上游账号
机场拼车	多人共享代理订阅或节点流量	关注线路、倍率、延迟、解锁能力和剩余流量

拼车里的常用词：

车主：组织资源的人，负责购买、维护、分配、收款。
车友：加入共享资源的人。
车位：一个可用名额，可以是账号席位、API 子 Key、流量份额或远程桌面用户。
发车：拼车开始。
翻车：账号、节点、额度、支付或环境失效。
补票：续费或补差价。
限速/限额：对车友做并发、频率、流量或 token 限制。

从简单看，拼车就是资源池 + 鉴权 + 计量 + 分账。NewAPI、sub2api、机场面板、订阅转换器，都在做类似的事。

11. 笔者认为最稳的 AI 访问环境
#

我觉得比较稳的方案是：

text
海外信用卡 + 海外家用带宽 + 服务器 + 海外电脑系统

这四样东西各管一层。

11.1 海外信用卡
#

AI 平台做支付时，经常会看卡 BIN、账单地址、支付地区、账号地区、IP 地区、设备环境。海外信用卡的作用，是让这些信息看起来更一致。很多订阅失败，不是模型问题，是支付风控问题。

比较理想的是：

海外信用卡或虚拟卡；
与卡匹配的账单地址；
长期稳定的邮箱和手机号；
账号注册地区、登录地区、支付地区尽量一致。

11.2 海外家用带宽
#

AI 平台对 IP 的判断不只看国家，还会看 ASN、机房属性、代理属性、滥用记录、是否为机房 IP、是否被大量账号共用。

海外家用带宽有几个好处：

IP 看起来像真实家庭宽带；
与普通用户访问行为更接近；
相比云服务器 IP，更不容易被识别为批量代理出口；
适合长期维护账号 Cookie、浏览器历史和设备画像。

这也是为什么“住宅 IP”“家宽”“原生 IP”“ISP 线路”在 AI、流媒体、跨境电商、广告投放圈子里都很重要。

11.3 服务器
#

服务器不是用来替代家宽的，它更像中间层：

部署 NewAPI、LiteLLM、sub2api、订阅转换器；
作为代理入口、反向代理、跳板或监控节点；
跑代码 Agent、浏览器 Agent、自动化脚本；
维护日志、限流、账单和模型路由；
做远程开发环境、CI、文件同步和定时任务。

家宽更像可信出口，服务器更像可控中枢。两者配起来，用起来会更稳。

11.4 海外电脑系统
#

海外电脑系统可以是真实物理机、远程桌面、云桌面、海外 Mac mini、Windows 主机，或者长期使用的一台 Linux 桌面。它主要解决设备指纹和使用环境问题。

重要变量包括：

系统语言、地区、时区；
浏览器语言、字体、插件、Canvas/WebGL 指纹；
Cookie、LocalStorage、登录历史；
DNS、IP、WebRTC、IPv6 暴露情况；
App Store / Microsoft Store / Google Play 地区；
邮箱、手机号、支付方式和账号恢复方式。

对 ChatGPT、Claude、Codex、Claude Code 这类产品来说，网络只是第一层。长期稳定体验来自“账号、支付、IP、设备、系统、浏览器历史”整体一致。

12. 翻墙技术大概怎么发展过来的
#

这里说的“翻墙技术”，就是各种代理、隧道、混淆、流量伪装技术。大概可以按时间分成几代。

12.1 HTTP / SOCKS 代理时代
#

早期最常见的是 HTTP 代理、SOCKS4/5 代理、CGIProxy、PHPProxy、在线网页代理。特点是简单、便宜、门槛低，但协议特征明显，容易被封锁、限速或污染。

这一时期常见词：

HTTP proxy；
SOCKS proxy；
SSH dynamic forwarding；
网页代理；
公开代理列表。

12.2 VPN 和 SSH 隧道时代
#

后来常见的是 OpenVPN、PPTP、L2TP/IPSec、Cisco AnyConnect、SSH tunnel。这类更像把整台机器接到另一个网络。

特点是：

配置简单，系统自带支持较多；
协议指纹明显；
长连接、固定端口、固定握手容易被识别；
OpenVPN、IPSec、PPTP 这类传统 VPN 在躲识别上不占优势。

12.3 Shadowsocks 时代
#

Shadowsocks 的出现是一个分水岭。它不是传统 VPN，而是轻量加密代理。客户端本地监听 SOCKS/HTTP，远端服务器转发流量。它的优势是简单、轻、快，容易部署，适合个人和小团队。

Shadowsocks 的技术关键词：

AEAD 加密；
本地 SOCKS 代理；
UDP 转发；
插件混淆，例如 simple-obfs、v2ray-plugin；
订阅链接和各种客户端。

早期 Shadowsocks 的问题是协议特征逐渐被研究，单纯加密代理不等于隐蔽代理，于是后续出现了更多混淆和伪装技术。

12.4 V2Ray / VMess / VLESS 时代
#

V2Ray 不是单个协议，更像一个代理框架。它支持多入口、多出口、多路由、多协议、多传输层，可以把代理流量放到 TCP、mKCP、WebSocket、HTTP/2、gRPC、QUIC 等不同通道里。

VMess 曾经是 V2Ray 的主力协议，后来 VLESS 更流行。VLESS 去掉了 VMess 的一些复杂认证机制，配合 TLS、XTLS、Reality 等传输方式，把重点放在外层传输伪装和性能上。

这一阶段常见词：

VMess；
VLESS；
WebSocket + TLS；
HTTP/2；
gRPC；
XTLS；
Reality；
分流规则和路由表。

12.5 Trojan 和“像 HTTPS 一样”的路线
#

Trojan 的思路是尽量让代理流量看起来像普通 HTTPS 服务。它一般跑在 TLS 上，外观接近真实网站流量。与传统 VPN 相比，它更强调“混在正常 TLS 流量里”。

Trojan 这一类思路的变化是：代理协议不只追求加密，还要看起来像正常互联网服务。后面的 Reality、NaiveProxy、Hysteria、TUIC 也都在处理类似问题。

12.6 QUIC / UDP / Hysteria / TUIC 时代
#

随着 HTTP/3 和 QUIC 普及，很多代理方案开始使用 UDP 承载，提高弱网和高丢包环境下的吞吐。

代表路线：

Hysteria / Hysteria2：基于 QUIC 思路，强调高延迟、高丢包环境下的传输性能。
TUIC：基于 QUIC，兼顾认证、多路复用和性能。
sing-box：统一客户端/服务端框架，支持 Shadowsocks、VLESS、Trojan、Hysteria2、TUIC、WireGuard 等。

这类协议在体验上经常表现为“速度快、抗丢包强”，但 UDP 在部分运营商网络里也可能被限速、丢包或阻断。

12.7 浏览器伪装和真实客户端路线
#

另一条路线是尽量复用真实浏览器或真实协议栈：

NaiveProxy 基于 Chromium 网络栈；
Chrome/Edge 浏览器的 TLS/HTTP2/HTTP3 指纹更接近真实用户；
部分方案强调 JA3/JA4、ALPN、SNI、HTTP/2 frame、TLS extension 顺序等细节。

背后的逻辑很简单：现在不只看有没有加密，还看你像不像真实浏览器、真实 App、真实用户。

13. GFW 大概会怎么处理这些流量
#

GFW 不是一台机器，而是一整套跨运营商、跨出口、跨协议的检测和干扰系统。它也从早期的域名/IP 封锁，慢慢发展到流量指纹、主动探测、行为分析。

13.1 DNS 污染
#

DNS 污染是最早、最常见的手段之一。用户查询某些域名时，解析结果会被注入错误 IP、保留地址或不可达地址。表现为域名解析成功但网站打不开，或者解析到奇怪 IP。

常见现象：

本地 DNS、运营商 DNS、公共 DNS 返回结果不一致；
同一个域名在境内外解析结果不一样；
DoH/DoT/DoQ 可以改变 DNS 查询路径，但不等于解决所有封锁。

13.2 IP 封锁与端口封锁
#

如果某个代理节点、服务器或机房 IP 被识别，最直接的做法就是封 IP 或封端口。表现为某个节点突然完全不可连，或者某个端口不可用但换端口可用。

所以机场经常强调：

多入口；
多落地；
多地区；
中转；
自动故障切换；
节点池轮换。

13.3 SNI / Host / HTTP 头识别
#

TLS 早期握手中的 SNI 会明文暴露访问域名，HTTP 请求里的 Host 头也能暴露目标服务。对未加密或半加密流量来说，基于域名和 Host 的过滤很直接。

ECH、HTTP/3、QUIC、DoH 等技术都在不同程度上减少明文信息暴露，但现实网络里还要看客户端、服务端、CDN 和中间网络是否完整支持。

13.4 TLS 指纹和流量指纹
#

现代识别不只看域名，还会看协议指纹。常见维度包括：

TLS ClientHello 的扩展顺序、cipher suites、ALPN；
JA3/JA4 指纹；
HTTP/2 frame 行为；
包长分布；
上下行比例；
连接持续时间；
首包大小；
心跳和重传情况；
是否像真实浏览器或真实 App。

所以很多协议后来不再自己搞一套明显的握手，而是复用 TLS、WebSocket、gRPC、QUIC、Chromium 网络栈。

13.5 主动探测
#

主动探测是 GFW 对代理节点的重要识别方式。简单说，当系统怀疑某个 IP:Port 是代理服务时，会从探测节点主动连接它，尝试发送特定握手或异常数据，看它是否表现出代理服务器特征。

代理协议一般会这样处理：

失败时伪装成普通 Web 服务；
需要正确认证才返回代理行为；
错误认证时返回正常网页、空响应或 TLS 失败；
使用真实站点证书或外观；
减少可被重放的固定握手特征。

13.6 机器学习和行为分析
#

随着加密普及，明文内容越来越少，流量行为本身变得更重要。高阶检测会把 IP、端口、协议、ASN、连接频率、账号行为、流量峰值、客户端特征综合起来判断。

所以现在比的不是单纯加密，而是：

像不像正常 HTTPS；
像不像真实浏览器；
是否使用高信誉出口；
是否多人共享同一出口；
节点是否频繁被扫描；
流量模式是否异常。

14. 现在常见的代理协议
#

14.1 Shadowsocks
#

Shadowsocks 现在还很常见，适合轻量代理和自用节点。它客户端多，配置简单。单独用时不如早期隐蔽，所以经常配合插件、混淆或其他传输层。

14.2 VMess / VLESS
#

VMess 是 V2Ray 早期常见协议，VLESS 后来更常见。现在很多节点会写成：

text
VLESS + TLS
VLESS + gRPC
VLESS + Reality
VLESS + XTLS

VLESS 的优势是灵活，能和多种传输层组合。Reality 这类方案强调减少传统证书和域名配置负担，让外观更接近真实 TLS 连接。

14.3 Trojan
#

Trojan 的思路是把代理服务伪装在 HTTPS 之后。它一般看起来像正常 TLS 服务，错误访问时可以返回普通站点或正常 TLS 行为。很多机场仍然提供 Trojan 节点，特别是对流媒体和网页访问场景。

14.4 Hysteria2
#

Hysteria2 主要优势是弱网速度。它基于 QUIC/UDP 思路，对高延迟、高丢包链路比较友好。缺点是 UDP 在部分网络下可能不稳定，运营商可能对 UDP 做限速或丢包。

14.5 TUIC
#

TUIC 也是 QUIC 路线，兼顾多路复用、认证和低延迟。它在一些场景下比传统 TCP 代理更快，但同样受 UDP 网络质量影响。

14.6 NaiveProxy
#

NaiveProxy 依赖 Chromium 网络栈，目标是让流量更像真实 Chrome 访问 HTTPS。它的思路不是设计一个很“代理味”的协议，而是尽量复用真实浏览器网络行为。

14.7 WireGuard / OpenVPN
#

WireGuard 和 OpenVPN 是经典 VPN 技术。它们适合组网、远程办公、内网访问、点对点连接，但在“伪装成普通网页流量”这个目标上不如 VLESS/Trojan/NaiveProxy 这类路线自然。

14.8 sing-box / Clash / Mihomo
#

多数用户实际接触到的不是协议本身，而是客户端内核：

Clash / Clash Meta / Mihomo：常用来做规则分流和订阅管理。
sing-box：支持协议多，配置模型现代，适合统一管理各种入站/出站。
V2Ray / Xray：常见于 VLESS、VMess、Reality、XTLS 这些组合。
Shadowrocket、Stash、Quantumult X、Loon、Surge：iOS/macOS 上常见客户端。

这些客户端最大的用处是分流：国内网站直连，国外网站走代理，AI 服务走好出口，流媒体走解锁节点，开发工具走低延迟节点。

15. 机场大概是怎么运作的
#

“机场”是代理服务商的俗称。它一般不是一台服务器，而是一整套代理服务。

15.1 机场的大概结构
#

一个机场大概有几层：

text
用户客户端
  |
订阅链接 / Clash / sing-box / Shadowrocket 配置
  |
入口节点 / 中转节点
  |
专线 / 隧道 / 公网链路
  |
出口节点
  |
目标网站 / AI 服务 / 流媒体

简单说：

入口节点：用户实际连接的节点，可能在香港、日本、新加坡、台湾、美国等地。
中转节点：用于改善国内到海外的链路质量，常见于高端机场。
出口节点：最终访问目标网站的出口 IP，决定地区、流媒体解锁、AI 可用性、IP 信誉。
专线：如 IPLC、IEPL、MPLS、企业跨境专线等，特点是延迟和稳定性更好。
公网中转：用普通云服务器转发，成本低但波动大。

15.2 机场面板
#

机场一般会有一个网页面板，用来做这些事：

用户注册和登录；
套餐购买；
流量统计；
节点订阅；
工单；
公告；
邀请返利；
节点测速；
订阅链接重置。

常见面板有 V2board、SSPanel、AirGo、Marzban、Xboard，也有很多自研面板。面板后面再接节点管理、支付、流量统计、订阅生成、限速限流。

15.3 订阅链接
#

订阅链接很关键。用户不用手动复制每个节点，只要把订阅 URL 导入客户端，就能拉到节点列表、协议、端口、加密方式、倍率、地区和分流规则。

订阅转换器负责把一种格式转成另一种格式：

Clash 配置；
sing-box 配置；
Surge 配置；
Quantumult X 配置；
Shadowrocket 配置；
V2RayN / V2RayNG 配置。

15.4 倍率、流量和限速
#

机场常用“倍率”算流量。比如某个节点 2x，用户实际用了 1GB，面板扣 2GB。高倍率节点一般是专线、低延迟、解锁好，或者落地成本高。

常见套餐维度：

月流量；
在线设备数；
速率上限；
节点等级；
流媒体解锁；
AI 解锁；
专线倍率；
低倍率普通节点。

15.5 AI 解锁节点
#

AI 解锁节点关注的不是单纯网速，而是出口画像：

是否为住宅 IP；
是否为原生 IP；
ASN 是否干净；
是否被大量代理用户滥用；
是否能访问 OpenAI、Claude、Gemini、Grok、Perplexity；
是否能完成登录、支付、验证码和长会话。

对 AI 来说，很多时候“低延迟数据中心节点”不如“稳定住宅出口”。这就是为什么 AI 场景里家宽、住宅代理、远程海外桌面会显得特别重要。

15.6 机场与 AI 中转站的关系
#

机场解决网络出口，中转站解决 API 入口。两者经常一起用：

text
本地客户端 -> 机场节点 -> AI 官方服务

业务系统 -> AI 中转站 -> 上游模型 API

业务系统 -> AI 中转站 -> 机场/代理出口 -> 上游模型 API

如果目标是网页使用 ChatGPT/Claude，机场更重要。如果目标是程序调用模型，AI 中转站更重要。如果目标是稳定跑 Codex、Claude Code、opencode 这类代码 Agent，网络出口、API 网关、本地环境都重要。

16. 总表
#

名称	是什么	用来干什么	后面接什么	重点
ChatGPT	面向人的 AI 助手产品	聊天、写作、分析、代码问答、多模态	OpenAI	账号、订阅、浏览器环境、网络出口
OpenAI API	开发者 API	把模型接入产品或脚本	OpenAI	API Key、模型、token、流式响应
Codex	OpenAI 代码 Agent	读改代码、跑测试、审查、调试	OpenAI / ChatGPT 账号或 API	本地仓库、命令执行、长任务会话
Claude	Anthropic AI 平台/模型	通用问答、写作、分析、代码	Anthropic	长上下文、推理、写作、代码
Claude Code	Anthropic 代码 Agent	终端/IDE/GitHub/Web 里的代码任务	Claude 模型/API/订阅	终端权限、仓库理解、测试修复
opencode	开源代码 Agent	用不同模型驱动本地代码 Agent	多供应商或本地模型	模型无关、可接国产模型和本地模型
NewAPI	开源 AI API 网关	多模型聚合、路由、鉴权、计费、格式转换	多家模型 API	自建模型网关、用户和额度管理
sub2api	开源 AI API 网关/订阅转 API 工具	多账号/订阅资源统一 API 化、额度分发	订阅账号、OAuth、API Key 等	资源池、账号池、OAuth、限流
中转站	第三方 API 代理/聚合服务	低门槛调用境内外模型	多种上游	反向代理、格式转换、计费、路由
拼车	共享资源模式	共享账号、额度、API、代理流量	车主资源池	车位、额度、账号环境、分账
机场	代理服务商	网络出口、节点订阅、流媒体/AI 解锁	节点、专线、出口 IP	协议、线路、倍率、订阅、落地

17. 怎么用比较顺
#

17.1 自己学习
#

可以按四层理解：

应用层：ChatGPT、Claude、Gemini、Kimi、豆包、通义、文心。
Agent 层：Codex、Claude Code、opencode、Cursor、Windsurf。
API 层：OpenAI API、Claude API、DeepSeek API、Qwen API、NewAPI、sub2api。
网络层：机场、VLESS、Trojan、Hysteria2、TUIC、住宅 IP、远程桌面。

这四层经常绑在一起。比如用 Claude Code 写代码，就会同时碰到 Claude 账号、终端工具、网络出口、项目依赖、API/订阅额度。

17.2 团队里用
#

团队里用 AI，比较实用的是“多模型 + 网关 + 路由”：

默认聊天和技术问答走 GLM-5.2。
复杂代码 Agent、长上下文任务和本地模型后端按实际项目评测选择。
网关层用 NewAPI、LiteLLM 或自研服务统一 Base URL、Key、日志、计费和模型路由。

17.3 访问环境
#

如果目标是稳定用海外 AI 产品，体验大概是：

text
海外家宽 + 海外电脑系统 + 海外支付环境
    >
质量好的住宅代理 / 原生 IP
    >
质量好的机场 AI 解锁节点
    >
普通云服务器代理
    >
免费代理 / 公开节点

如果目标是稳定调 API，体验大概是：

text
模型官方 API Key + 自建网关 + 稳定服务器
    >
靠谱中转站 + 可控额度
    >
拼车 API 池
    >
临时共享 Key

18. 建议阅读顺序
#

如果只花 30 分钟看，可以按这个顺序：

先理解 LLM、API、Token、Agent、OpenAI 兼容 API。
再区分“人用产品”和“程序 API”：ChatGPT/Claude vs OpenAI API/Claude API。
再理解“代码 Agent”：Codex、Claude Code、opencode。
再理解“网关和中转”：NewAPI、sub2api、中转站。
再理解“拼车和机场”：账号池、资源池、节点、订阅、流量、倍率。
最后理解“代理协议”：Shadowsocks、VLESS、Trojan、Hysteria2、TUIC、NaiveProxy。

19. 总结
#

国内模型已经不弱，开源/开放权重模型也很多。
ChatGPT 是 OpenAI 的通用 AI 助手，Codex 是 OpenAI 的代码 Agent。
Claude 是 Anthropic 的模型和助手，Claude Code 是 Anthropic 的代码 Agent。
opencode 是开源、模型无关的代码 Agent，可以接多家供应商或本地模型。
NewAPI 是开源模型网关，适合统一管模型、额度、用户和计费。
sub2api 更偏把订阅和多账号资源变成 API，重点是账号池、OAuth、额度分发和转发。
拼车是资源池共享模式，机场是网络出口服务，AI 中转站是 API 层代理。
笔者认为最稳的海外 AI 使用环境是：海外信用卡 + 海外家用带宽 + 服务器 + 海外电脑系统。

先说重点#

0. 先分清 AI 到底是哪一类#

1. 先说代码 Agent#

1.1 普通 Chatbot 与代码 Agent 的区别#

1.2 为什么总有人提 Codex 和 Claude Code#

1.3 国内模型放在哪里#

1.4 后面按什么顺序讲#

2. 先把几个词说清楚#

LLM / 大语言模型#

Token#

API#

OpenAI 兼容 API#

Agent#

API 网关 / 聚合器 / 中转站#

3. ChatGPT 是什么#

4. Codex 是什么#

5. Claude Code 是什么#

6. opencode 是什么#

7. 什么是“中转站”#

8. NewAPI 是什么#

9. sub2api 是什么#

10. 拼车是什么#

11. 笔者认为最稳的 AI 访问环境#

11.1 海外信用卡#

11.2 海外家用带宽#

11.3 服务器#

11.4 海外电脑系统#

12. 翻墙技术大概怎么发展过来的#

12.1 HTTP / SOCKS 代理时代#

12.2 VPN 和 SSH 隧道时代#

12.3 Shadowsocks 时代#

12.4 V2Ray / VMess / VLESS 时代#

12.5 Trojan 和“像 HTTPS 一样”的路线#

12.6 QUIC / UDP / Hysteria / TUIC 时代#

12.7 浏览器伪装和真实客户端路线#

13. GFW 大概会怎么处理这些流量#

13.1 DNS 污染#

13.2 IP 封锁与端口封锁#

13.3 SNI / Host / HTTP 头识别#

13.4 TLS 指纹和流量指纹#

13.5 主动探测#

13.6 机器学习和行为分析#

14. 现在常见的代理协议#

14.1 Shadowsocks#

14.2 VMess / VLESS#

14.3 Trojan#

14.4 Hysteria2#

14.5 TUIC#

14.6 NaiveProxy#

14.7 WireGuard / OpenVPN#

14.8 sing-box / Clash / Mihomo#

15. 机场大概是怎么运作的#

15.1 机场的大概结构#

15.2 机场面板#

15.3 订阅链接#

15.4 倍率、流量和限速#

15.5 AI 解锁节点#

15.6 机场与 AI 中转站的关系#

16. 总表#

17. 怎么用比较顺#

17.1 自己学习#

17.2 团队里用#

17.3 访问环境#

18. 建议阅读顺序#

19. 总结#