OKOK大家好欢迎大家来到大鹏 AI 教育我是张大鹏。今天我想复盘一个有点反常的决定。我不是因为 Docker 做不出来而放弃它。恰恰相反我已经为如意浏览器做出了多阶段镜像、Compose 开发环境、真实 Camoufox 容器测试和内部持续集成然后又把这些东西从当前项目里移除了。这篇文章只回答一个问题一个技术方案已经能运行为什么我仍然决定停止投入Docker 最初为什么很有吸引力如意浏览器依赖的不只是 Node.js。它还依赖 Camoufox、Playwright、字体、图形库和浏览器运行环境。只要开发机、测试机和最终运行环境不一样就可能出现“我的电脑正常换台机器就失败”。Docker 对这种项目天然有吸引力把系统依赖、Node 版本和浏览器环境一起固定下来开发、测试和运行尽量使用同一套基础镜像。从技术逻辑看这个方向没有问题。所以我没有只写一份 Dockerfile 就停下而是把镜像、Compose、真实浏览器测试和 CI 都走了一遍。问题也正是在走完整条链路后才变得清楚。我真正要优化的不是环境一致性项目当时已经明确了三个事实它首先是我和 AI 助手长期使用的本地浏览器。正式运行平台是 Windows。后续还要交给学习项目的学生使用。在这个范围里最重要的问题不是“如何让 Linux 容器更像生产环境”而是Windows 上能否双击启动浏览器窗口会不会自己消失AI 能否操作人正在观察的同一个窗口学生遇到端口、Node 或安装问题时能否自己判断ZIP、安装、回滚和卸载是否可靠。Docker 解决的是一组真实问题但不是当时最贵的那组问题。当前不是最高优先级项目真实目标Windows 本地 AI 浏览器学生可安装和自检可见窗口与可靠恢复Docker-firstLinux 环境一致性容器测试与 CI技术上能做不等于现在该做工程里最容易掉进去的坑是把“已经投入很多”当成“必须继续投入”的理由。如果我继续沿 Docker-first 往下走还要长期维护容器基础层、Compose、缓存、CI、Windows 与 Linux 浏览器行为差异以及学生电脑上的 Docker Desktop 和 WSL 资源问题。这些工作不是没有价值而是会持续推迟更直接的目标。所以我重新做了一次范围判断判断问题当前答案是否需要公共云部署不需要是否有多开发者统一 Linux 环境暂时没有是否以 Windows 可见浏览器为正式体验是是否需要学生快速安装和自检是是否需要保留未来跨平台可能性是但不提前实现结论不是“Docker 不好”而是“Docker-first 不适合当前阶段”。我删掉了什么又保留了什么当前项目树移除了 Docker、Compose、Railway、Linux VNC、公共发布和外部崩溃中继等路径并增加了范围检查防止它们在同步上游代码时被悄悄带回来。与此同时我保留并继续加强了这些能力Windows 浏览器 ZIP安装、校验、回滚和卸载开始菜单快捷方式和正确图标AI 托管的可见浏览器学生自检、修复和脱敏支持包Windows 真实浏览器 smoke、recovery 和 soak。这不是从“工程化”退回“手工作坊”。工程化仍然存在只是围绕真实用户重新排序。这次路线反转给我的三个提醒第一基础设施必须服务当前产品边界。技术再标准如果没有缩短用户完成任务的路径就应该重新评估优先级。第二做完一次实验并不浪费。正因为镜像、Compose 和容器测试都真正跑过我才能基于证据停止而不是凭感觉否定。第三删除也是交付。删掉不再需要的维护面意味着以后同步上游、排查问题和给学生讲解时都少一层复杂度。哪些事情还不能下结论这次决策只适用于当前的如意浏览器私有、个人使用、Windows-first并服务一部分学生。如果以后出现 Linux 服务器部署、多开发者协同、公开 SaaS 或跨平台课程需求我会重新立项评估容器而不是把今天的选择当成永久禁令。我也没有做 Docker 与 Windows 的统一性能基准所以这篇文章不讨论谁更快。我的结论我最终让如意浏览器回到 Windows不是因为 Docker 失败而是因为我终于把问题问对了当前最值得节省的是环境差异还是开发者、AI 和学生的总工时对这个阶段的如意浏览器答案是后者。技术路线不是信仰。能根据真实目标及时停止和把功能做出来一样重要。