终端里加 AI 编码能力这件事，真正让人头疼的往往不是"装不上"。我这两年在几个团队里推过类似的工具链，最初大家的预期都停留在"能不能用"，跑通之后立刻撞上第二个问题：手上不止一个模型接入通道——有的按量计费便宜但长文件读得吃力，有的上下文窗口大却单价高，有的在特定语言上明显更靠谱。于是每天开工第一件事变成改配置文件、改环境变量、重启终端，改错了还要排查半天。后来我们把这件事工程化了：用 npm 安装终端工具本体，用 cc-switch 这类配置管理工具做第三方大模型的配置档切换，把"换模型"从手工改文件变成一条命令。这篇就把这套做法完整拆开讲，包括安装环节的取舍、配置档该写哪些字段、token 预算怎么估、切换脚本怎么写、以及我们踩过的那些坑。适合已经决定在终端里用 AI 编码助手、并且需要在多个模型接入通道之间来回切的人看。至于某个服务在某个地区能不能订阅、能不能用，那是商务与合规层面的事，本文不做讨论，也不该用技术手段去绕；技术侧能做的是把配置做干净、可切换、可回滚、密钥不裸奔，这才是长期可维护的部分。
1. 先把问题定义清楚：卡点到底在哪一层
1.1 把这类工具的运行链路拆成三段看
终端 AI 编码工具看起来是一个黑盒，其实拆开只有三段：第一段是本地进程，负责读文件、跑命令、维护会话，它由 npm 包提供；第二段是模型请求，进程把上下文打包成一个 HTTP 请求发给某个端点；第三段是端点背后的模型服务，负责推理并返回。这三段里，第一段几乎不会出问题，第三段你控制不了，真正能动手的是第二段——请求发到哪里、带什么密钥、用哪个模型名、超时多久、失败了怎么办。
很多人一上手就去折腾第一段和第三段，结果问题根本不在那里。我见过最典型的例子：某同学花了半天重装 Node、换包管理器、清缓存，最后发现是配置文件里ANTHROPIC_BASE_URL多写了一个/v1，请求打到了不存在的路径上，返回 404，而工具把 404 当成"服务不可用"处理了。所以判断故障之前，先把链路分段，明确自己在哪一段上，能省掉大量无效动作。
1.2 四种最常见的"不能用"，归因完全不同
按我们的排查记录，报错信息看起来相似的情况至少有四类，处理方式完全不一样：
| 表象 | 真实原因 | 该动哪一段 |
|---|---|---|
| 命令能跑，一提问就报鉴权失败 | 密钥无效、过期，或者密钥类型与端点要求不匹配 | 第二段，配置档 |
| 命令能跑，请求超时无响应 | 端点地址写错、路径多了层级、端口不通 | 第二段，端点字段 |
| 请求成功但返回内容被截断 | 模型上下文窗口小于实际输入，或 max_tokens 设得太小 | 第二段，模型参数 |
| 装完命令找不到 | npm 全局 bin 目录不在 PATH 里 | 第一段，环境变量 |
这四类里只有最后一类跟"安装"有关系。所以我在团队里定的规矩是：报错先看 HTTP 状态码和响应体，不要凭感觉重装。工具本身通常会把请求失败的原始信息打出来，翻一翻比什么都快。这个习惯建立起来之后，平均排障时间从半小时降到几分钟。
1.3 为什么选 npm 装 + cc-switch 管配置这个组合
选 npm 的理由很直接：这类终端工具基本都以 Node 包形式首发，官方文档的安装命令就是 npm，跟着官方走能少踩版本坑；而且 npm 的好处是版本可锁定，npm i -g pkg@1.2.3能精确回到某个版本，出问题时可以快速降级验证。
选 cc-switch 这类工具的理由是它把"改配置"这件重复劳动抽象成了配置档。你自己当然可以写脚本切换~/.claude/settings.json，事实上我们最开始就是写脚本的。但脚本的问题在于：配置文件是 JSON，手工拼接容易破坏格式；多台机器同步时路径不一样；团队里非技术岗看不懂。cc-switch 提供的是可视化加一键切换，本质还是改那份 JSON，但它把"新增一个供应商""切换当前供应商""回滚到上一个"这几步固化了，出错概率明显下降。
提醒一句：cc-switch 是第三方工具，它的配置目录和字段名在不同版本间会调整，具体路径务必以项目 README 为准，不要照抄网上旧文章的截图。
2. npm 安装环节：把不确定性压到最低
2.1 Node 版本与包管理器的选择依据
这类工具对 Node 版本有硬性要求，官方目前的门槛是 Node 18 及以上，但我不建议卡在最低线。原因有两个：一是原生 ESM、fetch、structuredClone这些 API 在新版本里行为更一致，工具内部的兼容分支更少；二是很多间接依赖会在 Node 18 上打出大量 warning，日志被淹没后排障很痛苦。我的实际操作是装 Node 20 LTS 或 22 LTS，用版本管理工具（nvm、fnm 之类）做多版本共存，这样万一哪天某个工具死活不兼容，切回去只要一条命令。
包管理器上，npm、pnpm、yarn 都能装全局包，但我只推荐 npm 装全局命令行工具。原因很实际：pnpm 的全局目录结构和 npm 不同，pnpm add -g装出来的可执行文件路径有时不在默认 PATH 里；yarn 的 classic 和 berry 两代行为差异大，团队里一旦有人用 berry，yarn global直接不可用。项目内的依赖随便用，装全局命令行工具这一步，统一用 npm 最省事。
2.2 三种安装方式的取舍
同一个包，至少有三种装法，适合的场景完全不同：
| 方式 | 命令 | 优点 | 代价 | 适合谁 |
|---|---|---|---|---|
| 全局安装 | npm i -g @scope/cli | 一次装好，任意目录可用 | 版本全局唯一，多项目冲突 | 日常主力开发机 |
| 临时执行 | npx @scope/cli@latest | 不污染全局，永远最新 | 每次可能拉包，启动慢，版本漂移 | 偶尔试一下 |
| 项目内依赖 | npm i -D @scope/cli | 版本随项目锁定，可进版本库 | 要在项目根目录跑，或用npx调 | 团队统一环境 |
我们团队最终选的是全局安装加固定版本号，比如npm i -g @scope/cli@1.2.3。理由是这类工具会读项目文件、跑 shell 命令，行为差异带来的风险比版本更新带来的收益大得多。升级走"先在一台机器上试，跑通一周再推全员"的节奏，不要在周五下午升级。
2.3 权限、缓存与 registry 的工程化处理
全局安装最常见的失败是权限问题。Linux 和 macOS 上直接npm i -g到系统目录会报 EACCES，网上的老办法是加sudo，我不建议——用 sudo 装的包属主是 root，后续升级、卸载都会再次卡权限，而且工具本身要读你的项目文件，用 root 身份跑没有任何好处。正确做法是把 npm 的全局目录改到用户目录下：
# 查看当前全局目录和 bin 目录 npm config get prefix npm bin -g 2>/dev/null || echo "$(npm config get prefix)/bin" # 改到用户目录（写入 ~/.npmrc，一次生效） npm config set prefix "$HOME/.npm-global" echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.zshrc source ~/.zshrcnpm bin -g在新版 npm 里已经移除，上面这行做了兜底，取不到就直接拼路径，不影响使用。
registry 这块，公司内网环境通常有私有源或统一镜像。配置方式是在项目或用户级.npmrc里改registry=，不要用命令行参数临时指定，否则换台机器就忘了。如果是私有源，还要注意 scoped 包的指向：
# ~/.npmrc registry=https://registry.npmmirror.com @mycompany:registry=https://npm.mycompany.internal/缓存方面，npm cache clean --force这个命令被滥用了。绝大多数"装不上"跟缓存没关系，盲清缓存只会让你多等几分钟。真正需要清缓存的场景是：包内容损坏（解压报错、文件校验失败）。判断方法是看错误码，EINTEGRITY才是缓存问题，ETIMEDOUT、ENOTFOUND是网络和域名问题，E404是包名或版本写错。
2.4 安装完成后的五项自检
装完别急着用，跑一遍下面这五条，能提前发现八成环境问题：
# 1. 版本是否可执行 cli-name --version # 2. 可执行文件到底在哪（确认不是旧版本残留） which -a cli-name # 3. Node 版本 node -v # 4. 全局包列表里是否有它，版本对不对 npm ls -g --depth=0 | grep cli-name # 5. 配置文件目录是否存在 ls -la ~/.claude/ 2>/dev/null || echo "配置目录尚未创建"第 2 条特别值得说。我遇到过一台机器上同时存在三个同名可执行文件：一个来自旧版全局安装、一个来自 Homebrew、一个来自项目内 node_modules 的软链。which只显示第一个，用which -a才能看到全部，然后按 PATH 顺序确认到底跑的是哪个。这种"幽灵旧版本"造成的诡异行为，排查起来能耗掉一整个下午。
3. cc-switch 的机制拆解与配置档设计
3.1 它本质上只做一件事：改写配置文件的 env 段
把 cc-switch 的神秘感去掉，它做的事非常朴素：维护一份自己的供应商列表，你点"切换"的时候，把它写到目标工具的主配置文件里。以这类终端编码工具为例，主配置通常是~/.claude/settings.json，其中env字段就是环境变量注入点：
{ "env": { "ANTHROPIC_BASE_URL": "https://your-endpoint.example.com/anthropic", "ANTHROPIC_AUTH_TOKEN": "sk-replace-me", "ANTHROPIC_MODEL": "your-model-name", "ANTHROPIC_SMALL_FAST_MODEL": "your-small-model-name" } }理解这一点之后，很多事情就通了：为什么切换之后要重启会话（进程启动时读了环境变量）、为什么两个工具同时开会让配置互相覆盖（都写同一个文件）、为什么 cc-switch 崩了你的配置还在（它只是文件的写入方，不是运行时依赖）。也正因为如此，你完全可以不用 cc-switch，用脚本或符号链接达到同样效果，后文会给方案。
3.2 一个 profile 里真正影响行为的字段
新建供应商时界面会给你一堆输入框，但真正影响行为的就那几个。我把它们按重要性排了一下：
| 字段 | 作用 | 写错的后果 | 建议 |
|---|---|---|---|
| 端点地址（base URL） | 请求发往哪里 | 404 或超时，工具报"服务不可用" | 严格按服务商文档，注意末尾要不要带版本路径 |
| 密钥 | 身份认证 | 401/403，一问就挂 | 用专用密钥，别复用其他系统的 |
| 主模型名 | 复杂任务的推理模型 | 模型不存在，400 报错 | 从服务商控制台复制，别手打 |
| 小模型名 | 后台轻量任务（摘要、补全） | 部分功能静默降级 | 不填时通常回落到主模型，成本会上升 |
| 超时 | 单请求等待上限 | 太短则长任务频繁中断 | 编码任务建议不低于 120 秒 |
端点是错误率最高的一个。不同服务商的路径规则差别很大，有的要求https://host/v1，有的要求https://host/anthropic，有的要求https://host/api/anthropic。判断方法很土但有效：用 curl 直接打一次最小请求，看返回是 404（路径错）还是 401（路径对了但密钥错）。401 反而是好消息，说明路走对了。
3.3 上下文窗口与 token 预算的估算方法
第三方大模型和原厂模型的上下文窗口往往不一样，有的是 200k，有的只有 32k 或 128k。窗口不够的直接表现是：请求能发出去，但返回内容莫名其妙地短，或者工具提示上下文超限。这个不能靠猜，要算。
粗估规则（够用，不必精确）：英文代码约 1 个 token 对应 3~4 个字符；中文约 1 个字对应 1.5~2 个 token；一个 500 行的组件文件，大约 15000 字符，混合中英文注释，粗估 6000~9000 token。一次典型的"改一个功能"会话里，工具会读若干文件、跑命令、看输出，累计的输入 token 远大于单次粘贴：
- 首轮：系统提示 + 项目说明 + 相关文件，约 1.5 万 ~ 3 万 token
- 中间轮：每次工具调用结果回灌，常见 2 千 ~ 8 千 token
- 一个中等任务跑 10~20 轮：累计输入 20 万 ~ 60 万 token
算成本就很简单：
单次任务成本 = 累计输入token / 1,000,000 × 输入单价 + 累计输出token / 1,000,000 × 输出单价举个示例（价格请按自己服务商的价目表替换）：输入 3 元/百万 token，输出 15 元/百万 token，一次任务累计输入 40 万、输出 3 万，则成本 = 0.4×3 + 0.03×15 = 1.2 + 0.45 = 1.65 元。这个数字的意义在于横向对比：如果另一个通道输入 1 元/百万，同样的任务只要 0.4 + 0.45 ≈ 0.85 元，但它读不了 40 万 token 的上下文，就得拆任务，拆了任务又要多跑几轮，实际省下的可能没那么多。这就是为什么我坚持记录真实任务的消耗，而不是只看单价。
3.4 密钥不能明文躺在配置文件里
配置文件是 JSON，密钥写进去就是明文。这个文件一旦被同步到网盘、提交进仓库、或者被某个脚本打印出来，密钥就泄露了。我在团队里定了三条硬规矩：
第一，编码工具的密钥单独申请，不复用其他系统的，权限范围尽量小。第二，~/.claude/这个目录加进全局.gitignore，并且不允许出现在任何项目目录内。第三，真要上多机同步，配置文件里只写占位符，真实密钥走环境变量注入：
# ~/.zshrc 里注入，不写进 settings.json export ANTHROPIC_AUTH_TOKEN="$(security find-generic-password -s claude-token -w 2>/dev/null)"macOS 上用系统钥匙串，Linux 上用secret-tool，Windows 上用凭据管理器。多一层间接确实麻烦，但比密钥进了公开仓库再到处撤销要轻松得多。如果 cc-switch 的界面要求填密钥，那就接受它落盘这个事实，但要保证那台机器是个人设备、磁盘加密开启、目录不进版本库。
4. 多模型切换的完整实操流程
4.1 第一步：确认你的第三方端点兼容哪种协议
这一步决定后面所有配置能不能成。终端编码工具通常按某一家的消息协议实现，第三方模型服务商为了兼容，会提供"协议兼容层"。你要做的是去服务商文档里确认三件事：有没有提供这个协议的兼容端点、端点的完整路径是什么、支持哪些模型名。
如果服务商只提供另一种协议的兼容（比如只提供 OpenAI 风格的/v1/chat/completions），那通常需要中间加一层转换服务，自己部署一个轻量网关，把两端协议对上。这不是本文重点，但要提前知道有这条路，别在配置档里死磕。我见过有人在端点字段里反复尝试各种路径组合，试了一下午，根本原因是服务商压根没提供这个协议的兼容端点。
4.2 第二步：写第一个可用 profile 并跑通最小验证
配置文件按第 3.1 节的样子写好之后，先用 curl 验证，不要直接进工具里试。原因很简单：工具的报错信息经过包装，curl 的响应是原始的，一眼就能看出问题在路径、密钥还是模型名。
curl -sS -o /tmp/resp.json -w "HTTP %{http_code}\n" \ -X POST "$ANTHROPIC_BASE_URL/messages" \ -H "x-api-key: $ANTHROPIC_AUTH_TOKEN" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "'"$ANTHROPIC_MODEL"'", "max_tokens": 64, "messages": [{"role":"user","content":"reply with ok"}] }' head -c 500 /tmp/resp.json判断逻辑：200 且返回里有正常内容，说明通路完整；401 说明密钥或请求头字段不对；404 说明路径错；400 且错误里提到 model，说明模型名不对。这四种情况覆盖了 95% 的首次配置失败。
注意：有些兼容层对请求头要求比较宽松，
x-api-key和Authorization: Bearer都认；有些只认其中一种。看到 401 别急着换密钥，先换请求头试试。
4.3 第三步：一键切换与项目级绑定
跑通之后，把这份配置在 cc-switch 里存成一个供应商条目，命名上带足够的信息，比如"通道A-大窗口-贵"、"通道B-便宜-32k"。名字带成本和窗口大小，切换时不用查文档。
但全局切换有个明显问题：你在 A 项目里需要大窗口，切到 B 项目又需要便宜通道，来回切很烦。更彻底的做法是项目级绑定。较新版本的工具支持用命令行参数指定另一份配置文件，思路是每个项目根目录放一份.claude/settings.local.json，里面写这个项目专用的端点：
# 项目内启动，使用项目专属配置 cd /path/to/project cli-name --settings ./.claude/settings.local.json如果版本不支持这个参数，退一步用环境变量在启动脚本里覆盖，优先级高于配置文件：
# scripts/dev-ai.sh #!/usr/bin/env bash set -euo pipefail export ANTHROPIC_BASE_URL="https://cheap-endpoint.example.com/anthropic" export ANTHROPIC_MODEL="cheap-model-name" exec cli-name "$@"这个脚本进版本库，团队成员 clone 下来就能用同一个通道，密钥从各自的环境变量取。这个方案我们用了很久，比全局切换更省心的地方在于：项目自带的通道配置是"声明式"的，不会因为切了全局就忘记切回来。
4.4 第四步：降级链路、超时与重试参数
单通道总有挂的时候。这时候不需要人工介入，前端脚本做一层降级就行：主通道超时或 5xx，自动切到备用通道再跑。实现方式很土但可靠——包一层 shell：
#!/usr/bin/env bash set -uo pipefail run_with() { local base="$1" model="$2" ANTHROPIC_BASE_URL="$base" ANTHROPIC_MODEL="$model" \ timeout 900 cli-name "$@" } run_with "$PRIMARY_BASE" "$PRIMARY_MODEL" "$@" && exit 0 echo "[warn] 主通道失败，切备用通道重试" >&2 run_with "$FALLBACK_BASE" "$FALLBACK_MODEL" "$@" && exit 0 echo "[error] 两条通道都失败，请检查配置" >&2 exit 1几个参数上的经验值：单请求超时我设 120~180 秒，因为大文件读入加推理确实慢，设太短会打断正常任务；整体任务超时 900 秒，防止卡死；重试最多一次，不做指数退避——编码是交互式场景，用户就在屏幕前等着，三次重试的时间里人已经手动干预了。
4.5 一份可复现的成本与质量对照记录
光说不练没意义。我们在同一个真实任务上（给一个约 400 行的模块补类型定义并修复两处空值判断）跑了几条通道，记录如下，价格按示例值，重点看相对关系：
| 通道 | 上下文窗口 | 轮次 | 累计输入 token | 输出 token | 估算成本 | 结果质量 |
|---|---|---|---|---|---|---|
| 通道A | 200k | 9 | 约 38 万 | 约 2.4 万 | 约 1.5 元 | 一次通过，改动最小 |
| 通道B | 128k | 11 | 约 42 万 | 约 3.1 万 | 约 0.9 元 | 需要一次补充指令 |
| 通道C | 32k | 17 | 约 55 万 | 约 3.8 万 | 约 0.7 元 | 拆了三次任务，漏改一处 |
结论不是"贵的好"，而是：小窗口通道在需要跨文件推理的任务上会额外付出轮次成本，省下的单价被轮次吃掉了。我们的实际策略是按任务类型分派——大范围重构走大窗口通道，单文件小修改、补注释、写测试走便宜通道。这个分派规则写进了团队 wiki，比任何"最优模型推荐"都实用，因为它是在自己代码库上测出来的。
5. 常见问题排查实录
5.1 排查速查表
下面这张表是我们内部 wiki 上被查得最多的一页，按报错关键词索引：
| 现象 / 关键词 | 高频原因 | 处理动作 |
|---|---|---|
401/invalid api key | 密钥填错、带了空格、密钥类型不匹配 | 复制密钥后echo -n检查长度，去掉首尾空白 |
403/forbidden | 密钥权限不含该模型，或账户额度耗尽 | 去控制台看余额和模型授权 |
404/not found | 端点路径多写或少写了层级 | 对照文档逐字符比对，用 curl 复现 |
400+ 提到 model | 模型名拼错或该账户没开通 | 从控制台复制模型名 |
| 请求无响应直到超时 | 端点不可达、端口错、DNS 问题 | curl -v看卡在建连还是等响应 |
| 返回内容被腰斩 | max_tokens太小或上下文超窗 | 调大max_tokens，拆小输入 |
| 切换后行为没变 | 旧会话进程还在跑，读的是旧环境变量 | 完全退出会话，重开 |
| 装了但命令找不到 | 全局 bin 目录不在 PATH | 见 2.3 节改 prefix 和 PATH |
| 两个工具配置互相覆盖 | 都写同一份 settings.json | 只让一个工具做写入方 |
5.2 几个反直觉的坑
第一个坑：密钥末尾的换行。从网页上复制密钥，很容易带上一个不可见的换行符，粘进配置文件后 JSON 还是合法的（\n被转义），但请求头里就多了一个字符，服务端直接判无效。表现是"密钥明明是对的却一直 401"。排查方法：printf '%s' "$KEY" | xxd | tail -2，看看最后是不是0a。
第二个坑：改了配置但行为没变。这类工具在启动时读一次环境变量，进程活着就一直用旧值。你在另一个终端切了供应商，当前会话完全感知不到。所以切换之后必须完全退出重开，Ctrl+C之后还要确认进程真的没了，有些情况下后台还挂着一个。
第三个坑：小模型名空着。有些工具会把摘要、文件路径补全这类轻量任务发到小模型上，小模型名不填时回落到主模型，成本悄悄涨了一截，而你完全看不出来。我在一份账单里发现过这个问题：明明只用了主模型，费用却比预估高 40%，最后定位到是后台任务全都打到了主模型上。
第四个坑：多台机器配置漂移。笔记本和台式机各改各的，一周后两边行为不一样，排查时以为工具出了 bug。解决办法是把配置模板放进一个私有仓库，密钥用占位符，每次改动都提交，切换时从仓库拉。这件事听起来笨，但它把"配置"变成了有历史记录的资产。
5.3 团队协作：配置进版本库，密钥进钥匙串
团队里推这套东西，最容易失控的是配置分发。我的做法是三层：
第一层是模板层，仓库里放config/settings.template.json，只写端点和模型名，密钥写"${ANTHROPIC_AUTH_TOKEN}"。第二层是个人层，每个人的~/.claude/settings.json从模板生成，密钥由环境变量注入。第三层是项目层，项目根目录的.claude/settings.local.json覆盖全局设置，这个文件进.gitignore。
# 从模板生成个人配置 mkdir -p ~/.claude envsubst < config/settings.template.json > ~/.claude/settings.jsonenvsubst会把${ANTHROPIC_AUTH_TOKEN}替换成环境变量里的真实值。这个命令在大多数 Linux 和 macOS 上都有（macOS 需要装 gettext，也可以改用sed或一小段 node 脚本）。替换完记得检查文件权限：chmod 600 ~/.claude/settings.json。同组机器上曾经因为权限是 644，同机器另一个账户直接读到了密钥。
6. 落地节奏建议
6.1 单人：一周内跑通的顺序
别一上来就配三条通道，会乱。我给自己的顺序是这样的：第一天只装工具本体，跑通官方默认配置，确认命令能执行、能读文件；第二天接入一个第三方通道，用 curl 验证再加进配置，跑一个小任务；第三天开始记录 token 消耗，连续记三天真实任务的数据；第四天根据数据决定要不要加第二条通道；第五天把切换脚本写好，做成一条命令；周末前把配置模板整理进私有仓库。
这个节奏的核心是"先跑通一条，再谈切换"。我见过太多人第一天就把五条通道全配上，结果出了问题根本不知道是哪条通道的锅，最后全部推倒重来。单通道跑通之后，第二条通道的接入时间通常不到十分钟，因为所有坑都已经踩过了。
另外，记录消耗这件事坚持下来收益最大。三天数据就能看出你的真实使用模式：是短平快的单文件修改多，还是跨文件的大任务多。前者用小窗口便宜通道完全够，后者硬上小窗口只会浪费轮次。数据比任何选型文章都靠谱。
6.2 小团队：三件事先定下来
团队推的时候，先把三件事定死，剩下的都好办。第一件，统一工具版本，写进 README，升级走"一人试跑一周再推"的流程。第二件，统一配置模板，端点、模型名、超时这些字段由一个人维护，其他人只提供密钥。第三件，统一任务分派规则，明确什么任务走哪条通道，写成一句话能说清的规则，比如"改三个文件以内用便宜通道，跨模块重构用大窗口通道"。
这三件事定完，剩下的分歧基本都能靠数据解决。我们组后来还加了个小约定：每周五花十分钟对一下这周的费用和返工情况，返工指的是 AI 改完还要人再改一遍的情况。这个数字比成本更能说明问题——某个通道便宜但返工率高，实际总成本反而更贵。这个体会我在多个项目上反复验证过：省下来的模型费用，往往被多出来的人工返工吃回去，而且吃得更多。所以选通道的时候，先看返工率，再看单价，最后才看上下文窗口这类纸面参数。
