接入一个 AI CLI 时，最容易出现一种“层层绿灯，最终不能用”的假成功：
- 安装命令返回成功；
- 账号完成登录；
- CLI 能列出模型；
- 但真正发出请求时，被资格、地区、配额或策略系统拒绝。
前面三步都是真的，却仍不足以证明服务可用。因为它们分别只验证了软件、身份和目录读取，没有验证最关键的业务执行权限。
四层状态不要混在一起
1. 安装层
验证二进制存在、版本正确、依赖完整。
这一层失败，工具根本跑不起来；这一层成功，只能说明本机环境准备好了。
2. 认证层
验证账号能完成 OAuth 或其他登录流程，凭据可以被客户端读取。
登录成功说明“系统认识你”，不代表“系统允许你调用这个能力”。
3. 发现层
验证客户端能获取模型、项目或资源列表。
列表接口经常比推理接口权限更宽，也可能返回面向多个套餐的公共目录。模型出现在列表里，不等于当前账号拥有它的调用权。
4. 执行层
用目标账号、目标模型和真实网络环境发出一个最小业务请求，并检查返回结果。
只有这一层成功，才能回答“现在能不能用”。如果产品还要求无人值守运行，还要继续验证凭据持久化和重启后的自然恢复。
最短验收脚本
每次接入外部 AI 工具，都可以固定问五个问题：
- 客户端版本是否符合要求？
- 当前登录的是不是目标账号？
- 模型或资源目录能否读取？
- 最小真实请求能否成功返回？
- 退出终端或重启后，是否仍能正常调用？
其中第 4 步是硬闸门。它失败时，前面所有绿色状态都只能算排障线索，不能写进交付结论里的“已可用”。
为什么真实请求会在最后失败
外部平台往往把控制拆成多套系统：
- 身份系统决定能否登录；
- 产品目录决定能看到什么；
- 订阅系统决定套餐权益；
- 地区与风控系统决定当前账号是否放行；
- 配额系统决定还能调用多少；
- 推理网关执行最终请求。
因此，“能登录但不能请求”并不矛盾。它只是说明故障域已经从本机安装和认证，缩小到了账号权益、地区资格、风控、配额或服务端策略。
这时继续重装客户端通常没有价值。更有效的动作是保存最终请求的错误码与错误文案，再针对对应控制层排查。
结论应该怎么写
不要写：
已安装并登录，接入成功。
应该写：
客户端已安装，账号已登录，模型目录可读；最小真实请求因资格检查失败，当前不可用。
可靠性并不来自多跑几个安装命令，而来自对“成功”定义得足够严格：
能看到不等于能调用，能调用一次不等于能稳定运行。真实业务请求，才是验收起点。
马启航Marvis