菜单
用 Context7 CLI 查最新模型事实（参数规模、API 格式、上下文窗口），用下面的指南 来理解"什么类型的模型适合 doc verification 应用的哪一段"。在为某个 tier 槽位 挑模型、在多个服务商之间取舍、或回看现有分层分配是否合理时调用。Context7 给你 新鲜事实；本 skill 给你把那些事实落到 KC 流水线上的启发式经验。可选插件 （安装：npm i -g context7）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use Context7 CLI for up-to-date model facts (size, API format, context window) and the guidance below for "what kind of models are good for what part of a doc verification app". Consult whenever you need to pick a model for a tier slot, decide between provider alternatives, or sanity-check an existing tier assignment. Context7 gives you fresh facts; this skill gives you the heuristic that maps those facts onto KC's pipeline. Optional plugin (Context7 install: npm i -g context7).
Determine whether extracted entities comply with verification rules. Use after entity extraction to make the pass/fail judgment for each rule on each document. Covers translating natural language rules into executable logic, choosing between Python calculation and LLM semantic judgment, and producing actionable comments on failures. Also use when designing the judgment step of a workflow or when a rule's judgment logic needs debugging.
Design and calibrate confidence scoring for extraction and verification results. Use when building any workflow that needs to quantify trust in its output, when setting up quality control sampling thresholds, or when calibrating existing confidence scores against actual accuracy. Confidence is the bridge between workflows and quality control — high confidence means less review, low confidence means more review. Also use when the quality control skill reports that confidence scores do not correlate with actual correctness.
Identify, catalog, and handle corner cases that do not fit the mainstream verification workflow. Use AFTER several rounds of skill/workflow iteration have surfaced documents that genuinely don't fit and can't be accommodated by reasonable changes to the standard flow. Covers when something is a corner case vs. a systemic fix needed, how to register it, how to wire detection-and-resolve so the corner case stays out of the hot path until a similar document appears again, and when to promote a corner case to a regular rule.
Build cross-document verification rule-skills and workflows — i.e., rules where the verdict depends on facts that appear in MORE than one document. Use when authoring or distilling a rule that requires comparing entities/values across documents in a case (main contract + appendices, loan application + income certificate + bank statement, etc.). Covers what the rule definition must specify (source-doc → entity → target-doc → entity → consistency level), how the resulting check.py/workflow walks the case, contradiction types to handle, and severity classification. Distinct from `compliance-judgment` (within-doc rules); KC is the builder, not the executor.
Generate HTML dashboards for developer users to visualize verification results, system progress, and quality metrics. Use when a testing round completes, when production batches finish processing, when the developer user wants visual reporting, or when they explicitly ask for it. Dashboards are self-contained HTML files. Use this skill **when there's something visual worth showing** — not as a default deliverable. For routine status updates use KC's TUI. The dashboard is a complement to direct reporting, not a substitute.
| name | auto-model-selection |
| tier | meta |
| description | 用 Context7 CLI 查最新模型事实（参数规模、API 格式、上下文窗口），用下面的指南 来理解"什么类型的模型适合 doc verification 应用的哪一段"。在为某个 tier 槽位 挑模型、在多个服务商之间取舍、或回看现有分层分配是否合理时调用。Context7 给你 新鲜事实；本 skill 给你把那些事实落到 KC 流水线上的启发式经验。可选插件 （安装：npm i -g context7）。 |
模型选择并不是经常调用的 skill —— 对大部分用户来说，工作区 .env 里的分层已经设定得很合理，4 层 + 成本敏感的精细选型其实是过度设计。本 skill 存在的两个时刻：conductor 在从零启动时配 tier 分配（少见）；在 skill-to-workflow 内部某个 workflow 需要挑选合适的 worker LLM。
下面的内容是经验性的 —— 是作者在这个领域里摸出来什么有效。当作起点启发式即可，保质期大概 3–6 个月，毕竟模型家族迭代很快。
当前这一代旗舰 MoE LLM 有一个可识别的形状：总参数 200-400B，每个 token 激活 ~20B 专家。例子（几个月后就会过期）：Qwen 在 200-400B-A20B 区间的旗舰 MoE、DeepSeek-V4-Flash 等。
这个形状是不错的 worker LLM 首选 —— 不一定是 tier1 绝对最强，但作为基准起点很合理。挑 tier1 模型时，先从这一类开始，除非有特定理由再往别处走。
参数量降到 ~30B 以下后，大部分服务商上这些模型都极便宜。Qwen 在这个区间提供了一大堆选择，质量都不错。
这个区间挑模型有两条规则：
coder / code 的）—— 小尺寸的 coder 模型在通用 worker 任务上多半不可靠。只在任务确实是代码相关时再用。第一个问题：视觉任务是什么类型？
不确定时先跑最便宜的 OCR，只在它漏掉了结构信息时再升级。
上面的启发式回答的是"挑哪种模型"。具体事实（当前模型名、确切上下文窗口、定价、API 格式）用 Context7 查：
c7 library <服务商名>
c7 docs <libraryId> "available models"
两条命令：先用前者找到服务商的 library ID，再用后者拿到最新文档和代码示例。适用场景：
model-tiers.json 看起来过期了（KC 自上次模型发布后没更新）/models 端点返回空或无帮助.env 里的模型名是不是还在线安装：npm i -g context7。验证：c7 library openai 应返回结果。
tier 分配最后决定的是成本。能满足准确率要求的最便宜模型胜出。正则是隐含的 "tier 0"，规则只靠模式匹配就能完成时，应该先伸手去拿正则 —— 关于何时从正则升级到 worker LLM，见 skill-to-workflow。
不需要填满所有 tier。如果服务商没有合适的小模型，tier3/tier4 留空完全可以。把生效的选择写到 AGENT.md，下次会话就能继承。
本 skill 的启发式会过期。作者打算每 3–6 个月在新模型代际落地之后回来更新一次。如果你发现这里的建议和 Context7 今天显示的事实矛盾了，信 Context7 —— 事实已经走在前面了。