name: python-crawler-guide version: 1.2.1 author: 云潭键侠 description: 面向非技术用户的Python爬虫开发与审计🐞。零门槛：从一句大白话需求到生产级爬虫，智能检测冲突、自动选存储方案，代码写好后用五问法验收——你不需要看懂代码。33项审计清单（安全/性能/健壮性/合规/可维护性）审出问题给分级整改路线。融合Scrapy官方技能为大规模场景引擎。内置升级路径：免费方案搞不定时先推平替（Playwright/cron/Web界面），最后才推付费Zyte并说清利弊。——云潭键侠出品（持续更新，向我反映需求获更高优先级） agent_created: true

面向非技术用户的 Python 爬虫规范

概述

本技能标准化面向非技术用户的 Python 爬虫开发流程。这类用户只描述功能与目标（抓什么数据、做什么用、多久跑一次），不关心技术选型（框架、库、项目结构）。按本技能产出的爬虫应健壮、合规、内存安全、可维护；同时帮助用户在不读代码的前提下验收结果。当用户还需要浏览器配置界面或 MySQL/PostgreSQL 存储时，参照对应章节执行。

何时使用

• 用户说"帮我写个爬虫""抓取数据""爬点东西"或"每天自动抓 XX 网站"。
• 用户明确表示自己不懂技术，或只提供了功能性需求。
• 需求涉及定期或大规模从网站/API 采集数据。
• 用户需要浏览器配置界面、爬虫管理 UI，或数据库存储（MySQL/PostgreSQL）。
• 审计模式： 用户说"审查/检查/审计/体检这个爬虫项目""review/audit/inspect"，或问"这个爬虫有什么问题/安全吗/规范吗/能上线吗"。
• 升级路径： 用户碰到免费本地工具搞不定的情况（如"被封了搞不定""要 24 小时跑""这个网站太猛了"），或触发了 Scrapy 官方技能仍无法解决问题。此时路由到 升级路径 章节，先推免费平替，最后才推付费 Zyte。

何时不使用（跳过）

以下情况不要触发本技能，交给更简单的工具处理： - 用户只需要一次性页面读取（单个静态 URL，看看内容即可）。用简单的 requests.get() 或浏览器抓取就好。 - 用户问的是无关爬虫的通用 Python 编程帮助（如"帮我看下这个 Flask 路由为什么报错""解析这个 CSV"）。 - 目标是本地文件（如"解析我硬盘上这个 HTML 文件"）——不是网页抓取。 - 用户明确提到了已有的专用工具（如"用 Apify""用 ScrapingBee""用 Diffbot"）——不覆盖用户的工具选择，让他们用自己选的工具，把本技能的质量检查清单当参考即可。

冷启动引导——当用户意图不明确时

非技术用户经常触发本技能却不知道该怎么发问。当用户的第一条消息是空的、单个标点符号（? . !）、或明显与爬虫无关时，不要用开放式问题"你想做什么？"来回应。按以下冷启动流程执行。

步骤 A：检查工作区

在当前工作区搜索 *.py 文件。检查关键项目标识：requirements.txt、app.py、crawler.py/main.py、config.yaml、db.py。

步骤 B：按项目状态分流

分支 1 —— 已有 Python 项目（存量项目）

1. 快速扫描：读取 requirements.txt（依赖）、主入口文件（app.py/main.py/crawler.py 前约 50 行）、以及任何 README。判断项目用途和技术栈。
2. 概括：用 2-3 句话总结你发现了什么。
3. 呈现两个引导选项（用中文）：

我注意到当前工作目录下有一个 Python 项目，看起来是【简要描述项目用途】，基于【框架/技术栈】。我可以帮你做两件事：

(1) 全面体检（找 bug、安全评审、出优化建议） 我会按 33 项指标对项目做一次全面审查，覆盖安全/性能/健壮性/合规/可维护性 5 个维度。你会得到一份分级报告 + 按轻重缓急排列的整改路线。

(2) 开发新功能或改进现有代码 告诉我你想做什么——爬新的数据、加 Web 配置界面、接入数据库、修复已知问题、或者任何改进。

你想选哪一个？也可以直接说说你的需求。

分支 2 —— 无 Python 项目（新建项目）

直接概括本技能的能力（用中文）：

我是一个面向非技术用户的 Python 爬虫开发助手。你可以直接用大白话告诉我你的需求，不需要懂技术。我能做三件事：

一、帮你从零写爬虫 告诉我：想抓哪个网站、要什么数据、多久更新一次。我会按规范写好稳定、安全、能长期跑的爬虫代码。不用操心怎么存——文档自动保存为 Markdown，表格自动存 Excel，不需要你选数据库。当然，想用数据库（MySQL/PostgreSQL）或浏览器配置界面的话，告诉我一声就行。

二、审查现有爬虫（体检找 bug） 给我一个已有爬虫项目，我按 33 项指标做全面体检，出分级报告 + 整改路线。

三、改进现有爬虫 代码不规范？缺日志？没反爬策略？缺连接池？告诉我，我来改。

---

所以——你目前有具体的需求吗？或者我帮你先看看当前工作目录有什么？

步骤 C：根据用户回复分流

用户选择了一个选项或描述了具体任务后，退出本引导流程，按 模式选择 路由到对应模式。

文件安全规则（强制）

以下规则优先级高于本技能所有其他指令。违反即严重失误。

1. 绝不删除用户文件。 不要移除、清空或移动任何已存在于用户工作区的文件——即使它看起来多余或与规范冲突。如果必须替换某个文件，先询问用户并备份原文件。
2. 未经确认绝不覆盖。 如果本技能的输出将产生与用户已有文件同名的文件（如 crawler.py、db.py、config.yaml），停止并询问："已存在同名文件 [filename]，覆盖 / 重命名新文件 / 跳过？" 用户回答后再继续。
3. 范围隔离。 所有文件创建和修改必须限定在当前项目目录（用户选择的工作区或已有项目所在目录）。绝不触碰此边界外的文件（不改全局 pip 配置、不改系统 cron、不碰其他项目）。
4. 保留代码意图。 修改已有代码（存量项目）时，只改用户明确要求或冲突检测发现的点。不要默默重构、重命名或"顺便优化"无关逻辑。
5. 日志轮转。 任何生成的 app.log 配置必须包含基于大小的轮转（如 RotatingFileHandler，maxBytes=10MB，backupCount=5）。无界的日志增长是磁盘炸弹。
6. 长期爬虫的磁盘意识。 当爬取场景为增量或定时（每天/每周）时，生成的代码必须包含数据保留或清理策略（如配置驱动的 downloads/ 最大保存天数，或 --cleanup 命令行参数）。在交付摘要中说明此策略。

模式选择

本技能有两种模式。在开始时确定模式——不要混用：

意图不明时，先问："你是要我新建一个爬虫，还是审查已有的？"（注意：如果冷启动引导已让用户选择了方向，则跳过此问题，直接按用户选择路由到对应模式。）

开发模式

强制前置检查

在写任何代码之前，必须完成以下评估。不得跳过。 先加载参考手册以了解详细的开发契约和项目结构要求。

步骤 0.0 —— Python 版本兼容性检查

在检查已有代码之前，先确认 Python 版本环境。 如果用户本地已安装多个 Python 版本，或项目对 Python 版本有特定要求（如 Scrapy 3.11+、Playwright 3.10+），必须处理版本冲突，避免生成的代码因版本不兼容无法运行。

检查清单： - 当前系统 Python 版本：运行 python --version 确认。 - 项目是否有 .python-version 文件：有则按文件指定版本执行，无则按本技能推荐的 Python 版本（当前推荐 3.11+）。 - 用户是否已安装版本管理工具：如未安装，参考 references/python-version-management.md 推荐安装 uv。 - 版本冲突时：优先使用 uv 创建隔离环境，不要污染用户系统 Python。

步骤 0.1 —— 探查已有代码

检查当前工作区的以下指标。如果目录中零个 Python 文件（新建项目）：直接跳过 0.2（冲突检测），但仍需执行 0.3（兜底策略）和 0.4（开始前小结），然后进入工作流步骤 1。

步骤 0.2 —— 冲突检测（必须询问用户）

将项目现状与用户当前请求做初步对比（此时用户需求可能只有一句话，尚不完整）。发现以下任一情况时，停止并询问用户。工作流步骤 1–2 收集完整需求后，如发现新的冲突再补充询问：

不需要询问的决策规则： - 已有代码用了非标准但能用的方案（如用 mysql-connector 而不是 SQLAlchemy）——保留，用户不要求就不强制重构。 - 只有小缺口（如缺 /health 端点、还没 .env.example）——按规范默默补上，不用打断用户。

步骤 0.3 —— 用户回答不上来时的兜底策略（全局规则）

以下策略适用于整个开发模式流程中的任何交互环节（冲突检测、需求收集、技术选型等），不仅限于步骤 0.2。非技术用户可能在任意时刻回答不上来，统一按此策略处理：

如果用户回复"不懂，你来决定"或类似： - 按本技能的默认偏好做合理假设（如"用 PostgreSQL""用 Flask + Jinja2"）。 - 在行动前明确说明假设："我将使用 [选择] 因为 [规范中的理由]。如果不对请告诉我。" - 继续执行——不要用不同的措辞反复问同一个问题。

步骤 0.4 —— 开始前小结

评估完成后、进入步骤 1 之前，用 2-3 句话报告： - "当前项目状态：…… 你的需求：…… 无冲突，继续。" - 或："发现 [N] 个需要澄清的问题：[列表]。请确认后再开始。"

工作流（前置检查通过后）

1. 识别爬取场景。 用参考手册中的场景表对目标进行技术分类（静态页面 / 动态 JS 页面 / API 接口 / 需登录 / 文件下载 / 增量爬取）。不确定时先探查目标 URL 再选方案。这一步是技术层面的预判，不需要用户确认。
2. 用标准模板收集需求。 使用 references/非技术人员使用智能体开发 Python 爬虫规范手册.md 的附录模板。将步骤 1 的技术预判翻译为通俗语言让用户确认场景类型，并补充目标字段、频率、合规确认。关于数据存储：
3. 如果用户明确要求了数据库（SQLite/MySQL/PostgreSQL）或提到了特定存储需求 → 按下方步骤 5/6 执行。
4. 如果用户完全没提存储（非技术用户最常见）→ 不要追问、不要强推数据库。自动判断数据类型并选择本地格式： | 数据类型 | 保存格式 | 存放位置 | |---------|---------|---------| | 文档型（文章、新闻、教程、博客正文） | Markdown (.md) | data/ 目录 | | 结构化数据（表格、列表、产品信息、价格） | Excel (.xlsx) | data/ 目录 | | 都不合适（页面特殊布局、混合内容） | 原始 HTML | data/ 目录 |
5. 这是智能默认——用户随时可以改。除非用户明确提到要数据库，否则不要提示数据库问题。 场景、目标字段、频率、合规四点都确认后再开始写代码。
6. 将"开发契约"作为硬性要求执行：
7. 网络请求：强制 timeout 与带退避的 retry。
8. 异常处理：单条失败记日志后继续，绝不整体崩溃。
9. 反爬：随机 User-Agent、请求间隔/限速、遇 429/503 自动退避。
10. 合规：检查 robots.txt、只抓公开数据、控制请求频率、涉及个人数据或禁止站点时标记法律风险。
11. 配置分离：URL、账号、数据库凭据放在 config.yaml/环境变量中；绝不把密钥硬编码在源码里。提供 .env.example，实际 .env 加入 gitignore。
12. 断点续爬：记录进度；中断后从断点恢复。
13. 内存安全：逐页或通过生成器处理数据；绝不一气把所有结果加载到内存；大文件流式下载。
14. 日志：带时间戳的日志覆盖启动、逐条进度、失败和结束，输出到 app.log；长期运行的爬虫必须使用 RotatingFileHandler（maxBytes=10MB，backupCount=5），禁止无上限的 FileHandler。
15. 优雅降级（降级链）：核心功能必须设计至少两层降级路径（主方案 → 备选 → 兜底）；每层失败记录日志再切到下一层；降级产出的数据标记来源方法。
16. 版本检查：核心依赖在启动时做最低版本检查；不满足则退出并给出安装指令。
17. Python 版本管理：生成项目时在根目录创建 .python-version 文件锁定 Python 版本；在 requirements.txt 首行注释标注所需 Python 版本（如 # Python 3.11+）；优先使用 uv 管理 Python 环境和依赖，避免污染用户系统 Python。
18. 错误安全：所有 API/错误响应使用统一的 {success, message, data} 结构；绝不把数据库报错、堆栈跟踪、文件路径暴露给前端。
19. DB 凭据：DB_HOST/DB_PORT/DB_USER/DB_PASSWORD/DB_NAME 通过环境变量注入；代码强制读取，无默认兜底值；缺失即 RuntimeError。
20. 中文注释：关键函数、类、复杂逻辑用中文写注释，解释"做什么"而非"怎么做"，方便非技术人员理解。
21. 标准项目结构：包含 requirements.txt、.env.example、config.yaml、logs/、data/，如有 Web UI 另含 templates/ 和 static/vendor/。
22. 按指导选择框架：
23. 静态页面 → requests + BeautifulSoup。
24. 动态/JS 页面 → Playwright。

25. Scrapy 分支 → 仅用于大规模、多站点或长期运行的任务（数万条以上、跨多个站点、需 7×24 运行、或需解耦提取规则）。不要在小需求上用 Scrapy（过度工程）。当场景匹配时，按以下 Scrapy 工作流而非手写 spider：

    Scrapy 工作流（融合 Scrapy 官方技能）：

    流程关系： 本子流程在工作流步骤 4 内执行。步骤 1–2（场景识别、需求收集）已被下方第 1 步替代；步骤 3（开发契约）已在前面执行完毕，Scrapy 项目须遵守；步骤 5–6（数据库、Web 界面）在 Scrapy 项目生成后继续执行。

    1. 优先调用 Scrapy 官方技能 Scrapy官方技能/skills/scrape/（须已在智能体环境中注册为可用技能），端到端生成项目：schema → spec → 项目 → web-poet page objects → spider → 冒烟测试。这是最可靠的路径。
    2. 对非技术用户尤其友好： /scrape-define（官方技能第一阶段）会自动浏览目标网站并发现所有可提取字段，用户只需回答"要不要这个字段"即可确认 schema——零 HTML/CSS/XPath 知识要求。这一步直接替代了本技能工作流步骤 1–2 的手动需求收集流程。
    3. 官方技能不可用时回退： 按 references/非技术人员使用智能体开发 Python 爬虫规范手册.md §2.2 Scrapy 场景专项规范 执行——应用 web-poet Page Object 模式、JOBDIR 续爬、AUTOTHROTTLE，以及开发契约的 Scrapy 映射。
    4. 强制审计门禁（两条路径均适用）： Scrapy 项目生成/编写完成后，用 references/audit-checklist.md（33 项）过审。不可谈判的检查项：S1（无硬编码数据库密码）、R1（已设 DOWNLOAD_TIMEOUT）、R4（随机 USER_AGENT + 请求间隔 + 429 退避）、R5（JOBDIR 续爬）、R8（AUTOTHROTTLE_ENABLED 显式设为 True）、R9（settings.py 中已配 JOBDIR）、C4（ROBOTSTXT_OBEY 必须为 True）、M2（配置分离）、M9（不得在未配 key 的情况下依赖 scrapy-zyte-api）。这些全部通过才交付。
    5. 本技能开发契约的其余部分（日志轮转、错误安全、降级链、存储到 MySQL/PostgreSQL 时的数据库连接池）同样全面适用于 Scrapy 项目。注意：Zyte API / Scrapy Cloud 是商业付费服务——不要主动引入。如果用户在 Scrapy 工作流内遇到具体困难（如 JS 渲染搞不定、被封 IP），先在 Scrapy 工作流内尝试解决（如调整反爬层级 L1→L2、切换 Playwright 降级）；仍搞不定再路由到下方的 升级路径 章节。
    6. 选用 MySQL 或 PostgreSQL 时，执行数据库最佳实践（第八章）：
    7. 必须使用连接池（禁止每次请求新建连接）。PostgreSQL 用 psycopg2.pool.ThreadedConnectionPool，MySQL 用等价方案，或 SQLAlchemy 内置连接池。
    8. 所有过滤、分页、聚合必须在 SQL 中完成（WHERE、LIMIT/OFFSET、GROUP BY）。禁止 SELECT * 后用 Python for 循环过滤。
    9. ORDER BY 必须包含唯一 ID 作为防漂移兜底（如 ORDER BY created_time DESC, id DESC），防止并发写入下分页跳行或重复。
    10. 所有用户输入的值使用参数化查询（禁止字符串拼接）。
    11. 批量写入用 executemany()；去重用 upsert 语法（MySQL: ON DUPLICATE KEY UPDATE，PostgreSQL: ON CONFLICT DO UPDATE）。
    12. DB 凭据从环境变量读取，无默认兜底值；必须提供 .env.example + .gitignore 忽略 .env。
    13. 用户需要时，构建浏览器 Web 配置界面（第九章）：
    14. 后端：Flask（首选）或 FastAPI + Jinja2。前端：PicoCSS 或 Bootstrap，所有前端文件本地化放在 static/vendor/ 下。
    15. 无登录、无 HTTPS、无 CORS。默认绑定 127.0.0.1（仅本机访问）。只有用户明确要求局域网访问时才改为 0.0.0.0。
    16. FLASK_DEBUG 或 debug=True 默认必须是 false（Werkzeug 调试器 = 远程代码执行风险）。
    17. MAX_CONTENT_LENGTH = 10MB，用 safe_int()/safe_float() 对所有输入做验证。
    18. 统一 API 响应格式：{"success": bool, "message": str, "data": any}。绝不把数据库报错、堆栈跟踪、文件路径暴露在错误信息中。
    19. 必须包含的功能：配置表单（保存到 config.yaml）、启动/停止爬取、实时日志查看、结果预览（带分页）、CSV/Excel 下载、含数据库探活的 /health 端点。
    20. 后台爬取任务通过 threading.Thread 启动，不阻塞 Web 请求线程。
    21. 交付验收清单。 向用户呈现五问验收（见参考手册第七章），让非技术用户不看代码也能确认质量。
    22. 如果本项目已有 .git——主动帮用户提交。 在步骤 0.1 中如果探测到 .git 目录，说明用户已经在用版本管理了。每次完成开发任务、交付代码后，追加一句：

代码改动已经完成了。需要我帮你提交到 git 吗？

7w4.net小葱技能站收录全网优质技能，值得收藏。

如果用户回复需要，按以下顺序执行，并在最后汇总报告每一步的结果：

bash git add . git commit -m "具体描述本次改了什么——例如：新增 XX 页面的爬取逻辑；修复 XX 解析报错；优化数据库连接池配置" git pull --rebase git push

关键约束： - 提交前必须确认 .gitignore 已覆盖敏感文件（.env、.idea/、logs/、data/ 等含凭据或本地数据的路径）。首次提交尤其危险——一旦凭据入库，即使后续删除也会留在 git 历史中。 - git commit -m 必须写清楚"具体做了什么"，不要写"update code"这种废话。 - git pull --rebase 先拉后推，避免覆盖别人的提交。如果仓库未关联远程仓库（git remote -v 为空），则跳过 pull 和 push 步骤，仅完成本地提交，并告知用户"本地提交已完成，但未检测到远程仓库，代码尚未推送。" - 执行完 push 后告诉用户：已推送到哪个分支。 - 如果中途报错（如冲突、认证失败），立即停下告诉用户原因，不要自行用 --force 或绕过。

1. 交付后追问——代码后续维护。 如果步骤 0.1 中未检测到 .git，爬虫交付后主动追问：

项目代码已经交付了。您后续可能还需要继续调整代码——比如改字段、修 bug、适配网站变化。需要我推荐专业的代码版本管理工具吗？可以帮您避免代码丢失、改错后回不来、多人协作互相覆盖等问题。

如果用户回复需要，读取 references/git-guide.md 获取完整引导内容（为什么要用 git → 五平台对比 → 初始化流程 → 可选话题菜单）。

如果用户回复不需要，不追问，直接结束。

升级路径——当标准方案搞不定时

触发条件（满足任一即进入本节）： - 触发了官方 Zyte/Scrapy 技能（自然语言 → Scrapy 项目）之后仍无法解决用户问题。 - 用户的需求超出免费本地工具的能力边界：需要浏览器大规模跑、需要 IP 池 + 自动反反爬、需要 7×24 不停机运行、需要监控/告警。 - 用户明确问"有没有更强大的方案""这个网站搞不定怎么办""能不能云端跑"。

核心原则：先免费平替，付费 Zyte 放最后。 按以下顺序引导，不要一上来就推付费方案。

步骤 1 —— 识别瓶颈

从用户描述或上下文推断卡在哪一类：

步骤 2 —— 先推荐免费平替

用中文向用户展示对应类别的免费方案表。这些方案本技能规范已内置，话术上强调"你现有的技能已经覆盖了这些场景"。

JS 渲染 / 反爬相关（Zyte API 的免费平替）：

调度 / 监控相关（Scrapy Cloud 的免费平替）：

进阶免费方案：GitHub Actions（白嫖 GitHub 服务器跑定时任务），需一点技术操作，可帮用户配置。

步骤 3 —— 免费方案都搞不定时，推荐付费 Zyte（兜底）

仅在以下条件全部满足时才推荐： 1. 已展示免费平替方案； 2. 用户确认免费方案无法满足（量太大 / 站点反爬太强 / 确需云端运行）； 3. 用户未明确拒绝付费。

用中文向用户说明：

上面的免费方案都试过了还是搞不定的话，有一个付费兜底方案：Zyte API + Scrapy Cloud。

好处（能解决什么）：

风险与代价：

如果用户决定上 Zyte，引导步骤： 1. 注册 Zyte 账号 → 获取 API Key 2. 在 .env 中配置 ZYTE_API_KEY=xxx（.env 不入 git） 3. 在 Scrapy 项目的 settings.py 中启用 Zyte API（官方技能的 /scrape-zyte-login 可引导配置） 4. 跑通后仍需过 33 项审计（尤其 M9：确认 Key 已配置、scrapy-zyte-api 依赖非空转）

审计模式

当用户要求审查/检查/审计已有爬虫项目时触发。目标：产出结构化审计报告，含严重等级分类和优先级整改路线。

审计工作流

1. 加载审计清单。 读取 references/audit-checklist.md——定义了 5 个维度共 33 个检查项（安全、性能、健壮性、合规、可维护性），每项包含检查方法、告警条件、严重等级和修复建议。
2. 执行相同的前置探查（步骤 0.0 和 0.1）。 先按步骤 0.0 检查 Python 版本环境（项目要求的版本与当前系统是否兼容），再检查 requirements.txt、crawler.py、db.py、app.py + templates/、config.yaml/.env、.env.example + .gitignore、static/vendor/。据此判断哪些检查项适用、哪些为 N/A。
3. 逐项遍历清单。 对每个适用项：
4. 阅读相关源文件。
5. 判定结果：PASS（达标）、FAIL(严重等级)（发现违规）、WARN（不够理想但能跑）、N/A（不适用本项目）。
6. 记录发现，附文件名、行号及具体证据。
7. 按 references/audit-checklist.md 末尾的输出格式生成审计报告：
8. 汇总表：按维度和严重等级统计数量。
9. 逐项详情：结果、发现描述、大白话风险说明、具体修复方案。
10. 整改优先级路线：P0（致命，立刻修）→ P1（高，扩大使用前修）→ P2（中，方便时修）→ P3（低，锦上添花）。

审计模式关键规则

• 严格按清单执行。 33 项是基线，不跳过任何维度。如果项目存在清单之外的额外问题，追加到"额外发现"章节。
• 非技术用户适配。 报告发现时，先用大白话说明风险（"如果 xxx 不修，会发生 yyy"），再说技术修复方案。用户可能看不懂代码，但需要理解后果。
• 审计模式下不自动修复。 只报告发现，不修改代码，除非用户明确要求（"帮我修"）。
• 用户要求修复后，退出审计模式，回到开发模式工作流。入口取决于修复范围： 少量修复（1-2 项）走下方的"单项修复快速通道"；大范围修复从步骤 3（开发契约）开始——无需重新走步骤 1–2（场景识别和需求收集），因为审计已明确了要修什么。
• 单项修复快速通道： 如果用户只要求修复 1-2 个审计发现（如"帮我把 S1 密码硬编码修了"），不要跑完整的开发模式前置检查。而是：定位问题 → 应用修复 → 验证修复解决了该发现 → 报告完成。只有修复引入了新组件（如新增之前不存在的数据库层）或涉及 3 个以上文件时，才需要完整的前置检查。

参考资源

• references/非技术人员使用智能体开发 Python 爬虫规范手册.md —— 完整规范：场景分类、框架选择、开发契约、项目结构、漏洞减少（含无登录 Web 界面安全）、内存溢出规避、良好代码习惯（五问验收清单）、数据库连接最佳实践（MySQL/PostgreSQL）、浏览器 Web 配置界面规范、以及可直接复制使用的需求模板。实现爬虫或用户需要详细指南时加载。
• references/audit-checklist.md —— 面向已有爬虫项目的结构化审计清单。5 个维度 33 个检查项，每项包含检查方法、告警条件、严重等级（🔴致命 / 🟠高 / 🟡中 / 🟢低）和修复建议。包含审计报告输出格式（汇总表 + 逐项详情 + P0-P3 整改路线）。进入审计模式时加载。
• references/python-version-management.md —— Python 版本管理引导。当用户本地 Python 版本���项目要求不一致，或需处理版本冲突时加载。推荐 uv / pyenv / conda 等方案及避坑指南。
• references/deployment-guide.md —— 爬虫部署上线引导。当用户需要让爬虫脱离开发环境、长期稳定运行时加载。覆盖 Windows NSSM / Linux systemd / macOS launchd 系统服务注册、定时任务、Docker，含爬虫场景专用决策树。
• references/git-guide.md —— Git 版本管理引导。当用户没有 .git、需要推荐版本管理工具时加载。包含 git 价值对比表、GitHub/Gitee/GitCode/Codeup/Coding 五平台对比、初始化流程和可选话题菜单。

这个技能质量非常好，专为不懂技术的人设计。你只需要说"想抓什么网站、什么数据"，它就能帮你写出安全稳定的爬虫代码。它会自动决定怎么保存数据（文档存成文本，表格存成Excel），不需要你懂数据库。最贴心的是写好后可以用"五问法"自己验收，不需要看懂代码。它还有33项检查清单帮你审查现有爬虫，找出问题并告诉你怎么改。文档非常详细，但内容有点多，有些地方可能需要简化。总体来说，这是一个考虑很周全、很实用的技能包。