| name | drpy-node-source-create |
| description | 适用于 drpy-node 新建 DS 源。用户提到“新建源”“写个 drpy 源”“分析这个站做 DS 源”“创建新规则”“从零开始做源”时使用。专注于站点分析、模板判断、规则生成与初步验证，优先走模板继承与最小覆盖路线，避免一开始就把修复、仓库上传等杂事混在一起。 |
drpy-node Source Create
调度优先级（新增强规则）
当本地环境已安装本 Skill 时：
- 本 Skill 的工作流优先级 高于 drpy-node MCP 的通用 prompts
- MCP 通用 prompt 仅作为无本地 Skill 时的兜底说明
- 如果用户只提供网址、没有提供源文件名，必须先自行分析站点并推导合理源名，不能机械等待用户补文件名
强约束
如果已经命中本 Skill 的使用场景，不要退回到通用 MCP 基础流程充当主流程。
与其他 drpy-node skills 的分流关系（新增）
本 Skill 负责什么
- 从网址出发分析站点
- 判断是否命中模板
- 推导合理源名
- 生成初版
rule
- 完成首页 / 一级 / 二级 / 搜索 / 播放的初步验证
何时切换到 drpy-node-source-workflow
如果任务已经从“新建源”转变成以下任一情况，应交给总控 workflow：
- 用户开始强调“修源 / 调试 / 评估源是否有效”
- 已存在源文件，需要系统性排查而非继续从零生成
- 问题涉及多接口串联（home/category/detail/search/play）
- 任务包含仓库上传、替换、公开/私密、标签修正等动作
何时切换到 drpy-node-play-debug
如果主要问题已经明显收缩到播放链路，例如：
- lazy 逻辑不对
- play.html 被当成直链
- iframe / m3u8 提取
- parse:0 / parse:1 / jx:0 / jx:1 判断
则应切换给 drpy-node-play-debug，不要在 create skill 里继续扩写播放排障。
强制停手检查点（新增）
出现以下任一情况时，必须停止继续在 create skill 内扩写，并明确切换到其他 skill：
- 任务已从“新建源”转为“系统性修源 / 评估源是否有效 / 决定是否上传” → 交给
drpy-node-source-workflow
- 主要问题已明显收缩到 lazy / 直链 / iframe / m3u8 / parse/jx 判断 → 交给
drpy-node-play-debug
禁止在这些前提已出现时，继续把 create skill 当成总控或播放专项 skill 使用。
30 秒最短建源路线（新增）
当用户说“新建源 / 写个 drpy 源 / 分析这个站做 DS 源”时，优先按下面顺序起手：
- 先定源名
- 用户没给源名 → 先从站名 / 标题 / 域名推导稳定候选
- 先分站型
- 命中模板站 → 优先模板继承 + 最小覆盖
- 非模板异步站 → 先判断是否签名接口驱动
- 先保住最小可用链路
- 最后才决定是否进入更深排障
- 如果已经变成系统性修源 / 评估 / 上传问题 → 交给 workflow
- 如果主要卡在播放链 → 交给 play-debug
强提醒
不要一上来就大面积手写 一级/搜索/二级。
先分站型、先判断模板/签名接口、先保住最小可用，再决定是否需要最小覆盖。
新增强规则：非模板站也要先判断“一级是否由签名接口驱动”
当站点不是内置模板，且分类页列表明显由前端 JS 异步渲染时，必须优先参考：
references/references-non-template-signed-api-site.md
强提醒
不要看到页面上有 data-api 就直接假设这是可裸 GET 的 JSON 接口。
必须先确认：
- 浏览器真实请求是 GET 还是 POST
- 是否带
time/key/token 等签名参数
- 是否需要 Ajax 请求头
已验证经验
本类站点可能出现：
- 裸 GET 只返回一段无效文本
- 浏览器真实请求却是带签名的 POST
新增强规则：继承模板站首页推荐空时，优先检查 double
当站点已命中内置模板，且通过模板继承生成最终 rule，但首页推荐节点已确认存在而 home.list 仍为空时，必须优先参考：
references/references-inherited-template-minimal-override-site.md
强提醒
如果手写 推荐 已经直接落到最终卡片层，例如：
.cbox_list&&ul&&li
而首页仍为空，不要立刻怀疑字段槽位全部错误，优先检查：
double: true
对于单层推荐结构，应优先尝试：
double: false
在处理搜索前，必须先阅读：
references/references-search-strategies.mdreferences/references-old-encoding-search-site.md
尤其要先判断当前站点属于：
- 原生搜索接口
- suggest / 联想搜索 fallback
- RSS fallback
强约束
不要在没有完成这一步判断前，就直接拍脑袋写 searchUrl，也不要随手决定使用 suggest / RSS。
新增经验：评估搜索时不要机械沿用默认词
在新建源或初步验证阶段，如果 evaluate_spider_source 仅搜索失败，而首页 / 一级 / 二级 / 播放已正常，不要立刻回头重写搜索规则。
应优先判断是不是评估词不适配当前站点。evaluate_spider_source 的搜索词由 keyword 参数决定；若不传，默认词常为 斗罗大陆，这并不适用于所有垂类站。
正确动作
优先主动传入更高频、更宽匹配、且更贴合站型的词进行验证，例如：
- 通用宽匹配词：
我的
- 动漫站高频词：
异世界、转生
- 或直接取首页 / 一级真实
vod_name 的稳定片段
判定原则
如果换词后搜索恢复正常，应优先判定为评估参数问题，而不是直接把责任归到 searchUrl / 搜索 规则上。
新增强规则：看到 * 先按“对齐一级”理解，再决定要不要覆盖
当模板字段中出现：
搜索: '*'推荐: '*'推荐: '.xxx;*;*;*;*;*'- 其他含多个
* 的模板摘要写法
必须先阅读：
references/references-template-summary.md
强约束
不要在没有理解 * 的源码级行为前，就把它机械改写成完整手写规则。
当前应采用的理解
- 单个
*：整体继承一级
- 多个
*：按分号位置逐位继承一级对应槽位
新增重点：模板继承核查清单（强制执行）
当站点明显命中模板时，不要一上来就手写 一级/搜索/推荐/二级。必须先完成这份核查清单。
核查顺序
class_parse 是否残留并覆盖 class_name/class_urldouble 是否导致首页推荐为空url 是否是真实分类模板，而不是首页导航表层链接searchUrl 是否是真实搜索模板- 首页推荐节点是否真实存在
- 分类页第 1 / 2 页翻页结构是否真实匹配
fyclass/fypage
- 在必要时先删除手写
一级/搜索，优先验证模板内置规则
一条强规则：模板内置优先
禁止事项
当模板站未完成模板继承核查前，禁止一上来就大面积手写：
正确顺序
优先顺序应为：
- 先修模板继承残留项
- 先确认真实
url/searchUrl
- 先验证模板内置链路
- 只有模板内置规则确认不通，才允许最小覆盖
新增强规则：尊重 parser 真实语法边界
|| 的推荐用法
|| 应优先用于同一 selector 下的属性 fallback，例如：
img&&data-original||src
a&&data-original||src
不推荐写法
不要默认生成这种“完整双规则 fallback”：
img&&data-original||img&&src
除非已经明确验证当前 parser / engine 显式支持。
原因
这类写法看起来合理，但可能超出当前 htmlParser.js 的稳定支持边界，导致：
- category 接口报错
- debug 与引擎行为看似不一致
- 自动评估串联失败
处理原则
在生成字符串型规则时：
- 优先生成 parser 已明确支持的规范写法
- 不要因为“语义上看起来合理”就假定引擎已支持
- 如果对 parser 边界没有把握，优先写更保守、可验证的规则
新增经验：detail 不通先查 detailUrl
如果继承模板站的二级字典看起来合理，但 detail 测试传纯数字 ID 时仍返回模板兜底值，应优先检查：
detailUrl
很多模板站 detail 真正失败的根因不是二级字典错误，而是引擎无法把纯数字 ID 映射成详情页 URL。
新增经验：搜索为空时优先判断搜索页是否独立于一级 DOM
搜索结果为空时，要优先确认搜索页是否使用独立 DOM（如 .searchlist_item），不要默认 搜索: '*' 或一级列表结构可以直接复用。
新增经验：一级 async 优先用引擎上下文变量，不要先拆 URL
当 一级: async function () {} 需要处理分类和页码时，优先直接使用：
this.MY_CATEthis.MY_PAGE
不要先从 input 或 MY_URL 做正则拆参，除非引擎上下文确实未提供。
新增经验：request/post 是全局函数，不在 this 上
在 drpy async function 中：
request / post 应直接全局调用- 不要写成
let { request } = this
5. 当页面真实有多集但 vod_play_url 只吐出 1 集时，先检查 lists 容器层级
不要看到详情页真实能抓到多个 <a>，就立刻否定二级字典方式或切到 async。应优先检查：
lists 是否落在了适合引擎逐项消费的容器层级#id 是否仅用于线路容器替换，而不是被误理解为控制单线路集数
已验证案例：咕咕番
对于这类“一级异步接口 + 详情页直出资源列表”的动漫站，页面上：
.anthology-list-box:eq(0) .anthology-list-play 可抓到 1 个 ul.anthology-list-box:eq(0) .anthology-list-play a 可抓到 2 个 a.anthology-list-box:eq(0) .anthology-list-play li 可抓到 2 个 li
但在 drpy 引擎的二级字典模式下，要稳定吐出多集，最终应优先尝试：
lists: '.anthology-list-box:eq(#id) .anthology-list-play li',
list_text: 'a&&Text',
list_url: 'a&&href'
判定原则
#id 的主要作用是“线路容器替换定位”- 真正影响该站多集展开成功与否的关键，往往是
lists 落在 li 项层，而不是 ul 容器层
- 因此：先调
lists 容器层级，再考虑放弃字典或切 async
1. 二级字典字段不是随意拼接，; 有固定槽位语义
默认应按 drpy-node 引擎契约理解：
title: '片名;类型'img: '封面图规则'desc: '备注;年份;地区;演员;导演'content: '简介规则'tabs: '线路节点选择器'tab_text: '线路名提取规则'lists: '当前线路的选集列表选择器，支持 #id / #idv'list_text: '每一集标题提取规则'（默认 body&&Text）list_url: '每一集链接提取规则'（默认 a&&href）
2. 调试 detail 时，必须使用一级真实返回的 vod_id
禁止在 detail 测试时主观把 vod_id 简化成纯数字 id、短 id 或手工猜测的详情 id。
必须遵守：
- 先跑
category
- 复制一级真实返回的
vod_id
- 用这个
vod_id 去测 detail
3. 二级默认遵循最小化原则
默认优先保证以下信息可用即可：
只有在用户明确要求，或先征询用户是否需要补全时，才继续完善：
4. 先让 detail 真通，再进入播放链排障
如果 detail 还没有稳定产出：
vod_play_fromvod_play_url
就不要急着把问题归因为 lazy / play 链路。应先回头检查：
- 二级字典契约是否写对
tabs/lists/tab_text/list_text/list_url 是否匹配- detail 测试用的
vod_id 是否来自一级真实返回
1. 模板残留 class_parse 会压住 class_name/class_url
如果继承模板后准备使用：
class_name: '电影&电视剧',
class_url: '1&2'
则必须检查模板是否自带 class_parse。
若模板残留的 class_parse 仍在生效，可能导致首页 class 为空，自动评估拿不到分类 ID。
处理原则
优先显式补：
class_parse: ''
让 class_name/class_url 真正接管。
2. 首页推荐为空时，要检查 double
如果首页真实存在推荐卡片节点，但 home.list 仍为空，要考虑模板默认推荐可能按双层定位处理。
对于实际是单层推荐结构的站点，应优先尝试：
double: false
处理原则
- 真实推荐是单层 → 优先
double:false
- 真实推荐是分组+分组内卡片 → 再考虑双层
3. 分类 url 不能只看首页导航表面链接
不要看到首页导航是 /list/1.html，就直接推断 url 模板是 /list/fyclass_fypage.html。
必须验证：
- 分类页真实地址
- 翻页第 2 页地址
fyclass 与 fypage 的真实落位
已验证经验
有些站首页导航是 /list/1.html，但真正可用的分类模板可能是：
/top/fyclass--------fypage---.html
另一些站则可能是：
/index.php/vod/type/id/fyclass/page/fypage.html
所以：
分类 url 必须通过真实网页和翻页结构验证，不可只靠表层导航推断。
4. 要区分“规则不通”与“自动评估串联没接上”
如果 evaluate_spider_source 结果很差，不要立刻断言整份源不可用。
应优先用：
test_spider_interface(category)test_spider_interface(detail)test_spider_interface(play)
分别验证单接口是否真实可用。
处理原则
- 如果单接口通，但自动评估不通 → 优先怀疑自动串联条件（如首页 class、模板残留覆盖、
double、错误分类 URL）
- 不要把“评估器没串起来”误判成“规则完全不通”
