最近在做一个 HTTP 抓包调试工具，叫 HTTPeep 。做到一半，开始有点怀疑自己。
不是因为技术难，技术部分现在有 AI ，生产不再是瓶颈，但是另一方面我又一直在问自己，我现在在做的东西，几年后还有人需要吗？就我自己的感受，抓包工具确实是打开得变少了。
根据这几个月高强度的 Agent Coding 和经历过好几次模型迭代，我感受到一个以前要用抓包才能搞清楚的 API 问题，直接问 AI ，就算上下文不足，根据已有的代码信息，多推理几轮基本上问题也能解决了。然后开始认真想这件事。有两个想法在脑子里打转...
AI 通过静态代码就能推理出大部分网络行为。随着模型越来越强，很多中低复杂度的调试场景会被直接替代。
你不再需要亲眼"看"请求，因为 AI 已经能帮你"想"出来了。随着 Claude ，Codex 模型越来越强，它们正在让开发者越来越少地打开抓包工具。
VSCode 内嵌 Browser ，Codex 出了 Computed-Use ，本质上都是给模型增加 Context ，让 Agent 任务完成质量更高更正确
这个论点我没办法反驳，因为我自己也感受得到
但我同时也在想另一种可能
长期来看，AI 让软件行业的规模在变大，从业者更多，应用更多，网络请求的总量只增不减。
更重要的是，AI 生成的代码本身会产生更多奇怪的网络行为——它不理解你的业务上下文，它会写出能跑但行为诡异的 API 调用，这些东西只有抓包才能看清楚。当然大部分情况下 Agent 都工作得很好
还有一个点就是：调试工具支持 MCP 和 CLI SKILLS 可以成为 AI Agent 的眼睛。
AI 现在推理网络问题的方式，是分析你的代码——它在猜。但如果让 AI 直接看到真实的网络请求，它就不用猜了。这是两种完全不同的能力。 所以在 HTTPeep 里，我做了 SKILLS 和 CLI 集成，让 Claude Code 或者其他 AI 编码工具可以直接连上来，读取实时的请求数据。不是让 AI 替代调试工具，而是让调试工具变成 AI 的感知层。
我押注论点 B ，但不确定对不对
还有我像说一下，为什么我做这个工具，以前我是一个重度的抓包使用者，做这个工具之前，我们几乎用遍了市面上所有同类产品——Charles 、Proxyman 、Fiddler 、Reqable 、HTTP Toolkit 。它们基础功能都很扎实，但有两个问题一直没有被好好解决：
一是规则管理太分散。MapLocal 规则在一个面板，断点在另一个面板，规则少的时候没问题，一旦复杂起来，你会开始调试自己的调试规则。
二是本地和共享的矛盾。要么纯本地、换机器就丢，要么云同步、数据存在别人服务器上。没有一个好的中间方案。 HTTPeep 的做法是：规则就是文件（ JSON/YAML ），直接放进 Git ，团队拉取即用。不需要账号，不需要登录，完全离线。本地优先，但不孤立。 这是我对"这类工具应该长什么样"的一个判断。
现在想听听大家的看法和不同的观点，特别是：
你现在还在用抓包工具吗？频率有没有因为 AI 变化？ "让 AI 直接读网络请求"这个方向，你觉得有实际价值吗？
HTTPeep 感兴趣的可以看看： httpeep.com
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。