企业官网建设流程全解析

1. 项目概述：在古董电脑上运行现代AI

最近在折腾我那台1984年的IBM 5155便携式电脑，这台老伙计搭载的是4.77MHz的Intel 8088处理器和MS-DOS 6.22系统。一个偶然的想法冒了出来：能不能让这台几乎和我同龄的机器，也体验一下当下最火的AI对话？听起来像是天方夜谭，毕竟DOS系统连原生的HTTPS支持都没有，更别提运行复杂的现代应用了。但正是这种“不可能”的挑战，激起了我的兴趣。于是，我花了些时间，捣鼓出了一个名为doschgpt的概念验证项目。本质上，它是一个能在纯DOS环境下运行的客户端，可以连接后端的ChatGPT、Hugging Face或者本地部署的Ollama大语言模型，实现文本对话。这不仅仅是一个怀旧玩具，更是一次对软硬件极限的有趣探索，它证明了即使是最古老的个人计算平台，通过巧妙的架构设计，也能与最前沿的技术进行对话。

这个项目的核心价值在于“连接”与“简化”。它不是在DOS上从头训练一个AI模型（那确实不可能），而是充当一个极其轻量级的“终端”，将用户在本地的输入，通过一个精心设计的网络管道，发送到远端的强大AI服务器，再把结果带回来显示在古老的CRT屏幕上。整个过程涉及DOS下的网络编程、内存管理、与现代化API的对接，以及如何在极度受限的环境下（640KB常规内存是天花板）保持程序的稳定和可用。如果你也对复古计算、嵌入式网络或者只是想看看AI如何与80年代的硬件共舞感兴趣，那么接下来的内容应该能给你不少实操的启发和避坑指南。

2. 核心架构与设计思路拆解

2.1 为什么需要HTTP-to-HTTPS代理？

这是整个项目面临的第一个，也是最重要的技术障碍。MS-DOS及其时代的网络栈（如我们使用的MTCP）诞生于互联网的早期，当时SSL/TLS加密尚未成为网页传输的标准。因此，这些栈通常只提供纯HTTP和底层TCP/IP支持，而没有内置的HTTPS（即HTTP over TLS）库。而OpenAI和Hugging Face的现代API端点无一例外都强制使用HTTPS。

直接让DOS程序实现TLS是不现实的：TLS协议本身及其所需的加密算法（如AES、RSA）对8088 CPU来说是沉重的负担，且会消耗大量宝贵的内存。因此，最务实的方案是引入一个“中间人”——一个运行在现代机器（比如你日常用的笔记本电脑或树莓派）上的代理服务。这个代理的工作流程非常清晰：

1. 监听：代理在现代机器上启动，监听一个指定的TCP端口（例如8080），等待来自DOS客户端的纯HTTP连接。
2. 转发：DOS客户端doschgpt.exe将API请求（包括模型、消息、温度等参数）以纯HTTP格式发送到这个代理。
3. 升级与转发：代理接收到HTTP请求后，将其转换为HTTPS请求，并通过现代操作系统的网络栈安全地发送到真正的AI服务提供商（如api.openai.com）。
4. 回传：代理收到HTTPS响应后，剥离TLS加密层，将纯文本的HTTP响应回传给DOS客户端。

这样，DOS端就完全无需处理加密，只需要关心最基础的HTTP/1.1协议文本的组包和拆包。我为此专门编写了一个轻量级的Go语言代理程序http-to-https-proxy，它只做最直接的协议转换，开销极小，非常适合在资源有限的单板计算机（如树莓派Zero）上常驻运行。

注意：对于本地部署的Ollama服务，情况有所不同。Ollama默认使用未加密的HTTP接口（通常在http://localhost:11434）。因此，如果你的DOS机器和运行Ollama的机器在同一个可信局域网内，你可以让doschgpt直接连接到Ollama服务器的IP和端口，完全绕过代理。这简化了部署，但也意味着通信内容在局域网内是明文的。

2.2 网络栈选择：为什么是MTCP？

在DOS下搞网络，你不是在调用标准的socket()API。你需要一个专门的DOS TCP/IP实现。常见的选择有Watt-32、DJGPP下的Allegro库网络部分，以及MTCP。我选择MTCP基于几个关键考量：

1. 纯粹性与兼容性：MTCP是专门为16位实模式DOS设计的TCP/IP栈，不依赖任何32位扩展器（如DOS/4GW）。这意味着它可以在最“纯净”的DOS环境下运行，兼容性极广，从最早的8088到后期的486 DOS实模式都能稳定工作。
2. 与Packet Driver的完美集成：DOS下的网络硬件驱动标准是“Packet Driver”（包驱动）。MTCP被设计为直接与Packet Driver接口通信，这种设计非常底层和高效。你只需要加载对应网卡（即使是NE2000兼容的ISA网卡或某些虚拟机虚拟网卡）的Packet Driver，然后配置MTCP即可。
3. 资源消耗可控：MTCP以小巧和高效著称。你可以通过配置文件（mtcp.cfg）精细地控制其内存使用，例如TCP socket数量、接收缓冲区大小等。这对于只有640KB常规内存的DOS系统至关重要。
4. 优秀的文档与示例：MTCP的作者Michael Brutman提供了清晰的文档和大量示例代码。doschgpt的网络通信部分几乎完全基于其提供的HTTP客户端示例改造而来，这大大降低了开发难度。

2.3 内存与上下文管理的权衡

DOS的640KB内存限制是悬在头顶的达摩克利斯之剑。一个典型的AI对话会话可能轻松产生数十KB的文本历史。如果尝试将整个对话历史都保存在内存中并随每次请求发送，很快就会耗尽内存，导致程序崩溃。

因此，我采取了一个折中的、对资源友好的策略：仅发送上一轮对话的上下文。具体来说，程序在内存中只维护两个字符串缓冲区：一个用于保存用户上一次的提问（previous_request），另一个用于保存AI上一次的回答（previous_reply）。当用户发起新一轮对话时，程序会将[previous_request, previous_reply, current_request]这个结构组装成API所需的JSON格式（对于ChatGPT是messages数组，对于Hugging Face是特定的指令格式）发送出去。

这样做的优缺点非常明显：

• 优点：内存占用恒定且极小，无论对话进行多久，都只存储最近的两条消息。程序运行稳定，不会因对话增长而变慢或崩溃。
• 缺点：模型失去了更早的对话历史背景。这意味着如果你在第十轮对话中问“它是什么颜色？”，模型将无法知道“它”指的是第一轮对话中提到的“我的车”，因为第一到第八轮的对话历史已经丢失。模型只能基于最近的一问一答来推理。

对于大多数简单的、回合制不强的问答，这个策略完全够用。这也是我在项目说明中提及“如果这对你是个问题，请告诉我”的原因。如果确实需要更长上下文，方案会复杂很多，可能需要将历史记录写入磁盘文件，并在每次请求时动态地从磁盘读取和组装部分历史，但这会显著增加I/O延迟和代码复杂度。

3. 详细配置与实操部署指南

3.1 环境准备：DOS侧的搭建

要让doschgpt跑起来，你需要一个配置好的DOS网络环境。以下是在一台真实古董机或像VirtualBox/86Box这样的虚拟机中的标准设置流程：

1. 准备DOS系统：安装MS-DOS 6.22或更高版本。确保系统启动后至少有500KB以上的可用常规内存（可用mem命令查看）。这通常需要合理管理HIMEM.SYS、EMM386.EXE，并精简AUTOEXEC.BAT和CONFIG.SYS中的内存驻留程序（TSR）。
2. 安装Packet Driver：
   • 真实硬件：找到与你ISA网卡（如NE2000兼容卡）对应的Packet Driver（通常是一个.com文件，如ne2000.com）。在AUTOEXEC.BAT中加入一行：C:\NET\NE2000.COM 0x60（0x60是软件中断号，可更改）。
   • 虚拟机：VirtualBox等虚拟机通常提供“虚拟的”Packet Driver。例如，VirtualBox的“Intel PRO/1000 MT Desktop”网卡可以使用vboxdp.com这个驱动。同样将其加载到内存中。
3. 配置MTCP：
   • 下载MTCP包，将其中的MTCP.COM、DHCP.EXE、PING.EXE等工具和MTCP.CFG配置文件拷贝到DOS机器的一个目录（如C:\MTCP）。
   • 设置环境变量，告诉MTCP配置文件在哪：SET MTCPCFG=C:\MTCP\MTCP.CFG。
   • 编辑MTCP.CFG文件。如果你使用DHCP，配置相对简单。如果需要静态IP，你需要手动指定IP、子网掩码、网关和DNS。一个静态IP的配置示例：

     # MTCP.CFG hostname MYDOSPC # 使用静态IP ip 192.168.1.200 netmask 255.255.255.0 gateway 192.168.1.1 nameserver 192.168.1.1 # 你的路由器或公共DNS packetint 0x60 # 必须与加载Packet Driver时使用的中断号一致

4. 测试网络：运行DHCP（如果动态获取）或直接运行MTCP初始化栈。然后使用PING命令测试是否能通你的现代主机（运行代理的那台机器）的IP地址。ping 192.168.1.100。如果成功，说明DOS侧的网络基础已经打通。

3.2 代理服务器与API配置

1. 部署HTTP-to-HTTPS代理：
   • 在你的现代机器（Windows/macOS/Linux）上，从项目仓库下载http-to-https-proxy的对应版本。
   • 通过命令行运行它。默认情况下，它会监听本机8080端口，并将请求转发到https://api.openai.com。你可以通过参数修改监听端口和上游目标。
   • 关键步骤：防火墙：确保现代主机防火墙允许入站连接到代理监听的端口（如8080）。否则DOS客户端无法连接。
2. 获取并配置API密钥：
   • OpenAI：前往 OpenAI平台 创建API Key。选择gpt-3.5-turbo或gpt-4o等模型。注意保管好Key，它会在doschgpt.ini中以明文配置。
   • Hugging Face：前往 Hugging Face设置 创建Token，选择Read权限即可。同样用于配置。
   • Ollama：本地部署无需Key，但需确保Ollama服务已启动，且通过环境变量OLLAMA_HOST=0.0.0.0允许局域网访问。
3. 编辑doschgpt.ini配置文件： 这是程序运行的核心。你需要仔细填写以下字段：

   [config] ; OpenAI 或 Hugging Face 的API密钥。Ollama模式可留任意字符，但必须有一行。 apikey = sk-你的OpenAI-Key-在这里 ; 使用的模型。ChatGPT: gpt-3.5-turbo, gpt-4o。 Hugging Face: mistralai/Mistral-7B-Instruct-v0.3。 Ollama: llama3.2, mistral 等。 model = gpt-3.5-turbo ; 温度参数，控制随机性。0.0最确定，1.0最随机。建议0.7-0.9。 temperature = 0.7 ; 代理服务器或Ollama服务器的IP地址 proxyhost = 192.168.1.100 ; 代理端口（如8080）或Ollama端口（默认11434） proxyport = 8080 ; 本地端口范围，用于建立TCP连接。保持默认即可，除非有冲突。 localportstart = 2000 localportend = 2010 ; 连接超时（毫秒），网络慢可适当调高 connecttimeoutms = 10000 ; 响应超时（毫秒），等待AI回复的时间，根据模型速度调整 responsetimeoutms = 120000

   实操心得：responsetimeoutms（响应超时）是关键参数。在8088这样的慢速CPU上，网络栈处理数据本身就需要时间，加上AI模型生成回复可能需要数十秒。我曾将其设为30秒，结果在模型思考较长问题时频繁超时。建议设置为120秒（120000毫秒）或更长，给足等待时间。

3.3 运行与基础故障排查

配置完成后，在DOS命令行下直接运行doschgpt.exe即可。程序会尝试读取doschgpt.ini，连接代理，并进入一个简单的全屏文本界面。你可以直接打字提问，按回车发送。按ESC键退出。

首次运行常见问题排查：

1. “Packet driver not found” 或 “MTCP not initialized”：

   • 检查：运行mtcp命令看是否有错误。运行ping 127.0.0.1测试MTCP自身环回。
   • 解决：确认Packet Driver已正确加载（查看AUTOEXEC.BAT和内存驻留程序列表）。确认MTCPCFG环境变量指向正确的配置文件路径。确认配置文件中packetint的中断号与驱动加载时一致。

2. “Could not connect to proxy”：

   • 检查：在DOS端用ping 192.168.1.100（你的代理IP）测试网络连通性。
   • 解决：确保代理程序正在现代主机上运行。检查现代主机防火墙是否放行了代理端口（如8080）。确认doschgpt.ini中的proxyhost和proxyport填写正确。

3. “API error” 或收到HTTP 4xx/5xx错误：

   • 检查：使用-drr参数运行程序（如doschgpt.exe -drr），这会显示原始的HTTP响应头和信息。常见的401错误是API Key无效或过期；429错误是触发了OpenAI的速率限制。
   • 解决：核对API Key是否正确无误且有余额。对于免费试用的OpenAI Key，注意其有每分钟/每天的请求限制。可以稍后再试，或升级账户。

4. 程序启动后立即退出或无响应：

   • 检查：内存可能不足。DOS下可用mem查看。doschgpt.exe本身不大，但MTCP和Packet Driver会占用一部分。确保“Largest executable program size”至少还有300KB以上。
   • 解决：优化CONFIG.SYS和AUTOEXEC.BAT，移除不必要的驱动和TSR。使用LH（LoadHigh）命令将一些程序加载到上位内存（UMA）。

4. 高级功能与深度使用技巧

4.1 语音合成：让古董机“开口说话”

让一台1984年的电脑用语音读出AI的回复，这大概是整个项目中最有“赛博朋克”复古未来感的特性了。实现依赖于一块Sound Blaster（或100%兼容）的声卡和相关的文本转语音（TTS）驱动。

1. 硬件与驱动准备：

   • 你需要一块ISA接口的Sound Blaster（或AdLib，但SB更常见）声卡，并正确安装到DOS机器上。在AUTOEXEC.BAT中设置环境变量SET BLASTER=A220 I5 D1 T4，这分别指定了端口地址、中断号和DMA通道。
   • 从项目发布的文件或WinWorld等存档站点获取Sbtalker.exe（First Byte的SmoothTalker TTS引擎）、Blaster.drv（声卡驱动）和Remove.exe（卸载程序）。将它们与doschgpt.exe放在同一目录。

2. 启用语音功能：

   • 运行doschgpt.exe时，加上-sbtts参数即可：doschgpt.exe -sbtts。
   • 程序启动时会自动尝试加载Sbtalker.exe作为TSR，退出时调用Remove.exe清理。AI的每一条文字回复都会通过这个引擎转换为语音，从声卡输出。
   • 性能注意：语音合成在8088 CPU上是一个沉重的负担。实测中，合成一段中等长度的回复会导致系统明显变慢，甚至可能影响网络响应。建议仅在CPU主频高于8MHz（如286、386）的机器上稳定使用此功能。

3. 替代方案与集成：项目后期集成了dosbtalk库，这是一个直接与First Byte引擎通信的库，理论上比通过外部TSR调用更高效、更稳定。如果你从源码编译，可以关注这部分代码，它提供了更底层的控制接口。

4.2 调试与日志：洞察程序内部

doschgpt提供了多个命令行调试参数，对于开发和排查问题极其有用。合理组合使用它们，可以清晰地看到程序每一步在做什么。

• -dri：显示请求详情。在每次请求后，打印出本次连接使用的本地端口号、以及从API返回的token使用量（Prompt Tokens和Completion Tokens）。这对于监控API消耗非常直观。
• -drr：显示原始响应。这是最强大的调试工具。它会将服务器返回的完整HTTP响应头和JSON内容打印到屏幕上。当遇到API错误时，这里会显示具体的错误码和消息，是诊断问题的第一现场。
• -drt：显示时间戳。在每个请求和回复旁加上本地时间戳。可以用来评估网络延迟和AI模型的响应速度。
• -fhistory.txt：保存完整历史。将所有对话内容（如果同时启用-drr，则包括调试信息）追加写入到指定的文本文件中。这对于事后分析对话流或调试信息非常方便。

示例组合使用：

doschgpt.exe -hf -chf.ini -drt -fdebug.log

这条命令会：1) 使用Hugging Face模式；2) 读取hf.ini配置文件；3) 显示时间戳；4) 将所有输出（对话和时间戳）保存到debug.log文件。

4.3 针对不同后端的配置差异

虽然程序试图用统一的接口对接三个后端，但它们在配置和表现上仍有细微差别，需要特别注意：

1. OpenAI (ChatGPT)：

   • 配置：在doschgpt.ini中，apikey必须填写有效的OpenAI Key，model填写如gpt-3.5-turbo。
   • 特点：响应格式最规范，速度通常最快（尤其是GPT-3.5），token计数准确（-dri参数有效）。但受限于API速率和费用。
   • 代理：必须通过http-to-https-proxy转发。

2. Hugging Face Inference Endpoints：

   • 配置：使用-hf参数启动。apikey填写Hugging Face的User Access Token，model填写完整的模型ID，如mistralai/Mistral-7B-Instruct-v0.3。
   • 特点：免费额度慷慨。但需要注意，Hugging Face的对话API格式与OpenAI不同。doschgpt内部已经做了适配，会将历史记录格式化为[INST]...[/INST]的格式。模型响应速度取决于HF后端负载，有时较慢。
   • 代理：同样必须通过代理，因为其端点也是HTTPS。

3. Ollama (本地部署)：

   • 配置：使用-ol参数启动。apikey可任意填写（但不能为空），model填写你在Ollama中拉取并运行的模型名，如llama3.2、mistral。proxyhost和proxyport直接填写运行Ollama服务的机器IP和端口（默认11434）。
   • 特点：完全本地，无网络延迟（局域网内），无费用，隐私性好。响应速度取决于你本地服务器的CPU/GPU性能。Token计数同样支持。
   • 代理：不需要代理，直接HTTP连接。务必在运行Ollama的机器上设置OLLAMA_HOST=0.0.0.0以允许外部连接。

5. 开发环境搭建与编译指南

如果你想自己修改代码、添加功能，或者只是好奇它是如何从C源码变成那个小小的EXE文件的，那么你需要搭建一个特定的16位DOS开发环境。

5.1 编译器选择：为什么是Open Watcom 2.0 Beta？

现代编译器如GCC、Clang主要面向32/64位系统，无法生成纯16位实模式的DOS可执行文件。Open Watcom是一个曾经与Borland、Microsoft齐名的经典编译器套件，其遗产版本至今仍被广泛用于复古编程和嵌入式开发，因为它对16位DOS和32位扩展DOS（DOS/4GW）的支持非常成熟。

我特别推荐使用Open Watcom 2.0 Beta（2025-08-02版本），而非稳定的1.9版本。原因在于，2.0 Beta版本修复了许多在古老硬件（如Compaq Portable）上运行时出现的微妙问题，生成的二进制文件兼容性更好。你可以在GitHub的Open Watcom发布页找到它。

安装与设置要点：

• 安装时，建议不要让安装程序永久性地修改系统环境变量。这可以避免与你现有的现代开发工具链冲突。
• 取而代之的是，创建一个批处理文件（例如setenv.bat），在其中临时设置Watcom所需的环境变量（WATCOM,PATH,INCLUDE,LIB等）。每次需要编译时，先在这个命令行环境下运行这个批处理文件。

  @echo off set WATCOM=C:\WATCOM set PATH=%WATCOM%\binnt;%WATCOM%\binw;%PATH% set INCLUDE=%WATCOM%\h set LIB=%WATCOM%\lib286

• 注意LIB路径指向lib286，因为我们编译的是16位实模式程序。

5.2 编译流程与依赖管理

项目使用wmake（Watcom的make工具）来管理编译，其Makefile很大程度上参考了MTCP库自身的编译脚本。

1. 获取依赖：

   • 克隆或下载doschgpt的源代码。
   • 下载最新版的MTCP源代码包（如mTCP-src_2025-01-10.zip），将其解压到项目目录下的mtcpsrc文件夹中。确保mtcpsrc目录内有mtcp.lib、mtcp.h等文件。

2. 编译步骤：

   # 1. 打开命令行，进入源码目录 cd doschgpt-code # 2. 设置Watcom环境变量（执行刚才创建的setenv.bat） setenv.bat # 3. 执行编译 wmake

   如果一切顺利，你会在当前目录下得到doschgpt.exe。如果使用Open Watcom 1.9，可能还需要运行MTCP提供的PTACH.exe工具对生成的可执行文件进行一个特殊补丁，以解决在某些特定硬件上的兼容性问题。2.0 Beta版本通常不需要这一步。

3. 测试与部署： 编译出的二进制文件可以直接在DOS实模式下运行。为了快速测试，我强烈推荐使用虚拟机。我在VirtualBox中配置了一个纯净的MS-DOS 6.22虚拟机，并设置了共享文件夹或使用htget工具通过网络传输编译好的exe文件，这比用软盘映像来回倒腾高效得多。

5.3 开发调试技巧：模拟代理与网络抓包

在开发过程中，频繁调用真实的OpenAI API既慢又浪费额度。我采用了两个方法来提升调试效率：

1. 使用模拟代理（Mock Proxy）： 项目附带了一个用Go编写的小工具mockprox.go。它的功能非常简单：启动一个本地HTTP服务器，无论收到什么请求，都固定返回reply.txt文件中的内容。你可以把一段预设的、格式正确的AI回复JSON放入reply.txt。

   # 准备一个正确的回复样本 cp correct_reply.json reply.txt # 编译并运行模拟代理 go build mockprox.go ./mockprox.exe

   然后，将doschgpt.ini中的proxyhost指向运行mockprox的机器IP，proxyport设为它监听的端口（默认8080）。这样，doschgpt的所有请求都会得到这个固定的回复，非常适合测试程序解析响应、处理网络超时、界面显示等逻辑，而无需消耗真实的API。

2. 结合现代工具进行网络抓包： 虽然DOS端的调试手段有限，但我们可以利用运行代理的现代主机进行监控。在运行http-to-https-proxy的机器上，使用像Wireshark或Fiddler这样的抓包工具。

   • Wireshark：可以过滤tcp.port == 8080来查看DOS客户端与代理之间的所有纯HTTP通信。你能看到原始的HTTP请求头和JSON载荷，确保数据格式正确。
   • Fiddler：作为HTTP调试代理，可以更直观地截获、查看甚至修改HTTP/HTTPS请求。你可以让http-to-https-proxy将请求先发往Fiddler（作为上游代理），再由Fiddler转发到真实的OpenAI。这样就能完整地看到HTTPS层面的请求和响应，对于调试复杂的API错误非常有用。

6. 常见问题、故障排查与优化实录

在实际部署和运行过程中，你肯定会遇到各种各样的问题。下面是我在多次测试中踩过的坑和总结出的解决方案，希望能帮你节省时间。

6.1 连接与网络类问题

6.2 程序运行与功能类问题

6.3 性能优化与稳定性建议

1. 最大化可用内存：这是DOS下所有程序稳定运行的基石。深入研究CONFIG.SYS和AUTOEXEC.BAT的优化。使用DEVICEHIGH和LOADHIGH将驱动和程序载入上位内存区（UMA）。移除不需要的驱动（如光驱驱动MSCDEX、鼠标驱动等）。

2. 调整MTCP参数：编辑MTCP.CFG，可以尝试减小TCP窗口大小、减少最大socket数量来节省少许内存。但对于doschgpt，默认的MTCP配置通常已足够。

3. 使用更轻量的模型：如果你使用Ollama，可以尝试更小的模型，如tinyllama，它在慢速CPU的服务器上也能更快响应，减少超时风险。

4. 为代理服务器减负：确保运行http-to-https-proxy的现代主机网络通畅。如果可能，将其放在与DOS机器同一局域网段，并确保该主机到互联网的延迟较低。

5. 耐心是关键：在8088/8086这样的CPU上，每一次键盘输入、屏幕滚动、网络封包处理都比现代计算机慢成千上万倍。与doschgpt交互需要一种“复古的耐心”。等待AI回复时，看着光标闪烁，仿佛回到了那个拨号上网、等待网页一行行加载的时代，这本身就是体验的一部分。

这个项目就像一座桥梁，连接了两个计算时代。它没有追求极致的效率或功能，而是探索了一种可能性。当你看到绿色的CRT屏幕上缓缓打出AI对某个哲学问题的思考时，那种时空交错的感觉非常奇妙。它提醒我们，技术的进步是迭代的，但创造力和探索精神是永恒的。如果你也成功运行起来了，不妨试试问它一个经典问题：“你认为MS-DOS在计算机历史中的地位是什么？”然后，听听来自2024年的AI，如何通过一台1984年的机器，来评价这段历史。