AI 越来越强，抓包工具还有必要做下去吗？

兰德 · 2026-05-20T06:44:04.049Z

最近在做一个叫 HTTPeep 的 HTTP 抓包调试工具，做到一半突然有点怀疑人生。不是因为技术卡住，现在有 AI 帮忙，写代码快多了，瓶颈早不在生产环节。真正让我犹豫的是：几年后，还有人需要这种工具吗？说实话，我自己打开抓包的频率确实比以前低了。这几个月高强度用 Agent Coding，经历了几轮模型迭代，明显感觉以前得靠抓包才能搞明白的 API 问题，现在直接问 AI，哪怕上下文不全，多聊几轮基本也能定位。于是开始认真琢磨这事，脑子里冒出两个相反的想法…… ### 想法一：这个方向可能正在萎缩现在的 AI 已经能通过静态代码推理出大部分网络行为了。像 Claude、Codex 这类模型越来越强，很多中低复杂度的调试场景，根本不用再手动看请求。你不再需要“亲眼”看流量，因为 AI 已经能帮你“脑补”出来。 VSCode 内嵌浏览器、Codex 支持 computer use，本质上都是在给模型加 Context，让 Agent 更准更快。这个趋势我没法反驳，毕竟我自己也体验到了。 ### 想法二：需求不会消失，甚至可能变多但反过来想，AI 让软件行业整体变大了——开发者更多，应用更复杂，网络请求总量只会涨不会跌。更重要的是，AI 生成的代码本身也会带来新问题：它不理解你的业务逻辑，可能写出“能跑但行为诡异”的 API 调用，这种时候不抓包根本看不出来。当然，大部分时候 Agent 都挺靠谱。还有个角度：调试工具如果能支持 MCP 或 CLI SKILLS，完全可以变成 AI 的“眼睛”。现在 AI 是靠猜你的网络行为，但如果能直接看到真实请求，就不用猜了。这是两种完全不同的能力层级。所以在 HTTPeep 里，我加了 SKILLS 和 CLI 集成，让 Claude Code 这类工具能直接连上来读实时请求数据。不是让 AI 替代调试工具，而是让调试工具变成 AI 的感知层。 ### 我暂时押注想法二，但心里也没底顺便说下为什么做这个工具。我之前是重度抓包用户，市面上主流的都试过——Charles、Proxyman、Fiddler、Reqable、HTTP Toolkit，基础功能都没问题，但有两个痛点一直没解决： - 规则管理太散：MapLocal 在一个面板，断点在另一个，规则一多，反而要调试自己的调试规则； - 本地和共享的矛盾：要么纯本地，换机器就丢；要么上云同步，数据又不在自己手里。 HTTPeep 的做法是：规则就是文件（JSON/YAML），直接扔 Git 里，团队拉下来就能用。不用注册，不用登录，完全离线，但也能协作。这算是我对“这类工具该长什么样”的一个判断吧。现在挺想听听大家的看法，尤其是： - 你现在还用抓包工具吗？频率有因为 AI 变少吗？ - “让 AI 直接读网络请求”这个方向，你觉得有实际价值吗？项目地址放这，感兴趣的可以看看： https://httpeep.com

发现产品榜单精选讨论