教程让你用某个 AI 工具（命令行调用的那种），你在终端敲 which 工具名（Mac/Linux）或 where 工具名（Windows）或 PowerShell 的 Get-Command 工具名，结果返回"找不到"。你心想"没装啊"，于是去 npm install -g 全局装一个。可装完发现还是用不对，甚至装错版本、跑偏了整个方案。
关键认知：which/where 找不到，只代表"这个名字没注册成全局命令"，不代表"工具没装、不能用"。
很多现代工具根本不注册全局命令，而是靠别的方式调用，最典型的两种：
npx --package 某包 工具名 调用，npx 会临时下载/缓存到本地来跑，通常不往全局 PATH 注册命令。所以 which 工具名 找不到不能直接说明它不能用。python -m 某模块 这种方式调，也没有独立的全局命令名。你拿"全局命令名"去探测一个"本来就没有全局命令名"的工具，当然找不到——但这是探测方法的错，不是工具没装。
别一看到"找不到"就动手装。先用 30 秒确认工具到底是哪一种调用方式：
npx ...？是 python -m ...？还是某个带后缀的包装脚本？npx 或 python -m 调它，就不要先用全局命令名判断存在性——这类调用方式通常不依赖全局 PATH，which/where 找不到不能证明没装。which 判存在性了，直接去看框架的运行记录。一句话：用 which 去探测 npx/python 模块类工具，方法本身就是错的。
npx 包名？python -m 模块？某个包装脚本？）。which/where 报"找不到"就以为没装。 错。npx 调用的工具通常不需要全局命令名，which 失败不能直接说明工具不能用。npm install -g。 结果可能装错版本、污染全局环境、甚至和方案要求的版本冲突，越装越乱。python -m 调用的工具。 这种工具可能没有独立命令名，用全局命令名探测很容易误判。"我要用<工具名>，命令行which/where <工具名>显示找不到。但教程里它的调用命令是<粘贴原始命令，比如 npx xxx 或 python -m xxx>。请帮我判断：这个工具是不是本来就不需要全局命令名？我该怎么用文档里的原始方式直接验证它能不能用，而不是去全局安装？"
判别要点：which/where/Get-Command 找不到某工具 ≠ 工具没装。
npx 调用的 → 先按原始 npx 命令验证，不要把 which 失败等同于不可用。python -m 模块 调用的 → 先按模块方式验证，不要强行找全局命令名。which 的返回。npx ... / python -m ...）直接跑，工具正常返回结果。npm install -g 的包数没增加），问题却解决了。which 找不到但工具其实能用"。which/where 某工具 not found，先别下"没装"结论。npx --package ... 还是 python -m ... 还是包装脚本？这是判定关键。which 失败不能证明没装；先按原始命令验证"。很多小白第一次用 Codex，会把两件事混在一起：
最常见的坑是：明明想让 AI 用中文回复，却一直去找“界面语言设置”；或者在项目里临时说了一句“用中文”，下一次开新会话又变回英文。
这两件事要分开处理：界面语言归产品设置，回复语言归指令文件。
关键认知：AGENTS.md 控制的是 Codex 做事和回复的指导原则，不等于 UI 语言包。
OpenAI Codex 官方 manual 里明确写了几件事：
AGENTS.md。~/.codex/AGENTS.md。AGENTS.md。AGENTS.md。所以，如果你要解决“AI 回复英文”，最稳的是写一条持久中文回复规则，而不是反复在每次对话里提醒。
先看你到底要改哪一种“英文”：
AGENTS.md，这是本卡重点。AGENTS.md。AGENTS.md。AGENTS.md 保证；按当前产品设置处理。一句话：想改“AI 怎么说话”，写 AGENTS.md；想改“界面怎么显示”，找产品设置。
### A. 让所有 Codex 会话默认中文回复
~/.codex/%USERPROFILE%\.codex\AGENTS.md。## Communication
- Always respond in Chinese.
- 默认用中文解释、总结和写代码注释。
- 命令、API 名称、错误原文和文件路径保持原样，不要硬翻译。### B. 只让某个项目默认中文
如果你只想让某个项目用中文回复，就在项目根目录放 AGENTS.md，写同样的 Communication 规则。
项目级 AGENTS.md 适合团队协作，因为它跟着仓库走；全局 ~/.codex/AGENTS.md 适合你个人所有项目默认中文。
### C. Codex App 里怎么改
如果你用 Codex App，可以在 Settings 里写 custom instructions。官方 manual 说明：编辑 custom instructions 会更新你的个人 AGENTS.md。
适合写：
默认用中文回复。解释、总结、代码注释用中文；命令、API 名称、错误原文和文件路径保留原文。### D. IDE 扩展界面语言不要和回复语言混在一起
Codex IDE extension 有一个 chatgpt.localeOverride 设置，官方说明它是“Codex UI 的首选语言”；留空则自动检测。
注意：这类 UI 设置影响的是界面显示，不等于强制 AI 回复中文。AI 回复语言仍然建议用 AGENTS.md 固定。
AGENTS.md。"我想让 Codex 默认用中文回复。请先判断我应该改全局~/.codex/AGENTS.md，还是只改当前项目的AGENTS.md。请帮我写一个最小规则：解释、总结和代码注释默认中文，但命令、API 名称、错误原文、文件路径保留原文。不要修改密钥或系统设置。"
判别要点：先分清 UI 语言和回复语言。
AGENTS.md。AGENTS.md。AGENTS.md。AGENTS.md 改界面。AGENTS.md；项目规则放在项目根目录 AGENTS.md。AGENTS.md。AGENTS.md 的关系。chatgpt.localeOverride。本条为公开官方文档的脱壳重写；UI 设置名称可能随版本变化，实际操作以当前 Codex App / IDE extension 界面为准。
AGENTS.md 固定回复语言；AGENTS.md 不负责 UI 语言；跟着教程装 AI 工具，命令行敲 npm install 或 npm install -g 某个包，进度条卡死，最后报：
npm ERR! network context deadline exceeded或者干脆挂在那儿十几分钟不动。明明开着科学上网，浏览器能打开网页，偏偏 npm 装不上。这是国内玩 AI 工具的头号拦路虎——Cursor、Claude Code、飞书 lark-cli、小程序自动化工具，装的时候几乎都会撞上。
关键认知：npm 默认根本不走你的系统代理。
proxy / https-proxy 配置默认是空的（null）。HTTP_PROXY 环境变量，npm 也不读。所以"我明明开了代理"≠"npm 走了代理"。这是两回事。
国内 npm install 卡住 / 超时，很常见的原因是 npm 没走代理，而不是包本身有问题。先做两个确认：
context deadline exceeded / ETIMEDOUT / ENOTFOUND / 进度条十几分钟不动 → 锁定是代理问题，别去怀疑包损坏或版本不对。一句话：只要在国内 npm 卡住，先按"代理没走"排查，通常最快定位。
<你的代理地址:端口>；不要照抄别人的端口）。npm install -g <包名>@latest --proxy http://<你的代理地址:端口> --https-proxy http://<你的代理地址:端口>npm config set registry https://registry.npmmirror.comnpm install 不再需要代理参数（镜像源在国内，直连就快）。--proxy 或在 npm config 里设。HTTP_PROXY 环境变量以为 npm 会读。 新版 npm 默认不读环境变量里的代理配置，得用参数或 npm config set proxy。context deadline exceeded，别干等，直接按代理处理。--proxy。 反而会拖慢国内镜像，镜像源直连最快，换源后就别再带代理参数了。"我在国内用npm install -g <包名>，报context deadline exceeded/ 一直卡住装不上。我开了代理（地址和端口是<你的代理地址:端口>），浏览器能正常上网。请帮我生成一条带--proxy参数的安装命令，并说明怎么一劳永逸换成国内镜像源（registry.npmmirror.com）。"
判别要点：只要你在国内用 npm install 出现 context deadline exceeded 或长时间卡住 → 优先怀疑 npm 没走代理。
--proxy 参数后秒装成功 → 确认就是代理问题。npm config set registry 换国内镜像，根治。--proxy 参数后，原本卡十几分钟的安装在几秒到十几秒内完成。context deadline exceeded / ETIMEDOUT 报错。npm config get registry 显示国内镜像源，且普通 npm install 不带代理也快。context deadline exceeded / ETIMEDOUT / npm 长时间卡住等关键词 → 命中即按代理问题处理。--proxy http://<你的代理地址:端口> --https-proxy http://<你的代理地址:端口> 的安装命令。npm config set registry https://registry.npmmirror.com 换国内镜像。用音频驱动口型的数字人方案（Musetalk / Wav2Lip / SadTalker 这类），生成出来的视频要么音频嘈杂、要么人物脸部变形扭曲、要么嘴巴动的跟说的话对不上。源视频明明是好的，配音也是好的，合在一起就崩了。
关键认知：这类数字人是"音频驱动"的——它按音频的时长和节奏去驱动嘴型。 一旦音频时长和视频时长对不上，整个口型同步就会错乱。
最常见的情况：原始音频（比如 39 秒）在某个环节被裁剪 / 压缩成了很短的一段（比如 6 秒），而源视频是 64 秒。短音频去驱动长视频，引擎为了凑时长就会拉伸 / 错位，结果就是口型对不上、脸部变形、音频变质。
换句话说：不是模型不行，是你喂给它的音频被悄悄"瘦身"了。
所有"音频驱动口型"的数字人，只要出现口型错位 / 脸部变形 / 音频嘈杂，第一怀疑是音频时长 vs 视频时长不匹配，而不是模型参数或源视频质量。一条命令定性——分别取两边时长：
ffprobe -i <音频>
ffprobe -i <视频>一句话：口型崩了，先 ffprobe 对一下两边时长，别先调模型。
核心一条：保证驱动音频的时长完整，覆盖视频需要口型的整段，不要被裁剪。
ffprobe 看一下两边各是多少秒。"我用音频驱动口型的数字人（Musetalk / Wav2Lip / SadTalker 这类）生成视频，出现口型对不上、脸部变形、音频嘈杂。请帮我用 ffprobe 分别查看驱动音频和源视频的时长，判断是不是音频被裁短了；如果是，告诉我怎么回溯上游（TTS 是否截断、转码是否压缩）取完整音频重新合成。"
判别要点：所有"音频驱动口型"的数字人，只要出现口型错位 / 脸部变形 / 音频嘈杂，第一怀疑音频时长 vs 视频时长不匹配，而不是模型参数或源视频质量。
ffprobe 确认：驱动音频时长 ≥ 视频中需要口型的段落时长。本条截至发布日有效（音频驱动口型是这类方案的通用原理，长期稳定）。
ffprobe -i <音频> 和 ffprobe -i <视频> 分别取两边时长。把一篇长文章（比如几千上万字的讲稿）一次性丢给 AI 配音，结果要么直接报错生成失败，要么"生成成功了"但听下来发现后半段内容没了——音频莫名其妙变短，结尾内容丢失。更坑的是有些接口不报错，直接静默裁剪，你以为成功了，其实交付的音频已经缺斤短两。
关键认知：几乎所有 TTS 接口对"单次请求的文本长度"都有硬上限，超过就失败或被截断。
TTS 处理长文本，凡是"失败"或"音频比预期短 / 内容缺失"，第一怀疑对象是超长被截断，而不是网络或模型问题。两个动作就能定性：
len(text)，跟你所用接口的单次上限比一比。超了 → 基本确定会被接口拒绝、截断或要求分段。一句话：长文本一次性塞必失败或残缺，先量长度，别赌一次成功。
生成前先量一下文本有多长，超限就分段，不要赌一次性成功。
len(text)。伪代码思路：
MAX = 10000 # 你所用接口的字符上限
if len(text) > MAX:
chunks = split_at_sentence(text, MAX) # 按句号切，每段不超 MAX
audios = [tts(c) for c in chunks]
final = concat(audios)
else:
final = tts(text)"我有一篇约<字数>字的讲稿要 AI 配音，用的 TTS 接口单次上限约<上限字数>字。请帮我写一段 Python：先len(text)判断是否超限，超限就按句号切成每段不超过上限的小段、逐段生成、最后拼接音频；并在每段生成后核对音频时长与文本长度是否匹配，以防静默截断。"
判别要点：TTS 处理长文本时，凡是"失败"或"音频比预期短 / 内容缺失"，第一怀疑对象就是超长被截断，而不是网络或模型问题。
本条截至发布日有效（各 TTS 接口都有长度上限，具体数值以官方文档为准）。
len(text) 算字符数。用 AI 配音（TTS）把文案转成语音，听下来总觉得"一顿一顿的"——每句话之间停特别久，整个音频拖沓、不连贯。明明文案读着挺顺，生成出来却像机器人一句一句往外蹦。更迷惑的是：同样一段话，只是换了个排版（比如把"一句一行"改成"一段连写"）重新生成，节奏居然差了一大截，停顿从十几秒缩到几秒。
关键认知：TTS 引擎是按你文本里的"换行符"和"标点"来决定停顿时长的，不是按语义。 你以为只是排版好不好看，对引擎来说每个符号都是一条"停几秒"的指令：
\n：被当成"一句话结束"，产生长停顿（最狠的一个）。坑就在这：如果你习惯每写一句就敲回车（一句一行），6 个换行 = 累计约 12 秒的停顿堆在音频里。文案"看起来"很整齐，听起来却稀碎。
AI 配音出现"停顿过长 / 不连贯"，第一件事不是换模型、不是调参数，而是回去看文案的换行和标点。两个动作就能定性：
\n 的数量。换行越密，累计停顿越长。一句话：只要停顿怪，先查换行，别先怪模型。
记住一个排版原则：段落之间才空行，段落内部坚决不换行。
\n\n）隔开。如果想程序化批量优化，一句话搞定（把多余换行压成标点）：
optimized = raw_text.replace('\n\n', '。').replace('\n', '，')改完后用新文案重新生成一遍 TTS，对比停顿时长。
"我有一段要 AI 配音的文案，生成出来停顿太长、一顿一顿的。请帮我按'段落之间空行、段落内部不换行、冒号后不换行、并列词用顿号'的规则重排这段文案，并给出一个 Python 一行命令把多余换行压成标点（\n\n→。，\n→，）。文案是：<贴你的文案>"
判别要点：只要 AI 配音出现"停顿过长 / 不连贯"，第一件事不是换模型、不是调参数，而是回去看文案的换行和标点。
本条截至发布日有效（标点 / 换行决定停顿是各 TTS 引擎的通用机制，长期稳定）。
\n 数量，向用户说明根因：换行被引擎当成"长停顿指令"，越密累计停顿越长。raw_text.replace('\n\n', '。').replace('\n', '，')，并提示边界：段落之间仍应保留空行区分层次。写了个 .bat 批处理脚本（比如一键启动某个程序），双击它，黑色命令行窗口"闪"一下就消失了，脚本根本没执行。你反复检查命令没写错，可就是跑不起来。用编辑器打开看内容明明好好的。
关键认知：Windows 的 cmd 命令行对 .bat 文件有两个硬要求，现代编辑器默认都不满足。
\r\n），不能是 LF（\n）。.bat 会解析错乱，直接闪退。两个坑任意一个都会让 .bat 双击秒退。
双击 .bat 黑框一闪就没，高频原因是换行或编码问题，也可能是命令本身报错。先做一步排除：
.bat 里的命令逐行复制到 cmd 窗口手动敲一遍：如果手动敲能正常跑 → 基本可以判断是文件保存格式（CRLF/GBK）的问题，跟命令本身无关。LF？编码是不是 UTF-8？只要这两个里有一个不是 CRLF / GBK，就是元凶。一句话：手动敲能跑、双击闪退 → 别改命令，去修换行和编码。
.bat 里的命令行整理成一个列表（Python 的 lines），方便一次性生成。lines = [
"@echo off",
"echo 正在启动...",
"node 你的程序.js",
"pause",
]
content = ('\r\n'.join(lines) + '\r\n').encode('gbk')
open('启动.bat', 'wb').write(content)'\r\n'.join(...) 让每行用 CRLF 换行；.encode('gbk') 让中文按 GBK 编码，wb 二进制写入（别用文本模式，否则又会被改回）。.bat，黑框应正常停留、命令执行、中文不乱码。.bat 本身就会错乱闪退，跟命令对错无关；先手动敲验证命令。"我写了个 Windows.bat脚本，双击黑框一闪就退、没执行。命令内容是这几行：<粘贴每行命令>。请用 Python 帮我生成一个强制 GBK 编码 + CRLF 换行的版本（wb二进制写入覆盖原文件），保证中文不乱码、能正常双击运行。"
判别要点：Windows 下双击 .bat 黑框一闪就没，常见原因是换行（LF vs CRLF）或编码（UTF-8 vs GBK）问题，但仍要先排除命令本身报错。
.bat 双击闪退 → 先手动敲命令验证无误，再去检查换行是不是 CRLF、中文是不是 GBK。.bat 启动脚本。.bat 不再闪退，黑框正常停留并执行命令。pause 让窗口停住，能看清输出。echo 时内容不乱码。file 命令可辅助确认）。.bat 双击闪退，先让其把命令逐行在 cmd 手动敲一遍：能跑 → 判定为换行/编码问题，不是命令错。.bat 的命令行内容（整理成 lines 列表）。('\r\n'.join(lines) + '\r\n').encode('gbk') + wb 重新生成 .bat，覆盖原文件。你改了某个服务的配置，或者装了东西要求"重启生效"，于是关机、再开机。结果发现：服务还是老样子、配置没读进去、问题依旧。你以为重启没用，甚至怀疑是配置写错了，反复折腾。查一下系统的"上次启动时间"，居然还是好几天前——根本没更新。
关键认知：Windows 8 以后的"关机再开机"，其实不是真正的重启，而是"混合休眠"。
简单说：关机再开 ≈ 睡一觉醒来接着干；重启 ≈ 彻底重新开始。 它俩对系统来说不是一回事。
"重启后该生效却没生效"，先怀疑根本没真重启，而不是配置或软件问题。一条命令就能定性——查上次启动时间有没有更新到"刚才"：
(Get-CimInstance Win32_OperatingSystem).LastBootUpTime一句话：先看 LastBootUpTime 有没有更新，没更新就是快速启动的锅。
LastBootUpTime（上面命令），确认系统到底有没有真启动过。shutdown /r /f /t 0（/r = 重启，/s 才是快速启动式关机，别搞混。）
Restart-Service <服务名>（需要管理员权限）。LastBootUpTime，应已更新为当前时间，服务/配置随即生效。"我在 Windows 上改了<服务/配置名>的配置，按要求重启后没生效。请帮我用 PowerShell 查LastBootUpTime确认到底有没有真的重启，并告诉我怎么真正重启（shutdown /r）或只刷新这一个服务（Restart-Service），以及怎么永久关掉快速启动。"
判别要点：凡是"重启后应该生效却没生效"，先怀疑根本没真重启（快速启动捣鬼），而不是配置或软件问题。
(Get-CimInstance Win32_OperatingSystem).LastBootUpTime 是否更新到当前时间。没更新 = 快速启动，你只是休眠唤醒了。LastBootUpTime 更新为本次重启的时间（不再是几天前）。(Get-CimInstance Win32_OperatingSystem).LastBootUpTime。shutdown /r /f /t 0，或管理员 Restart-Service <服务名>（仅刷单个服务）；可选建议永久关掉快速启动。电脑用着用着突然画面冻结、鼠标键盘全无反应，只能长按电源键强制断电重启。而且会反复发作。第一反应往往是："是不是 CPU 坏了？内存条故障？电源不行？过热？"于是跑去跑内存诊断、换驱动、刷 BIOS，折腾一圈没用。
关键认知：这类"硬死机"（无蓝屏、只能断电）里，内存耗尽是很常见、也最值得先排查的原因之一。
典型元凶（尤其在装了一堆 AI 工具的电脑上）：
第一步建议先做"定性"：先区分硬件证据和内存耗尽证据，别盲目送修。 硬件故障通常会留下一些线索，先排三项：
C:\Windows\Minidump\ 有没有 minidump 文件（有 = 真蓝屏）。三项全没有 → 硬件故障概率下降，转去查内存耗尽。一句话：无蓝屏的硬死机，先查内存，别急着判硬件、别急着送修。
C:\Windows\Minidump\ 是否空）、显卡 TDR（Event 4101）、WHEA 硬件错误。Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Resource-Exhaustion-Detector'} -MaxEvents 4 | Format-List TimeCreated,Message事件 ID 2004 = 内存耗尽诊断，消息里会直接写出"某某进程占了多少字节"，一眼定位元凶。
"我的 Windows 电脑经常硬死机（画面冻结、鼠标键盘无反应，只能断电重启），没有蓝屏。装了不少 AI 工具和 Docker/WSL2。请帮我用 PowerShell 先排除硬件故障（查 C:\Windows\Minidump\ 蓝屏、显卡 TDR、WHEA 错误），再查 Event 2004 内存耗尽诊断，定位是哪个进程吃满了内存，并给出限制 WSL2 内存和清理后台孤儿进程的具体办法。"
判别要点：电脑硬死机（无蓝屏、强制断电才恢复），先查内存耗尽（Event 2004），别急着判硬件。
C:\Windows\Minidump\ 是否空）、显卡 TDR（Event 4101）、WHEA 错误。你用代码（Python 的 openai SDK / httpx）调用国内的大模型接口（智谱 GLM、通义、百度等，服务器都在国内，本来该很快），结果一次调用要等好几分钟，甚至等到连接超时被中断。但你用命令行 curl 直接调同一个接口，明明是秒回的。代码里也没设奇怪的超时，就是莫名其妙地慢。
关键认知：openai SDK 底层用 httpx，httpx 默认会读系统的代理环境变量（HTTP_PROXY / HTTPS_PROXY）。
trust_env=True，会乖乖地把请求绕到系统代理去。换句话说：不是大模型慢，是你的请求被系统代理"绑架"去绕了一圈。
用 openai / httpx SDK 调国内大模型，凡是"代码慢、curl 快"，第一怀疑是被系统代理绕路。两个动作定性：
HTTP_PROXY / HTTPS_PROXY 环境变量。一句话：curl 快、SDK 慢，先查 httpx 是不是偷偷走了系统代理。
一行代码解决：让 httpx 忽略系统代理、直连国内大模型接口。
import os
import httpx
from openai import OpenAI
# 关键：trust_env=False → 不读系统代理，直连
http_client = httpx.Client(trust_env=False, timeout=60.0)
client = OpenAI(
api_key=os.environ["MODEL_API_KEY"], # 密钥只放本机环境变量，示例不写明文
base_url="https://open.bigmodel.com/api/paas/v4", # 以智谱为例
http_client=http_client,
)两个要点：
httpx.Client(trust_env=False) → 忽略系统代理环境变量，直连。timeout=60.0（SDK 默认 600 秒，太长了），避免卡死干等。trust_env=True，会把国内请求也绕去代理。trust_env=False 直连。"我用 Python 的 openai SDK（底层 httpx）调用国内大模型接口，一次调用要等好几分钟甚至超时，但命令行 curl 同一个接口是秒回。程序跑在<带系统代理的 Windows / 服务 / 容器>。请帮我写一段代码：用httpx.Client(trust_env=False, timeout=60.0)忽略系统代理直连，传给OpenAI(http_client=...)，并解释为什么 curl 快而 SDK 慢。"
判别要点：用 openai / httpx SDK 调国内大模型，凡是"代码慢、curl 快"，第一怀疑被系统代理绕路。
httpx.Client(trust_env=False) 直连；如果根因确实是系统代理绕路，通常会明显变快。trust_env=False 后，调用时长从分钟级降到秒 / 十几秒级（实测约从 357 秒降到 25 秒），无超时 drop。timeout（如 60 秒），不再卡死干等。本条截至发布日有效（httpx 默认 trust_env=True 是其长期行为）。
HTTP_PROXY / HTTPS_PROXY（Windows 服务继承系统环境、容器、开发机代理）。httpx.Client(trust_env=False, timeout=60.0) 传给 OpenAI(http_client=...)。你在某个 AI 编程工具里配置了自己的大模型（比如想用智谱 GLM 的套餐，便宜），结果出现怪事：要么配置完根本看不到自己加的模型；要么看到了但用的是工具内置的那个（走的是工具官方额度，不是你买的套餐，钱白花）；要么一调用上游就报"模型不存在"。明明填得没错，就是拧不到一起去。
关键认知：这类问题往往是三个条件叠加造成的死结，工具配置层怎么调都解不开：
<套餐方精确模型名>），优先级还高于你自定义的——你自定义的同名 id 会被云端压制。<套餐方精确模型名>，你填个 <随手改的显示名> 它就说"模型不存在"）。三者一对：id 不能跟内置重名（否则被压制），但又必须发套餐方认的精确名（否则报不存在）——矛盾，配置层无解。
在 AI 工具里配自定义大模型，凡是"看不到 / 看到内置的 / 走错额度 / 上游报模型不存在"，先查这四问：
前三个同时命中 → 配置层无解，直接上本地中转，别在配置里死磕。
破解办法是加一层本地中转，把矛盾转移到中转层解决：
<你的本机中转地址> 占位，不写真实端口）。<不重名的显示ID>），URL 指向 <你的本机中转地址>。<套餐方精确模型名>），注入只保存在本地的套餐 key，再转发给套餐方，结果原样流式返回。local-proxy 之类）。这样：工具看到的是不重名的 id（不被压制），套餐方收到的是精确名（不报错），key 只留在本机中转层（安全）。
中转脚本核心逻辑（示意，key、地址与端口都用占位符，换成你自己的）：
# 仅示意：收到工具请求 → 改写 model 名 → 注入本地套餐 key → 转发 → 流式返回
LOCAL_KEY = "<你的套餐KEY占位符>" # 只放本机脚本或环境变量，不上传到工具配置
REAL_MODEL = "<套餐方精确模型名>" # 套餐方认的精确名
UPSTREAM = "https://<套餐方域名>/v1" # 套餐方真实地址
def handle(request):
request["model"] = REAL_MODEL # 把显示 ID 改回套餐方精确模型名
request.headers["Authorization"] = "Bearer " + LOCAL_KEY
return stream_forward(UPSTREAM, request) # 原样流式返回"我在 AI 编程工具里配自定义大模型，出现<看不到 / 看到内置 / 走错额度 / 上游报模型不存在>。套餐方只认精确 model 名<精确名>，但工具云端已内置同名 id 会压制我。请帮我写一个零依赖的本地中转脚本（Python / Node）：监听<你的本机中转地址>，把工具发来的 model 名改写回<精确名>，注入本地套餐 key（只放本机脚本或环境变量里），转发到套餐方并原样流式返回；并告诉我工具里自定义 id 起什么不重名的名字、URL 怎么填。"
判别要点：在 AI 工具里配自定义大模型，凡是"看不到 / 看到内置的 / 走错额度 / 上游报模型不存在"，先查这四问：
适用于所有"AI 工具接自定义 / 第三方大模型"撞内置 id 的场景。
本条截至发布日有效（各工具的模型配置机制会迭代，核心判别式长期适用）。
「晓峰·AI 工具技能卡包」— 你的 AI 助手能直接调用的技能卡
小红书搜「晓峰AI增长实验室」或在豆包搜「晓峰AI避坑助手」
想持续更新 + 全量经验 + 答疑 → 升级「晓峰AI工具库」订阅