在手机上写代码这个事放在几年前说出来大概会被当成段子。屏幕那么小键盘那么挤编译环境又跑不动凭什么跟桌面IDE掰手腕但AI出现之后这个问题的底层逻辑直接变了写代码的重点从“敲字符”变成了“表达意图”自然语言、代码补全、自动纠错都能把输入成本压到极低。加上云端算力池化、容器沙箱技术成熟手机的定位就从“计算终端”变成了“遥控器”。我自己就把这套想法完整落地过——一个叫WebCode的AI编程平台从最初的疯狂想法到一整套可运行的架构中间踩了不少坑也沉淀了很多值得复盘的设计取舍。这篇文章就把WebCode的架构拆开讲清楚说说移动编程为什么现在真的能做、核心模块怎么设计、分布式架构怎么落地、以及那些只有动手做过才知道的坑。适合正在做AI编程工具、移动端IDE或者想了解现代云原生架构怎么跟AI结合的人看。1. 这个想法看起来很疯狂但卡点其实很具体1.1 手机上写代码的真正痛点先说痛点。手机写代码不是“难用”那么简单它是从交互到算力全链路受阻。第一层是输入。代码里全是特殊符号{}、[]、;、这些东西在九宫格或者26键上都要切换符号面板一个函数写完手指已经酸了。不要说手机就是平板上敲代码效率也比桌面低一大截。第二层是上下文。程序员写代码的时候要频繁在编辑器、终端、文件树、浏览器之间切换手机上可没有三块屏幕让你分屏。第三层是算力。本机编译、运行、调试光是拉起一个JVM或者Node进程手机就够呛了更别说机器学习任务的训练环境。这三层痛点叠在一起导致过去十年移动端代码编辑器一直是“玩具”级别的存在。不是没人想做是做了也解决不了根本问题。1.2 AI出现之后移动编程的逻辑变了AI把“写代码”的动作从手工输入变成了人机对话这是移动编程能成立的真正原因。传统IDE的补全是基于AST抽象语法树和类型系统做局部推理补的是“下一个token”。AI编程工具做的是更上层的意图理解你说一句“写一个函数把数组里的偶数抽出来并按大小排序”它直接给你输出完整实现。这意味着用户不再需要精确输入每一行只要意图表达清楚就行。意图表达用什么语音、短句、甚至点选模板这些在手机上都比键盘打字更友好。AI还顺带解决了另一个问题学习成本。传统IDE给新手的是几百个快捷键和密密麻麻的配置项AI编程工具给的是一个对话框。对这个场景来说移动端反而是AI编程的最佳载体——轻交互、强反馈、对话式流程天生跟移动端匹配。1.3 产品定位不是“编辑器搬家”而是一套平台很多人听到WebCode的第一反应是“把VS Code搬上手机”。如果只是这样那这个项目没有存在必要。WebCode的定位是一套完整的、面向移动场景的AI编程平台它要解决的问题不只是“能编辑”而是“在手机上完成从想法到运行的全部闭环”。所以产品形态上必须有几块东西一个可用的移动编辑器、一套AI编码助手、一个云端编译执行环境、一套文件同步与版本管理、以及支撑所有服务的高可用架构。手机端只做交互和展示重计算全部上云。这就是WebCode的整体基调。2. WebCode整体架构三层解耦把重活留在云端2.1 端侧轻客户端 编辑器内核移动端不能做成一个大而全的IDE。WebCode的客户端是一个“轻壳”负责三件事渲染编辑区、管理文件树、展示AI对话流。核心功能全部通过API和WebSocket跟云端交互。编辑器内核这块我们直接基于Monaco Editor做了裁剪移植。Monaco是VS Code同款编辑器内核功能强大但也确实胖。手机上内存吃紧我们就做了三件事砍掉用不到的语言扩展、把语法高亮词法分析放到Web Worker、按需加载语言服务。这里有个经验Monaco默认加载会把主线程卡死必须把非渲染逻辑全部丢进Worker渲染层只保留文本拼接和视图更新。这么说吧移动端编辑器不是“能跑就行”而是时刻盯着三个指标启动耗时、输入延迟、内存占用。我们给自己定的基线是中端安卓机启动编辑器不超过3秒输入延迟不超过100ms运行30分钟内存占用不超过300MB。2.2 接入层与网关连接手机和云端的第一道门接入层用了一个混合网关REST API处理非实时请求WebSocket网关处理实时消息。为什么不用纯HTTP因为AI补全、代码执行日志、远程终端输出这些场景都需要服务端主动推送。WebSocket长连接省掉了轮询开销配合心跳机制30秒一次维持连接。网关层还统一做了鉴权、限流、灰度路由。一个比较关键的点是网关的“连接迁移”能力。手机网络在Wi-Fi和蜂窝数据之间切换时TCP连接会断开如果网关不做session重建用户正在进行的AI生成请求就直接断了。我们的方案是网关层通过userId维护session状态客户端断线重连后带上旧的sessionId网关把它重新绑定到新连接上。实现起来不复杂但对移动端体验的影响非常大。2.3 核心服务层AI、编译、存储三路并行核心服务分成三块AI服务、执行引擎、数据服务。AI服务是平台的大脑。它向上承接编辑器的补全请求和对话式生成请求向下连接多模型网关。多模型网关的意义在于不同的任务走不同的模型简单补全用中规模模型延迟低、成本低复杂代码生成用大模型质量优先代码解释和纠错走专门微调过的模型。模型网关要做统一的路由、超时控制、降级策略。后端跟模型交互时有大段超时所以AI服务全部走异步化前端拿到的是SSEServer-Sent Events格式的流式token流。执行引擎负责把用户代码跑起来。手机不跑代码代码全在云端容器里执行。这需要一套容器编排系统接收“构建请求”、拉镜像、起容器、跑测试、返回日志。数据服务则管三样东西文件元数据、内容对象、AI会话上下文。文件内容放在对象存储元数据放在结构化数据库缓存走Redis各司其职。2.4 为什么选这样的架构而不是“全端一体化”架构选择上有一个很常见的诱惑把大量逻辑塞进单体后端客户端也尽量多干活。听起来链路短、快实际上碰两个问题就崩。第一是资源不匹配。手机端做编译、做模型推理都是不现实的追求本地算力只会让体验更糟。第二是迭代效率。同时改客户端、服务端发版成本极高。三层解耦最大的好处是把变化高频的部分AI策略、编译流程隔离在后端客户端一旦稳定就可以长时间不做大改动。换句话讲这个架构选择就是向现实妥协的结果移动端做它擅长的事云端做移动端做不到的事中间用一套稳定的API协议对话。3. 核心模块实现细节从AI生成到代码跑起来3.1 AI辅助编码模块不只是“接个大模型API”AI模块是整个平台最核心的部分但它的难点不在“调用模型”而在“怎么把模型的能力用对”。先说补全。传统补全按字符触发AI补全能这么做但成本太高。我们实现的策略是“轻量上下文缓存 延迟触发”用户停笔超过500ms或者输入换行、特殊分隔符时才发起补全请求。上下文不是把整个文件都塞给模型——那既慢又贵——而是抽取当前文件的关键上下文函数签名、引用依赖、附近代码段加上项目里被改动过的关联文件摘要拼成一个context包。这个context包的组装非常考验功力。包太大token成本暴涨首token延迟飙到几秒包太小模型没有上下文生成质量很差。我们当时的经验是最大不超过6000 token其中当前文件尽量完整其他文件只带核心符号和最近改动。再说对话式生成。这是一条完整的链路用户输入自然语言诉求意图解析是新建文件、修改函数、还是解释代码检索关联上下文涉及哪些文件、哪些依赖组装提示词模板带上项目基础信息模型路由选择合适模型流式生成把token逐个推送到前端代码落地AI返回后做语法校验云端跑一次lint再写回编辑器为什么最后一定要lint因为模型输出的代码经常有低级错误比如引用了不存在的变量、括号不匹配。不做校验直接写给用户用户点运行时才炸体验就很差。WebCode的做法是AI代码落盘前先做一次快速静态检查和一个“dry run”编译试跑报错直接回传模型让它改改完再落盘。我还想提醒想做类似项目的朋友不要迷信模型的“一次性生成正确率”。实际跑下来让模型自纠错两次正确率能提升一大截。3.2 移动端代码编辑器的体验改造Monaco Editor上了手机之后最先崩的是性能。一个几千行的大文件滚动都会掉帧。我们做的优化有几个一是“分层渲染”。屏幕外区域的代码不渲染文本行只占位滚动时动态拼接。这跟长列表虚拟滚动是同一个原理但代码编辑器的行高会因为换行而变化所以要做行高预计算。二是“输入防抖”。手机上没有物理键盘中文输入法的组合态事件极其混乱。我们最终跟输入法做了两层适配监听compositionstart/compositionend事件输入法组合期间不触发补全键盘弹起时重新计算编辑区的可视高度。三是重做了补全候选框的交互。桌面上的补全列表是从当前行往下展开手机屏幕上根本没有那么多垂直空间。我们的方案是把候选框做成底部半悬浮面板显示5个候选上滑翻页点一下插入。这个交互设计后来用户反馈很好比传统弹出式候选框在手机上舒服得多。硬要说有什么遗憾就是手机端的终端模拟器始终是块短板。我们不能跑本地终端只能在云端容器里跑Shell再把输出通过WebSocket传回屏幕。这本身不难难的是交互没有Tab键、没有Ctrl组合键vim和htop这类工具在手机虚拟终端里用起来还是很别扭。所以WebCode把默认调试方式设计成“日志面板”而不是“终端面板”让80%的场景不需要折腾命令行。3.3 云端构建与执行沙箱代码写完了怎么跑WebCode走的是“容器即服务”的思路。用户在手机上点“运行”请求先到构建服务。构建服务拆成三层任务拉取/缓存依赖、执行构建命令、打包镜像启动容器。依赖缓存是个大头为了提速我们给常用语言Node、Python、Java、Go都预置了基础镜像里面把高频依赖的下载缓存做了固化。比如Node项目npm install从冷启动的十几分钟压缩到几秒就是因为大部分包在镜像缓存里已经有了。容器运行要做好三件生死攸关的事资源限制、网络隔离、日志流控。资源限制靠cgroup做CPU和内存配额单容器内存上限默认512MB防止有人的代码把宿主机打爆。网络隔离是允许访问外网但经过一层HTTP代理做域名白名单避免容器被当成肉鸡。日志流控是限制stdout输出速率有些程序死循环里println一秒钟吐几十MB日志必须截断。这里要特别说明沙箱不是只靠容器就安全了容器和宿主机之间共享内核还是有逃逸风险。更保险的做法是配合gVisor这类用户态内核隔离或者在虚拟机里跑容器。WebCode当时因为成本考量没有全量上虚拟机方案但做的是双层加壳容器层做资源隔离网络层做白名单文件系统做只读挂载用户代码只能写指定的工作目录。3.4 文件同步与版本管理手机端的文件系统是不可信的。用户可能断网、锁屏、App被杀文件同步必须设计成“状态收敛”而不是“实时镜像”。我们设计的同步模型是客户端只在上层维护一个虚拟文件树真正的文件内容全部存云端。编辑操作通过“变更序列”上传每次改动只传增量diff而不是整个文件。断网时操作进入本地队列网络恢复后按序重放。服务端收到diff并应用版本号版本冲突时采用“后写优先 快照回滚”如果两个端对同一文件做了不同修改记录冲突标记提示用户选择以哪个版本为准另一个版本作为快照保留。有个实测数据想分享全文件上传一个数千行的Python文件按SD卡速度也得秒级走蜂窝网络可能几十秒但diff增量同步通常只需要几十到几百字节延迟几乎无感。移动编程如果没有增量同步这个设计整个产品在弱网场景下就是废的。4. 移动端交互与性能优化4.1 触控输入与软键盘策略移动编程的输入难题不只在代码生成还在于和系统输入法的斗争。软键盘的“回车键”在输入法里通常会被应用层改造。代码编辑器希望回车换行但聊天框里回车发送这会直接导致误操作。我们的处理是编辑器模式下强制申请带换行能力的输入法模式同时把底部动作条上一步/下一步/补全触发等做成随键盘弹起而浮动的状态。代码里大量符号在手机键盘上要切换面板这个必须通过自定义符号栏解决。我们在键盘上方加一条符号栏放着{}()[];这些高频符号再配合滑行输入手指在符号栏左右滑动选择松手插入。这套交互打磨了好几版核心原则就一条——高频操作单手可完成不打断写代码的心流。4.2 流式输出与虚拟渲染AI生成结果如果一次性返回用户会对着转圈等半天。WebCode全链路走流式服务端模型一次只吐一个token经过WebSocket推到客户端客户端以“打字机”方式渲染到编辑器里。但这里有个交互细节流式插入不能直接用编辑器默认的setValue那会打断用户的光标位置。我们做的是“待定插入区”AI生成的代码先进入一个高亮区域用户可以随时接受回车或者拒绝Esc接受时才正式合并进文件。这样一个设计保护了一个核心场景——你正在写另一段代码AI结果到了不会覆盖你的工作区。虚拟渲染前面提到了再补一点长文件除了分层渲染我们还做了AST折叠。代码里的大段注释和模板字符串默认折叠成一行占位用户点一下才展开。这种“代码预览模式”牺牲了一点真实感但手机上浏览大文件确实流畅很多。4.3 弱网环境的请求策略手机网络最大的问题不是慢而是波动。地铁、电梯、地下车库网络质量说变就变。WebCode的应对策略是“自适应消抖 请求分级”。自适应消抖的意思是网络质量好时AI补全的触发阈值可以短比如停笔400ms网络质量差时增加本地规则补全的权重减少远程AI请求降低失败率。请求分级则是文件同步、对话消息这种关键请求走“可靠通道”自动重试 幂等处理AI补全这种高实时、可丢弃的请求走“尽力通道”失败了大不了不补全不影响主流程。还有个很土但很有效的优化数据压缩。移动网络带宽有限我们在WebSocket消息里加了一层gzip压缩AI的流式token文本重复度高压缩率非常可观实测流量消耗能降65%左右。5. 分布式微服务架构的关键设计5.1 服务拆分的边界WebCode后端不是一上来就是微服务最开始是个单体后来按“故障隔离”和“伸缩维度”拆开。拆出来的核心服务有用户服务、项目服务、AI网关服务、构建服务、运行容器管理服务、文件同步服务、通知服务。判断标准很简单——这个服务挂了会不会把别人拖死AI网关要是超时重试风暴不能把构建服务也拖挂构建服务CPU跑满不能导致文件同步服务响应变慢。服务间通信统一走gRPC比HTTP快、有强类型约束天然适合内部调用。但gRPC的调试比HTTP麻烦一点所以网关层对外还是REST/WebSocket。每个服务的状态都对客户端不可见。客户端只能走在网关层开好的API不能直接访问内部服务地址。这么设计不只是安全考虑也为了以后可以随意调整后端拓扑——只要API不变内部怎么拆都是自由的。5.2 异步任务如何不“堵车”构建任务是典型的“重异步”场景用户点运行后端要经过排队、拉镜像、构建、运行、日志采集等一串步骤整个流程可能持续几十秒。这里的核心是任务队列不能丢、不能重复执行、要有优先级。我们用消息队列做了一个“多级队列”交互要求高的任务文件保存、AI反馈走一个低延迟队列重型任务构建、测试、部署走工作队列消费端按能力拉取。排队还要带“去重”与“熔断”。比如用户连续点了三次运行我们会把前两次相同请求合并取消只保留最新一次。构建服务如果连续失败5次自动熔断这个项目的构建请求返回提示而不是让用户一直等待。这些机制在教科书里叫“幂等”“熔断”但在实际体验里它们就是“用户没被推进死胡同”。5.3 状态同步与一致性问题分布式架构最头疼的是状态一致尤其是AI会话上下文和项目文件版本。AI会话是强依赖上下文状态的。用户跟AI聊了10轮每一轮的对话历史都要保存模型的上下文窗口又有限我们采用“摘要压缩”策略前5轮对话保留原文后续轮次先把旧对话压缩成摘要再跟新对话一起拼装发给模型。状态存到共享存储Redis 持久化兜底即使网关重启会话也能恢复。文件版本的最终一致性我们用的是“版本号 事务日志”。每次文件更新版本号1客户端必须带着自己知道的版本号来提交版本落后就拒绝并提示拉取最新。这个方式比复杂的一致性协议容易实现得多对移动端“单用户为主”的场景完全够用。6. 安全与隔离体系6.1 沙箱与运行时隔离AI编程平台最大的安全风险不是平台被攻击而是用户代码在云端容器里被用来做坏事。我们的沙箱设计分了三层。第一层是网络白名单用户容器默认只能访问公网但要经过一个HTTP代理代理端配置域名级和IP级黑名单把云元数据服务这类高危地址直接堵死。第二层是资源配额CPU、内存、磁盘、文件句柄数全限用完就杀绝不商量。第三层是文件隔离每个容器的工作目录挂载在宿主机上但做了用户态映射容器里看到的路径是虚拟的碰到宿主机真实路径会直接拒绝。这套方案能挡住绝大多数问题但防不住极端的内核漏洞利用。如果项目预算允许还是建议用轻量虚拟机方案兜底。安全这个事投入多少都不嫌多。6.2 代码隐私与权限控制用户的代码是最敏感的数据资产。存储层全部加密传输层走TLS用户之间的项目默认互相隔离分享功能必须显式开启权限。还有一个细节是AI数据的去向。用户代码片段会送给模型做推理这里有两条路走第三方模型服务要匿名化并脱敏走私有化部署模型数据能不离开内网。WebCode当时为了体验选择了混合路线补全场景走第三方模型但代码片段只送必要的上下文会话场景支持用户主动选择“隐私模式”切到私有模型。做这类产品一定要把隐私选项放在明面上让用户有知情权和选择权。这不是合规要求的问题而是产品信任的基础。6.3 审计与配额用户跑代码不能无限制消耗资源。一是成本问题二是风险问题。WebCode做了配额体系免费用户每天有运行次数上限和CPU时长额度付费用户额度更高。审计日志记录每一次构建、运行、文件访问和AI请求出了问题能回溯到具体操作。审计这件事早期容易偷懒等到出问题再补就晚了。我建议从第一版就加上“最小可用审计”时间、用户、项目、操作类型、结果五个字段就能覆盖90%的排查需求。7. 常见问题与排查实录7.1 移动端编辑器掉帧与崩溃最常被用户吐槽的是打开大文件掉帧。排查下来发现元凶是语法高亮Monaco默认的语法高亮在主线程跑几千行的词法分析必然卡顿。我们把高亮计算移到了Web Worker同时引入“高亮降级”快速滚动时只高亮当前可视区域停止滚动15ms后再补全全屏高亮。还有一个崩溃案例罪魁祸首是图片资源的OOM。移动端WebView对内存极其敏感代码里一个全屏背景图片就能造成低端机崩溃。我们的经验是编辑器界面的图片资源全部走“CSS渐变 载体字体图标”能不用图片就不用图片那点视觉上的丰富度不值得用bug换。7.2 构建超时与任务堆积高峰时段构建任务排队用户等到超时然后疯狂重试形成“重试风暴”。我们后来在构建服务前加了请求收敛层相同项目的相同构建请求5秒内只处理一个其他直接返回“已在构建中”的结果。这个改动几乎零成本但直接把构建服务高峰期的压力降了一半。还有一类超时是依赖安装导致的。npm install冷启动在网络波动时会卡很久。我们给依赖安装设了硬超时默认90秒超时就自动切换镜像源重试再不行就直接报“依赖安装失败请重试”。与其让用户无限等不如快速失败给出明确反馈。7.3 AI生成代码的“幻觉”问题模型生成的代码经常“一本正经地胡说八道”。比如生成一个Python函数调用了不存在的第三方库或者写了一个逻辑看起来对、但用真实数据一跑就出错的实现。光靠提示词约束是挡不住的。我们的兜底方案是“生成后校验链”语法检查 - 静态类型检查 - 测试用例运行三级都过了才给用户“全绿”标记。前两级不过自动回传模型修正第三级过不了就明确告诉用户“代码能运行但建议补充测试验证”。这种透明机制反而赢得用户信任因为平台不假装自己永远正确。7.4 文件同步冲突用过网盘同步的人都知道同步冲突是恶性bug温床。WebCode早期版本里用户离线编辑一小时后上线服务端直接拒绝提交导致用户以为自己写的东西全丢了。后来改成“本地草稿永不丢失”服务端冲突时把云端版本存为一个历史快照把用户本地版本保存为正在编辑的版本同时标红提示“有冲突发生请检查”。这个策略让用户觉得永远是自己在主导不会产生“被系统坑了”的绝望感。最后再分享几点实际体会WebCode做到最后我最大的体感是移动AI编程平台真正的门槛不是AI能力本身而是“把AI、移动端交互、云端算力、分布式可靠性揉在一起的系统工程能力”。有一点经验想留给后来者技术选型上别追新框架用你团队最熟的那套把精力花在业务链路上交互设计上永远要问“用户的大拇指够得到吗”而不是“桌面IDE是怎么做的”安全隔离上宁可保守到被吐槽也不要因为疏忽引发事故。如果你也想做类似的事建议从最小闭环开始先做一个能“自然语言生成代码并在云上跑起来”的Demo然后慢慢补编辑器体验、补容错、补可观测性。这条路走通之后你会发现手机上写代码早就不是什么疯狂想法了它只是AI时代里一个顺理成章的新形态。