用途与定位
老韩深度审查（Laohan Shencha）是一个外部资源联网核验技能。它的出发点是：模型在写技术文档时天然倾向于相信自己写下的声明是对的，因此需要一套流程专门找出“看起来正确但实际是错的”声明，并在获得授权时修正。
它明确不做纯文风审查（表述矛盾、格式不统一靠文本比对即可发现），也不是代码审查器——它验证的是 URL、版本号、包名、文件路径等可联网查证的外部声明，无法检测未定义变量、类型错误、逻辑缺陷、缺少导入等代码级 bug。
模式与动作
技能要求把“核验对象”和“是否修改”分开选择：
- TECH_CLAIMS：默认模式，用于技术文档、脚本、配置和外部资源声明。
- CONTENT_CLAIMS：仅在真人口播工作流⑤或用户明确要求核验口播事实时使用。
- RECORDED_FINAL_INPUT_GUARD + AUDIT_ONLY：仅在已录制最终稿的编排入口使用，审计是否必须重录。
- AUDIT_ONLY：用户说“审查、核验、看看有没有问题”时的默认动作，只出发现与证据，不改文件。
- VERIFY_AND_FIX：只有用户明确要求“修复、改掉”，或上游工作流合同明确授权修改时使用。
选择 CONTENT_CLAIMS 不等于降低事实标准；选择 VERIFY_AND_FIX 也不授权修改文风、方法论或与事实无关的内容。
五阶段审查流程
- 扫描：读取工作区相关文件，提取可验证声明。优先扫描可执行脚本（.py/.sh/.ps1）、配置文件（.json/.yaml/.toml）与项目文档。文件超 20 个时优先脚本和配置类。提取类型包括 GitHub 仓库、版本号、参数值、API 端点、CLI 命令、环境变量、文件路径、端口号、Docker 标签、硬件需求、文件大小、pip 安装命令、npm 包、CVE 编号、浏览器兼容、git clone 等。脚本中的外部资源引用自动提升一个严重度等级。
- 联网验证：必须实际查询，不能凭训练知识判断。工具优先级包括 gh repo view／gh api、Web search、Context7、curl -I、npm view／pip index versions／brew info、Docker Hub API／HuggingFace API／PyPI JSON API 等。注意 GitHub API 未认证为 60 req/hr，设置 GH_TOKEN 或 GITHUB_TOKEN 可得 5000 req/hr。源冲突时按 官方文档 > GitHub README > 官方 Wiki > 社区讨论 > 博客文章 的优先级解决。
- 交叉比对：检查同一参数或描述在不同文件中的表述是否一致，如数值参数、仓库 URL 与安装命令、硬件需求、步骤流程。
- 修复（仅 VERIFY_AND_FIX）：按严重度排序修复。严重度分为 CRITICAL（可证明导致崩溃或异常，如仓库不存在、命令语法错误、NameError）、HIGH（可证明导致错误输出／行为，如参数值错误、VRAM 估算偏差 >20%）、MEDIUM（信息不正确但不改变系统行为，如版本号过时、失效链接）、LOW（功能正确但表述不精确）。
- 出报告：给出统计（总声明数、已验证、有问题按严重度分布、已修复）、发现的问题表格，以及仍需实际验证的项。修复完成后回到阶段 1 重新扫描，最多迭代 2 轮。
CONTENT_CLAIMS 模式
输入为 episodes/<slug>/01-口播稿.md，输出固定为 04-事实核验.md 与 04-事实主张.json。报告开头必须包含 script_hash、fact_check_status: CLEAR|REVISE_REQUIRED|BLOCKED、contradicted_count 与 unverifiable_count。
只提取会影响观众判断、且能被外部证据验证的主张，例如机构行为、职位／产品定义、数字、增速、政策、研究结论、原话引用和时间关系。每条优先找一手来源，没有一手来源才用可靠二手报道并注明。
结论只有五种：SUPPORTED、INFERRED、CONTRADICTED、UNVERIFIABLE、OPINION。SUPPORTED 至少要有一条可审计证据，即真取回页面正文（retrieval: FETCHED_HTTP_200）或 episode 内本地证据（local_path + 实测一致的 sha256）；只读到标题／搜索摘要（TITLE_ONLY）或没取回（FETCH_FAILED）不得写 SUPPORTED，只能写 INFERRED（须附非空 inference_note）或 UNVERIFIABLE。个人经验、价值判断、比喻与行动建议标为 OPINION。CONTRADICTED 必须回②改；UNVERIFIABLE 必须删除、换成不带数字的谨慎表述，或标明这是个人判断，不得用“据说”遮盖。只有 CONTRADICTED=0、UNVERIFIABLE=0 且需要修改的句子都已处理后，才可写 fact_check_status: CLEAR。网络不可用或无法完成核验时写 BLOCKED。
CONTENT_CLAIMS 不评价钩子、节奏、共鸣或传播性，也不改变上游 Cheat 的 rubric。原版模板、口头禅、比喻、冲突表达、个人判断和戏剧化场景不属于待消除的“安全风险”，只提取其中可外部核验的事实部分。
分级抽样
声明超 50 条时启用抽样以节省 token：高可信（官方 README 复制、环境变量名）抽检 20%；中可信（版本号、参数值）抽检 50%；低／未知可信（社区讨论、博客引用）全部验证。声明数 ≤50 条时逐条全量验证。纯类别常识且不影响观众判断的声明可跳过，但版本号、推荐值、资源需求、端口等会改变操作结果的参数必须核验。
适用场景与限制
适用场景包括：AI 模型部署方案（ComfyUI、LoRA 训练、推理服务）、基础设施配置（Docker、K8s、CI/CD）、依赖版本密集的技术项目、多文档维护的项目（指南＋脚本＋工作流），以及任何引用外部资源的 Web 应用后端、移动应用、数据库架构等项目。
审查反模式（不应标记为问题）：包管理器版本命名空间差异、平台／环境特定参数、故意使用 shell=True、私有／内部包（标为“未公开”而非“不存在”）、文档化的已知问题、长时间操作的大超时设置、平台特定标准路径、区域镜像／代理。
重要注意事项：不信任训练知识，即使“常识性”参数也要联网验证；仓库被删除／私有化／改名只有实际查询才能发现；参数推荐值以官方源为准；修一处参数需检查所有引用文件；无法通过网络验证的项要明确标注；资源有限时按后果优先核验，报告须写清覆盖范围，不能把部分覆盖说成全面完成；不设机械查询上限，只有任务预算耗尽、外部访问失败或缺少用户信息时才停止。