Feapder
Overview
Implement feapder 1.9.2 code in the style expected by the framework's own docs, templates, and tests. Choose the right spider base class first, then follow the matching startup, request, parse, persistence, and debugging patterns.
Workflow Decision Tree
- 1. Classify the request before writing code:
- Use
AirSpider for small, local, non-distributed jobs.
- Use
Spider for Redis-backed distributed crawling, resumable queues, and automatic item persistence.
- Use
TaskSpider when seeds come from MySQL or Redis task tables and the framework should manage seed loading.
- Use
BatchSpider for periodic batches with batch records and explicit task-state transitions.
- 2. Read only the reference file that matches the task:
- Spider selection, CLI scaffolding, and project layout:
references/spider-types-and-scaffolding.md
- Code patterns for request flow, items, task updates, and render usage:
references/code-patterns.md
- Settings, pipelines, shell debugging, and upstream source anchors:
references/settings-debugging-and-sources.md
- 3. Reuse feapder conventions instead of inventing abstractions:
- Import
feapder directly and subclass the correct base spider.
- Emit work with
yield feapder.Request(...).
- Keep parsing in
parse or explicit callback methods passed through
callback=....
- Prefer
__custom_setting__ for spider-local overrides and
setting.py for project-wide config.
- Default to
from feapder.utils.log import log and
log.info(...) for runtime logs instead of
print(...) unless the user explicitly asks to mirror upstream demo output.
- Default to concise Chinese log messages and Chinese code comments when comments are needed.
- 4. If the user asks to create new feapder code, prefer the framework's generated structure and naming conventions over bespoke layouts.
- If the user asks for a simple crawler demo and does not mention persistence,
Item, UpdateItem, pipeline wiring, Redis, MySQL, task tables, batch scheduling, distributed workers, or multi-file output, default to the single-file AirSpider style shown in references/vendor/feapder-1.9.2/tests/air-spider/testair_spider.py: one file, one spider class, minimal startup block, and only the code required to demonstrate the requested behavior.
Working Rules
- - Keep output aligned with feapder 1.9.2, not newer community variants.
- Prefer minimal, working spider code over framework-agnostic architecture.
- When the request is underspecified, do not scaffold a full feapder project by default. Write the smallest single-file
AirSpider demo only for pure crawling or parsing requests. If the request mentions Item, UpdateItem, 入库, ITEM_PIPELINES, Redis, MySQL, task tables, or batch/task state, choose the corresponding spider and project shape instead. - When modifying an existing feapder project, preserve its current spider type,
main.py dispatch style, item modules, and setting.py shape unless the user asks for a migration. - When persistence is needed, decide explicitly between:
- Manual DB calls with
MysqlDB or
RedisDB
- Automatic batch persistence via
Item or
UpdateItem
- Custom
ITEM_PIPELINES
- - When render is required, set
render=True on the request and then align downloader configuration with the project's setting.py or __custom_setting__. - When handling
BatchSpider or TaskSpider, treat master and worker entrypoints separately. Do not collapse them into a single ambiguous startup path. - When writing new spider code, default to
log.info(...), log.error(...), and similar logger methods for runtime output. Avoid print(...) unless the user explicitly asks for raw console prints or exact upstream reproduction. - Write log messages in Chinese by default, for example
log.info(f"第{request.page}页原始结果 | {response.json}"). - Write comments in Chinese by default and only keep comments that clarify non-obvious logic.
Chinese Trigger Hints
Treat these Chinese requests as strong signals to use this skill:
- - INLINECODE36
- INLINECODE37
- INLINECODE38
- INLINECODE39
- INLINECODE40
- INLINECODE41
Implementation Checklist
Before finishing a feapder task, verify the code against this checklist:
- - The spider inherits the correct feapder base class.
- If the task is a pure crawling or parsing demo and does not require persistence or task orchestration, the new spider defaults to the single-file
AirSpider pattern anchored by references/vendor/feapder-1.9.2/tests/air-spider/test_air_spider.py. - Startup code passes the required constructor args such as
redis_key, task_table, task_keys, or batch metadata when needed. - Request callbacks, carried parameters, and middleware hooks use feapder's expected method signatures.
- Distributed spiders update task state where required instead of relying on implicit completion.
- Item, pipeline, and setting references match the project's existing module layout.
- Debugging guidance uses feapder-native tools such as
feapder shell, to_DebugSpider, or to_DebugBatchSpider when appropriate. - New example code uses
log for runtime logs, with Chinese log text and Chinese comments unless the user requested a different style.
Source Anchors
Use the vendored feapder 1.9.2 snapshot under references/vendor/ as the source of truth. This keeps the skill portable when copied to another machine:
技能名称: feapder
详细描述:
Feapder
概述
按照框架自身文档、模板和测试所期望的风格实现 feapder 1.9.2 代码。首先选择合适的爬虫基类，然后遵循匹配的启动、请求、解析、持久化和调试模式。
工作流决策树
- 1. 在编写代码前对请求进行分类：
- 对于小型、本地、非分布式任务，使用 AirSpider。
- 对于基于 Redis 的分布式爬取、可恢复队列和自动条目持久化，使用 Spider。
- 当种子来自 MySQL 或 Redis 任务表且框架应管理种子加载时，使用 TaskSpider。
- 对于具有批次记录和显式任务状态转换的周期性批次，使用 BatchSpider。
- 2. 仅读取与任务匹配的参考文件：
- 爬虫选择、CLI 脚手架和项目布局：
references/spider-types-and-scaffolding.md
- 请求流、条目、任务更新和渲染使用的代码模式：
references/code-patterns.md
- 设置、管道、Shell 调试和上游源锚点：
references/settings-debugging-and-sources.md
- 3. 复用 feapder 约定而非自行发明抽象：
- 直接导入 feapder 并继承正确的爬虫基类。
- 使用 yield feapder.Request(...) 发出工作请求。
- 将解析逻辑放在 parse 方法或通过 callback=... 传递的显式回调方法中。
- 优先使用
custom_setting 进行爬虫本地覆盖，使用 setting.py 进行项目级配置。
- 默认使用 from feapder.utils.log import log 和 log.info(...) 进行运行时日志记录，而非 print(...)，除非用户明确要求镜像上游演示输出。
- 默认使用简洁的中文日志消息，并在需要注释时使用中文代码注释。
- 4. 如果用户要求创建新的 feapder 代码，优先使用框架生成的结构和命名约定，而非自定义布局。
- 如果用户要求简单的爬虫演示且未提及持久化、Item、UpdateItem、管道连接、Redis、MySQL、任务表、批次调度、分布式工作节点或多文件输出，则默认使用 references/vendor/feapder-1.9.2/tests/air-spider/testair_spider.py 中展示的单文件 AirSpider 风格：一个文件、一个爬虫类、最小的启动代码块，以及仅演示所请求行为所需的代码。
工作规则
- - 保持输出与 feapder 1.9.2 一致，而非更新的社区变体。
- 优先使用最小可运行的爬虫代码，而非与框架无关的架构。
- 当请求说明不足时，默认不搭建完整的 feapder 项目。仅针对纯爬取或解析请求编写最小的单文件 AirSpider 演示。如果请求提及 Item、UpdateItem、入库、ITEM_PIPELINES、Redis、MySQL、任务表或批次/任务状态，则选择相应的爬虫和项目形态。
- 修改现有 feapder 项目时，保留其当前的爬虫类型、main.py 调度风格、条目模块和 setting.py 形态，除非用户要求迁移。
- 当需要持久化时，明确在以下方式中选择：
- 使用 MysqlDB 或 RedisDB 手动调用数据库
- 通过 Item 或 UpdateItem 自动批量持久化
- 自定义 ITEM_PIPELINES
- - 当需要渲染时，在请求上设置 render=True，然后将下载器配置与项目的 setting.py 或 custom_setting 对齐。
- 处理 BatchSpider 或 TaskSpider 时，分别对待主节点和工作节点的入口点。不要将它们合并为单个模糊的启动路径。
- 编写新的爬虫代码时，默认使用 log.info(...)、log.error(...) 等日志方法进行运行时输出。避免使用 print(...)，除非用户明确要求原始控制台打印或精确复现上游输出。
- 默认使用中文编写日志消息，例如 log.info(f第{request.page}页原始结果 | {response.json})。
- 默认使用中文编写注释，仅保留用于澄清非明显逻辑的注释。
中文触发提示
将以下中文请求视为使用此技能的强烈信号：
- - 用 feapder 写一个爬虫
- 帮我改这个 AirSpider
- 把这个项目迁移到 Spider 或 BatchSpider
- 写 feapder 的 item / pipeline / setting.py
- 用 feapder shell 调试
- 分析 feapder 1.9.2 示例代码
实现检查清单
在完成 feapder 任务前，对照此清单验证代码：
- - 爬虫继承了正确的 feapder 基类。
- 如果任务是纯爬取或解析演示且不需要持久化或任务编排，新爬虫默认使用由 references/vendor/feapder-1.9.2/tests/air-spider/testairspider.py 锚定的单文件 AirSpider 模式。
- 启动代码在需要时传递所需的构造函数参数，如 rediskey、tasktable、taskkeys 或批次元数据。
- 请求回调、携带参数和中间件钩子使用 feapder 期望的方法签名。
- 分布式爬虫在需要时更新任务状态，而非依赖隐式完成。
- 条目、管道和设置引用与项目现有的模块布局匹配。
- 调试指导在适当时使用 feapder 原生工具，如 feapder shell、toDebugSpider 或 to_DebugBatchSpider。
- 新的示例代码使用 log 进行运行时日志记录，日志文本和注释使用中文，除非用户要求不同风格。
源锚点
使用 references/vendor/ 下提供的 feapder 1.9.2 快照作为事实来源。这使技能在复制到另一台机器时保持可移植性：
