laohan-shencha

name	laohan-shencha
version	1
description	深度联网审查技术文档和部署方案，联网验证事实准确性、参数正确性、版本兼容性。Use when 用户说"深度审查""老韩审查""联网审查""技术文档审查"或要求对技术方案/部署脚本/配置文件进行事实核查。不适合纯文字审查或非技术文档。

Laohan Shencha（老韩深度审查）

核心原则

LLM 写技术文档时天然相信自己写的声明是对的。本 skill 的唯一目的：找出并修正那些"看起来正确但实际是错的"声明。

纯文字审查（表述矛盾、格式不统一）不是本 skill 的重点——那些靠文本比对就能发现。

分级抽样（声明超 50 条时启用，节省 token）： 高可信（官方 README 复制、环境变量名）→ 抽检 20%；中可信（版本号、参数值）→ 抽检 50%；低/未知可信（社区讨论、博客引用）→ 全部验证。声明数 ≤50 条时，逐条全量验证。常识性声明（如"PyTorch 是深度学习框架"）始终跳过。

五阶段审查流程

阶段 1：扫描 — 提取可验证声明

读取工作区所有相关文件，提取以下类型的声明：

文件范围选择： 优先扫描可执行脚本（.py/.sh/.ps1）、配置文件（.json/.yaml/.toml）、项目文档（README.md/workflows/）。纯散文/日记/日志类文件跳过。文件超 20 个时优先脚本+配置类。

声明提取模式：

• GitHub 仓库：github\.com/[\w.-]+/[\w.-]+ → github.com/xxx/yyy
• 版本号：v?\d+\.\d+(\.\d+)*(?:-[.\w]+)? → PyTorch 2.7.1
• 参数值："?\w+"?\s*[:=]\s*"?[^\s,;"]+"? → blocks_to_swap=10, port: 3000
• API 端点：https?://[^\s]+\bapi[^\s]+ → https://api.example.com/v1/chat
• CLI 命令：(?:^|[\s]+)(docker|npm|pip|python|git|curl|cargo|go)\s[^\n]+ → docker compose up -d
• 环境变量：\b[A-Z_]{3,}\b（仅 .env/.sh/配置文件激活）→ OPENAI_API_KEY
• 文件路径：(?:/[\w.-]+)+/? → /etc/nginx/conf.d/, ~/.config/
• 端口号：:\d{2,5}(?:/\w+)? → :18789, :3000/api
• Docker 标签：[\w.-]+:[\w][\w.-]* → python:3.11-slim
• 硬件需求：\d+\s*(GB|MB|GiB|MiB)\s*(VRAM|RAM|显存) → 16GB VRAM
• 文件大小：(?:~|大约|约|about)?\s*\d+\s*(KB|MB|GB|TB) → ~10GB
• pip 安装：(?:pip3?|python\s+-m\s+pip|uv\s+pip)\s+install\s+\S+ → pip install xxx
• npm 包："(@?[\w@./-]+)":\s*"([^"]+)" → "next": "^14.2.0"
• CVE 编号：CVE-\d{4}-\d{4,} → CVE-2024-1234
• 浏览器兼容：(Chrome|Safari|Firefox|Edge)\s*\d+ → Chrome 90+
• git clone：git\s+clone\s+(?:--depth\s+\d+\s+)?\S+ → git clone --depth 1 https://...

可执行脚本中的外部资源引用自动提升一个严重度等级。 脚本（.ps1/.py/.sh）里的文件名、URL、仓库 ID 写错会直接导致运行失败，比文档中的同名错误严重得多。

输出：按文件分组的声明清单，标注每条的验证方法和优先级。

阶段 2：联网验证 — 逐条查证

对每条声明使用对应验证方法。必须实际查询，不能凭训练知识判断。

验证工具优先级：

1. gh repo view / gh api — GitHub 仓库可用性，gh api repos/{o}/{r}/releases/latest 查最新发布
2. Web search — 官方文档、社区报告
3. Context7 — 库/框架的最新文档（注意 API 限流）
4. curl -I {url} — 快速检查 URL 可达性（HEAD 请求优先）
5. npm view {pkg} / pip index versions {pkg} / brew info {fmla} — 包管理器验证
6. Docker Hub API / HuggingFace API / PyPI JSON API — 镜像和模型验证
7. gh auth status — 先检查认证状态，再决定是否设 GH_TOKEN

并行化： 独立的验证项用多个 Agent 并行跑，不要串行。

API 频率限制处理：

• GitHub API 未认证：60 req/hr。设置 GH_TOKEN 或 GITHUB_TOKEN 环境变量可获得 5000 req/hr。
• HuggingFace API：https://huggingface.co/api/models/{user}/{repo} 查看模型信息，/tree/main 查看文件列表。
• PyPI API：https://pypi.org/pypi/{package}/json 获取版本信息。

源冲突解决优先级： 官方文档 > GitHub README > 官方 Wiki > 社区讨论 > 博客文章。当源冲突时，以优先级高的为准，在报告中注明冲突详情。

阶段 3：交叉比对 — 文档间一致性

检查同一参数/描述在不同文件中的表述是否一致：

• 数值参数（节点数、VRAM、版本号）
• 仓库 URL 和安装命令
• 硬件需求描述
• 步骤/流程描述

阶段 3.5：确认 — 向用户展示发现

CRITICAL 发现必须经用户确认后才能修复。HIGH 发现若超过 3 个，或任一修复会改动超过 5 行，也需确认。MEDIUM/LOW 自动修复，汇总报告。确认格式：

### 发现 #1 [CRITICAL]
文件：xxx.py:42  原：`pip instal torch`  应为：`pip install torch`
证据：PyPI 官方文档 https://pypi.org/project/torch/
是否修复？[Y/n]（拒绝时标为"用户否决"，不修复但保留在报告中）

阶段 4：修复 — 逐项修正

按严重度排序修复。每个严重度锚定到可检验的后果：

严重度	定义	示例
CRITICAL	可证明会导致崩溃或异常	仓库不存在、命令语法错误、NameError
HIGH	可证明会导致错误输出/行为	参数值错误、VRAM 估算偏差 >20%
MEDIUM	信息不正确但不会改变系统行为	版本号过时、失效链接（若无人点击）
LOW	功能正确但表述不精确	措辞不统一、格式差异

阶段 5：出报告

输出格式：

## 审查报告

### 统计
- 总声明数：X
- 已验证：X
- 有问题：X（CRITICAL: X / HIGH: X / MEDIUM: X / LOW: X）
- 已修复：X

### 发现的问题
| 文件 | 行 | 原值 | 应为 | 证据来源 | 严重度 | 状态 |
|------|-----|------|------|---------|--------|------|
| ... | ... | ... | ... | ... | ... | 已修/待定/用户否决 |

### 仍需实际验证的项
（需要实际运行环境才能确认的项目）

关键注意事项

1. 不信任训练知识：即使是"常识性"的参数值，也要联网验证。模型训练数据有时效性。
2. 验证仓库可用性：仓库被删除/私有化/改名（如 user/repo 突然 404）只有实际查询才能发现，静态分析检测不到。
3. 参数值查官方源：blocks_to_swap 的推荐值、VRAM 需求，以官方 README/文档为准，不以博客为准。
4. 跨文档同步：修了一处参数，必须检查所有引用该参数的文件是否也需要更新。
5. 标注不确定项：无法通过网络验证的（如需要实际硬件测试），在报告中明确标注。
6. 迭代审查：阶段 4 修复完成后，回到阶段 1 重新扫描修复过的文件，确认修复没有引入新错误。最多迭代 2 轮。
7. Token 预算管理：单次审查总 token 预算建议 200K。文件超 30 个时分批审查，每批 ≤15 个文件。声明超 50 条时，按严重度排序，优先验证脚本和配置文件中的声明。
8. 时间限制：每条声明最多 3 次验证查询。每批声明最多 5 分钟工具调用墙钟时间。超过 80% token 使用量时停止验证，报告部分结果。若 10 分钟内未发现 CRITICAL/HIGH，输出"未发现严重问题"并跳过剩余 LOW 验证。

适用项目类型

本 skill 是外部资源验证器，不是代码审查器。它验证 URL、版本号、包名、文件路径等可联网查证的外部声明。无法检测：未定义变量、类型错误、逻辑缺陷、缺少导入等代码级 bug。

适用场景：

• AI 模型部署方案（ComfyUI、LoRA 训练、推理服务）
• 基础设施配置（Docker、K8s、CI/CD）
• 依赖版本密集的技术项目
• 多文档维护的项目（指南 + 脚本 + 工作流）
• Web 应用后端、移动应用、数据库架构等任何引用外部资源的技术项目

审查反模式（不应标记为问题）

以下场景在特定项目环境中是正常的，不应标记：

1. 包管理器版本命名空间差异：brew/apt/pip/npm 各有独立版本号体系，同一个工具在不同包管理器中版本号不同是正常的，不要交叉对比标记"过时"。
2. 平台/环境特定参数：某些 CLI 参数依赖本地环境（如浏览器 cookie、硬件特定 flag），在其他 OS 上不可用是设计如此，不是错误。
3. 故意使用 shell=True：某些脚本为了路径展开必须用 shell=True，不是安全漏洞。结合上下文判断而非机械标记。
4. 私有/内部包：内部 npm/pip/cargo 包可能无法在公共注册表中查到，标记为"未公开"而非"不存在"。
5. 文档化的已知问题：代码注释或文档中已标注"404"/"暂停"/"已废弃"/"TODO"的条目是有意记录，不是待修复的错误。
6. 长时间操作的大超时设置：音视频处理、大文件下载等操作的超时设置（如 300s+）是必要的，不要按常规 RPC 标准"优化"缩短。
7. 平台特定标准路径：各 OS 有标准安装路径（macOS /opt/homebrew、Linux /usr/local、Windows C:\Program Files），不应交叉标记。
8. 区域镜像/代理：pypi.tuna.tsinghua.edu.cn、ghproxy.com 等是合法镜像，不应标记为"非官方"。