企业官网建设流程全解析

要是在去年有人跟我说，一台装着 Windows 3.1 的 386 老机器也能完成一次正经的 AI 问答，我大概率会觉得这是个段子。但这个项目后来真的做到了：从最初 500 行代码的原型，经历 7 个版本迭代，最终压缩成 29 行的单文件程序，让 Win3.1 到 Win11 全系机器都能通过转发网关调用现代 AI 服务。这篇文章就把这段开源之路拆开讲讲，包括我为什么做、怎么砍代码、老系统和新系统之间到底隔着哪些坑，以及开源之后我又学到了什么。适合对老系统兼容性、极简客户端、程序精简方向感兴趣的读者。

1. 从一个"不切实际"的目标说起：老机器凭什么碰 AI

1.1 硬件差距不是妥协的理由

手头有一台很老的 386 DX2 机器，装着英文版 Windows 3.1，内存只有 8MB，硬盘 200MB，网卡倒是还在。这台机器平时干不了什么正经活，跑个画图程序都能让人等到怀疑人生，但偶尔开机听听蜂鸣器音乐，反而有一种奇怪的乐趣。

直到有天群里有人开玩笑：能不能让这台机器“蹭”一下现在的 AI。所有人都知道本地跑模型是没戏的——参数最小的现代模型也以百 MB 计，8MB 内存连加载都加载不下。但问题换个角度就豁然开朗：老机器跑不了模型，但它有完整的 TCP/IP 协议栈。只要能发出网络请求和接收响应，AI 这件事完全可以“外包”给后端。

于是项目目标就定为：把用户输入的问题从老机器发出去，再把 AI 回复显示回来。至于模型、推理、总数计算、并发调度，全部交给远端。这就是整个项目唯一起步正确的判断——老机器不该去解决算力问题，它只需要解决“对话”问题。

1.2 远程方案的首要矛盾不是算力，而是沟通成本

想法听起来简单，做起来才发现真正的难点不在“AI”，而在“沟通”。一台 Win11 机器和一台 Win3.1 机器虽然都叫 Windows，实际差异可以用“一个在天上一个在地下”来形容：一个是 64 位图形系统，一个是 16 位窗口外壳；一个原生 Unicode，一个只认识 ANSI 字节；一个自带现代网络库，一个还得靠 DOS 时代加载的网卡驱动来初始化 Winsock。

我最初的 v1 版本是在 Windows 11 上用 Python 写的，代码大约 500 行，包含异常处理、超时重试、JSON 解析、彩色终端输出、多轮对话的本地记录。功能很完整，但跑起来那一刻我意识到一个尴尬的事：这 500 行里，真正和“AI 对话”相关的核心路径可能只有 20 行，剩下 480 行都是现代系统给的便利和我在便利之上堆的复杂度。

堆复杂度很容易，砍复杂度很难。后来我做了一个关键决定：以一台 Win3.1 机器作为第一公民，让所有设计从“最穷环境”往回去推。这个决定看上去反直觉，却直接决定了后面 7 个版本的走向。

1.3 公共子集天然排斥高级功能

老机器和现代机器之间能共用的部分非常少：C 语言的经典语法、Winsock 1.1 的基础 API、最简单的窗口消息循环。凡是超出这个范围的功能，在某个老系统上大概率就会出幺蛾子。

所以项目的底层架构被压缩成一句话：用一个极小的原生程序，把用户输入的字节发送给一个“转发网关”，网关负责现代 AI 服务的鉴权、TLS 加密、请求拼接和编码转换，再把回复以老系统认识的编码原样返回。客户端不做任何加密、不做任何格式解析，只做收发和显示。

这套设计从一开始就注定了代码会越写越少，因为公共子集天然排斥高级功能。你越是想让代码覆盖更多老系统，就越没有空间去放那些“现代人觉得很正常”的东西。

2. 七次迭代，从 500 行跌到 29 行的决策树

2.1 v1 到 v3：先用现代工具验证需求，再一层一层"脱衣服"

第一步总是验证需求，所以我先用最舒服的方式把整个链路跑通。v1 是 Python 脚本，跑了完整的多轮对话流程，能正确处理超时、乱码、输入输出。完成度高于需求，但也暴露了问题：Python 运行时本身就要几百 MB 安装包，Win3.1 根本不认识这种文件。

v2 换成 C# + 图形界面，漂亮是漂亮，但依赖 .NET Framework，连 Windows XP 都跑得磕磕绊绊，更别提前面的系统。v3 退回到 .NET Framework 3.5，把覆盖范围拉到了 XP，但这时候我发觉方向错了——只要还依赖某个托管运行时，Win98 和 Win3.1 就永远是场外观众。

这三版的共同教训是：托管运行时的下限，就是整个系统的上限。想要真正下沉，只能放弃运行时带来的所有便利，回到原生代码。

2.2 v4 到 v5：纯 C + Win32 API，第一次拥有真正的跨版本能力

v4 是项目转折点。我把代码重写成纯 C + Win32 API，整个程序只有一个 exe，依赖降到系统自带的 kernel32 和 user32，不再需要任何运行时。第一次在 Windows XP、7、10、11 上都能跑通。

但此时离 Win98 还差一步：v4 里用的是比较新的网络接口，在老系统上解析不了。v5 把网络层切到 Winsock 1.1——这是 1990 年代 Windows 系统通用的套接字协议版本，几乎所有老系统的网络栈都认识它。移植完成后，覆盖范围一下子扩到 Win98/ME。代码行数也从 240 掉到 150，因为切到老接口时，很多现代 API 的“花活”都自动被排除了。

比如现代代码里经常会写“自动重试”和“超时管理”，但 Winsock 1.1 的老函数根本没有这些概念。你得自己实现，然而 150 行的体量又不允许你去实现得很完善，最后反而是“简单重试一次”的方案最实用。这条经验后来被我写进了项目文档：老环境会把你的设计逼向极简，但极简不等于脆弱。

2.3 v6 到 v7：Win3.1 的关卡和那 29 行

v6 是整个项目最痛苦的一版。Win3.1 是 16 位系统，内存模型、控件句柄、文件路径规则都跟 32 位系统不一样。程序必须能在 16 位和 32 位环境下编译出两个文件：一个给老的，一个给新的，核心逻辑则共用一份 C 代码。

最麻烦的是编码。Win3.1 中文环境下用的是 GBK 字节，而现代 AI 服务返回的是 UTF-8。老系统不认识 UTF-8，显示出来全是乱码。v6 的解决方案是：网关把所有内容按 GBK 转换好，老系统只负责把字节一个不差地打印出来。这一版代码行数压到 78 行。

v7 的目标就一句话：还能再少吗？我先画了一遍“金路径”，把输入、发送、接收、显示之外的所有内容都标记为可删，然后用宏把不同系统下的差异隐藏到编译期。最终版本固定为 29 行，一个入口函数，一个套接字，一个 GET 请求，一个接收循环。

版本演进可以用一张表看清：

2.4 为什么 29 行是必然结果

很多人问：为什么刚好是 29 行，是不是刻意炫技？坦率说，炫技的成分有，但更多是被逼的。每当我试图往程序里加一个功能，比如“显示 token 数”“带超时提示”“支持多行输入”，总会在某台老机器上触发一个新的兼容问题。Win3.1 的窗口控件不支持某些消息，Win98 的 Winsock 实现有奇怪的超时行为，NT4 的字符编码又跟 9x 系不一致。

换句话说，这些代码不是被“删”掉的，而是被系统差异“逼”走的。当程序只剩下最纯粹的“发请求、收响应、显示结果”时，所有系统的行为才终于对齐了。29 行不是一个美学目标，而是兼容性压力下的自然极限。

3. 老系统如何跟现代 AI 服务对话：核心链路拆解

3.1 网络层：Winsock 1.1 与现代 TCP/IP 的配合

Win3.1 上跑网络，前提是用户已经在 DOS 里加载了 TCP/IP 驱动，Windows 里能看到网络配置并且能 ping 通目标地址。项目的网络层直接使用 Winsock 1.1 的接口，初始化时调用WSAStartup(0x0101, &wsaData)，这代表请求 1.1 版本，老系统里很常见的新式 Winsock 2 反而不一定加载成功。

建立连接的过程在今天看来几乎是考古操作：先gethostbyname拿到 IP 地址，填sockaddr_in结构，然后socket+connect。好消息是这些函数从 1990 年代到现在名字和参数都没怎么变过，同一份 C 代码在 32 位系统里编译出来也能正常调用。

这里有一个极其关键的架构决策：老系统不能走现代加密协议。Win3.1 的协议栈连 TLS 1.0 都不认识，更别说现代版本了。所以我把所有安全操作都放到“转发网关”上：老系统发出的明文 HTTP 请求到网关，网关再跟 AI 服务建立加密连接、做鉴权，并把响应转回来。

安全红线：这个“客户端—网关”之间的明文链路，只能在隔离的实验内网里使用，绝对不要暴露到公网。项目文档里我用加粗字体写了三条警告，因为凡是跑老系统的人，都很容易把“看它能跑”当成“它可以随便跑”，这两者差别非常大。

3.2 编码层：GBK 和 UTF-8 之间，我把脏活全留给了网关

编码问题花了我三分之一的时间。现代 AI 服务默认返回 UTF-8，在 Win10/11 上显示完全没有问题；Win98 的英文版也能字节流式地显示一部分 ASCII；但到了中文环境的 Win3.1，UTF-8 的字节序列会被当成 GBK 去解释，结果就是一个字都认不出来。

最原始的方案是在客户端做转码，但转码代码至少增加 30 行，而且还涉及字节缓冲区的大小问题。后来我把转码逻辑放在网关里：网关收到老系统发来的 GET 请求，把 URL 上的 ANSI 字节按 GBK 解码为真实文本，再拼接请求；收到模型回复后，先把 UTF-8 转为 GBK，再原样返回。

客户端只做一个动作：把收到的每个字节打印到屏幕上。这样做之后，“编码”这个老大难问题在客户端视角彻底消失了。这也让我得出一个通用原则：老系统兼容性的最好边界，是让老系统永远不要处理它不认识的东西。谁有处理能力，谁就多干活。

3.3 内存模型：64KB 段限制如何逼出"流式收发"

16 位 Windows 的内存模型跟今天差距巨大。默认的char*是 16 位近指针，所能寻址的单个数据段最大只有 64KB。这意味着你不能随随便便声明一个大数组，比如char buffer[100000]，因为段内偏移放不下。

但这反而帮了我一个忙：既然放不下大缓冲区，就只能用小步长循环收数据。程序把接收缓冲区固定在 996 字节，每次recv只收到一个安全块，显示一段，再继续收下一段。这个设计顺带解决了很多老系统内存紧张的毛病——一个 1KB 的缓冲区，放在 8MB 内存的 386 上简直毫无压力。

后来我看那 29 行代码，recv循环就是整个程序的核心骨架。它不是在“读数据”，而是在“慢慢搬”。这个“搬”的过程在一个老系统上虽然谈不上流畅，但稳定，而且能保证哪怕响应有几十 KB，也不会把客户端内存打爆。

3.4 29 行代码实录

这是最终版的逻辑骨架，我用的是标准 C 加 Winsock 1.1，展示用教学式写法：

#include <winsock.h> #include <stdio.h> #define GW "192.168.1.10" #define PORT 8080 char buf[1024], q[200]; int main() { WSADATA w; SOCKET s; struct sockaddr_in a; struct hostent *h; WSAStartup(0x0101, &w); h = gethostbyname(GW); s = socket(AF_INET, SOCK_STREAM, 0); a.sin_family = AF_INET; a.sin_port = htons(PORT); a.sin_addr = *(struct in_addr*)h->h_addr; connect(s, (struct sockaddr*)&a, sizeof(a)); printf("Q> "); gets(q); sprintf(buf, "GET /q?text=%s HTTP/1.0\r\nHost: %s\r\n\r\n", q, GW); send(s, buf, strlen(buf), 0); while ((len = recv(s, buf, sizeof(buf) - 1, 0)) > 0) printf("%s", buf); closesocket(s); WSACleanup(); return 0; }

代码里的len变量在完整版里有定义，展示这里省略。注意几个演示性质的地方：gets是为了省行数，有缓冲区风险；URL 没有做百分号编码；请求方式用了最简单的 GET。这些在生产环境都是问题，但在这个项目里只有一半是问题——另一半正好体现了“代码越少越接近机器”的思路。

运行流程就是四步：初始化套接字、拼一个最朴素的 HTTP 请求、发出去、把响应循环打印。没有任何分支、没有任何退路，所以它才是 29 行，也因为没有任何分支，它在所有系统上的行为才足够一致。

4. 在七套老系统上做兼容性测试：工具和方法都不高级

4.1 虚拟机加实体机的测试矩阵

做这种兼容性项目，最大的问题不是写代码，而是凑齐测试环境。我手上真正的实体机有两台：一台 386 装 Win3.1，一台 Pentium 级别的机器装 Win98 SE。其他系统，包括 NT4、2000、XP、7、10、11，全部用虚拟机软件搭出来。

测试方案非常“土”：就是每个系统里放一个固定的批处理脚本，脚本先ping网关，再启动客户端程序问三组固定问题，看输出是否一致。手动操作虽然耗时，但好在客户端足够简单，测试一条龙下来不到十分钟。我每个月发一个新版本，就在这套矩阵上完整跑一遍。

下面是不同系统上容易出问题的地方：

测试里最反直觉的一条经验是：现代 Windows 上最容易出事儿的地方是防火墙和 DEP。Win3.1 那台机器，只要网络驱动装好了，反而一跑就通。时代倒了个个儿，老系统的问题集中在环境配好之前，新系统的问题集中在环境配好之后。

4.2 一次 DNS 解析超时的完整排查

Win98 这台测试机上有个问题让我折腾了整整两天：第一次运行客户端，请求秒回；退出再运行，就卡死在gethostbyname这一步，二三十秒后才报错。

最初的猜测是代码里没释放套接字，或者端口被占，但排查后排除。接着我用 IP 直连网关测试，结果每次都秒通，说明问题出在“域名解析”而不是“TCP 连接”。抓包工具在那个年代不普及，我只能在网关这边看访问日志，发现 Win98 那台机器向 DNS 服务器发出了重复请求，但第二个请求永远没有响应。

最终结论是：老 Winsock 驱动的 DNS 客户端有非常差的重传策略，第一个查询失败后，后续请求会长时间阻塞。而为什么第一次总是成功？因为网关上恰好有 DNS 缓存，第二次运行已经过了缓存有效期，于是问题才暴露。

修复方案不是去优化 DNS 重传——我改不了驱动，也不是给 Win98 换驱动——那样失去兼容性意义。最终方案很简单：配置文件里默认写网关 IP，而不是域名。反正这个程序的使用场景本来就是一个固定实验室环境，不依赖 DNS 反而更稳定。

4.3 中文乱码问题的头尾之战

Win3.1 中文版和 NT4 的中文版在同一套代码下显示结果不一样，这问题花了我大半个周末。现象是：Win3.1 显示正常，NT4 显示乱码；有时候反过来，Win98 能看到部分乱码。

我把两边收到的原始字节打出来对比，发现客户端拿到的数据完全相同，问题出在系统用什么代码页去解释。Win3.1 中文版直接按 GBK 显示没问题，NT4 的默认代码页需要额外设置，而 Win98 的英文版压根没有中文代码页。也就是说，同一份字节，在不同系统上“怎么看”完全取决于系统语言包。

最终我把网关做成“按需转码”：请求里带一个简单的Accept-Charset头，告诉网关“我是老系统，请把回复转成 GBK”。网关根据这个字段决定输出编码。客户端代码完全不用感知编码这件事。这个方案不够优雅，但对于一套面向考古硬件的程序来说，稳定性比优雅重要得多。

4.4 控件句柄的 16 位陷阱

Win3.1 上还有过一个“邪门”的问题：用同一个编译器参数编译出的程序，在这个系统上能显示消息，在另一个系统上点了按钮没反应。

排查后发现问题不在业务逻辑，而在 16 位环境下控件句柄的宽度。Win3.1 的某些窗口消息参数是 16 位的，而我在代码里声明了一个int类型的句柄。32 位环境没问题，16 位环境下高位被截断，消息就发给了错误的控件。

修复方式也很简单：把所有控件句柄和消息参数统一声明成WORD，并且用 16 位编译产物的代码路径单独分支。这个坑让我明白：在这种跨系统项目里，你永远要追问一句“这个类型在这个系统里到底占几个字节”，想当然地把所有类型都当成 32 位，老系统就会在某个角落狠狠咬你一口。

5. 开源之后，29 行代码真正教会我的事情

5.1 29 行代码真的够用吗

项目开源后收到的最多评论是：你这个能用，但它连“多轮对话”都没有，算什么 AI 应用？这话说得对，29 行版本确实不配叫一个完整的 AI 应用。它没有上下文记忆、没有流式输出、没有错误提示、没有重试逻辑。它唯一的意义，是证明了从 Win3.1 这种 1992 年的系统到 Win11 之间，存在一条极其细窄但走得通的 AI 通路。

我在项目描述里写得非常清楚：这是一个“最小可用证明”，不是一个产品。所有想要扩展功能的人，应该在这个证明的基础上往上加东西，而不是从零开始做兼容。开源社区里有人已经把它扩展成了 47 行的版本，加了循环接收和基础超时，也有人给它配上了一个 GUI，但核心网络路径仍然是我那 29 行。

5.2 一个用户报告把"能跑"和"每一次都能完整跑"分开了

有用户反馈说，在 Win3.1 实体机上经常收到半个回答就停住，有时要重新运行一次才能看到完整内容。一开始我没能复现，因为我的 386 测试机跑得慢但很稳定。后来那位用户把网卡换成了另一块老 PCI 网卡，问题稳定复现了。

看了他抓的原始网络数据，我意识到问题本质：我的 29 行代码只recv了一次，默认认为一个网络包就能装下全部回复。在慢速网络或 TCP 分片的情况下，AI 回复可能被拆成多个 TCP 段，单次recv看到的只是第一段。

修复逻辑其实很简单：把单次recv换成循环，直到对端关闭连接。这个改动增加行数不多，但从“大概率能跑”变成“每次都能完整跑”。这件事提醒了我：极简代码的每一行都必须回答一个问题——“上一个版本里用户报的 bug，是不是恰恰因为我省掉了不该省的一行？”后来我在仓库里同时保留了极简版和标准版，极简版用于考古演示，标准版用于实际日常使用。

5.3 如果让我重新做一遍，我只改一个决定

重做这个项目的话，我只会改一个最初的决策：不要先用 Python 和 C# 做原型，直接从 C + Winsock 起步。那两个现代原型浪费了我不少时间，因为现代系统的 API 会不断暗示你“代码本来就该这么复杂”——异常处理、超时、并发、多线程，但这些都是工具自带的习惯，不是问题本身的需求。

真正有用的切入方式是：先定义一条从用户输入到 AI 回复的最小字节路径，然后用最笨的语言把这条路径焊死。架构上的一切，包括网关、编码转换、版本分支，都是在这条路径旁边长的辅助设施。

最后分享一个复刻这类项目的实用技巧：在你决定支持一台老系统之前，先把它的 TCP/IP 栈彻底打通，用 ping 和一个极小的 socket 测试程序验证网络。如果这一步都不稳定，后面所有代码都会变成妥协；反之，只要网络通了，剩下的事情就是让代码尽量少干活。这个 29 行的项目虽然已经告一段落，但这个教训我会一直留到下一个项目里。