—— 一次实验后的冷静复盘与技术路线图谱
AI 现在能自动生成采集代码，这件事乍一听挺让人兴奋。只要丢给它一句“帮我写个采集程序”，马上就能得到一段看似专业的代码。但当我真正拿这些代码去跑实验时，心情就从“哇塞真智能”变成了“嗯……还是得冷静一下”。
为了弄清楚“AI 写采集到底靠谱吗”，我把这件事拆成两条路线来看：
一条是让程序像真人一样打开浏览器、点击按钮、滚动页面，这属于模拟行为路线；
另一条则是直接调接口，也就是我们常说的接口调用或 API 逆向路线。
这两条路线基本覆盖了所有自动生成采集的逻辑分叉，而 AI 在它们身上的表现差异非常大。下面就用一种更偏“结构图谱”风格的方式，把整个技术框架与经验总结梳理出来。
一、核心主题：AI 写采集的真正分界线在哪里？
所有自动生成采集的思路，最后都会指向一个关键选择：
到底是
“像人类一样操作浏览器？”
还是
“直接跟接口说话？”
这个选择看似简单，背后却决定了成功率、复杂度、维护成本，以及 AI 能帮你做多少事情。
两条路线可以这样理解：
路线 A（模拟行为）：Playwright、Selenium 这一类浏览器自动化方案
路线 B（接口调用）：通过抓包和分析 API，直接向接口发请求
雷区、优势点、AI 擅长程度完全不同。
二、多分支技术路线：AI 在两条路线上的真实表现
路线 A：模拟行为（Browser Automation）
如果你让 AI 用 Playwright 或 Selenium 来跑一个页面，它往往表现得非常“自信”：
打开页面、等待元素、提取文本，这些步骤它几乎都能准确写出来。因为浏览器自动化的 API 较为固定，流程本身也比较标准。
不过，一旦细节稍微复杂一点，它的问题就暴露了：
- 给出错误或不存在的 CSS 选择器
- 误判页面加载顺序，导致死等
- 在需要规避检测时显得“天真无邪”
- 对动态结构变化毫无预案
- 一些等待策略看起来合理，但实际运行会卡死
简单说，在“90% 标准场景”里 AI 表现很好，但那 10% 的细节往往决定成败。
适合 AI 发挥的场景通常包括：
- 无登录、无强防爬
- 页面结构相对稳定
- 想快速验证采集流程是否可行
- Demo、Proof of Concept、临时需求
不太适合 AI 的场景则是：
- 用户需要多步交互
- 滚动、动态加载变化频繁
- 网站使用自动化检测
- 页面结构二三天就改一次
换句话说，越“接近真实用户行为”的网站，越容易让 AI 给你挖坑。
路线 B：接口调用（API Reverse）
这一条路线是 AI 最不擅长的，因为接口往往牵涉参数加密、时间戳验证、动态 Cookie、Token 续期等等，不是靠“猜”就能写出来的。
AI 在这些场景中的典型失误包括：
- 想当然地生成不存在的参数
- 根本没理解加密逻辑，但凑了一个看似合理的伪代码
- 忽略必须的 Cookie
- 对 JS 加密函数的逆向理解不完整
- 无法推断签名算法中的细节
简单讲，如果你让 AI 猜一个有加密的接口参数，它给你的答案通常都是“错得充满自信”。
AI 比较靠谱的情况：
- 接口公开但网页包装了一层
- 请求参数基本明文
- 网站本身就是 REST API 架构
AI 不靠谱甚至完全靠不住的情况：
- 签名算法需要计算
- 参数使用 AES、RSA、MD5 混合加密
- Cookie 中包含多个动态字段
- 接口必须模拟设备指纹或时序行为
这类情况通常必须靠人类分析抓包，再让 AI 帮你补全代码，而不是“全自动”。
三、技术图谱：AI 写采集的思维框架
把经验抽象成一个结构图谱，大致是这样的：
AI 自动生成代码
→ 先判断网站类型
→ 如果是普通页面 → 推荐浏览器自动化
→ 如果是 API 驱动网站 → 可能需要接口调用
→ 如果接口有加密 → 必须人工介入
→ 如果页面强防爬 → 仍以浏览器自动化为兜底
→ 如果量大、接口明文 → API 最高效
这套路径实际上能解释 80% 的“为什么 AI 给我的代码能跑 / 不能跑”。
四、路线建议：AI 可以取代什么？不能取代什么？
场景 1：快速验证
优先 Playwright 自动化 + 让 AI 写代码
这一步 AI 的成功率最高。
场景 2：需要稳定、快速、可规模化的采集
手工抓包 + AI 帮你生成 requests 代码
效率非常高。
场景 3：遇到加密、强反爬
人工逆向 + AI 辅助整理逻辑
AI 不能独立完成。
场景 4：企业级长期项目
两种路线混合使用：
接口为主，浏览器为兜底补充。
五、示例代码（含代理，已加入中文注释）
示例基于 Playwright，这类代码 AI 最容易生成，也最稳定。
from playwright.sync_api import sync_playwright
# ======== 配置16YUN爬虫代理========
proxy_host = "proxy.16yun.com" # 代理域名
proxy_port = "port" # 代理端口
proxy_user = "username" # 代理用户名
proxy_pass = "password" # 代理密码
proxy_url = f"http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}"
# ========================================================
def run():
with sync_playwright() as p:
browser = p.chromium.launch(
headless=True,
proxy={
"server": proxy_url} # 设置代理
)
page = browser.new_page()
# 设置UA，防止简单的反爬策略
page.set_extra_http_headers({
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
})
# 打开一个测试页面（可替换为目标站点）
page.goto("https://quotes.toscrape.com")
# 等待页面加载完成
page.wait_for_selector("h1")
# 提取标题文本
title = page.text_content("h1")
print("页面标题：", title)
browser.close()
if __name__ == "__main__":
run()
这个示例也展示了 AI 最擅长的部分：
- 浏览器初始化
- 页面跳转
- 选择器操作
- 基础代理设置
但要让它自动处理复杂网站？目前仍然很难。
六、最终总结：AI 写采集到底靠不靠谱？
如果概括一句，那就是：
AI 写采集很有帮助，但不能盲信。
简单场景，它就像个非常能干的助手；
复杂场景，它又像个会写作文但不会做题的小学生。
AI 能稳定完成：
- 框架搭建
- 基础流程
- 自动化脚本
- 标准 requests 模板
但以下内容仍然需要工程师操刀：
- 接口逆向
- 加密参数
- 防检测绕过
- 大规模任务调度
最终能跑起来的采集，往往是“AI 写 60%，工程师补 40%”。
