mcpField
L
laohan-shencha

laohan-shencha

github.com/hanzhcnテスト・品質15146 回インストール今日更新
リポジトリ

laohan-shencha について

laohan-shenchaは、技術文書、スクリプト、設定の事実確認スキルです。外部の主張を検証する保守担当者向けで、証拠のみの監査と許可された修正を分けます。

主な機能

  1. 01検証可能な技術的主張を抽出
  2. 02リポジトリ、バージョン、外部リソースを確認
  3. 03複数文書間のパラメーターを比較
  4. 04監査と修正の許可を分離
  5. 05根拠付きの監査レポートを作成

活用シーン

  1. 01デプロイガイドのバージョンとコマンドを検証
  2. 02スクリプトが参照するリポジトリとリソースを確認
  3. 03トーク台本の検証可能な事実を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/hanzhcn/laohan-skills --skill laohan-shencha

インストール後、Claude Code で/laohan-shenchaを入力して読み込まれたか確認します。

詳細

Laohan Shencha（老韩深度审查）

核心原则

LLM 写技术文档时天然相信自己写的声明是对的。本 Skill 的唯一目的：找出那些“看起来正确但实际是错的”声明，并在获得授权时修正。

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

模式与动作

先分别选择“核验对象”和“是否修改”，不要把二者混在一起：

  • TECH_CLAIMS：默认模式，用于技术文档、脚本、配置和外部资源声明。
  • CONTENT_CLAIMS：仅在真人口播工作流⑤或用户明确要求核验口播事实时使用。
  • RECORDED_FINAL_INPUT_GUARD + AUDIT_ONLY：仅在已录制最终稿的编排入口使用，审计是否必须重录。
  • AUDIT_ONLY：用户说“审查、核验、看看有没有问题”时的默认动作，只出发现与证据，不改文件。
  • VERIFY_AND_FIX：只有用户明确要求“修复、改掉”，或上游工作流合同明确授权修改时使用。

选择 CONTENT_CLAIMS 不等于降低事实标准，选择 VERIFY_AND_FIX 也不授权修改文风、方法论或与事实无关的内容。

RECORDED_FINAL_INPUT_GUARD + AUDIT_ONLY

仅当episode记录USER_PROVIDED_FINAL_SCRIPT_AND_RAW且上游Prompt明确指定RECORDED_FINAL_INPUT_GUARD + AUDIT_ONLY时启用。读取当前01-口播稿.md与06-拍摄素材/raw.mp4，分别计算SHA-256；只做不改口播的阻断性审计。普通不可核验、非核心措辞和可安全剪辑的问题写入非阻断观察后继续，不得自动回②、重跑③—⑤或伪造常规审核历史。

固定写入00-编排/recorded-input-guard.json和00-编排/recorded-input-guard.md。JSON必须为：

{
  "schema_version": 1,
  "mode": "RECORDED_FINAL_INPUT_GUARD",
  "script_sha256": "64 lowercase hex",
  "raw_sha256": "64 lowercase hex",
  "status": "CLEAR_WITH_NOTES|BLOCKED_REQUIRES_RERECORD",
  "blocking_reasons": [],
  "non_blocking_observations": [],
  "checked_at": "ISO-8601"
}

blocking_reasons只允许以下四项，且只有其中至少一项成立时状态才可为BLOCKED_REQUIRES_RERECORD：

  • HIGH_RISK_PLATFORM_VIOLATION
  • CORE_FACT_DIRECTLY_CONTRADICTED
  • SCRIPT_RAW_MATERIAL_MISMATCH
  • RERECORD_ONLY_REMEDIATION

本模式不得写04-事实核验.md、04-事实主张.json或fact_check_status: CLEAR，不得编辑脚本。人类报告必须复述同一script/raw SHA、状态、阻断理由与非阻断观察，供RECORDED_FINAL_INPUT_GUARD下游汇总。

CONTENT_CLAIMS 模式（真人口播⑤）

输入是 episodes/<slug>/01-口播稿.md，输出固定为 04-事实核验.md 与 04-事实主张.json。报告开头必须含 script_hash: <当前稿 SHA-256>、fact_check_status: CLEAR|REVISE_REQUIRED|BLOCKED、contradicted_count 与 unverifiable_count frontmatter。claims JSON 必须含当前 script_hash、事实报告 SHA、每项外部主张的稳定 claim_id、原句、SUPPORTED|INFERRED|CONTRADICTED|UNVERIFIABLE|OPINION 结论及来源证据。只提取会影响观众判断、且能被外部证据验证的主张：机构行为、职位/产品定义、数字、增速、政策、研究结论、原话引用和时间关系。能由来源直接读出的才写 SUPPORTED；SUPPORTED 至少要有一条可审计证据——真取回页面正文（retrieval: FETCHED_HTTP_200）或 episode 内本地证据（local_path + 实测一致的 sha256）；只读到标题／搜索摘要（TITLE_ONLY）或没取回（FETCH_FAILED）不得写 SUPPORTED，只能写 INFERRED（附非空 inference_note）或 UNVERIFIABLE；从实现、多个来源或行为推导出的结论写 INFERRED，并提供非空 inference_note。个人经验、价值判断、比喻与行动建议标为 OPINION。

04-事实主张.json 最小结构：schema_version: 1、script_sha256、fact_report_sha256、claims 数组；每项至少含稳定 claim_id、statement、verdict、evidence 数组。每个证据项必须有稳定 id，并且二选一：外部证据写 url（http(s)）、source_type、retrieval（取回层级，三选一：FETCHED_HTTP_200 真取回页面正文 / FETCH_FAILED 取回失败 / TITLE_ONLY 只读到标题搜索摘要）——写 FETCHED_HTTP_200 时必须给可解析的 retrieved_at，写 FETCH_FAILED／TITLE_ONLY 时必须给非空 failure_note（说明为什么没取到）；本期本地证据写 episode 内 local_path 与文件 sha256（必须与实测一致）。两个 SHA 字段必须分别等于当前 01-口播稿.md 与 04-事实核验.md 的 SHA-256。无可核验主张时仍写空 claims 数组，不能省略文件或伪造来源。（取回层级与 SUPPORTED 判据自 2026-09-30 起由 scripts/verify-fact-claims.mjs 在 production/final 阶段机械核对；此前只登记 url 的旧产物在 accepted-final 复检时只 WARN，不追溯。）

  1. 逐条编号提取主张，保留原句和所在行。
  2. 每条优先找一手来源：机构官网/公告、原始研究、官方数据库、原采访或平台原帖；没有一手来源才用可靠二手报道，并注明。
  3. 只能给出 SUPPORTED、INFERRED、CONTRADICTED、UNVERIFIABLE、OPINION 五种结论；没有来源不能写“基本正确”。INFERRED 可用于口播判断，但不能作为后续 PROOF beat 的直接事实证据。
  4. CONTRADICTED 必须回②改；UNVERIFIABLE 必须删除、换成不带数字的谨慎表述，或标明这是个人判断。不得用“据说”遮盖。
  5. 报告最少包含：主张 ID、原句、结论、来源链接、来源日期、建议改法。无可核验主张时也写明“0 条”，不能省略文件。

只有 CONTRADICTED=0、UNVERIFIABLE=0 且所有需要修改的句子已在当前稿处理后，才可写 fact_check_status: CLEAR；否则写 REVISE_REQUIRED 并准确计数。网络不可用、来源无法读取或无法完成核验时写 BLOCKED，不得用 hash 或“已出报告”代替结论。

CONTENT_CLAIMS 不评价钩子、节奏、共鸣或传播性；这些由 dbskill 诊断。它也不改变上游 Cheat 的 rubric。

原版模板、口头禅、比喻、冲突表达、个人判断和戏剧化场景不属于待消除的“安全风险”。只提取其中可外部核验的事实部分；表达方式本身不得因为无法引用来源而删除或降级。个人真实经历只有在冒充不存在的实测、数据或结果时才作为事实问题处理。

AUTONOMOUS_RUN 边界： CONTENT_CLAIMS 不执行下文通用“阶段3.5向用户逐项确认”。发现 CONTRADICTED/UNVERIFIABLE 时先写 REVISE_REQUIRED、精确原句/证据/建议改法并回②；编排器可在最多三轮内自主删改或降级措辞，再重跑③—⑤和④最终预测。只有来源访问、账号授权或事实本身必须由 Jeffrey 提供且三轮仍无法消解时才 BLOCKED。不得把常规 HIGH/CRITICAL 事实修订变成人工确认 gate，也不得为继续流程把问题写成 CLEAR。

分级抽样（声明超 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://...

実行可能スクリプト内の外部リソース参照は、自動的に重大度を 1 段階引き上げます。 スクリプト（.ps1/.py/.sh）内のファイル名、URL、リポジトリ ID の誤りは実行失敗に直結するため、ドキュメント内の同じ誤りよりも重大です。

出力：ファイルごとに分類した主張の一覧。各項目に検証方法と優先度を記載します。

ステージ 2：オンライン検証 — 項目ごとに確認

各主張を、対応する検証方法で確認します。必ず実際に検索し、学習時の知識だけで判断してはいけません。

検証ツールの優先順位：

  1. gh repo view / gh api — GitHub リポジトリの利用可否。最新リリースの確認には gh api repos/{o}/{r}/releases/latest を使用
  2. Web 検索 — 公式ドキュメント、コミュニティの報告
  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 への委任は、ユーザーが明示的に要求した場合、またはホストのルールで複数 Agent が許可されている場合に限ります。

子 Agent への委任規律： 委任を決めたら、タスクの契約をすべて記載してから送信します。目標、許可範囲（明確な禁止事項を含む）、受け入れ基準（機械的に確認できる完了条件）、時間と呼び出しの予算を定めます。契約が整っていない場合はタスクを送信しません。送信前に監督体制を登録し、二つの時計を設けます。すなわち、一定時間を超えて状態更新がない場合に人手による対応へ移行する非アクティブしきい値と、予算超過時に強制停止して報告する総期限です。Agent 自身による時間管理には依存しません。受け入れ時に認めるのは実行の証拠（コマンド出力、生成ファイル、再確認可能な diff）のみです。子 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：確認 — 発見事項をユーザーに提示

このステージは、一般的な技術ドキュメントのレビューにのみ適用します。真人口播⑤の CONTENT_CLAIMS は、上記の AUTONOMOUS_RUN/REVIEW_GATED 契約に従って処理し、ここで重ねて確認を求めません。

  • AUDIT_ONLY：発見事項、根拠、最小限の修正提案を提示したら終了し、ファイルは変更しません。
  • VERIFY_AND_FIX：変更予定の主張と根拠を先に列挙します。修正によってユーザー指定の範囲が広がる場合、プログラムの動作が変わる場合、または製品上の判断が必要な場合は、先に確認を求めます。指定範囲内の通常の事実誤認は、そのまま修正できます。
  • CONTENT_CLAIMS：今回の実行モードとノード契約に従って処理し、確認のためのゲートを追加してはいけません。

確認が必要な場合は、次の形式を使用します。

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

AUDIT_ONLY ではこのステージをスキップします。VERIFY_AND_FIX では、重大度ごとに、検証可能な結果に結び付けて修正します。

重大度定義例
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. ドキュメント間の同期：パラメーターを 1 か所修正したら、そのパラメーターを参照しているすべてのファイルも更新が必要か確認します。
  5. 不確実な項目を明記する：実機でのテストが必要な場合など、オンラインで検証できない項目は、レポートに明示します。
  6. 反復レビュー：ステージ 4 の修正完了後、ステージ 1 に戻り、修正したファイルを再スキャンして、新たな誤りが生じていないことを確認します。反復は最大 2 回までです。
  7. 対象範囲を明示する：リソースが限られている場合は、影響を優先し、スクリプト、設定、高影響の主張を先に検証します。検証済み、未検証、サンプリング範囲をレポートに明記し、一部のみの確認を全面完了と表現してはいけません。
  8. 機械的な検索上限を設けない：情報源が競合する場合は、結論を出せるまで検索を続けるか、UNVERIFIABLE/BLOCKED と明示します。停止できるのは、タスク予算を使い切った場合、外部アクセスに失敗した場合、またはユーザー情報が不足している場合のみです。一般レビューでは PARTIAL/BLOCKED を正直に記載し、CONTENT_CLAIMS ではノード契約に従って BLOCKED と記載します。重大な問題が見つからないからといって、残りの範囲をスキップして完了を宣言してはいけません。

适用项目类型

本 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 等是合法镜像，不应标记为"非官方"。

コメント

Markdown 対応