共计 2204 个字符，预计需要花费 6 分钟才能阅读完成。
作为一名即将入学的大一新生，我报考了某211高校的计算机科学专业。近期看到GPT-5的发布，了解到它能够生成小游戏程序，这让我不禁担忧，七年后当我们步入职场时，程序员的工作岗位是否会因为技术进步而变得愈发稀缺，甚至贬值？
若点赞超过100，我将开源这一工具。整体的golang代码结构相对简单，虽然AI生成的代码有些冗长，但并未涉及复杂的抽象或扩展，非常适合新人们学习透明代理、socks代理及IP协议，手动搭建也是一种乐趣。
另外，对于为何不使用成熟工具的问题，真的无需再问。亲手编写代码是一种独特的乐趣。多年前我从他人处抄录了一套综合使用iptables、ipset、tproxy及chinadns的脚本，经过多年的实践，已然熟练。我一直使用这套脚本来实现透明代理，能够根据不同设备进行流量分流，例如BT下载和游戏机可以使用更便宜的代理，而上网的设备则使用cn2-GIA。
回归正题，一图胜千言
AI的替代作用不容小觑。昨天我利用它生成了一个翻墙工具，成功实现了socks5协议的透明代理。
今天则继续对透明代理的代码进行调试和修复，花费了整整一天的时间，最终解决了不少明显的错误。尽管我不断给AI提供反馈，它却只是无目的地进行修改，代码量庞大，实在无济于事。最后，我还是得逐行审查golang代码，因为我的golang水平有限，只能借助AI进行解释。
值得一提的是，AI生成的代码命名风格相对一致，阅读起来上下文容易把握。例如，混淆后的连接装饰器命名为obfuscatorConn，而未混淆的则有不同的命名。然而，若指望几句提示词就能生成一份完美的代码库，实在是异想天开。
那么，AI生成代码的问题究竟有多严重呢？
第一天上午
在设置透明代理监听3081端口时，它却给我使用了golang封装的普通监听socket。经过长时间的调试，我通过UDP协议发送数据或使用iptables配合tproxy转发，透明代理的代码却始终没有日志输出。我推测可能是普通socket监听192.168.1.1:3081时，底层封装会过滤掉目的地不是192.168.1.1:3081的UDP包。经过多次提示，它终于修正了，采用了更底层的API，能够顺利接收tproxy转发的UDP包。如果没有经验，对四层协议缺乏整体了解，连提示词都可能无从下手。
在解决了这个问题后，我却发现服务器无法解析客户端的协议。由于对golang了解不深，我希望通过提示词来解决bug，要求AI生成大量日志，最终将服务端与客户端的日志都发送给gemini-cli。结果，它却给我添加了许多无关的混淆工具代码和加锁功能。
经过逐行审查golang代码，我发现透明代理在接收到被代理端的UDP包后，转发给服务器之前未进行混淆，导致服务端在通过XOR进行反混淆解析协议时出现了故障。我花了很长时间进行调试，还逐行检查iptables转发规则，毕竟我手写的iptables规则已经使用了十多年，应该不会出问题。
在处理UDP透明代理时，我发现被代理端只能发送UDP数据包，例如使用8.8.8.8:53进行DNS解析，发送的UDP包没有问题，经过nc测试，被透明代理的客户端能够顺利发送。然而，当8.8.8.8:53返回时，包却无法接收。我使用tcpdump进行调试，发现client代理端根本没有将8.8.8.8:53返回的UDP包转发给被代理端，于是提示gemini-cli将其改为更底层的API实现转发。
第一天下午
经过一番折腾，我终于使用tcpdump捕获到client代理透明转发给被代理端的UDP包。然而，在使用dig google.com@8.8.8.8进行查询时，依然提示未收到服务端的请求，尽管tcpdump显示已接收到8.8.8.8的包。经过多次提示，仍未解决。仔细分析tcpdump的报文后，我发现AI悄悄将8.8.8.8:53的端口更改为8031，导致报文变为8.8.8.8:8031 -> dig:11920。这样的情况使得被代理端内核无法将UDP报文转发给dig应用层，明明请求的是8.8.8.8:53，却告诉我地址已经变为8.8.8.8:8031。
最终，宁可信AI无AI。AI有时确实会让人走入误区，毕竟它本质上是一个概率模型，只会给出一个大致的答案，而不一定符合实际需求。如果能力较强，可能几分钟就能解决问题；但若能力不足，如我所遇到的问题，缺乏背景知识，甚至不知道如何写提示词，最终不如自己踏踏实实复习TCP/IP协议和UNIX socket API，从头编写自定义混淆翻墙工具。
最后，我展示一下成果：这个轻量级的TLS+xor自定义混淆器翻墙工具，效率尚可，CPU资源占用较低。
https://github.com/fqdeng/x-proxy 已迅速开源
今天下班后，我又抽空开始了TUN设备代理的调试，利用TUN设备接收IP协议报文，并将其组装成TCP和UDP进行代理，仍在苦苦调试中…
