我已经失去了编写代码的能力，变成只会写提示词的提示词工程师。但也没有完全丧失，我还会Review代码，偶尔手动改几行代码。

比如用Swift写UI，我在完全不复制粘贴的情况下，已经不会从0行代码写出一个页面，只会在AI生成的代码微调布局。

准确的说，不是丧失了能力，而是丧失了记忆！

回顾最近在开发ApiCatcher这款iOS端HTTPS抓包和调试工具的过程中，除了用AI开发核心功能遇到困难，其实在开发UI过程中也遇到一些困难。

今天分享我用AI开发ApiCatcher UI遇到的两个问题。解决这两个问题，我从Gemini 3.1 Pro模型，升级到Claude Opus 4.6模型，又从Claude Opus 4.6模型降到Gemini 3 Flash，最新只用Gemini 3 Flash就解决了问题。

第一个案例，我让AI帮我开发ApiCatcher的“AI对话生成脚本”功能，这里遇到的问题就是Markdown渲染。AI响应的消息里面包含代码。

关于UI，我的提示词大概是这样的：

页面做成聊天对话界面，底部是输入框和发送按钮，其余空间是显示聊天记录，用户只能发送文本消息，AI响应的消息是Markdown格式，AI响应的消息包含代码块，需要能高亮渲染代码块，代码不自动换行，而是代码块可以左右滚动。

这里的难点就是要支持代码块的高亮和代码块可以水平滚动。

无论是Gemini还是Claude，他们的思路都是先用开源的Swift语言编写的Markdown渲染开源库，怎么调都调不出令我满意的效果，渲染结果太丑了。在尝试完几个开源库后，Gemini和Claude会走向自己实现，写得非常复杂，然后实现的效果更加糟糕！

在无数次挫败后，我开始自己思考解决方案。我告诉Claude，SwiftUI的Markdown渲染开源库不好用，我们可以用Web技术栈，找JS开源库，然后用WebView来渲染Markdown消息。

这次Claude终于开窍了，但也没完全开窍。他把每个Markdown消息，都用一个WebView来渲染....

我再告诉他，为什么不是只用一个WebView来渲染所有消息呢？这时候Claude限制额度了......

我降回了Gemini 3 Flash。终于在几次调整后，Gemini做出了我想要的效果。

最终用到的技术栈：WebView、CodeMirror、Highlight.js。

第二个案例，JSON可折叠可搜索。

这次一上来就用Claude Sonnet 4.6模型，提示词：帮我实现JSON全屏预览页面，要求：JSON高亮显示，路径可以折叠和展开，可以搜索，搜索结果高亮，可以点击“下一个”按钮跳转到下一个搜索结果的位置。

Claude还是一样的思路，先找SwiftUI的开源库，但折腾半天卡在了搜索功能。还是一样折腾到耗尽Claude额度。

SwiftUI没有好用的开源库，那就换个思路，于是我又想到了WebView。最后选择WebView+CodeMirror+Highlight.js，加上CodeMirror的一个行号插件、搜索插件，用Gemini 3 Flash开发，完美实现！

在这两个案例中，无论是Claude还是Gemini，他们的思考方式都是先找SwiftUI可以使用的开源库，如果达不到目的，就改变策略，自己实现，但这种复杂的任务，他们根本没能力实现好。他们无法变通到通过WebView去乔接，从使用Swift技术栈，转变为使用Web开发技术栈。

我们只要告诉AI方法，他们就能实现，所以，目前AI的能力，其实受限于使用者的能力、认知。初级程序员+AI 无法超越 高级程序员+AI！

未来提示词会替代编程语言，程序员从写代码变成写提示词，但我们依然需要学习提升写提示词的能力。编程能力从来不是指代码写得多漂亮，而是对底层原理的认知深度，同样写提示词的能力也并非是指表达能力，同样是对底层原理的认知深度和广度。

以上面两个案例为例，我们需要认识到Swift原生开发并不是只能使用Swift，SwiftUI开发的原生应用也可以使用WebView来渲染网页，可以Swift生成网页代码传递给WebView渲染，并且可以生成JS代码让WebView执行。我们可以不懂怎么去写代码实现，只需要知道可以这样做，这极大降低了学习难度！

AI放大了我们个人的能力：从需要学会如何编码实现，了解具体的底层原理，到只需要知道可以这样实现。

但只是放大个人能力，AI遇强则强，遇弱则弱，我们依然需要保持学习。

最近的一份工作，因为对业务不熟悉，产品经理出的需求又不考虑历史兼容性，问同事同事也不清楚，作为一个后端开发，我也拿不到客户端的代码，于是我就想到了抓包，通过安装app，抓取某块功能使用了哪些接口。

因为我手机是iPhone, 我因此试用了很多款在app store下载的HTTPS抓包工具，包括免费的Stream、ProxyPin、付费了一款螃蟹抓包。但这些工具感觉都是出自于同一个模版，体验雷同，因为没有别得选择，当时只好忍受。

当时没被满足的一些需求：

1、发现一些图片无法抓取到（我想知道图片用的域名和路径，知道是直接访问云存储，还是用的哪个文件系统服务，这在后端项目中看不出来，因为这个项目的后端也没提供文件上传功能）。

2、JSON无高亮、无搜索功能，也无法对比某个业务参数（比如当商品类型是电子钥匙时、以及商品类型是摄像头时，实际传的参数以及响应的Body有哪些不同的字段）。

3、除体验外，我当时还希望能满足我这个需求：我想把这些接口导入到Apifox，并且基于当前接口和新的迭代需求在此基础上去修改接口，并在团队中共享这份接口。 而当时我只能基于抓取的响应结构，自己在Apifox里面写接口，这耗费了我整整一天时间。

经过那次之后，我决定自己研究写一个，这个HTTPS抓包工具一定把用户体验做好，一定支持抓图片、支持JSON高亮和搜索（甚至是JSON Diff），以及支持自动生成API文档，可以一键导出到Apifox。

2026年1月我开发出来了，这款APP就叫ApiCatcher（因为一开始的目的就是抓API的，所以取名ApiCatcher），所有产品功能皆为原创设计。

能做出来要感谢那些开源项目的，比如ProxyPin，或许是因为开源项目没有盈利，所以体验没做好吧。我似乎也能理解为什么大多数抓包工具长得那么相似了。

我研究了他们的核心抓包功能是如何实现，用了哪些技术，然后自己花两周时间在Claude辅助下用Swift造了一份轮子(就是核心的NIO代理服务器以及SSL握手)，在此基础又花两周时间做了优化性能，降低CPU和内存的占用，同时支持抓取大文件请求，避免进程被系统kill掉。我使用SwiftData和文件来存储抓包数据，将请求和响应Body存文件，其它字符串存SwiftData，然后通过边读边写文件来降低对内存的占用，而SwitData则提供更强大的搜索能力，这为产品做查询过滤功能提供了支持，所以ApiCatcher支持非常多的过滤条件。

以下是产品最初几个核心功能的产品设计：

1、极简风格的抓包页面。（我还加了个小创意：正在抓包中的背景是一张蜘蛛网，有一只蜘蛛在上面爬）

2、请求详情内容聚合，便于在手机这种小设备上更好的查看数据，同时减少操作步骤。请求响应的每个部分都是一个卡片，卡片可展开收起。Body可导出和一键复制。Body可展开全屏预览。Body目前支持渲染图片、svg、html、xml和json。

3、JSON格式化、高亮、搜索、Diff支持：

4、接口文档自动生成，以及导出接口文档到Apifox等API调试工具，因为海外用户不用Apifox，所以也支持了Postman和Bruno：

5、可以抓文件，其实任何HTTP请求都支持，不仅仅是图片，而且没有限制图片大小，多大都能抓，这些图片还可以导出来拿来测试用（一些需要上传特定图片测试的接口）：

经过两个月时间，加上有不少用户给我提需求，于是慢慢功能都完善了。基本app store上的https抓包工具有的功能ApiCatcher都支持了，并且体验更好，像一些正则表达式、脚本都集成AI生成功能提升效率，让用户自己填API Key 。

工具本就是为开发者提升工作效率而开发，所以我们做了支持导入企业内部使用的受信的自签私钥和证书，也可以自己开发一个接收器实时接收抓包流量，实现API扫描分析需求。

这款工具不支持iOS17以下系统，因为用了SwiftData，SwiftData需要17.0以上才支持。整个项目纯SwiftUI开发，核心功能代码用swift-nio等apple官网库。代码高亮则用了WebView+CodeMirror+Highlight.js以及一些插件。这些在app关于我们->开源组件许可都有声明。

ApiCatcher与ChatTCP这两款网络数据包抓包分析工具都是我自己原创设计、开发的作品，目前两款产品在海外还是不少用户喜欢的，我知道国内大家都喜欢用免费的，比如Stream、ProxyPin、Reqable，但我还是要在各个平台上分享一下的，避免后面被人借鉴反被别人说是我们抄袭，赚不赚钱是次要的，得先证明自己是原创的。