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 嗎？

如果使用者回覆需要，按以下順序執行，並在最後彙總報告每一步的結果：

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 依賴非空轉）

7w4.net小蔥技能站，你的AI助手技能庫。

審計模式

當用戶要求審查/檢查/審計已有爬蟲專案時觸發。目標：產出結構化審計報告，含嚴重等級分類和優先順序整改路線。

審計工作流

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項檢查清單幫你審查現有爬蟲，找出問題並告訴你怎麼改。文件非常詳細，但內容有點多，有些地方可能需要簡化。總體來說，這是一個考慮很周全、很實用的技能包。