尧图网页设计 
jcode provider-doctor面向 OpenAI 兼容 Provider 的三级严格诊断流水线【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode本文基于 docs/PROVIDER_DOCTOR.md 撰写系统讲解 jcode 的jcode provider-doctor诊断命令它回答一个问题——“为什么我的 provider/模型或模型选择器不工作”。该命令以 interactive 方式走完与覆盖率台账jcode provider-test-coverage完全相同的严格端到端检查点提供清晰的 PASS/FAIL 输出与首个失败项的“下一步建议”。读完本文你可以掌握三级 tieroffline/catalog/full的选用策略、12 个严格检查点的逐项含义、花费spend追踪机制以及如何把该命令作为 CI/脚本门禁来定位 provider 接入问题。设计目标与适用范围jcode provider-doctor是一个面向用户的严格诊断strict diagnostic覆盖OpenAI 兼容型 providercerebras、fpt、nvidia-nim、comtegra、deepseek、groq、openrouter以及其它openai-compatibleprofile。这些 profile 集中定义在 provider_catalog.rs 中命令通过openai_compatible_profile_by_id按 id 查找并解析出 API 基址、密钥环境变量等字段若 id 无法识别会提示运行jcode provider-test-coverage查看合法的 provider id。从源码结构看该命令还有一个文档未展开的维度原生运行时 provider 的专用驱动器。在 provider_doctor.rs 中命令入口首先用native_doctor_supports_provider判断目标 provider 是否为非 OpenAI 兼容路径claudeOAuth/订阅路径走run_claude_native_e2eantigravityGoogle OAuth Cloud Code走run_antigravity_native_e2e其余原生运行时 providerOpenAI、Gemini、Cursor、Copilot、Bedrock走通用原生驱动器run_generic_native_e2e。这些原生驱动器直接驱动生产运行时例如 AnthropicProvider而不是 OpenAI 兼容的 HTTP 垫片从而验证与真实 agent 相同的凭据解析、目录拉取与请求整形路径。无论走哪条驱动器记录的都是同一组严格检查点因此原生 provider 也能像 OpenAI 兼容 provider 一样被提升到 READY 状态。快速上手# Validate jcodes own wiring for a provider, no API key, no spend: jcode provider-doctor cerebras --tier offline # Validate the key live model catalog (needs a key, negligible spend): jcode provider-doctor cerebras --tier catalog # Full readiness, including real chat, streaming, and tool calls (spends balance): jcode provider-doctor cerebras --tier full # Pin a specific model and emit JSON for scripting/CI: jcode provider-doctor cerebras --model gpt-oss-120b --tier full --json模型默认取该 provider 的默认模型或线上目录中的第一个模型用全局--model标志可以固定到具体模型。--json输出结构化的 JSON 报告字段包括provider_id、provider_label、model、tier、tier_passed、strict_passed、spend与逐项checks可直接用于脚本和 CI见 provider_doctor.rs 的report_to_json实现。三级 Tier从“只查接线”到“真金白银的完整就绪”Tier 决定要跑多深的验证。每一级在自身约束内验证尽可能多的部分因此你可以低成本调试、只在必要时升级Tier需要 key花费余额新增能力能捕获的问题offline否否基于合成目录synthetic catalog验证 jcode 侧接线该 provider 的目录重载、picker 渲染、fallback 标注、模型切换路由 bugcatalog默认是几乎不花线上GET /models调用密钥错误/缺失、端点不可达、模型不在线上目录中full是是非流式聊天、流式、工具调用循环模型真的能对话、流式输出并支持工具调用只有full层级能挣得严格“READY”覆盖率。更轻的层级会刻意把依赖 API 的检查点记为 skipped避免在覆盖率台账中“过度记功”。源码中这一语义由 DoctorTier 枚举 承载requires_api_key()对Offline返回 falsespends_balance()仅对Full返回 truetier 字符串解析对offline/catalog/full大小写不敏感非法值会报出unknown tier预期三选一的提示。几个值得注意的源码级实现细节offline 层级使用合成目录run_provider_e2e 在无网络时会构造一个包含 provider 默认模型与一个*-alternate-fixture-model的两项目录使“目录热重载 → picker 展示 → 模型切换路由”这条 jcode 内部管线仍然可以被完整验证。catalog/full 层级做真目录拉取fetch_live_openai_compatible_models 向{api_base}/models发起 GET带 20 秒超时若--model指定的模型不在返回的目录中model_catalog_live_endpoint检查点会直接 FAIL 并列出线上目录摘要。belvedir 特例belvedir 的 OpenAI 兼容路由刻意不提供/models端点其公开的目录面是项目级auto路由。源码在该分支provider_e2e.rs中直接把model_catalog_live_endpoint记为 PASS 并注明“使用文档化的 auto 路由”避免在到达计费探针前就因一个 provider 不实现的端点而失败。检查点Checkpoints逐项解析每次运行都会按顺序报告这些严格检查点。一个 provider/model 对只有在full层级上全部通过时才算完全就绪auth_credential_loaded— 为该 provider 找到了凭据model_catalog_live_endpoint— 线上/models端点返回了模型catalog_hot_reload_current_session— 目录已热重载进当前会话picker_live_models— picker 展示线上模型含所选模型picker_fallback_labeling— 路由由线上目录支撑而非静态 fallbackmodel_switch_route— 切换模型产生 provider 显式路由non_streaming_chat_completion— 基础聊天回复已返回full 层级streaming_chat_completion— 流式回复已返回full 层级tool_call_parse— 模型发出了可解析的工具调用full 层级tool_execution_loop— 工具调用循环已执行full 层级tool_result_followup— 工具结果已回填full 层级real_jcode_tool_smoke— 端到端工具冒烟测试通过full 层级检查点 1–2 与 auth 生命周期各阶段属于 pre-flight7–12 是依赖 API 的检查点由--tier full门控。源码中 API_DEPENDENT_CHECKPOINTS 正是这份门控清单另含一个可观测性探针见下文非 full 层级会为清单中每一项生成skipped记录并注明requires --tier full (spends balance)。各检查点背后的真实探针实现OpenAI 兼容路径聊天/流式/工具探针均 POST 到{api_base}/chat/completions分别对应 run_live_openai_compatible_smoke、run_live_openai_compatible_stream_smoke与run_live_openai_compatible_tool_smoke。工具探针使用一个名为auth_tool_probe的探测工具验证“模型发调用 → 循环执行 → 结果回填”的完整闭环。可观测性推理探针observe-only源码的检查点标签表 FULL_PIPELINE_LABELS 中还存在第 13 项reasoning_capability。从 push_reasoning_check 的实现看这是一个观察型探针无论模型是流式输出可见推理文本streamed、隐式推理信号opaque如 thought signature / reasoning item还是无推理信号none三者都记为 PASS隐藏推理是合法行为探针出错则记为skipped 而非 failed——该检查点从不参与严格覆盖率阶梯不能因一次观察失败把 provider 打成“不可用”因为更广泛的聊天/流式检查点已经守卫了回合完成性。读懂输出一次 catalog 层级的运行输出如下源自 docs/PROVIDER_DOCTOR.mdProvider doctor: Cerebras / gpt-oss-120b Tier: catalog (API key, ~no spend: adds live catalog fetch) ... [ PASS] Credential loaded Loaded credential from CEREBRAS_API_KEY [ PASS] Live model catalog endpoint 2 live model(s) returned [ PASS] Catalog hot reload in current session 2 catalog route(s) reloaded [ PASS] Picker shows live models 2 model(s) in picker, selected gpt-oss-120b [ PASS] Picker fallback labeling all routes backed by live catalog (no static fallback) [ PASS] Model switch route switch request cerebras:... routed via openai-compatible:cerebras [ skip] Non-streaming chat completion catalog tier: requires --tier full (spends balance) ... Verdict: tier catalog passed. Run --tier full to confirm full readiness (spends balance).PASS/FAIL— 检查点实际运行并通过/失败skip— 当前层级不运行该检查点用--tier full运行它结论行Verdict告诉你所选层级是否通过、是否完全通过READY或失败失败时指向第一个失败检查点并给出下一步动作。输出侧的实现补充两点状态符号比文档示例更丰富。status_symbol 定义了五种状态PASS、FAIL、BLOCK、skip、----NotRun。终端着色受NO_COLOR/JCODE_NO_COLOR控制且仅在 stdout 是终端时启用emit_report。“下一步提示”是内建的故障分诊表。next_step_hint 按检查点映射到具体建议auth_credential_loaded失败 → 运行jcode login --provider provider存储有效凭据model_catalog_live_endpoint失败 → 检查密钥、网络与 provider 状态catalog_hot_reload_current_session/picker_live_models/picker_fallback_labeling/model_switch_route失败 → 属于 jcode 侧该 provider 的路由/picker bug带输出提交 issue聊天/流式检查点失败 → 模型未返回可用补全换目录里的另一个模型tool_*检查点失败 → 模型可能不支持工具调用。退出码即门禁当所选层级未完全通过时命令以非零码退出provider_doctor.rs因此可以直接嵌入 CI 或发布脚本作为质量门。花费追踪一次运行到底花了多少钱计费等级的运行catalog发起一次目录调用full发起多次聊天/流式/工具调用会精确报告本次消耗便于预算Spend this run: 3 billable API calls, 554 tokens (289 in 265 out), cost not reported by providerbillable API calls— 实际打到 provider 的请求数tokens— 这些调用的 prompt completion 总量provider 返回usage块时流式探针会请求stream_options.include_usage保证流式调用也被计入——源码中该字段在 流式探针请求体 中显式设置cost— 仅当 provider 返回cost字段时显示为美元数许多 provider如 cerebras只返回 tokens因此你会看到 “cost not reported by provider”可自行用 token 数乘以套餐单价。一次完整的 cerebras 运行大约消耗 550–620 tokens约 $0.0003。--json输出在spend对象中包含同样的数据billable_calls、prompt_tokens、completion_tokens、total_tokens、has_token_data、reported_cost_usd。实现上DoctorSpend 在每次计费调用的usage/costJSON 上做一次归并兼容prompt_tokens/input_tokens与completion_tokens/output_tokens两种字段命名total_tokens缺失时用两者之和兜底cost字段按调用累加provider 不报告时保持None并在人类可读摘要中显示 “cost not reported by provider”。这份花费数据会随本次运行一起持久化到覆盖率台账因此jcode provider-test-coverage底部会显示一个累计 “Recorded spend” 页脚对每个 provider/model 对取最近一次运行求和。这为“为验证这份覆盖我到目前为止花了多少”给出了持久、可一眼查看的答案。与覆盖率台账的关系每次 doctor 运行都会向覆盖率台账记录一条 live-verification 事件并打上doctor_tier标签。一次通过全部 11 个严格检查点的full层级运行会把该 provider/model 对在jcode provider-test-coverage中翻转为严格“READY”。更轻的层级把依赖 API 的检查点记为 skipped因此永远不会过度记功。jcode provider-test-coverage把同一组检查点渲染为一条 11 阶段流水线。每个已观测到的 provider/model 对占一行紧凑输出一个状态记号READY或N/11 已通过多少阶段后跟provider / model对于尚未 READY 的对再附上首个阻塞项和恰好能推过该阻塞项的provider-doctor命令。两个命令因此是同一条流水线的两个视图覆盖率报告展示每个对卡在哪里并交给你推进它所需的 doctor 命令。每行以新鲜度注记结尾例如READY cerebras / gpt-oss-120b last tested 9 minutes ago (2026-05-30) by developer (dev build) 6/11 nvidia-nim / gemma-4-31b failed at streaming reply; run jcode provider-doctor nvidia-nim --model gemma-4-31b --tier full; last tested 2 days ago ...多久前测的自然语言 绝对日期一眼判断证据是否过期谁测的干净的 release 构建标为user (release build)真实用户证据dirty/dev 构建标为developer (dev build)。该标签由每次运行持久化记录的 build flag 推导不是猜测。典型排障流程按症状选择层级逐级升级“picker 坏了 / 展示了错误的模型。”跑--tier offline。若picker_live_models、picker_fallback_labeling或model_switch_route失败说明是该 provider 的 jcode 侧路由 bug截取输出并提交 issue。“连不上 / 提示 auth 失败。”跑--tier catalog。若auth_credential_loaded或model_catalog_live_endpoint失败问题在密钥/端点运行jcode login --provider provider。“能连上但模型行为不好。”跑--tier full。若non_streaming_chat_completion/streaming_chat_completion/tool_*检查点失败问题在模型本身从线上目录里换一个模型再试。源码导航若需深入实现关键文件如下均为仓库相对路径src/cli/provider_doctor.rs — 命令入口tier 解析、原生 provider 分发、报告打印/JSON 序列化、退出码与下一步提示表crates/jcode-provider-doctor/src/lib.rs — crate 说明位于jcode-base下游隔离 doctor 簇的重建成本crates/jcode-provider-doctor/src/provider_e2e.rs — 严格 e2e 运行器DoctorTier、DoctorReport、DoctorSpend、检查点标签表、offline/catalog/full 各阶段推进逻辑与原生驱动器crates/jcode-provider-doctor/src/live_provider_probes.rs — 真实 HTTP 探针GET /models20s 超时、非流式/流式聊天探针含stream_options.include_usage、工具调用冒烟auth_tool_probecrates/jcode-base/src/provider_catalog.rs — OpenAI 兼容 profile 目录cerebras、belvedir、openrouter 等及其解析docs/PROVIDER_DOCTOR.md — 本文所依据的官方文档。适用前提与限制本指南以当前仓库文档与源码为准OpenAI 兼容路径适用于上列 profile原生运行时 providerClaude OAuth、Antigravity 等由专用驱动器覆盖full层级产生真实账单调用建议在预算允许时运行并可先跑--tier offline与--tier catalog完成低成本分诊。【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 jcode provider-doctor：面向 OpenAI 兼容 Provider 的三级严格诊断流水线
jcode provider-doctor面向 OpenAI 兼容 Provider 的三级严格诊断流水线【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode本文基于 docs/PROVIDER_DOCTOR.md 撰写系统讲解 jcode 的jcode provider-doctor诊断命令它回答一个问题——“为什么我的 provider/模型或模型选择器不工作”。该命令以 interactive 方式走完与覆盖率台账jcode provider-test-coverage完全相同的严格端到端检查点提供清晰的 PASS/FAIL 输出与首个失败项的“下一步建议”。读完本文你可以掌握三级 tieroffline/catalog/full的选用策略、12 个严格检查点的逐项含义、花费spend追踪机制以及如何把该命令作为 CI/脚本门禁来定位 provider 接入问题。设计目标与适用范围jcode provider-doctor是一个面向用户的严格诊断strict diagnostic覆盖OpenAI 兼容型 providercerebras、fpt、nvidia-nim、comtegra、deepseek、groq、openrouter以及其它openai-compatibleprofile。这些 profile 集中定义在 provider_catalog.rs 中命令通过openai_compatible_profile_by_id按 id 查找并解析出 API 基址、密钥环境变量等字段若 id 无法识别会提示运行jcode provider-test-coverage查看合法的 provider id。从源码结构看该命令还有一个文档未展开的维度原生运行时 provider 的专用驱动器。在 provider_doctor.rs 中命令入口首先用native_doctor_supports_provider判断目标 provider 是否为非 OpenAI 兼容路径claudeOAuth/订阅路径走run_claude_native_e2eantigravityGoogle OAuth Cloud Code走run_antigravity_native_e2e其余原生运行时 providerOpenAI、Gemini、Cursor、Copilot、Bedrock走通用原生驱动器run_generic_native_e2e。这些原生驱动器直接驱动生产运行时例如 AnthropicProvider而不是 OpenAI 兼容的 HTTP 垫片从而验证与真实 agent 相同的凭据解析、目录拉取与请求整形路径。无论走哪条驱动器记录的都是同一组严格检查点因此原生 provider 也能像 OpenAI 兼容 provider 一样被提升到 READY 状态。快速上手# Validate jcodes own wiring for a provider, no API key, no spend: jcode provider-doctor cerebras --tier offline # Validate the key live model catalog (needs a key, negligible spend): jcode provider-doctor cerebras --tier catalog # Full readiness, including real chat, streaming, and tool calls (spends balance): jcode provider-doctor cerebras --tier full # Pin a specific model and emit JSON for scripting/CI: jcode provider-doctor cerebras --model gpt-oss-120b --tier full --json模型默认取该 provider 的默认模型或线上目录中的第一个模型用全局--model标志可以固定到具体模型。--json输出结构化的 JSON 报告字段包括provider_id、provider_label、model、tier、tier_passed、strict_passed、spend与逐项checks可直接用于脚本和 CI见 provider_doctor.rs 的report_to_json实现。三级 Tier从“只查接线”到“真金白银的完整就绪”Tier 决定要跑多深的验证。每一级在自身约束内验证尽可能多的部分因此你可以低成本调试、只在必要时升级Tier需要 key花费余额新增能力能捕获的问题offline否否基于合成目录synthetic catalog验证 jcode 侧接线该 provider 的目录重载、picker 渲染、fallback 标注、模型切换路由 bugcatalog默认是几乎不花线上GET /models调用密钥错误/缺失、端点不可达、模型不在线上目录中full是是非流式聊天、流式、工具调用循环模型真的能对话、流式输出并支持工具调用只有full层级能挣得严格“READY”覆盖率。更轻的层级会刻意把依赖 API 的检查点记为 skipped避免在覆盖率台账中“过度记功”。源码中这一语义由 DoctorTier 枚举 承载requires_api_key()对Offline返回 falsespends_balance()仅对Full返回 truetier 字符串解析对offline/catalog/full大小写不敏感非法值会报出unknown tier预期三选一的提示。几个值得注意的源码级实现细节offline 层级使用合成目录run_provider_e2e 在无网络时会构造一个包含 provider 默认模型与一个*-alternate-fixture-model的两项目录使“目录热重载 → picker 展示 → 模型切换路由”这条 jcode 内部管线仍然可以被完整验证。catalog/full 层级做真目录拉取fetch_live_openai_compatible_models 向{api_base}/models发起 GET带 20 秒超时若--model指定的模型不在返回的目录中model_catalog_live_endpoint检查点会直接 FAIL 并列出线上目录摘要。belvedir 特例belvedir 的 OpenAI 兼容路由刻意不提供/models端点其公开的目录面是项目级auto路由。源码在该分支provider_e2e.rs中直接把model_catalog_live_endpoint记为 PASS 并注明“使用文档化的 auto 路由”避免在到达计费探针前就因一个 provider 不实现的端点而失败。检查点Checkpoints逐项解析每次运行都会按顺序报告这些严格检查点。一个 provider/model 对只有在full层级上全部通过时才算完全就绪auth_credential_loaded— 为该 provider 找到了凭据model_catalog_live_endpoint— 线上/models端点返回了模型catalog_hot_reload_current_session— 目录已热重载进当前会话picker_live_models— picker 展示线上模型含所选模型picker_fallback_labeling— 路由由线上目录支撑而非静态 fallbackmodel_switch_route— 切换模型产生 provider 显式路由non_streaming_chat_completion— 基础聊天回复已返回full 层级streaming_chat_completion— 流式回复已返回full 层级tool_call_parse— 模型发出了可解析的工具调用full 层级tool_execution_loop— 工具调用循环已执行full 层级tool_result_followup— 工具结果已回填full 层级real_jcode_tool_smoke— 端到端工具冒烟测试通过full 层级检查点 1–2 与 auth 生命周期各阶段属于 pre-flight7–12 是依赖 API 的检查点由--tier full门控。源码中 API_DEPENDENT_CHECKPOINTS 正是这份门控清单另含一个可观测性探针见下文非 full 层级会为清单中每一项生成skipped记录并注明requires --tier full (spends balance)。各检查点背后的真实探针实现OpenAI 兼容路径聊天/流式/工具探针均 POST 到{api_base}/chat/completions分别对应 run_live_openai_compatible_smoke、run_live_openai_compatible_stream_smoke与run_live_openai_compatible_tool_smoke。工具探针使用一个名为auth_tool_probe的探测工具验证“模型发调用 → 循环执行 → 结果回填”的完整闭环。可观测性推理探针observe-only源码的检查点标签表 FULL_PIPELINE_LABELS 中还存在第 13 项reasoning_capability。从 push_reasoning_check 的实现看这是一个观察型探针无论模型是流式输出可见推理文本streamed、隐式推理信号opaque如 thought signature / reasoning item还是无推理信号none三者都记为 PASS隐藏推理是合法行为探针出错则记为skipped 而非 failed——该检查点从不参与严格覆盖率阶梯不能因一次观察失败把 provider 打成“不可用”因为更广泛的聊天/流式检查点已经守卫了回合完成性。读懂输出一次 catalog 层级的运行输出如下源自 docs/PROVIDER_DOCTOR.mdProvider doctor: Cerebras / gpt-oss-120b Tier: catalog (API key, ~no spend: adds live catalog fetch) ... [ PASS] Credential loaded Loaded credential from CEREBRAS_API_KEY [ PASS] Live model catalog endpoint 2 live model(s) returned [ PASS] Catalog hot reload in current session 2 catalog route(s) reloaded [ PASS] Picker shows live models 2 model(s) in picker, selected gpt-oss-120b [ PASS] Picker fallback labeling all routes backed by live catalog (no static fallback) [ PASS] Model switch route switch request cerebras:... routed via openai-compatible:cerebras [ skip] Non-streaming chat completion catalog tier: requires --tier full (spends balance) ... Verdict: tier catalog passed. Run --tier full to confirm full readiness (spends balance).PASS/FAIL— 检查点实际运行并通过/失败skip— 当前层级不运行该检查点用--tier full运行它结论行Verdict告诉你所选层级是否通过、是否完全通过READY或失败失败时指向第一个失败检查点并给出下一步动作。输出侧的实现补充两点状态符号比文档示例更丰富。status_symbol 定义了五种状态PASS、FAIL、BLOCK、skip、----NotRun。终端着色受NO_COLOR/JCODE_NO_COLOR控制且仅在 stdout 是终端时启用emit_report。“下一步提示”是内建的故障分诊表。next_step_hint 按检查点映射到具体建议auth_credential_loaded失败 → 运行jcode login --provider provider存储有效凭据model_catalog_live_endpoint失败 → 检查密钥、网络与 provider 状态catalog_hot_reload_current_session/picker_live_models/picker_fallback_labeling/model_switch_route失败 → 属于 jcode 侧该 provider 的路由/picker bug带输出提交 issue聊天/流式检查点失败 → 模型未返回可用补全换目录里的另一个模型tool_*检查点失败 → 模型可能不支持工具调用。退出码即门禁当所选层级未完全通过时命令以非零码退出provider_doctor.rs因此可以直接嵌入 CI 或发布脚本作为质量门。花费追踪一次运行到底花了多少钱计费等级的运行catalog发起一次目录调用full发起多次聊天/流式/工具调用会精确报告本次消耗便于预算Spend this run: 3 billable API calls, 554 tokens (289 in 265 out), cost not reported by providerbillable API calls— 实际打到 provider 的请求数tokens— 这些调用的 prompt completion 总量provider 返回usage块时流式探针会请求stream_options.include_usage保证流式调用也被计入——源码中该字段在 流式探针请求体 中显式设置cost— 仅当 provider 返回cost字段时显示为美元数许多 provider如 cerebras只返回 tokens因此你会看到 “cost not reported by provider”可自行用 token 数乘以套餐单价。一次完整的 cerebras 运行大约消耗 550–620 tokens约 $0.0003。--json输出在spend对象中包含同样的数据billable_calls、prompt_tokens、completion_tokens、total_tokens、has_token_data、reported_cost_usd。实现上DoctorSpend 在每次计费调用的usage/costJSON 上做一次归并兼容prompt_tokens/input_tokens与completion_tokens/output_tokens两种字段命名total_tokens缺失时用两者之和兜底cost字段按调用累加provider 不报告时保持None并在人类可读摘要中显示 “cost not reported by provider”。这份花费数据会随本次运行一起持久化到覆盖率台账因此jcode provider-test-coverage底部会显示一个累计 “Recorded spend” 页脚对每个 provider/model 对取最近一次运行求和。这为“为验证这份覆盖我到目前为止花了多少”给出了持久、可一眼查看的答案。与覆盖率台账的关系每次 doctor 运行都会向覆盖率台账记录一条 live-verification 事件并打上doctor_tier标签。一次通过全部 11 个严格检查点的full层级运行会把该 provider/model 对在jcode provider-test-coverage中翻转为严格“READY”。更轻的层级把依赖 API 的检查点记为 skipped因此永远不会过度记功。jcode provider-test-coverage把同一组检查点渲染为一条 11 阶段流水线。每个已观测到的 provider/model 对占一行紧凑输出一个状态记号READY或N/11 已通过多少阶段后跟provider / model对于尚未 READY 的对再附上首个阻塞项和恰好能推过该阻塞项的provider-doctor命令。两个命令因此是同一条流水线的两个视图覆盖率报告展示每个对卡在哪里并交给你推进它所需的 doctor 命令。每行以新鲜度注记结尾例如READY cerebras / gpt-oss-120b last tested 9 minutes ago (2026-05-30) by developer (dev build) 6/11 nvidia-nim / gemma-4-31b failed at streaming reply; run jcode provider-doctor nvidia-nim --model gemma-4-31b --tier full; last tested 2 days ago ...多久前测的自然语言 绝对日期一眼判断证据是否过期谁测的干净的 release 构建标为user (release build)真实用户证据dirty/dev 构建标为developer (dev build)。该标签由每次运行持久化记录的 build flag 推导不是猜测。典型排障流程按症状选择层级逐级升级“picker 坏了 / 展示了错误的模型。”跑--tier offline。若picker_live_models、picker_fallback_labeling或model_switch_route失败说明是该 provider 的 jcode 侧路由 bug截取输出并提交 issue。“连不上 / 提示 auth 失败。”跑--tier catalog。若auth_credential_loaded或model_catalog_live_endpoint失败问题在密钥/端点运行jcode login --provider provider。“能连上但模型行为不好。”跑--tier full。若non_streaming_chat_completion/streaming_chat_completion/tool_*检查点失败问题在模型本身从线上目录里换一个模型再试。源码导航若需深入实现关键文件如下均为仓库相对路径src/cli/provider_doctor.rs — 命令入口tier 解析、原生 provider 分发、报告打印/JSON 序列化、退出码与下一步提示表crates/jcode-provider-doctor/src/lib.rs — crate 说明位于jcode-base下游隔离 doctor 簇的重建成本crates/jcode-provider-doctor/src/provider_e2e.rs — 严格 e2e 运行器DoctorTier、DoctorReport、DoctorSpend、检查点标签表、offline/catalog/full 各阶段推进逻辑与原生驱动器crates/jcode-provider-doctor/src/live_provider_probes.rs — 真实 HTTP 探针GET /models20s 超时、非流式/流式聊天探针含stream_options.include_usage、工具调用冒烟auth_tool_probecrates/jcode-base/src/provider_catalog.rs — OpenAI 兼容 profile 目录cerebras、belvedir、openrouter 等及其解析docs/PROVIDER_DOCTOR.md — 本文所依据的官方文档。适用前提与限制本指南以当前仓库文档与源码为准OpenAI 兼容路径适用于上列 profile原生运行时 providerClaude OAuth、Antigravity 等由专用驱动器覆盖full层级产生真实账单调用建议在预算允许时运行并可先跑--tier offline与--tier catalog完成低成本分诊。【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考