1. 为什么我选择用 WorkBuddy 从零搭一个真实可上线的 App去年年底我接了个私活需求很明确做一个内容聚合类的轻量 AppAndroid 和 iOS 都要能装后台能推内容前端能展示图文和视频最好还能内嵌 H5 活动页。预算不多时间只有三周。我当时的第一个念头是原生开发但算了一下工作量——Android 一套、iOS 一套、后台一套、还要处理推送和热更新——三周根本不够。后来我把目光转向了 WorkBuddy 这类 AI 辅助开发工具。说实话一开始我是持怀疑态度的因为之前用过不少号称一句话生成 App的产品出来的东西要么是玩具要么根本跑不起来。但这次我决定认真试一次把整个流程完整走一遍看看它到底能撑到什么程度。结论先放在这里WorkBuddy 能帮你把一个 App 从想法推到可安装、可上线的状态但它不是魔法中间有大量需要你自己判断和补位的地方。这篇文章我会把整个项目拆成六个阶段来讲每个阶段踩过的坑我都会原样还原包括那些让我半夜爬起来改配置的瞬间。这篇文章适合几类人看一是想用 AI 工具快速验证产品想法的独立开发者二是有一定前端基础、想扩展到移动端的工程师三是接了小项目、需要在有限时间内交付的接单者。如果你完全没写过代码也能看懂大逻辑但部分配置环节可能需要找人帮忙。我用的技术栈大致是这样的WorkBuddy 负责生成主体代码和页面结构底层是 Android 原生壳加 WebView 承载 H5 内容iOS 侧用类似的 WebView 方案后台用轻量服务提供接口。关键词里提到的 WebView、Android、AI 这几个点基本贯穿了整个项目。下面进入正题我会按阶段讲每个阶段都会告诉你这一步要做什么、为什么这么做、我踩了什么坑、怎么绕过去。2. 第一阶段需求拆解与 WorkBuddy 的能力边界摸底2.1 先搞清楚 WorkBuddy 到底能做什么、不能做什么很多人拿到这类工具的第一反应是直接输入一句话让它生成整个 App然后发现出来的东西完全不能用就下结论说这玩意儿是玩具。我的经验是在动手之前你必须先花半小时摸清它的能力边界。我当时的做法是先建一个空项目用最简单的需求测试它的输出质量。比如我输入生成一个带底部导航栏的页面三个 Tab 分别是首页、发现、我的看它生成的代码结构是否合理、命名是否规范、有没有明显的逻辑错误。测试下来发现WorkBuddy 在页面结构生成、组件拼装、基础交互逻辑这几块表现相当不错但在涉及原生能力调用比如相机、文件系统、推送时它给出的代码往往需要大量手动调整。这个摸底过程非常重要因为它决定了你后面每个阶段的任务分配哪些交给 WorkBuddy 生成哪些自己手写哪些需要查文档补位。2.2 把模糊需求翻译成 WorkBuddy 能理解的结构化描述我见过太多人失败在这一步。他们给 AI 的输入是做一个好看的新闻 App然后抱怨生成的东西不符合预期。问题不在工具在于输入太模糊。我的做法是把需求拆成三层页面层有哪些页面每个页面放什么内容页面之间怎么跳转数据层数据从哪来什么格式怎么缓存怎么刷新交互层用户能做什么操作每个操作触发什么结果举个例子我当时的首页需求是这样描述的首页顶部是一个轮播 Banner下面是一个纵向列表列表项包含缩略图、标题、来源和时间点击列表项跳转到详情页详情页顶部是标题和来源下面是正文正文可能包含图片和视频。这种颗粒度的描述WorkBuddy 生成出来的东西基本可以直接用。提示描述需求时尽量用名词动词位置的句式避免形容词。说顶部放一个轮播图比说顶部放一个好看的轮播图有效得多。2.3 项目初始化时最容易忽略的目录结构问题WorkBuddy 生成的项目默认目录结构有时候不太符合我的习惯比如它会把所有页面组件平铺在一个目录下项目一大就乱。我在第一阶段就做了一件事手动调整目录结构按功能模块划分。具体来说我把它改成了这样src/ pages/ home/ detail/ profile/ components/ common/ business/ utils/ api/ assets/这个调整看起来不起眼但后面阶段加功能时省了我大量时间。因为当你要改某个页面的逻辑时你能立刻定位到文件而不是在一堆平铺的文件里翻找。另外提醒一句WorkBuddy 生成的配置文件比如构建配置、依赖声明有时候版本号写得比较随意建议在项目初始化完成后立刻检查一遍依赖版本把明显过时的依赖升级到稳定版本不然后面打包时容易出各种奇怪的错误。3. 第二阶段WebView 壳与 H5 内容的混合架构搭建3.1 为什么我选择 WebView 混合方案而不是纯原生这个决策值得展开讲。纯原生开发的好处是性能好、体验流畅但代价是两端各写一套工作量和维护成本翻倍。纯 H5 方案比如套个壳开发快但性能和原生能力调用受限。我最终选的是混合方案核心页面用原生壳承载内容页用 WebView 加载 H5。这样首页、导航这些高频交互用原生保证流畅度而详情页、活动页这些内容型页面用 H5 保证开发效率。WorkBuddy 在这个阶段帮了我大忙它生成的 WebView 容器代码结构清晰包括 WebView 的初始化、设置、加载逻辑、错误处理都有覆盖。但它默认的配置偏保守有几个关键设置需要手动改。3.2 WebView 初始化时必须改的几个配置WorkBuddy 生成的 WebView 初始化代码大概是这样WebView webView new WebView(context); WebSettings settings webView.getSettings(); settings.setJavaScriptEnabled(true);这段代码能跑但不够用。我在实际项目中补了这些配置settings.setDomStorageEnabled(true); // 开启 DOM 存储H5 本地缓存依赖它 settings.setDatabaseEnabled(true); // 开启数据库 settings.setAllowFileAccess(true); // 允许文件访问 settings.setLoadWithOverviewMode(true); // 适配屏幕宽度 settings.setUseWideViewPort(true); // 支持 viewport settings.setMixedContentMode(WebSettings.MIXED_CONTENT_ALWAYS_ALLOW); // 允许混合内容其中setDomStorageEnabled这个坑我踩得最深。当时 H5 页面里的登录态一直存不住刷新就丢排查了半天才发现是 DOM 存储没开。这个配置在 WorkBuddy 默认生成的代码里是没有的必须自己加。注意setMixedContentMode允许 HTTPS 页面加载 HTTP 资源方便调试但上线前建议改成MIXED_CONTENT_COMPATIBILITY_MODE避免安全风险。3.3 H5 与原生通信的桥接设计混合架构的核心难点在于 H5 和原生怎么通信。WorkBuddy 生成的桥接代码用的是addJavascriptInterface这是最基础的方式但有几个坑第一Android 4.2 以下版本存在安全漏洞虽然现在最低版本基本都在 5.0 以上但还是要加版本判断。第二注入的对象方法必须加JavascriptInterface注解否则不生效。第三H5 调用原生方法时是同步的如果原生方法耗时会阻塞 H5 线程。我的做法是封装一层异步桥接webView.addJavascriptInterface(new BridgeHandler(), NativeBridge); class BridgeHandler { JavascriptInterface public void call(String action, String params, String callbackId) { // 异步处理处理完通过 evaluateJavascript 回调 handleAction(action, params, result - { webView.evaluateJavascript( window.NativeCallback( callbackId , result ), null); }); } }H5 侧这样调用function callNative(action, params) { return new Promise((resolve) { const callbackId cb_ Date.now(); window.NativeCallback (id, result) { if (id callbackId) resolve(result); }; window.NativeBridge.call(action, JSON.stringify(params), callbackId); }); }这套桥接方案我在项目里用了三个月没出过问题。WorkBuddy 生成的原始版本是同步的改成异步后体验好了很多。3.4 WebView 加载失败与白屏问题的排查链路WebView 白屏是最常见也最让人头疼的问题。我遇到过三次每次原因都不一样第一次是网络权限没加Android 需要在 Manifest 里声明INTERNET权限。第二次是 H5 页面用了 ES6 语法但 WebView 内核版本太低不支持需要在构建时做语法降级。第三次最隐蔽是 H5 页面里的某个接口请求被跨域拦截了但控制台没报错排查了很久。我的排查顺序是这样的先看 WebView 有没有触发onReceivedError如果有看错误码如果没触发错误但白屏用chrome://inspect连上 WebView 看控制台控制台没报错的话检查 H5 页面的资源加载情况看是不是某个 JS 文件 404都正常的话检查 WebView 内核版本和 H5 语法兼容性关键词里提到的 error loading webview: could not register service worker 这个错误我也遇到过原因是 WebView 的 Service Worker 在某些版本上有 bug解决办法是在 WebView 设置里禁用 Service Worker或者升级 WebView 内核版本。4. 第三阶段核心功能开发中 WorkBuddy 的实际表现4.1 列表页与详情页WorkBuddy 生成质量最高的部分列表页和详情页是内容型 App 的核心也是 WorkBuddy 表现最好的地方。我给它描述需求后它生成的列表页代码包含了分页加载、下拉刷新、空状态、加载状态这些完整逻辑基本可以直接用。但有几个细节需要手动优化图片加载WorkBuddy 默认用的是原生 ImageView没有做缓存和压缩。我换成了 Glide加了内存缓存和磁盘缓存配置列表滑动流畅度提升明显。列表复用它生成的 RecyclerView Adapter 没有做 ViewHolder 复用优化长列表滑动会卡。我补了 ViewHolder 模式和 DiffUtil。点击防抖列表项点击没有防抖处理快速点击会触发多次跳转。我加了一个 500ms 的防抖。这些优化 WorkBuddy 不会主动帮你做因为它生成的是能跑的代码不是跑得好的代码。这部分需要你自己的经验来判断。4.2 视频播放WorkBuddy 搞不定、必须自己补的部分视频播放是我这个项目里 WorkBuddy 帮助最小的部分。它生成的视频播放代码用的是系统默认的 VideoView功能极其有限不支持全屏、不支持手势控制、不支持清晰度切换。我最后换成了 ExoPlayer自己封装了一个播放器组件。这部分代码基本是我手写的WorkBuddy 只帮我生成了播放器控制栏的 UI 布局。这里我想说的是不要指望 AI 工具能搞定所有事情。视频播放、直播、IM 这些复杂功能AI 生成的代码只能作为起点核心逻辑还是得自己写。4.3 数据缓存与离线阅读的实现细节内容型 App 的用户经常在地铁、电梯这种弱网环境下使用缓存和离线阅读是刚需。WorkBuddy 生成的缓存逻辑比较简单就是内存缓存加简单的磁盘缓存。我在这基础上做了三层缓存缓存层级存储内容过期策略实现方式内存缓存当前会话的列表数据会话结束清除LruCache磁盘缓存列表数据和详情内容24小时Room 数据库离线缓存用户主动收藏的内容永久文件存储离线阅读的实现思路是用户点击收藏时把详情页的 HTML 内容和图片一起下载到本地阅读时直接从本地加载。这部分 WorkBuddy 生成的代码只覆盖了数据存储图片下载和 HTML 本地化是我自己补的。4.4 推送与深链从点击通知到打开指定页面的完整链路推送功能 WorkBuddy 生成的代码用的是第三方推送 SDK 的基础集成但深链跳转的逻辑需要自己写。完整链路是这样的后台推送通知通知里带一个deeplink参数App 收到通知点击后解析deeplink根据deeplink判断目标页面和参数如果 App 在前台直接跳转如果在后台先拉起再跳转如果目标页面需要登录先跳登录页登录后再跳目标页这个链路里最容易出问题的是第 4 步。Android 在后台拉起 Activity 时如果启动模式配置不对会出现重复创建 Activity 的问题。我的解决办法是在 Manifest 里把目标 Activity 的launchMode设成singleTask并在onNewIntent里处理新的深链。5. 第四阶段打包、签名与上架前的那些坑5.1 Android 打包从 debug 到 release 的配置差异WorkBuddy 生成的项目默认是 debug 配置直接打 release 包会遇到一堆问题。我整理了一下必须改的地方签名配置debug 用的是默认签名release 必须用自己的签名文件。在build.gradle里配置signingConfigs。混淆配置release 默认开启混淆但 WorkBuddy 生成的代码里有些类不能混淆比如桥接类、数据模型类需要在proguard-rules.pro里加 keep 规则。资源压缩开启shrinkResources后有些动态引用的资源会被误删需要加 keep 规则。多渠道打包如果需要上多个应用市场要配置productFlavors。我第一次打 release 包时装到手机上直接闪退排查发现是混淆把桥接类的方法名改了H5 调用不到。加了 keep 规则后解决。5.2 iOS 侧WebView 配置与审核注意事项iOS 侧的 WebView 用的是 WKWebView配置逻辑和 Android 类似但 API 不同。WorkBuddy 生成的 iOS 代码质量整体不错但有几个点需要注意ATS 配置iOS 默认禁止 HTTP 请求如果 H5 页面里有 HTTP 资源需要在Info.plist里配置NSAppTransportSecurity。Cookie 同步WKWebView 的 Cookie 和原生不共享需要手动同步。审核风险如果 App 主要是 WebView 加载 H5审核时可能被判定为简单套壳需要在原生功能上做足文章。关键词里提到的 ios浏览器唤起安装app 这个场景在 iOS 上限制比较多不能像 Android 那样直接下载安装包需要通过 App Store 或者 TestFlight 分发。5.3 应用体积优化从 80MB 压到 25MB 的实操记录我第一次打出的 release 包有 80MB对于一个内容型 App 来说太大了。我做了这几件事把体积压到了 25MB图片资源压缩把所有 PNG 转成 WebP体积减少 60%移除无用依赖用gradle dependencies分析依赖树移除了几个没用到的库开启代码压缩和资源压缩minifyEnabled和shrinkResources都设为 true拆分 ABI用splits配置按 CPU 架构拆分每个包只包含对应架构的 so 文件移除未使用的语言资源只保留中文和英文其中第 4 步效果最明显直接从 80MB 降到了 35MB。5.4 上架材料准备隐私政策、权限说明与截图规范上架前的材料准备是个体力活但有几个坑必须提前知道隐私政策必须有一个可访问的隐私政策页面且内容要覆盖 App 收集的所有信息。WorkBuddy 不会帮你生成这个需要自己写或找模板。权限说明每个申请的权限都要在隐私政策里说明用途否则审核会被拒。截图规范不同应用市场对截图尺寸要求不同建议准备多套。软著国内应用市场基本都要求软著提前申请周期大概一个月。我第一次提交时因为隐私政策里没写设备信息收集被拒了补上后通过。6. 第五阶段上线后的监控、热更新与版本迭代6.1 崩溃监控接入上线第一天就抓到的问题App 上线第一天我接入了崩溃监控当天就抓到了三个问题某个低端机型上 WebView 初始化崩溃原因是内核版本太低某个 H5 页面在特定分辨率下布局错乱某个接口在弱网环境下超时没有正确处理如果没有监控这些问题可能要等用户反馈才知道。我用的方案是接入一个轻量级的崩溃收集 SDK配合自己写的日志上报。6.2 热更新方案选型为什么我最终没用热更新是个诱人的功能能绕过应用市场审核直接更新代码。但我最终没用原因有三个第一合规风险。国内对热更新的监管越来越严用不好可能被下架。第二技术复杂度高需要自己搭建更新服务、处理版本兼容、做灰度发布。第三我的 App 更新频率不高正常发版就够了。如果你的 App 需要高频更新可以考虑热更新但一定要做好合规评估。6.3 用户反馈驱动的迭代节奏上线后我保持了两周一个版本的迭代节奏。每个版本的内容来源是崩溃监控数据、用户反馈、自己的使用体验。这里有个经验不要一次性改太多东西。我第二个版本同时改了首页布局、优化了视频播放、加了新功能结果引入了三个新 bug。后来我改成每个版本只做一件事稳定性好了很多。7. 第六阶段十六个坑的完整复盘与可复用经验7.1 配置类坑6个坑现象原因解决方案WebView DOM 存储未开启H5 登录态丢失默认配置未开setDomStorageEnabled(true)混淆规则缺失release 包闪退桥接类被混淆加 keep 规则网络权限未声明接口请求失败Manifest 缺权限加 INTERNET 权限ATS 未配置iOS 加载 HTTP 失败默认禁止 HTTP配置 Info.plist签名配置错误打包失败用了 debug 签名配置 release 签名依赖版本冲突编译报错多个库依赖同一库不同版本用 exclude 排除7.2 逻辑类坑5个列表点击防抖缺失快速点击触发多次跳转加 500ms 防抖解决深链重复创建 ActivitylaunchMode 配置错误改成 singleTask异步桥接回调丢失callbackId 没做唯一性校验加了时间戳分页加载重复请求没有 loading 状态判断加了请求锁缓存过期策略错误用了固定过期时间改成滑动过期7.3 体验类坑5个图片加载卡顿没用缓存换成 Glide 加缓存配置WebView 白屏排查链路见 3.4 节视频播放器功能缺失换成 ExoPlayer 自己封装低端机崩溃WebView 内核版本判断低版本降级处理包体积过大见 5.3 节优化方案7.4 如果重来一次我会怎么调整流程如果让我重新做一遍这个项目我会做这几个调整第一在需求拆解阶段就确定技术方案而不是边做边改。我中间因为视频播放方案换了两次浪费了不少时间。第二更早接入崩溃监控而不是等上线后才接。开发阶段就能发现很多问题。第三把 WorkBuddy 当成高级代码补全而不是全自动开发。它的价值在于帮你快速生成结构化的代码骨架而不是替你思考架构和解决复杂问题。第四留出至少 30% 的时间做测试和修复。我原计划三周实际用了四周半多出来的时间基本都花在测试和修 bug 上。7.5 WorkBuddy 这类工具的正确使用姿势用了几个月下来我对这类 AI 辅助开发工具的定位是这样的它是一个效率放大器不是替代品。你越懂开发它帮你省的时间越多你越不懂它生成的代码你越改不动。具体的使用建议用它生成重复性高的代码列表页、表单页、设置页这些结构固定的页面它生成得又快又好不要用它处理复杂业务逻辑涉及状态管理、并发、性能优化的部分自己写更靠谱把它当文档查询工具不确定某个 API 怎么用时问它比翻文档快生成的代码一定要 review它有时候会生成看起来对但实际有问题的代码比如边界条件没处理、异常没捕获最后分享一个小技巧我在项目里建了一个workbuddy-notes.md文件每次 WorkBuddy 生成的代码有问题我就把问题和解决方案记下来。下次遇到类似场景直接翻这个文件比重新排查快得多。这个习惯帮我省了大量重复劳动的时间。