让 AI 做联网工具？小心那些你看不见的坑

让AI帮你写一个"抓取GitHub Trending然后自动生成文章"的工具。听起来很酷对吧？

我也这么想。然后我花了三天时间debug。

问题不在于AI写的代码逻辑——逻辑基本没问题。问题出在那些AI"看不见"的地方：网络超时、API限流、反爬机制、环境差异。这些东西，AI在写代码的时候要么完全忽略，要么写得过于理想化。

一、AI写联网代码的三大盲区

盲区一：网络是不稳定的

AI写代码的时候，默认网络是稳定的。它的代码里，fetch请求发出去，数据就回来了。没有超时，没有断连，没有DNS解析失败。

但现实是：GitHub Trending的页面加载可能需要5秒，国内访问某些API可能直接超时，WiFi信号差的时候TCP连接会莫名其妙断开。

我让AI写的一个爬虫脚本，在本地跑得好好的，一放到GitHub Actions上就跑不通。原因是GitHub Actions的runner网络环境跟本地完全不同，某些请求会被防火墙拦截。AI的代码里完全没有考虑这种情况。

盲区二：API会限流

很多API都有频率限制。GitHub API每小时最多60次未认证请求，腾讯云翻译API有每秒调用次数限制。

AI写的代码通常不会主动处理限流。它不会在请求之间加延迟，不会解析返回的429状态码，不会实现指数退避重试。

结果就是：脚本跑得好好的，突然所有请求全部失败，然后你看着一脸懵逼的错误日志不知道发生了什么。

盲区三：反爬机制是真实存在的

国内很多网站都有反爬机制。抖音的接口需要动态cookie，快手的页面是客户端渲染的，百度热搜的HTML结构经常变。

AI写的爬虫代码，往往用最简单的方式去请求——直接fetch页面URL，然后解析HTML。这种方式对静态页面有效，但对有反爬的网站完全无效。

更要命的是，AI不知道自己不知道。它给你的代码看起来完美，但实际运行的时候一个数据都抓不到。

二、真实踩坑记录

坑一：超时设置缺失

AI给我写的一个抓取脚本，用了Node.js的fetch，但没有设置timeout。结果有一次目标网站响应特别慢，整个脚本卡在那里，既不报错也不继续，就那么一直等着。

等了40分钟，直到GitHub Actions的6小时超时机制把它杀掉。

修复方法很简单：加一个AbortController，设置15秒超时。但AI的初始代码里没有这个。

坑二：重试逻辑过于简单

AI写的重试逻辑是这样的：失败了，等1秒，重试。失败了，等1秒，重试。失败了，等1秒，重试。三次都失败，报错退出。

问题是：如果失败原因是服务端过载（502/503），你每秒重试一次，等于在继续给服务器加压，让它更过载。正确的做法是指数退避——等1秒、等2秒、等4秒、等8秒，给服务器恢复的时间。

坑三：环境变量和路径问题

AI写的脚本在本地跑得好好的，一放到CI环境就挂。原因是：

• 本地用Windows，CI用Linux，文件路径分隔符不同
• 本地有.env文件，CI环境用secrets
• 本地Node.js版本是24，CI默认装了20

这些环境差异，AI在写代码的时候完全不会考虑。它不知道你的代码会在什么环境下运行。

三、联网工具的正确开发姿势

1. 永远设置超时

不管用什么语言、什么框架，所有网络请求都必须设置超时。15秒是个合理的默认值，具体看场景调整。

const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), 15000);
const response = await fetch(url, { signal: controller.signal });
clearTimeout(timeoutId);

这段代码，AI不一定会主动写，但你必须加上。

2. 实现指数退避重试

不要线性重试，要用指数退避：

• 第1次重试：等1秒
• 第2次重试：等2秒
• 第3次重试：等4秒
• 第4次重试：等8秒
• 第5次重试：等16秒

同时要检查返回的状态码。如果是429（限流），要等更长时间；如果是404（不存在），重试也没用，直接报错。

3. 每个数据源独立处理

不要把所有的网络请求写在一个try/catch里。每个数据源应该有独立的错误处理，这样即使一个源失败了，其他源还能继续工作。

AI倾向于把所有逻辑堆在一起，你需要手动拆分开。

4. 在目标环境测试

在本地跑通的代码，不代表在服务器上也能跑。一定要在实际部署的环境里测试至少一次。

特别是GitHub Actions这种CI环境，网络环境、文件系统、环境变量都跟本地不一样。很多坑只有在这种环境下才会暴露。

四、AI能做什么，不能做什么

AI在写联网工具时，擅长的是：

• 写出基本的请求逻辑
• 解析JSON/XML/HTML数据
• 组织代码结构
• 写注释和文档

AI不擅长的是：

• 处理网络异常和边界情况
• 应对反爬机制
• 适配不同的运行环境
• 设计可靠的重试和降级策略

所以正确的分工是：让AI写主体逻辑，你来补异常处理。让AI写第一版代码，你来加超时、重试、错误处理。

五、一个检查清单

每次让AI写完联网相关的代码，过一遍这个清单：

• 所有网络请求都有超时设置吗？
• 有重试机制吗？是线性重试还是指数退避？
• 每个数据源有独立的错误处理吗？
• 429限流有处理吗？
• 文件路径用了跨平台兼容的写法吗？
• 环境变量有默认值或检查吗？
• 在实际部署环境测试过吗？

如果有一个"没有"，那这段代码就不该上线。

六、结语

AI写代码的能力确实很强，但它写的是"理想世界"的代码——网络永远稳定，API永远可用，环境永远一致。

现实世界不是这样的。网络会断，API会挂，环境会变。这些"不理想"的部分，就是AI的盲区，也是你必须亲自把关的地方。

让AI帮你写代码，但别让AI替你思考。网络这块，尤其如此。