当时所有人都觉得我疯了。“在手机上写代码”这句话说出来基本等同于告诉别人你准备用一支铅笔去绣花。但后来我真的在手机上完成过一次线上 bug 修复——出差路上、凌晨两点、身边只有一部手机、生产环境出了个数据校验的紧急问题。从那个夜晚开始我确信这个场景是有真实价值的。WebCode 就是从这样一个“疯狂想法”里一步步长出来的一套完整 AI 编程平台架构把代码编辑、AI 辅助、项目管理和云端执行全套搬进浏览器手机上也跑得动。这篇文章不是来跟你辩论“手机写代码到底适不适合”而是把我们从想法萌芽、架构设计、核心实现到上线后踩坑排障的完整过程拆开讲一遍。如果你正在做 Web IDE、AI 编程助手、或者想把内部工具 Web 化这篇文章应该能给你一些不太容易从文档里找到的真实参考。1. 从“手机上写代码”到平台化这个需求真的存在吗1.1 移动编码的真实场景与用户痛点先说场景。大多数人的第一反应是我没事干嘛要在手机上写代码但真实世界里确实存在不少“必须用手机处理代码”的情况值班时线上服务出现小范围异常本地没带电脑只能用手机快速定位问题、改配置、重跑任务。出差到现场客户系统环境有临时问题需要立刻调整一段脚本参数不可能现场开电脑。通勤路上想看看项目代码或者练练算法题打开电脑太重手机反而顺手。物联网设备部署现场经常要在终端里敲几行命令验证接口或改一下逻辑。这些场景的共同点是单次改动量不大但对时效性的要求极高。用户的目的不是重构一个大型系统而是“把眼下这个冒烟的问题先处理掉”。真正的痛点也远不止“屏幕太小”这么简单。手机上没有顺手好用的终端装不了完整的 IDE远程桌面倒是能看但延迟高得让人崩溃手机上用鼠标点电脑桌面就像隔着手套抓蚊子代码原本躺在仓库里改一点点也要走一遍完整的拉取、修改、提交流程。就算这些都忍了改完之后谁来验证跑不了测试没人 review风险依然很大。所以 WebCode 的定位从一开始就不是“替代电脑开发”而是补足移动场景下一条完整链路快速查看、轻量修改、AI 协助、即时验证、安全提交。想明白了这一点后续所有架构决策都有了支点。1.2 为什么是浏览器 云端环境 AI 的组合而不是 App 或远程桌面定位清楚了接下来就是路线选择。我们当时认真对比过好几条路。原生 App需要维护 Android、iOS 两套端开发周期长更新还要走应用审核而真正复杂的编译执行仍然发生在云端App 本质上只是一个壳。用一个壳的代价换两个平台的维护成本不划算。远程桌面方案体验确实直观但手机屏幕看电脑桌面本来就是灾难字号小、触控不精准、流量消耗大而且对网络质量极其敏感。一旦网络波动整个操作直接卡死。纯本地执行引擎手机 CPU 和内存撑不起编译器装了 Node 也跑不了大型构建。更重要的是安全没法控制代码留在用户手机上回收和管控都是大问题。浏览器 云端的组合就合理多了跨平台、免安装、打开即用复杂的编译、依赖安装、运行验证全部放到云端手机上只保留轻量的编辑交互。真正的加分项是 AI这也不是为了炫技。移动端键盘敲代码实在慢直接跟 AI 说一句“把这个排序改成按时间倒序”比自己敲十行代码快得多。AI 把自然语言转成代码建议用户只做确认和微调这才是补足移动编码效率短板的正解。这条路线在工程上成本可控体验上限也高。核心就一句话把重活留在云端把轻量交互留给浏览器。2. 架构怎么设计WebCode 的四层骨架与关键选型2.1 四层架构总览与数据流WebCode 整体拆成四层接入层负责浏览器客户端和移动端 H5 的入口处理认证、路由、WebSocket 长连接、静态资源分发。服务层承载所有业务逻辑包括项目服务、会话管理、AI 服务编排、任务队列、用户权限。执行层云端开发环境的核心基于容器技术构建每个用户或项目有独立运行环境负责执行代码、安装依赖、跑测试、提供预览。存储层负责代码仓库、文件对象存储、项目元数据、会话记录、AI 操作日志。分层不是单纯为了好看。接入层把终端类型和上层业务隔离开以后要加小程序端或者桌面端都不会动到核心逻辑服务层把业务状态和 AI 能力拆开AI 模型升级不影响任务调度执行层独立成池因为容器的生命周期和业务接口完全不同需要单独管理。光看层还不够关键是数据怎么流。用户在手机浏览器编辑代码内容通过 WebSocket 实时推到服务层服务层保存快照并同步到执行层容器的文件系统里。点击“运行”之后服务层向对应容器下发命令执行结果stdout、stderr再通过 WebSocket 回流到前端前端实时渲染在屏幕上。AI 链路是并行的一套用户输入自然语言请求服务层收集当前文件内容、目录结构、最近修改记录、编译报错等上下文组装成 prompt 调用大模型模型流式返回建议代码服务层做 diff 和合并校验最终推给前端。用户确认之后才真正写盘。这套架构实质上就是把传统开发工具拆成了四件事前端编辑体验、云端计算环境、AI 智能辅助、数据持久化。每一块都能独立演进比如前端可以先上AI 能力后补执行层单独扩容。这也是后来项目能快速迭代的底气。2.2 编辑器内核、通信与控制面的选型逻辑编辑器这块我们一开始就没打算自研。完整支持语法高亮、代码折叠、多语言、diff 对比、智能提示的 Web 编辑器内核任何一个功能单独开发都是几周起步更别提移动端的各种兼容问题。最终方案是直接用成熟的开源 Web 编辑器内核把力气花在移动端手势适配和插件扩展上。对编辑器内核做二次开发时我们虚拟了一层“输入适配器”。桌面端内核默认监听鼠标和键盘事件手机上不一样键盘是没有的点击不是连续的光标要重新定义移动逻辑。所以内核之上必须有一层自己的手势映射层把触摸转换成编辑器能理解的操作。这个设计后面还会细讲。通信方案我们选了 WebSocket 作为主通道。相比轮询和 SSEWebSocket 是双向的延迟低非常适合编辑内容实时同步和 AI 流式返回这两类场景。AI 返回的流式输出和编辑同步共用一条通道也省去了另建连接的麻烦。但移动网络真的不可靠切后台、锁屏、过隧道、网络切换随时可能断。所以 WebSocket 只是“快通道”底层还有全量快照加操作日志的兜底机制。断线重连后先做版本对比不一致就回退快照或者走合并流程。控制面这块我们选择了自己可控的编排层而不是直接绑定某个云厂商的托管服务。原因是执行沙箱的调度策略、镜像预热、实例池伸缩这些逻辑实在太定制了绑定托管服务等于把命脉交出去。编排层只做三件事实例的创建与销毁、容器的资源配额、异常实例的自动替换。简单、可控、可观测这是选型时坚持的原则。2.3 存储、任务队列与可观测性设计存储层比想象中复杂。代码文件存在对象存储以“文件快照”方式保存每个版本之间有增量支持回滚。项目元数据、会话记录、AI 操作日志则放在数据库里这里要特别注意AI 操作日志是独立的一张表用户问过什么、AI 返回过什么、用户最终接受了什么全部留痕。一方面可以拿来做数据分析和模型调优另一方面出了纠纷也有据可查。任务队列单独拎出来是必然的。用户点“运行”后不能同步卡住请求先进队列异步消费。队列要支持优先级比如紧急任务可以插队还要支持并发控制防止某个人连续提交 30 个任务把整个平台打满。限流和排队是移动端场景下最容易忽视、但事故率最高的环节。可观测性设计也踩过坑。初期没有做链路追踪线上出问题全靠用户描述加日志翻找效率极低。后来把前端埋点和服务端 trace 串起来从“编辑器加载耗时、首次输入延迟、AI 返回耗时、运行任务排队时间”一条链路看清所有瓶颈。没有这些数据后续的优化基本都是盲人摸象。3. 三个最难啃的环节编辑器适配、AI 协同、云端执行3.1 移动端编辑器的适配难点与处理方案移动端编辑器这块实际开发中的坑比预想的多得多。以下是我们处理过的问题每个都值得展开说。第一是缩放与滚动冲突。浏览器默认支持双指缩放和双击缩放在代码编辑区里就是灾难手指稍微一抖页面就缩放乱了。我们用 viewport 锁死用户缩放同时在代码区设置触摸行为把双击缩放的问题直接按掉。这里要注意锁缩放只针对编辑区全局页面还是允许滚动的。第二是虚拟键盘避让。手机上键盘一弹出来编辑区底部经常被遮住光标所在行直接看不见。这个问题靠 CSS 里的height: 100%解决不了因为移动端键盘弹出时通常不会改变视口高度。我们监听可视高度变化事件动态计算键盘高度把编辑区的底部偏移量设为键盘高度同时在光标滚动时特意把光标行滚到可视区域的中部而不是底部给键盘留出空间。第三是光标移动与选区。桌面端鼠标点哪光标就在哪手机上触摸本身就是模糊的。我们加了一个手势层长按编辑区出现虚拟光标手指拖动光标移动再配合滑动实现选中。这层手势完全替换了内核默认的点击和双击行为否则双击选词、三击选段这些桌面逻辑在触屏上只会让人崩溃。第四是输入法兼容。中文环境下拼音输入法上屏时会有组合事件如果编辑器在组合期间就触发输入更新会导致字母和拼音被当成代码写进去。必须在输入法组合开始到结束的整个生命周期里暂停部分增量监听只在组合结束后做一次完整更新。这个 bug 线上出现过多次用户反馈“打中文时代码会乱跳”排查过程非常痛苦。第五是性能与加载体积。手机上 4G/5G 网络下加载一个几十兆的编辑器内核是不现实的。我们按特性拆分打包移动端不加载调试面板、代码对比等重型能力首屏控制在 1MB 左右。同时编辑器只做按需加载先渲染当前文件目录树和文件切换用异步加载。实测下来首屏加载速度从 7 秒降到了 2 秒以内感知明显。注意不要试图在移动端页面里塞一整套桌面级快捷键体系移动端的高频操作必须按钮化和手势化。只有外接键盘的用户才需要快捷键这部分单独做一层适配就好。还有一个设计原则从第一天就定了移动端编辑器的默认字体、行高、缩进宽度都要比桌面端大一圈保证在 6 英寸屏幕上也能轻松看清。这个看起来不起眼实际对用户是否愿意持续使用影响很大。3.2 AI 辅助编程的核心链路从请求到代码回写AI 模块不是做一个聊天机器人挂在边上而是做一个真正会读代码库、会改文件的开发搭子。整个链路能拆成六步第一步上下文收集。AI 要回答得好前提是信息足够。我们收集当前文件内容、光标位置、目录树、最近修改过的文件列表、编译输出、终端报错信息等。收集完之后必须做压缩这一步特别关键。直接全量塞给大模型是不现实的仓库几百个文件、每个文件几千行模型上下文窗口再大也扛不住。我们采用分层策略当前文件全量保留其他相关文件只提取函数签名、import 依赖和关键逻辑片段删除注释和空行。第二步prompt 组装。系统提示词里明确告诉模型这是一个编程助手只输出代码不要废话。用户请求会被转译成明确的编辑指令比如“把 38 行的排序逻辑改成按时间倒序”而不是简单地把用户原话丢给模型。上下文部分把“当前文件内容、光标位置、用户请求、相关报错信息”拼在一起格式固定方便模型解析。第三步调用大模型并流式返回。我们优先用流式接口首字延迟控制在 500ms 以内否则用户会以为服务挂了。前端拿到的是逐字输出的 token 流边显示边做语法高亮预览这样长代码也不会让用户干等。第四步改写与合并。这一步是最容易被忽略的。AI 返回的内容绝不直接写盘先做 diff生成一个“建议块”用户可以在编辑器内看到新增、修改、删除的对比明确选择“接受”还是“拒绝”。接受之后服务端还要重新格式化代码跑一遍快速语法检查全绿才真正写盘。第五步运行验证。写完代码不等于完事编辑器里一键调用执行沙箱跑测试。如果测试报错AI 会拿到报错信息进行下一轮修正这就形成了“AI 写代码—机器跑验证—AI 改代码”的闭环。第六步反馈沉淀。用户接受或拒绝的每一次操作都会被记录这些数据后续可以分析出模型在哪类任务上表现差、在哪类任务上用户信任度高再针对性地调整 prompt 模板。实测下来最该优先优化的不是模型本身而是上下文收集的准确性。我们一开始把所有文件一股脑塞进 prompt效果反而差因为噪音太多模型经常被无关代码干扰。后来锁定“当前文件 最近改动 报错上下文”这个组合准确率提升了接近一倍成本也降下来了。如果你的 AI 编程工具效果不好先检查上下文再怀疑模型。3.3 云端执行沙箱的构建与资源调度执行沙箱是 WebCode 的底座没有它“手机写代码”就是纸上谈兵。设计上我们坚持几个关键点。每个用户或项目分配独立的轻量容器互相隔离这是底线。用户跑得再疯也不能影响别人。容器里预置常用语言运行时Node、Python、Java、Go 等主流版本一应俱全支持多版本切换。用户不需要自己在手机上去装环境这一点直接决定了移动端体验的成败。资源限制是必须做死的。每个容器我们默认给 CPU 0.5 核、内存 1GB、磁盘 5GB进程数和线程数也有上限。没有限制就会出现一个死循环直接吃满宿主机 CPU 的恶性事件。下面是一个典型配置{ cpu: 500m, memory: 1Gi, disk: 5Gi, processLimit: 128, network: whitelist-only, defaultTimeout: 120 }网络策略也值得单独说。容器不能随便访问内网任意地址否则用户写一段恶意代码就能在内网里横向扫描。我们只开放白名单出口而且依赖安装全部走专用下载源既安全又能保证速度。冷启动优化是执行体验的关键。早期没有预热池用户点“运行”之后要现拉镜像经常要等十几秒这个等待在电脑上还能忍手机上完全没法接受。后来做了两个改进一是常驻一个预热池里面预启动 10-20 个空容器请求进来直接复用二是镜像用分层缓存按使用频率提前拉取热门语言的运行时层。改进之后冷启动时间从 15 秒降到了 2 秒左右用户基本无感。运行过程中的输出处理也踩过坑。编译和运行会产生大量 stdout 和 stderr一次性传回来会撑爆 WebSocket 消息。我们的方案是边执行边推送把输出切分成小块流式到达前端同时支持中断任务。任务有默认超时时间120 秒强制 kill防止无限循环拖死容器。3.4 资源池与性能指标的量化测算资源规划如果靠拍脑袋上线第一天就会出问题。我们建立了一个简单的换算模型。假设目标支持 2000 个在线用户高峰期活跃率达到 20%也就是 400 个活跃用户。其中又有约 20% 的用户在同一时刻点“运行”执行任务那并发任务数就是 80 个。每个容器同时能处理 2 个任务就需要 40 个可用容器。再加上冷启动缓冲和故障冗余实例池至少预留 60 个容器。按每个容器 1GB 内存算就是 60GB 内存按 CPU 0.5 核算就是 30 核。这个数字看着大但实际不用一次性全部常驻。容器编排层可以根据队列长度动态伸缩低峰期收缩到 20 个高峰期扩到 60 个以上。核心是建立“在线数—活跃率—并发率—实例池”的换算关系然后拿真实业务数据去校准这几个比例。除了容器资源还要盯住另外几个指标前端编辑器加载体积、WebSocket 消息压缩率、AI 请求的熔断与降级策略、日志与可观测链路的覆盖率。尤其是 WebSocket代码内容大开启压缩后实测带宽能降 60% 左右移动网络环境下体验差异非常明显。另一个经常被忽略的点是预留余量。系统设计不能卡着容量上限走需要留出至少 30% 的冗余。线上状况永远比预估复杂突然涌进来一批用户、某个容器异常占用、某些任务的超时时间设置不合理这些都是运行时不可控的因素没有余量就只能眼睁睁看着系统雪崩。4. 踩坑实录线上问题排查与稳定性优化技巧4.1 移动端高频问题速查表上线半年移动端的问题清单整理下来也有小一百条。我挑最典型的几条做成速查表这些基本每个做移动 Web 工具的人都会碰到。现象可能原因解决思路键盘弹出后编辑器被遮挡未监听可视高度变化用视觉视口 API 动态获取键盘高度设置编辑区偏移双指缩放导致页面乱跳浏览器默认手势未禁用锁死视口缩放设置触摸行为不响应双击缩放中文输入法上屏时代码乱跳输入法组合事件未正确处理组合开始期间暂停增量监听组合结束时一次性更新断网一段时间内容丢失只有实时通道缺少本地缓冲编辑器内容定时存本地重连后优先恢复草稿锁屏再解锁页面白屏浏览器回收了 WebView 内存记录页面状态与文档版本reload 后自动恢复现场代码区滑动时误触侧边栏滚动事件穿透编辑区滚动时捕获事件阻止冒泡到抽屉组件这里最想强调的是最后一条。移动端页面里编辑区和其他 UI 组件的滚动冲突几乎无处不在而且很难在桌面浏览器里复现。调试这种问题最有效的方式不是改代码而是在真机上用一只手操作、另一只手盯着事件日志一步一步看手势到底被谁吃掉了。模拟器只是参考真机才是真理。另一个容易被忽略的测试维度是网络切换。移动端用户会在地铁里、电梯里、隧道里使用你的工具断线重连是常态而不是异常。上线前我们专门做过步行测试从电梯到走廊来回走让网络反复切换排查掉了一批连接恢复的缝隙问题。4.2 云端执行与 AI 服务问题实录线上踩坑最多的是云端执行和 AI 服务这两块各有各的难缠之处。冷启动超过 15 秒的问题持续了一个多月。现象是用户点“运行”后转圈很久才出结果排查日志发现问题不在容器启动本身而是每次请求都会重新拉取基础镜像层即使本地已经有缓存也每次校验。优化方案是预热池加反向复用空容器不销毁请求直接绑定。冷启动从 15 秒降到 2 秒耗时问题基本消失。运行任务卡死也出过几次。用户写了个while(true)死循环容器 CPU 直接飙满其他任务跟着遭殃。这个问题的根源是当时 CPU 限制没生效进程数限制也没配。后来把所有容器的资源配额规范成统一模板同时把任务默认超时时间设为 120 秒超时强制 kill。从机制上杜绝了单个用户拖垮全平台的可能。AI 服务的问题更有意思。有段时间用户反馈“AI 生成的代码风格跟项目完全不一样”排查之后发现上下文里根本没有项目的代码规范。后来我们把 ESLint、Prettier 配置和最近几次提交记录一起加到上下文里AI 的输出风格明显向项目靠拢。这说明 AI 编程不是纯粹靠模型聪明而是靠上下游的工程配合。代码合并冲突也曾经让用户困惑过。早期我们尝试让 AI 自动写盘用户回来一看文件被改得乱七八糟体验非常惊悚。后来改成“建议模式”AI 的输出永远先以 diff 预览形式呈现用户明确点了接受才写盘。这一改动把用户的掌控感拉满信任度提升是肉眼可见的。连接断开的问题主要集中在 WebSocket 被网关掐断。有些移动网络在空闲一段时间后会主动断开长连接如果不做心跳前端还以为连接活着。我们加了 30 秒一次的心跳配合指数退避重连和离线操作日志回放用户感知到的“断线”几乎消失了。4.3 安全与稳定性的几个硬约束安全这条线起步就要立规矩不能等出了事再补。容器逃逸防护是第一条。容器内绝对禁止特权模式文件系统关键目录只读挂载/tmp作为临时目录可写但禁止挂载容器引擎的 socket。否则用户写一段代码就可能拿到宿主机的控制权这就是灾难级事故。具体配置上还要注意关闭危险的系统调用限制可挂载的文件系统类型。资源耗尽攻击也得防。任何执行任务都必须走配额与限额容器内存、CPU、磁盘、进程数统统锁死网络只允许白名单地址。用户代码能做的事必须被严格限制在一个可控范围内。代码与日志脱敏是 AI 接入之后新增的硬需求。AI 请求的上下文里经常包含密钥、token、内网地址等敏感信息统一用正则脱敏之后再发给模型。日志输出也做了分级不打印用户隐私内容生产环境日志里的敏感字段一律打码。这个规范从第一天就强制执行到了后期省了无数麻烦。AI 接口的限流与风控也单独做了。按用户和 IP 双层限流防止某个用户刷爆月度预算注册用户默认配额和免费试用次数分开计算超出部分走计费审批流。没有这套机制一个用户就能在一晚上把整个平台的 AI 成本烧穿。如果让我给准备做同类产品的团队提一条最真诚的建议我想说一定要先把“手机上最常用的三个场景”列出来全部设计围绕场景走不要试图把桌面端的所有能力原样搬到移动端。WebCode 走到现在最受益的一条原则始终是“把复杂留给云端把简单留给用户”。AI 给了移动编码真正的可能性但真正决定产品能不能活下去的还是那些键盘弹出、手指误触、断网重连的细节打磨。只有自己亲手在手机上完成一次完整的修改—提交—验证流程你才会明白这些细节到底值不值得这么较真。