前阵子有个朋友问我你有没有试过不用电脑、光靠一部手机把代码写完我当时第一反应是“疯了吧”。但笑完之后我认真想了一下。我确实经常在地铁上只想改一个变量名却要打开远程终端、连编辑器都打不开就为了线上配置里一个timeout参数。那之后我开始琢磨如果“手机上写代码”这件事本身不疯狂只是市面上没有一套针对手机而非 PC 的 AI 编程平台架构那我们能不能自己把它做出来。WebCode 就是我在这条路上跑出来的一个答案。这篇文章不是一份产品说明书而是一个项目的完整复盘。我会把从想法到架构、从踩坑到最终形态的整个过程都写出来尽量多放技术细节和取舍背后的理由。如果你正在做 Web IDE、移动端开发工具或者想在一个相对窄的领域里把 AI 编程能力落地这篇文章应该能给你一些参考。1. 从“地铁上改 Bug”到认真立项WebCode 想解决的不只是编辑器问题最早有这个冲动不是因为想要“随时随地写代码”这种浪漫化的诉求而是被现实逼的。那天我在通勤路上接到反馈说某个接口超时时间写错了需要改一行配置。我掏出手机试图用一键命令行工具连服务器结果先被终端字体小到看不清楚劝退又被命令行嵌套的引号转义搞得七荤八素。最后折腾了十五分钟才改完体验差到我想把手机扔出车窗。这个场景暴露的问题让我意识到真正的阻碍根本不是“手机上能不能装 IDE”而是已经存在几十年的移动端远程编辑从来都是直接把桌面终端或桌面编辑器压缩到小屏里。它们没有为手机形态做过任何适配所以无论功能多强大用户都会觉得“疯狂”。1.1 那些“看起来能行”的方案其实都不行先说说我最初调研过的几条路每一路都死得很快。第一SSH Vim。这是技术人最容易想到的方案。在手机上装一个终端模拟器连上服务器后用 Vim 改代码。缺点非常致命移动键盘没有Esc没有Ctrl连移动光标都只能用全键盘上的上下左右键效率低到反人类。再加上手机屏幕尺寸根本撑不起多窗口布局改一行代码能急死一头牛。第二远程桌面类 App。类似把电脑屏幕镜像到手机上或者用 RDP 连回办公室电脑。画面倒是完整但延迟、画面缩放、文字清晰度全部不合格拖动一次滚动条等于在摸鱼。而且这类方案对网络链路要求太高4G 环境下基本没法用。第三用手机浏览器打开一个在线 Web IDE。像 Cloud IDE 这类服务把 VS Code 搬到浏览器里PC 上用没问题。但放到手机上以后布局挤压、菜单重叠、标签页被挤成省略号最关键的是所有交互都是为鼠标设计的。手机用户觉得每一步操作都在跟页面斗智斗勇。这些尝试让我确定了一件事不是“手机上写代码”这个目标有问题而是现成的方案都建立在桌面心智模型上没有人替小屏幕、触控、虚拟键盘和移动网络写过真正的调度逻辑。1.2 WebCode 的立项原则把手机当成独立平台而不是 PC 的退化版WebCode 从一开始就定了一个原则手机不是缩小版的电脑而是信息密度更低、中断频率更高、网络更不稳定的独立平台。所以整个产品设计逻辑必须围绕移动端的特点重建而不是把桌面功能列表抄一遍。围绕这个原则我列了三个核心需求用户在手机上能完成从查看代码、修改代码、运行代码到看测试结果的完整闭环保留 AI 编程助手的能力比如补全、解释、生成、改错但不能简单套一个聊天窗在编辑器旁边任何一次异常退出都不能丢失用户当前的工作进度移动端 App 被切后台、等下再打开状态必须还能接上。后面的架构设计基本都是从这几点推导出来的。你可能已经注意到这里没有把“最高性能”放在第一位这是刻意的。移动场景下的第一痛点永远是“能不能在需要时属于我的环境里继续动手”而不是“帧率拉满”。2. 架构骨架五层划分与各层的真实职责边界想通需求以后我开始画系统的整体结构。最初只有三块浏览器界面、服务器执行环境、AI 能力。但实际落地以后我发现这三块之间需要一层清晰的调度中枢否则浏览器界面和 AI 模型都各自要为“会话状态、项目文件、执行结果”负责逻辑会迅速变成一团乱麻。于是 WebCode 最终演化为五层架构。每一层的边界比最开始清晰得多故障排查也容易得多。层级核心职责关键组件一旦出问题的表现展示层渲染编辑器、操作面板、AI 结果流PWA 前端、Monaco Editor、Web Worker白屏、输入卡顿、页面闪退接入层处理连接、鉴权、协议转换HTTPS、WebSocket、SSE连接超时、消息串发、鉴权失败控制层管理会话生命周期、项目快照、权限Session Manager、Snapshot Store项目状态丢失、多人冲突执行层在隔离环境里跑命令语言、测试容器沙箱、资源配额、容器编排OOM、进程挂死、构建超时模型层提供 AI 补全、解释、生成代码大模型、Prompt Engine、上下文缓存响应慢、生成错误代码、上下文跑偏2.1 为什么前端选 PWA 而不是原生 App做移动端工具逃不掉 PWA、React Native、Flutter、纯原生这几个选项。我最后选了 PWA不是因为 PWA 更先进而是因为项目在验证期。但它确实有独特的优势。PWA 可以安装到手机桌面体验上接近原生但它本质上是一个网页。这意味着 iOS 和 Android 可以使用同一套代码不需要分别开发两套原生工程也不用走应用商店审核。对一个还在迭代 UI 和交互的新项目来说这个速度优势比什么都重要。更重要的是PWA 天然支持 WebSocket。AI 补全和运行日志都是高频、低延迟、双向通信的场景原生 App 里做 WebSocket 还要处理生命周期网页里反而干净。配合浏览器的 IndexedDB前端可以先把用户编辑内容落盘等网络恢复后再同步到沙箱。对移动弱网环境的容忍度比原生 App 自行实现缓存要高很多。2.2 控制层是五层里最容易被低估的一层很多 Web IDE 架构都会直接跳过“会话管理”这一步用户连接上服务器开一个 Shell 或一个编辑器插件完事。但 WebCode 不能这样做。因为手机用户的操作是高度断续的。举个例子用户在地铁上打开项目改了一半信号丢失。他回到办公室再打开手机时屏幕上应该立刻恢复到他离开时的文件列表、光标位置、甚至终端输出。这个目标要求项目的所有状态都被控制层持久化而不是只保存在前端内存里。所以控制层维护了三类状态一是项目文件系统快照包括内存中还没写入磁盘的改动二是会话内运行进程状态比如正在执行的构建任务和它的输出三是 UI 状态比如当前打开哪个文件、光标在哪、AI 对话滚动位置。控制层的 Session Manager 每隔几秒把这些状态的变更记录到对象存储重连时按快照恢复。这套机制后来成了 WebCode 稳定性的基石。3. 小屏上的编辑器内核调优Monaco/LSP 在移动端的性能取舍编辑器内核是整个 WebCode 里看起来最“成熟”、实际坑最多的部分。我选用了 Monaco Editor主要是因为它已经有丰富的生命力和生态代码高亮、智能补全、语义着色都直接可用。但它最初是为桌面浏览器设计的一个完整构建包动辄数兆字节移动端加载又慢又卡。3.1 给 Monaco 做减法按需注册语言而不是全量打包很多 Web IDE 项目图省事会直接引入统一构建脚本把几十种语言一起打包。PC 上无所谓但手机首次加载这种包体验接近灾难。WebCode 的做法是只保留monaco-editor-core语言定义和语法高亮全部做异步注册。也就是说用户当前打开的是 Python 文件前端才去加载 Python 的语法包和补全配置打开 Go 文件再按需加载 Go。第一次加载完善安装壳型之后后续打开新的语言类型会有一个短暂的 loading但整体首包体积能降到原来的三分之一以下。为了让用户感知不那么生硬我在语言包加载期间会显示一个很轻量的“正在准备语言支持”的状态标签。同时我关闭了大量桌面编辑器习惯功能。小屏上 minimap缩略图没有任何用处直接关掉高亮行、参差括号也几乎用不到字体连字和 GPU 渲染在移动端会产生不可控的兼容问题也关掉。保留的核心能力只有三个语法高亮、代码折叠、自动补全。剩下的功能留给外接键盘用户按快捷键触发屏幕内不展示入口。3.2 LSP 不能跑在本地把语言服务挪到沙箱侧代码补全通常依赖语言服务器协议 LSPLanguage Server Protocol。如果在手机本地上跑一个 Python Language Server内存占用动不动就几百兆稍微大一点的项目手机浏览器直接被系统杀掉。所以 WebCode 把 LSP 全部放在沙箱环境里跑。前端编辑触发补全请求后通过 WebSocket 把当前文件内容和光标位置发到沙箱沙箱内的语言服务计算候选结果再把补全列表返回前端。这个往返过程取决于网络质量但移动网络本地分支后的 RTT 大约在 50120ms 之间只要服务端计算够快补全的体感不会比本地差多少。这套设计真正解决的是冷启动问题。用户不需要在手机上安装任何语言环境打开项目就能获得和桌面 IDE 相当的补全能力。这个体验在校验在线代码演示时尤其重要因为听众往往不会提前在你的系统里安装 Node 或 Python。3.3 虚拟键盘下编辑器的“焦点保卫战”移动端编辑器最隐蔽的坑其实是虚拟键盘弹出收起时页面的视觉视口visual viewport变化非常激进。传统做法是监听resize事件去调整编辑器高度但在 iOS Safari 上resize的触发时机很不靠谱经常出现键盘已经收起来了编辑器仍然被压缩在屏幕下半部分的情况。最后我改用window.visualViewport接口来获取真实可视区域高度每次visualViewport.resize触发时重新计算编辑器容器的尺寸。在键盘弹出时把编辑器内容区高度设置为新的可视高度同时给编辑器底部留出额外 32 像素避免光标被键盘上沿遮挡。这样处理以后键盘收起后编辑器的尺寸能准确恢复不再出现“高度错乱”的诡异现象。顺带一个经验不要在键盘弹起时强行把焦点跳回编辑器。这看起来是一个贴心的动作但会打断用户选择补全项的手势甚至导致补全弹框自己关闭。移动端的“键盘展开—点击补全—回写内容”是一条完整链路任何中间环节的焦点跳转都会破坏这个链路。4. 沙箱集群与 AI 服务远程执行环境如何支撑“完整”的编程体验光有个编辑器远远算不上“写代码”。真正写代码的过程中跑脚本、装依赖、执行测试、看报错每一件事都需要一个可执行环境。手机本地不可能自带一套完整工具链尤其 iOS 上根本无法随意执行 Python 脚本。所以 WebCode 把执行环境完全放到云端每个会话对应一个隔离的沙箱容器。这个决策的背后逻辑并不复杂手机本身是弱势终端能做的只是输入和展示而计算必须集中在服务器侧。这一层也是整个 AI 编程平台架构里资源消耗最大、最容易崩溃的地方。4.1 容器预置与资源配额宁可用久一点不让它随便 OOM每个 WebCode 沙箱容器实际上是一个轻量级 Linux 虚拟机。基础镜像预先安装好 Node.js、Python、Go、Git、curl、jq 等常见工具启动时用 Cgroup 限制 CPU 和内存默认配额是 1 vCPU / 1GB 内存。对于绝大多数日常脚本和算法题这个规格足够但如果不加控制一个写死循环的用户就可能把整台宿主机的资源吃干。资源配额策略我做了两层软限制与硬限制。软限制是容器内存达到 700MB 时系统会向用户推送一条资源告警建议优化代码或升级计划硬限制是达到 1GB 后直接杀掉进程并把 OOM 信息返回编辑器终端。用户看到的不只是一条报错而是“容器内存超出配额进程已结束”的明确语义这样至少能避免无意义的 debug。还有一个实用技巧所有沙箱容器都不授予特权模式挂载文件系统时使用只读挂载的系统目录并在 seccomp 层面屏蔽掉容器内对宿主设备节点的访问。这样即便用户执行了一段恶意代码也很难逃出沙箱去接触宿主机网络。4.2 AI 服务不是聊天框把模型嵌进工程链路AI 编程平台的核心竞争力不在于模型多强而在于模型能否在正确的时间出现在正确的位置。最初我做的版本是一个固定在侧边栏的 chatbot用户选中代码后可以“问问题”或“生成函数”。但实测下来用户根本不会主动去找 AI 聊天反而更希望写一个函数时tab 按下那一瞬间补全和生成能自己跳到光标处。所以我把 AI 服务从“聊天框”改成了两个交互入口代码补全和指令生成。代码补全由模型基于当前文件和最近修改内容直接生成代码 diff然后异步加载到编辑器里使用者确认。指令生成则是在编辑器底部输入一行自然语言比如“写一个把 CSV 转 JSON 的函数”模型会生成一段代码片段插入到光标位置同时附带预览。这个设计看起来轻背后却很重。因为模型需要知道当前文件的整体结构也需要知道最近用户改过什么否则容易出现答非所问。技术上我做了两层上下文过滤第一层只抽取当前函数或类的签名不把整个文件塞进 prompt第二层是记录最近五分钟的编辑 diff把 diff 里的变量名和函数名作为额外的关键上下文。这样模型的输入长度能控制在 2k tokens 左右响应延迟也稳定在 700ms 上下比整文件投喂快了将近三倍。5. 移动端独有体验设计键盘遮罩、断线恢复与手势操作这一部分是我觉得 WebCode 区别于其他 Web IDE 的核心护城河。很多技术团队做一个在线 IDE会把 95% 的精力放在服务端执行能力上但用户真正在手机上放下手机的那一刻唯一的感知是“这玩意好不好操作”。所以我花了很多时间在移动端交互细节上这里挑几个我踩得最深的点讲。5.1 手机键盘是敌人不是工具手机虚拟键盘的弹出会直接压缩可视区域。如果不做任何处理光标总被键盘盖住用户每敲一行字都得手动滚动一下屏幕。我用了两个策略共同解决这个问题。第一个策略是上面提过的visualViewport高度监听。当键盘弹出时编辑器底部 set 一个 padding等于键盘高度加 16 像素确保当前光标行始终高于键盘上沿。第二个策略是一个“代码符号快捷栏”。手机键盘的数字和符号切换成本极其高普通用户要打一个大括号几乎要忍受三次键盘切换。WebCode 在编辑器底部做了一个可折叠的符号条只有半屏高包含{ } [ ] ( ) ; : 和 Tab 键点击后直接插入文本不需要切换键盘。这个小东西看起来简单实际节省的时间远超预期我甚至考虑过单独把它做成一个输入法但后来精力不够就暂时搁置了。5.2 网络切换不丢代码断线恢复策略手机使用场景意味着网络切换极其频繁。从家 WiFi 出门切到 4G或者从电梯里出来WebSocket 连接瞬间断开。如果用户此刻正在编辑器里打字前面写的代码绝对不能丢。WebCode 前端维护了一个“本地工作区”。编辑器里的每个改动都会在 300ms 内写入 IndexedDB同时标记哪些变更还没有被沙箱确认。网络恢复后前端会重新建立 WebSocket并主动把暂存变更同步给沙箱的控制层。如果沙箱已经存了同一位置的旧版本则由控制层做一次简单的 diff 合并冲突时保留最新版本旧版本作为副本放到回收站目录。这套流程说实话并不复杂核心就一句话把“保存”的信任从云端转移到本地临时缓存。但对移动用户来说它决定了你敢不敢只拿手机去修生产问题因为哪怕网断了你也不会慌。5.3 没有鼠标和右键手势系统是移动端效率的关键桌面端 Web IDE 的右键菜单在手机上是不可用的。为了覆盖这个功能我定义了一套手势系统。三指左右滑动在已打开的文件标签之间切换双指双击显示当前文件的版本历史长按编辑器空白处弹出光标位置对应的上下文菜单包括复制、插入 AI 指令、跳转到定义双指缩放改变编辑器字号从 14px 到 24px 实时缩放。这套手势不是凭空设想的。我把它们写成表格后找了几位日常只用手机工作的朋友预测试调整了大约三版才稳定。核心原则是手势必须符合人类直觉不能为了“创新”而故意让用户记一堆组合动作。所以最常用的“切换文件”只用了最简单的滑动而很少用的版本历史才用双指双击这种更复杂的手势。6. 实测结果与踩坑记录哪些方案被证明可行哪些必须回滚WebCode 从第一个可跑版本到现在我反复做过三轮真机实测。手机型号覆盖了 iPhone 12、iPhone 13、小米 11、一款低端安卓。每一次实测都会推翻几个原有设计这里挑几个典型的记录。问题根因处理方案效果首屏加载超过 12 秒Monaco 全量打包 首页加载所有代码资源改按需语言注册图片和代码包加缓存策略冷启动降到 6 秒左右输入补全卡顿每秒掉帧使用主线程跑高亮 LSP 请求阻塞 UI语法高亮搬到 Web WorkerLSP 走异步 WebSocket输入延迟从 300ms 降到 30ms断线恢复后文件丢失前端没有把未保存内容落盘增加 IndexedDB 本地工作区断线 30 秒内恢复无丢字补全内容经常“文不对题”模型拿不到当前函数上下文只提取当前签名 最近 diff 发给模型有效补全率提升 40%沙箱执行时间过长用户放弃等待没有超时和进度反馈增加命令超时 60s实时输出流式日志用户能清晰感知进度减少放弃6.1 最初用 WASM 在本地跑 Python终究还是回滚了我一开始很天真想着如果能在浏览器里用 WebAssembly 直接跑 Python就不用把每个会话都软牵扯到云端了。这样手机的计算压力还在本地也不会有网络延迟体验一定最好。然而现实非常残酷。WASM 版的 Python 解释器对标准库支持不完整像requests、numpy这类重要依赖根本没法直接安装只能通过 CDN 拉一个别人做的构建兼容性差到离谱。跑一个简单的 CSV 解析内存占用远超预期连低端机都跑不稳。最后一咬牙决定把这个方案彻底回滚全部切到云端沙箱。回滚之后用户体验大幅提升虽然网络有 50ms 延迟但至少能安装任意 pip 包不会被解释器限制住。这个教训很深刻架构选型时不能只被“新鲜技术”吸引必须想清楚你服务的场景是完整开发不是玩具 demo。对于强调“完整”的移动编程平台云端执行是唯一靠谱的底座。6.2 资源配额设太低第一次上线就误杀了一片第一版沙箱内存配额我只给了 256MB觉得这样最省成本。结果上线测试当天连续有用户在跑 Node.js 项目时 OOM一查日志Node 进程本身启动就要占用差不多 200MB再加载几个依赖256MB 根本没有余量。后来我把默认配额调整到 1GB但给用户提供可选的“轻量模式”和“重型模式”。轻量模式仍然 256MB适合跑简单脚本重型模式 2GB适合跑中等项目。这个调整听起来平淡无奇但它直接决定了用户是否愿意长期使用。开发者对新工具的容忍度很低第一次就失败后面很难再拉回来。6.3 AI 生成代码的“防手滑”机制每一次落地都必须显式确认AI 生成代码是一个高风险动作。如果模型生成了一段不可靠的代码直接覆盖用户文件用户会很爽地点击“应用”然后整个项目崩掉。为了防止这种误操作WebCode 里的所有 AI 生成内容都先在编辑器里以“可预览的 diff”形式展示用户确认后才会写入文件。同时系统会在写入前自动执行一次语法解析如果有明显的语法错误直接拒绝写入并弹出红色提示。这个机制虽然降低了一点流畅度但换来的是用户对 AI 能力逐渐建立了信任。用过 Copilot 的人都知道AI 补全有时候会产生非常离谱的代码如果没有任何防线用户很快就不再信任整个工具。所以无论多追求流畅安全确认这条底线绝不能省。7. 从 WebCode 延伸开去协作编程、自动化测试与可复用基建WebCode 完整跑起来以后我最大的感受是这个项目的价值已经超过了“手机上写代码”本身。它的架构里很多模块是可以独立复用的未来的扩展点也很清晰。7.1 实时协作手机也能做 Code Review因为控制层已经维护了会话状态和项目快照只要在 WebSocket 消息里增加操作类型和时间戳就能演变成一个实时的协作系统。两个人同时打开同一个项目一个改代码另一个看 diff手机上也可以完成 code review。这块我目前的实现还比较初级只是把编辑器内容变更广播出去但底层的数据结构已经足够支撑更复杂的 CRDT 协同协议。7.2 自动化测试链路把 CI/CD 塞进口袋既然沙箱里已经可以跑任意命令下一步自然就是把测试链路打通。用户在手机上改完代码后触发一次“远程测试”沙箱执行pytest或npm run test结果以列表形式推回前端。测试失败时模型可以读取失败日志并给出修复建议。这个能力解决的不只是移动痛点任何离开工位的开发者都会受益。实际上WebCode 目前已经支持在编辑器里配置一个“测试按钮”按下去以后终端会打印构建和测试日志底部弹出一个 AI 总结卡片。卡片会指出最可能的失败原因和修复方案用户只要点一下“应用补丁”AI 就会生成修改建议。整个链路已经从一个“远程终端”演进成完整的开发助手了。7.3 沉淀出的可复用基建开发 WebCode 的过程中我沉淀了三套独立组件沙箱调度器、AI 上下文引擎、前端运行时缓存系统。这三块现在都是普通的协议驱动接口可以嵌进任何 Web IDE 或面向开发者的工具里。如果以后有人想做一个桌面版、平板版甚至车机版的编程环境这几块几乎可以直接复用只换前端 UI背后的会话、执行、模型三层完全不用改。这也是我觉得整个项目最划算的地方。你做的时候是在解决一个具体问题但最后得到的是一套“移动优先”的开发基础设施而不仅仅是一个“手机 App”。最后再分享一个我自己的感受做这个项目前我也觉得手机写代码是伪需求是极客自娱自乐。但真正体验过“地铁上修复线上问题”“在咖啡馆跑通一个 demo”“开会时用手机现场调整参数”之后我越来越确信这个方向有它的真实价值。限制你的不是设备而是围绕设备构建的工具和架构是否认真思考过移动端。WebCode 还远谈不上完美但它至少证明了把“手机上写代码”这件事从疯狂的想法变成能落地的 AI 编程平台架构技术上完全走得通。