从爬虫到产品思维：一个AI写码人的技术野路子
上周五晚上十点半，我还在公司调一个奇怪的反爬策略，地铁末班车早就开走了。坐在工位上啃着凉透的煎饼果子，突然想到——这已经是我连续第三周因为爬虫需求加班了。作为一个重度依赖 Cursor 的程序员，我甚至开始怀疑自己是不是被 AI 养废了：以前手写正则都跟呼吸一样自然，现在连最简单的 requests.get() 都要让 Cursor 帮我补全。
坐标北京，每天通勤一小时，挤在10号线人堆里时总在想：为什么我们团队的爬虫项目总是踩坑？为什么产品经理总觉得“不就是抓个网页嘛”？以及，当我准备跳槽时，这些折腾出来的经验真的能帮我拿到 offer 吗？
今天就来聊聊这几年在技术探索和实践中的那些事儿，尤其是关于爬虫、产品思维和求职这三件看似不相关、实则环环相扣的事。
爬虫不是“小工具”，而是产品能力的试金石
刚入行那会儿，我也以为爬虫就是写个脚本跑一跑，数据哗哗地进数据库，完事。直到去年双11前，产品老大甩给我一个需求：“我们要实时监控竞品价格，每5分钟更新一次，不准漏，不准错。”
我心想：小意思。结果上线第一天，对方网站加了 Cloudflare 验证，我的脚本直接被拦在门外。第二天，IP 被封了；第三天，页面结构改了；第四天……算了，我不说了。
后来我才明白，爬虫不是技术问题，是产品问题。它背后是对目标系统的理解、对数据质量的要求、对异常处理的容忍度，甚至是对商业逻辑的洞察。比如：
- 用户要的是“最新价格”，但“最新”到底指什么？是页面显示的时间戳，还是实际生效时间？
- 如果某次抓取失败，是重试三次就放弃，还是等下次轮询？要不要通知运营？
- 数据入库后，前端怎么展示？如果价格突降99%，是 bug 还是促销？
这些问题，光靠技术解决不了。你得懂产品语言，才能把爬虫从“脚本”升级成“服务”。
用 Cursor 写爬虫：效率翻倍，但别交出思考权
说到工具，必须吹一波 Cursor。我现在几乎离不开它了。比如上次要处理一个动态渲染的电商页面，传统 requests + BeautifulSoup 直接扑街。我让 Cursor 帮我生成 Playwright 脚本：
from playwright.sync_api import sync_playwright
import time
def scrape_dynamic_page(url):
with sync_playwright() as p:
browser = p.chromium.launch(headless=True)
page = browser.new_page()
page.goto(url)
# 等待关键元素加载
page.wait_for_selector(".price", timeout=10000)
price = page.text_content(".price")
browser.close()
return price.strip()
Cursor 不仅写了代码，还贴心地加了超时控制和注释。我只需要微调选择器，搞定！省了至少两小时查文档的时间。
但这里有个大坑：别让 AI 替你做架构决策。有一次我让 Cursor “优化爬虫性能”，它建议我用多线程 + 代理池。听起来很酷，但没考虑我们部署在公司内网，出口 IP 固定，代理根本走不通。结果白折腾半天。
所以我的经验是：让 AI 干脏活累活（写模板、处理异常、格式化数据），但核心逻辑——比如重试策略、数据校验、调度机制——必须自己把控。毕竟，AI 不会为你的线上事故背锅。
产品思维：从“我能做”到“该不该做”
有次产品经理说：“我们能不能把全网招聘网站的数据都抓一遍，做个智能推荐？”
我差点脱口而出：“能啊！”
但话到嘴边，我忍住了，反问：“用户是谁？解决了什么痛点？和现有功能有什么区别？”
他愣了一下，说：“呃……就是感觉很酷？”
这就是典型的“技术驱动” vs “产品驱动”。作为工程师，我们很容易陷入“能做就做”的陷阱。但真正有价值的项目，往往始于“为什么要做”。
后来我们一起梳理：
- 用户其实是 HR，他们需要快速找到匹配的候选人
- 现有渠道（BOSS直聘、猎聘）已经很全，但信息分散
- 所以核心不是“抓全网”，而是“聚合+去重+打标签”
于是我们调整方向：只抓三个主流平台，重点做简历解析和岗位匹配度计算。爬虫只是第一步，后续的数据清洗、NLP 处理、推荐算法才是关键。
这个项目上线后，HR 团队反馈特别好。更重要的是，它让我意识到：技术人必须学会问“为什么”。否则，你写的每一行代码，可能都是在给错误的方向加速。
求职时，别只秀技术，要讲“故事”
今年春招，我面了几家公司。有次面试官问：“你做过最有挑战的项目是什么？”
如果按以前的思路，我会说：“我用 Scrapy + Redis + Docker 搭了个分布式爬虫，日均百万请求。”
听起来很牛，但面试官大概率会打哈欠。
这次我换了个说法：
“我们发现竞品监控数据经常不准，导致运营决策失误。我牵头重构了整个爬虫系统，不仅解决了反爬问题，还加了数据校验层和告警机制。上线后，数据准确率从78%提升到99.2%，运营团队再也不用半夜打电话问我‘为什么价格不对’了。”
你看，技术细节藏在故事里，而故事的核心是“问题 - 行动 - 结果”。面试官关心的不是你会不会写 XPath，而是你能不能用技术解决真实业务问题。
而且，现在很多公司（尤其是中大型厂）都在强调“工程效能”和“可维护性”。我特意在简历里写了：“所有爬虫脚本均通过 Pytest 单元测试，CI/CD 自动部署，日志接入 ELK”。结果好几家都问得很细——看来大家真的被烂代码折磨怕了。
顺便吐槽一句：有些公司一面就让你现场写爬虫题，还要求绕过验证码。我说大哥，这都2024年了，真要抓这种网站，要么买代理服务，要么合作 API，谁还硬刚验证码啊？这种题除了筛掉老实人，没啥意义。
可读性与可维护性：别让队友想删库跑路
说到代码质量，我真的越来越在意可读性和可维护性。以前觉得“能跑就行”，现在看到没人注释、变量名全是 a/b/c 的代码，血压直接拉满。
比如爬虫配置，我坚决不用魔法数字：
# ❌ 别这样
time.sleep(3)
# ✅ 这样
CRAWL_DELAY_SECONDS = 3
time.sleep(CRAWL_DELAY_SECONDS)
再比如异常处理，很多人直接 try...except: pass，图省事。但一旦线上出问题，你连错在哪都不知道。我现在强制要求：
try:
response = requests.get(url, timeout=10)
response.raise_for_status()
except requests.exceptions.Timeout:
logger.error(f"Timeout fetching {url}")
raise CrawlTimeoutError(url)
except requests.exceptions.HTTPError as e:
if e.response.status_code == 403:
logger.warning(f"Blocked by anti-bot: {url}")
raise AntiBotDetected(url)
else:
raise
虽然啰嗦点，但出了问题，日志一目了然。运维同事都说：“你这爬虫报错，我看一眼就知道要不要找你。”
另外，所有爬虫任务我都封装成独立模块，用配置文件驱动：
| 配置项 | 说明 | 示例 |
|---|---|---|
start_urls |
起始URL列表 | ["https://shop.com/cat1", ...] |
selectors |
CSS选择器映射 | {"price": ".final-price"} |
retry_count |
重试次数 | 3 |
proxy_enabled |
是否启用代理 | true |
这样，产品或运营想临时加个站点，改个 YAML 就行，不用动代码。他们开心，我也少加班。
写在最后：技术是手段，不是目的
回看这几年，从只会写脚本的“爬虫仔”，到能和产品对需求、和算法聊模型、和运维谈部署的“全栈打杂”，最大的转变不是技术栈变深了，而是视角变宽了。
爬虫教会我：数据不是天然存在的，它需要被理解、验证、赋予意义。
产品思维提醒我：别沉迷于技术炫技，先搞清楚用户到底要什么。
求职经历告诉我：市场要的不是“工具人”，而是能闭环解决问题的人。
现在每天通勤路上，我不再刷 LeetCode，而是听《硅谷101》或者《产品沉思录》。偶尔还会打开 Cursor，让它帮我 draft 一篇技术博客——就像你现在读的这篇。
技术探索没有终点，但每一步都算数。希望我的野路子，能给你一点启发。
（完）
P.S. 如果你也在北京做爬虫，欢迎约咖啡吐槽反爬策略。不过别选周五晚上，我得赶末班车回家——不然又要吃凉煎饼果子了。
评论 0