hjdhnx/drpy-node-skill/drpy-node-source-workflow

⚠️ 已归档（2026-07-17）：本 skill 已被 `drpy-node-coder` 取代。coder 融合了 4 个旧 skill（workflow/create/play-debug/repo-upload）的全部工作流，并自带 scripts/cli.js CLI 替代 drpy-node-mcp 服务——一个 skill、无需安装 MCP。本文件保留仅供历史参考，新工作请直接用 drpy-node-coder。

drpy-node Source Workflow

快速索引

执行契约

• 输入：源名/源文件/URL/评估结果/用户目标。
• 输出：证据链分级诊断、分流路线、修复后验证结果、上传建议。
• 原则：先评估 → 再分流 → 再修复 → 再验证 → 最后给上传建议/结束。

模式闸门：先判断是否允许写入

如果用户说“只诊断 / 不要改 / dry-run”，本 skill 输出证据链、根因判断、拟改字段和验证计划后停止。

Reference Map

调度优先级

当本地环境已安装本 Skill 时：

• 本地 Skill 优先级 高于 drpy-node MCP 的通用 prompts
• 当用户只给网址、不给文件名时，总控层应主动分析站点并推导源名

强约束

如果本地 Skill 已覆盖场景，不允许让 MCP 通用 prompt 抢占主流程。

自主全流程模式

当用户明确说“自动完成”“修到100”“满分后上传”“不要中途问我”“给网址做源并上传”时，本 skill 作为总控编排器，使用 packet 贯穿子 skill：

URL → alive check → source-create → L1/L2/L3 → 按丢分最小修复 → play-debug → L3=100 → repo-upload → info核验

执行规则：

1. 先识别 autonomous=true、target_score=100、upload_preauthorized=true/false、tags、is_public。
2. 先做 alive check；broken_site、hard_anti_bot、missing_credentials 直接停止，不建源、不上传。
3. 站点可用时转 source-create 建源；source-create 返回源路径、站型、五接口结果和 L3 分数。
4. L3 未满 100 时按丢分接口拆 L2：home/category/detail/search 在 workflow/source-create 修；play 带真实 ids/play_url/flag 转 play-debug。
5. 回收 play-debug 的 autonomous_next：continue_evaluate 继续 L3；stop_for_user 停止并报告 blocker。
6. L3=100 且上传已预授权时，带本地路径、A/B/C、L1/L2/L3、tags/is_public 转 repo-upload。
7. 自主模式下普通检查点只记录证据不中断；遇到 high_risk_change、仓库目标歧义、凭据缺失时必须停手确认。

自主 handoff packet 必含：

autonomous: true/false
target_score: 100
upload_preauthorized: true/false
tags: 用户明确标签或空
is_public: 用户明确可见性或空
source_name/path: ...
blocker_type: none / broken_site / hard_anti_bot / missing_credentials / high_risk_change / ambiguous_upload / score_below_target
autonomous_next: continue_evaluate / return_workflow / stop_for_user

以下排查项对模板站/签名接口站/纯 API 站都适用。只要源中有 async function，就必须先过这个清单。

完整参考：../drpy-node-source-create/references/references-async-function-patterns.md

强约束

不要因为"这是模板站"就跳过这些检查。只要源中有 async function，就必须先过通用清单。

总控闭环（5 步）

用户输入
   │
   ▼
Step 1: 识别输入类型 ──仅有网址──→ 分析站点 → 转 source-create
   │
   ├─已有源名/文件
   ▼
Step 2: 评估现状 (L1语法→L2单接口→L3 evaluate)
   │
   ▼
Step 3: 判断失败类型
   ├─ A 规则不通 → 本 skill 修复
   ├─ B 评估串联 → 本 skill 排查
   ├─ C 播放链   → 转 play-debug
   └─ 新建场景   → 转 source-create
   │
   ▼
🛑 检查点 1: 确认诊断结论
   │
   ▼
Step 4: 分流执行
   │
   ▼
Step 5: 收束 → 🛑 检查点 2 → 结束 / 转 repo-upload

Step 1：识别输入类型

• 仅有网址 → 先分析站点并推导源名
• 已有源名/源文件 → 进入修复与评估流程

Step 2：评估现状

1. drpy_read_file 读取源文件，确认源名、host、@header 类型和用户目标一致
2. drpy_check_syntax + validate_spider 基础校验
3. get_resolved_rule（模板站适用），记录继承后的 class_parse/url/searchUrl/play_json/play_parse/sniffer/isVideo
4. evaluate_spider_source 全流程评估
5. 记录证据链：每个结论必须能对应到工具输出（语法/结构/单接口/全流程）

Step 3：判断失败类型

诊断工具调用（MCP 真实字段示例）：

# 逐接口拆分验证
test_spider_interface(source_name='源名', interface='category', class_id='分类ID')
test_spider_interface(source_name='源名', interface='detail', ids='一级返回的真实 vod_id')
test_spider_interface(source_name='源名', interface='search', keyword='高频宽匹配词')
test_spider_interface(source_name='源名', interface='play', play_url='二级返回的播放地址', flag='线路名')

单接口测试必须使用上游真实返回值：category → vod_id → detail → play_url，不要手推 ID。

• A. 规则本身不通 → 单接口 test 也失败
• B. 评估器没串起来 → 单接口通但 evaluate 不通（见「专项排查参考」→「评估器失败分流」B类优先检查）
• C. 主要卡在播放链 → detail 正常但 play 异常

🛑 检查点 1：确认诊断结论

在进入分流前，向用户呈现诊断摘要：

## 诊断结论
-首页：通/不通
-一级（category）：通/不通
-二级（detail）：通/不通
-搜索：通/不通
-播放：通/不通
-失败类型：A（规则不通）/ B（评估串联）/ C（播放链）
-证据链等级：L1=语法结构；L2=单接口；L3=全流程 evaluate
-关键工具输出：...（列出支撑结论的工具和结果）
-建议路线：继续本 skill 修复 / 转 source-create / 转 play-debug / 转 repo-upload / 结束
-用户确认后再进入修复；自主全流程模式下，低风险最小修复不暂停，只记录本摘要并继续执行

Step 4：分流

Step 5：收束

• evaluate_spider_source 重新评估
• 给出是否有效结论
• 决定是否建议上传/替换/回滚；需要仓库动作时转 drpy-node-repo-upload，不在 workflow 内直接操作 house_file

🛑 检查点 2：确认操作方案

在收束前向用户确认：

## 修复结果摘要
-已修复：...（接口和改动简述）
-仍未通：...
-建议上传：A（建议上传）/ B（技术上可传）/ C（暂不应上传）
 
用户确认后再转 repo-upload 处理上传/替换/标签等仓库动作，或结束；自主全流程模式下若 L3=100、A 档、upload_preauthorized=true 且 tags/is_public/目标明确，可直接转 repo-upload 执行上传核验

强约束

不要把 workflow 变成"所有事都自己做完"。它的价值在于：先评估 → 再分流 → 最后收束。

工具证据链分级

结论必须带等级：例如“L2 证据显示 detail 通、play 断”，不要说成“整个源不通”。L1 只能作为继续拆测的门槛，不能包装成“可用/已修好/可上传”。

大改确认点

以下情况必须先给出方案并等用户确认：

• 从模板继承改为全 async。
• 删除大段已有规则或重写推荐/一级/二级/搜索。
• 需要登录态、Cookie、Token 或复杂签名逆向。
• 准备上传、替换仓库文件或回滚改动；自主全流程中，只有 L3=100、A 档、用户已预授权且目标/tags/is_public 明确的 repo-upload handoff 可免二次确认。

确认模板：

## 修复方案确认
-当前证据链：L1 / L2 / L3
-根因判断：A / B / C
-拟改字段：...
-为什么不是更小改动：...
-验证计划：...

分流输出契约

转交子 skill 前，必须带上 handoff packet，避免子流程重新摸索；缺少关键上下文时先补上游真实值，不要空转交接。

子 skill 不可用时，按本 skill 的证据链先输出诊断，不要临时拼一个不完整替代流程。

A/B/C 路由速判

安全边界

Reference 使用规则

本 skill 引用两类资料：

• 本地总控 reference：references/references-workflow-triage.md、references/references-template-summary.md、references/references-framework-internals.md、references/references-search-strategies.md。
• 子 skill reference：../drpy-node-source-create/references/...，用于 async、纯 API、二级字典等细节。

如果某个 reference 文件不可达，不要中断诊断；按本文件内的 P0/P1 清单继续最小排查，并在输出中标注“reference 未读取，依据本 skill 内置规则处理”。

子 skill 不可用时的兜底

这样即使子 skill 暂不可用，也能完成“诊断与分流”，但不冒充完成专门实现。

专项排查参考

模板站排查路线

当站点命中内置模板但评估不顺时，严禁直接大面积手写覆盖。

排查顺序（按此顺序逐项检查）

1. 查模板默认定义 → references/references-template-summary.md
2. class_parse 是否残留覆盖？→ 补 class_parse: ''
3. double 是否导致推荐空？→ 补 double: false
4. 真实分类 url → 必须验证真实分类页和翻页
5. 真实搜索 searchUrl
6. 删除手写 一级/搜索，优先验证模板内置规则
7. test_spider_interface 拆开验证各接口
8. 最后才允许最小覆盖

强禁止

未完成 1~7 之前，禁止一口气重写 推荐/一级/搜索/二级。

关键原则

不要把模板问题、分类 URL 问题、评估器串联问题，误当成单纯的一级选择器问题。

纯 API 站排查路线

当页面源码为空、所有数据走 JSON API 时，走此路线（不套用模板站 checklist）。

完整参考：../drpy-node-source-create/references/references-pure-api-async-site.md

排查顺序

1. this.input 是否被误当响应 → 必须 await request(this.input)
2. detailUrl 是否设置 → 纯数字 vod_id 必须设
3. 搜索 searchUrl 是否带 ** → 否则 KEY 为空
4. POST 是否用了 body 而非 data
5. 外部 API 是否需要 Authorization
6. 推荐是否完整聚合

强约束

纯 API 站排障路线与模板站完全不同，不要混用模板站的 checklist。

评估器失败分流

B 类分数速映

evaluate_spider_source 各接口分数可快速映射到排查步骤：

B 类优先检查（顺序执行，逐项排查）

Step 1. 查 get_resolved_rule(path) → 看模板继承后的 class_parse/double/url 是否被覆盖
Step 2. 查首页 class 是否为空 → class_parse 是否命中（未命中 → 补 class_parse）
Step 3. 查 class_parse 是否残留覆盖 → 显式设 class_parse: ''
Step 4. 查 double 是否导致推荐为空 → 单层推荐优先 double: false
Step 5. 查分类 url / 搜索 searchUrl 是否真实
Step 6. 查手写 一级/搜索 是否反而扰乱模板内置链路（删除手写，先用模板内置）

B 类深层机制理解

B 类失败的根本原因在于评估器串联机制与模板继承机制的交互。排查时先记住完整初始化链：

init() → getSandbox()/vm.createContext → 执行源文件获得 rule
      → handleTemplateInheritance() → initParse() → invokeMethod()

含义：

• 源运行在沙箱中，不能假设 require/fs/process 可用；只能用沙箱注入的 request/pdfh/pd/CryptoJS/local 等能力。
• handleTemplateInheritance() 发生在正式调度前，源中显式字段会覆盖模板字段。
• initParse() 会处理 host、headers、URL 模板、预处理等运行态配置；这些异常会表现为后续接口通断问题。
• invokeMethod() 再按 推荐/一级/二级/搜索/lazy 和字段类型分流。

// 引擎 invokeMethod 分发逻辑 (drpyS.js)
switch (method) {
    case '推荐': injectVars = homeVodParse(...); break;  // 依赖 class + double
    case '一级': injectVars = cateParse(...); break;     // 依赖 url 模板渲染
    case '分类': injectVars = homeParse(...); break;      // 依赖 class_parse
}

• 首页空分类 → 后续 category 无 class_id 可用 → 全链断裂
• class_parse 未命中 → class 为空 → 评估器拿不到分类 ID
• get_resolved_rule(path) 可查看模板继承后的最终字段值，快速判断哪个字段被覆盖

详见 references/references-framework-internals.md 第七章节「调度分发机制」。

搜索排查

搜索词适配（高频误判点）

当自动评估仅搜索失败，其他接口正常时：

1. 不要立刻判定"搜索规则失效"
2. 不要急着改 searchUrl
3. 应先换高频宽匹配词验证（通用词 我的，动漫站 异世界，或取一级 vod_name 片段）
4. 换词后正常 → 判定为评估参数问题

搜索策略参考

处理搜索前必须先判断属于：

1. 原生搜索接口
2. suggest / 联想搜索 fallback
3. RSS fallback

参考：references/references-search-strategies.md

二级 detail 规范

完整参考：../drpy-node-source-create/references/references-detail-dict-and-multiep.md

测试输入

• detail 测试必须使用一级真实返回的 vod_id
• 禁止主观简化为纯数字 id 或手推 id
• 正确顺序：先跑 category → 取真实 vod_id → 再测 detail