1. 为什么我选择 WorkBuddy 来搭一个真正能上线的 App去年年底我接了个私活帮一个做线下活动策划的团队做内部工具。需求不复杂活动排期、人员签到、物料清单、简单的数据看板。但对方提了一个硬性要求——必须是一个能装到手机上的 App而不是丢个网页链接让大家在浏览器里点来点去。预算有限工期三周团队里就我一个人。这个场景其实很典型。大量中小团队、个人开发者、甚至大公司里的创新小组都会遇到“需要一个 App但不值得养一个移动端团队”的情况。传统的路子是 React Native 或者 Flutter学习成本、构建链路、上架流程随便哪一环都能卡住你。我当时的判断是用 WorkBuddy 这类 AI 辅助开发工作台来搭骨架把精力集中在业务逻辑和上线流程上而不是耗在环境配置和样板代码里。WorkBuddy 本质上是一个 AI 驱动的开发工作台你可以把它理解成一个“懂代码的搭档”。它不是一个低代码拖拽平台也不是一个纯粹的代码生成器而是介于两者之间——你用自然语言描述需求它帮你生成结构化的项目代码、配置文件、甚至部署脚本然后你在它的基础上做修改和调试。这个定位决定了它特别适合“有明确需求、有一定技术基础、但不想从零搭架子”的场景。我最终交付的是一个 Android 原生壳 WebView 混合架构的 App后端用 Supabase 做数据存储和鉴权前端页面用 HTML/CSS/JS 写通过 WebView 加载。这个方案的好处是开发速度快、调试方便、后续维护成本低。整个项目从零到能装到手机上跑通用了大概两周半中间踩了十六个坑有些坑差点让我推翻重来。这篇文章我会把这六个阶段、十六个坑、以及最终沉淀下来的可复用经验完整拆开讲。适合谁看如果你是一个独立开发者、小团队的技术负责人、或者想快速验证一个 App 想法的产品经理这篇文章里的每一步你都可以直接抄作业。如果你是完全零基础的小白也没关系我会把关键概念用生活化的方式解释清楚你跟着走也能跑通。2. 整体方案设计与技术选型拆解2.1 为什么是 Android 原生壳 WebView而不是纯原生或纯跨平台先说结论我选 Android 原生壳 WebView核心原因是开发效率和调试便利性的平衡。纯原生开发Kotlin/Java的问题是每一个页面、每一个交互都要写原生代码UI 调整要重新编译调试周期长。对于一个只有三周工期的项目来说这个路子太慢了。纯跨平台方案React Native、Flutter虽然能复用代码但环境配置本身就是一道坎而且遇到原生能力调用时还是要写平台特定代码学习曲线并不平缓。WebView 混合架构的逻辑是用 Web 技术写界面和业务逻辑用原生壳提供容器和原生能力。这样做的好处非常直接前端页面用 HTML/CSS/JS 写改一行代码刷新就能看到效果调试速度和写网页一样快。原生壳只需要处理几件事加载 WebView、处理文件下载、调用相机/定位等原生能力、管理应用生命周期。后续如果要上 iOS理论上可以复用大部分 Web 代码只需要换一个 iOS 原生壳。当然这个方案也有代价。WebView 的性能不如原生复杂动画和大量列表滚动时会有卡顿感。但对于内部工具类 App 来说这个代价完全可以接受。我当时的判断是用户不会因为一个签到按钮的动画不够丝滑就弃用这个工具他们关心的是能不能快速完成签到、数据能不能实时同步。2.2 Supabase 在后端扮演什么角色Supabase 是我在这个项目里做的最正确的一个决定。它是一个开源的 Firebase 替代品提供 PostgreSQL 数据库、用户鉴权、实时订阅、文件存储、边缘函数等能力。对于我这种一个人干全栈的场景来说它几乎解决了所有后端需求。具体来说我用到了这几个能力数据库活动排期、人员名单、物料清单、签到记录全部存在 PostgreSQL 里。Supabase 提供了一个可视化的表编辑器建表和改字段非常方便。鉴权用 Supabase Auth 做手机号验证码登录。它内置了短信发送能力我只需要配置好模板就行不用自己接短信服务商。实时订阅签到数据需要实时同步到看板页面。Supabase 的 Realtime 功能可以监听数据库变化推送到前端省了我自己搭 WebSocket 的功夫。行级安全策略RLS这个后面会详细讲是 Supabase 最强大的功能之一也是我踩坑最多的地方。Supabase 的免费额度对于中小型项目来说完全够用500MB 数据库、1GB 文件存储、每月 200 万次 API 请求。即使后续用户量涨了升级到 Pro 版也只要 25 美元一个月比养一个后端服务器便宜得多。2.3 WorkBuddy 在开发流程中的定位WorkBuddy 在这个项目里的角色不是“帮你写完所有代码”而是“帮你跳过所有样板代码和配置地狱”。我具体用它做了这几件事生成 Android 项目的基础结构包括build.gradle、AndroidManifest.xml、MainActivity 的 WebView 初始化代码。生成 Supabase 的客户端封装代码包括登录、查询、实时订阅的调用示例。生成前端页面的 HTML/CSS/JS 骨架我在此基础上调整样式和交互。排查报错时把错误日志丢给它让它给出可能的原因和修复方案。这里要强调一点WorkBuddy 生成的内容必须经过你的审查和修改。它给的代码不一定完全符合你的项目配置特别是版本号、依赖库、API 调用方式这些细节经常需要手动调整。我的经验是把它当成一个“高级代码补全工具”来用而不是“一键生成完整 App”的魔法按钮。3. 六个阶段的完整实操记录3.1 第一阶段需求梳理与项目骨架搭建这个阶段我花了大概两天。第一天跟需求方开了两次会把功能清单确定下来。第二天用 WorkBuddy 生成项目骨架。需求清单最终确定如下功能模块具体需求优先级登录手机号验证码登录P0活动排期列表展示、详情查看、创建/编辑P0人员签到扫码签到、手动签到、签到记录P0物料清单列表展示、勾选确认、备注P1数据看板签到率、物料完成率、实时更新P1消息通知活动变更通知、签到提醒P2P0 是必须上线的P1 是尽量上线P2 可以后续迭代。这个优先级划分很重要因为后面遇到坑的时候你需要知道哪些功能可以砍掉来保上线时间。用 WorkBuddy 生成项目骨架时我给的提示词大概是这样的帮我生成一个 Android 项目的基础结构要求使用 KotlinminSdk 24targetSdk 34主 Activity 使用 WebView 加载本地 assets 目录下的 index.html开启 JavaScript 和 DOM Storage处理返回键回退网页配置网络权限和文件下载权限。WorkBuddy 返回的代码基本可用但有几个地方需要手动改build.gradle里的依赖版本号是它训练数据里的旧版本我改成了当时最新的稳定版。AndroidManifest.xml里缺少android:usesCleartextTraffictrue这个在开发阶段加载本地 HTTP 服务时需要上线前要改成 HTTPS。WebView 的WebViewClient和WebChromeClient需要自己补充WorkBuddy 只给了最基础的版本。注意WorkBuddy 生成的build.gradle文件里compileSdk和targetSdk的版本号一定要根据你本地安装的 Android SDK 版本来改。我一开始没改直接同步失败报了一堆找不到 SDK 的错误。3.2 第二阶段Supabase 后端配置与数据建模这个阶段花了三天其中两天在踩坑。Supabase 的配置本身不复杂但有几个关键决策会影响后续开发效率。首先是数据表设计。我建了五张表events活动信息字段包括 id、title、description、start_time、end_time、location、created_by。attendees参与人员字段包括 id、event_id、name、phone、status。checkins签到记录字段包括 id、event_id、attendee_id、checkin_time、method。materials物料清单字段包括 id、event_id、name、quantity、checked、note。profiles用户信息字段包括 id关联 auth.users、name、role。这里第一个坑来了Supabase 的auth.users表不能直接外键关联。你需要建一个profiles表用触发器在用户注册时自动插入一条记录。我一开始不知道这个直接在events表里用created_by关联auth.users.id结果 RLS 策略怎么写都不对。正确的做法是-- 创建 profiles 表 create table profiles ( id uuid references auth.users on delete cascade primary key, name text, role text default user, created_at timestamp with time zone default timezone(utc::text, now()) ); -- 创建触发器用户注册时自动插入 profiles create function public.handle_new_user() returns trigger as $$ begin insert into public.profiles (id, name) values (new.id, new.raw_user_meta_data-name); return new; end; $$ language plpgsql security definer; create trigger on_auth_user_created after insert on auth.users for each row execute procedure public.handle_new_user();第二个坑是RLS 策略的编写。Supabase 默认开启 RLS如果你不写策略所有查询都会返回空。我一开始以为是自己代码写错了查了半天才发现是 RLS 没配置。RLS 策略的逻辑是针对每一张表、每一种操作select/insert/update/delete定义什么条件下允许访问。比如events表的查询策略-- 允许所有登录用户查看活动 create policy Allow logged-in users to view events on events for select using (auth.role() authenticated); -- 允许创建者编辑自己的活动 create policy Allow creators to update their events on events for update using (auth.uid() created_by);实操心得RLS 策略写完之后一定要在 Supabase 的 SQL Editor 里用set role authenticated;和set request.jwt.claims来模拟不同用户测试。我一开始只在客户端测试结果因为用的是 service_role key绕过了 RLS一直没发现问题。3.3 第三阶段前端页面开发与 WebView 集成这个阶段花了四天是工作量最大的部分。前端页面我用的是原生 HTML/CSS/JS没有上框架。原因很简单页面数量不多六个页面交互逻辑不复杂上框架反而增加构建步骤和调试复杂度。页面清单login.html登录页手机号输入、验证码发送、登录按钮。index.html首页活动列表、创建活动入口。event-detail.html活动详情参与人员列表、签到入口、物料清单入口。checkin.html签到页扫码签到、手动签到。materials.html物料清单页勾选、备注。dashboard.html数据看板签到率、物料完成率、实时更新。WebView 集成时踩了三个坑坑一本地文件加载路径问题。我把前端文件放在assets/www/目录下WebView 加载时用file:///android_asset/www/index.html。但页面之间的跳转链接如果写相对路径在 WebView 里会解析错误。解决方案是统一用绝对路径或者在WebViewClient里拦截 URL 请求手动映射到 assets 目录。坑二JavaScript 接口调用。前端需要调用原生能力比如扫码需要通过addJavascriptInterface注入一个 Java 对象。这里要注意注入的方法必须加JavascriptInterface注解否则在 Android 4.2 以上版本不会被识别。另外注入的对象名不要用window或document这种保留字我一开始用了app结果和某些页面的全局变量冲突了改成了NativeBridge才正常。坑三WebView 历史版本兼容性。不同 Android 版本内置的 WebView 版本差异很大。Android 8.1 可能还在用 Chrome 60 左右的内核不支持某些 ES6 语法。我一开始用了可选链操作符?.在测试机上直接白屏。解决方案是要么用 Babel 转译要么老老实实写 ES5 兼容代码。我选了后者因为项目不大没必要引入构建工具。// 不兼容的写法 const name user?.profile?.name; // 兼容的写法 const name user user.profile user.profile.name;3.4 第四阶段原生能力对接与文件处理这个阶段花了三天主要处理扫码、文件下载、图片上传这三个原生能力。扫码用的是 ZXing 库集成方式很简单在build.gradle里加依赖然后在 Activity 里启动扫码 Intent。但这里有个坑扫码结果的回调处理。如果你是在 WebView 里触发扫码需要先通过JavascriptInterface调用原生方法原生方法启动扫码 Activity扫码完成后通过evaluateJavascript把结果回传给 WebView。// 原生侧 JavascriptInterface fun startScan() { val intent Intent(this, ScanActivity::class.java) startActivityForResult(intent, REQUEST_CODE_SCAN) } override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) { if (requestCode REQUEST_CODE_SCAN resultCode RESULT_OK) { val result data?.getStringExtra(scan_result) ?: webView.evaluateJavascript(onScanResult($result), null) } }// WebView 侧 function triggerScan() { NativeBridge.startScan(); } function onScanResult(result) { // 处理扫码结果 document.getElementById(checkin-code).value result; }文件下载是另一个坑。WebView 默认不支持下载链接需要设置DownloadListener。但 Android 10 以上版本的文件存储权限变了不能直接往外部存储写文件。解决方案是用DownloadManager把下载任务交给系统处理。webView.setDownloadListener { url, userAgent, contentDisposition, mimetype, contentLength - val request DownloadManager.Request(Uri.parse(url)) request.setMimeType(mimetype) request.setNotificationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_COMPLETED) request.setDestinationInExternalPublicDir(Environment.DIRECTORY_DOWNLOADS, URLUtil.guessFileName(url, contentDisposition, mimetype)) val dm getSystemService(DOWNLOAD_SERVICE) as DownloadManager dm.enqueue(request) }图片上传用的是WebChromeClient的onShowFileChooser方法。这里要注意Android 不同版本返回的 Intent 不一样需要做兼容处理。我参考了网上流传的webview 历史版本合集里的兼容方案核心逻辑是判断系统版本分别处理ACTION_GET_CONTENT和ACTION_PICK。注意文件上传和下载的权限配置在AndroidManifest.xml里要写全。我一开始只写了INTERNET和CAMERA结果下载功能一直失败后来加了WRITE_EXTERNAL_STORAGE和READ_EXTERNAL_STORAGE才正常。Android 13 以上还需要加READ_MEDIA_IMAGES和READ_MEDIA_VIDEO。3.5 第五阶段调试、测试与性能优化这个阶段花了三天其中大部分时间在解决 WebView 的性能问题。第一个性能问题是首屏加载慢。WebView 加载本地 HTML 文件本身很快但如果页面里引用了外部 CDN 的 JS/CSS 库就会受网络影响。我的解决方案是把所有第三方库下载到本地放在assets/www/lib/目录下页面里用相对路径引用。这样即使断网App 也能正常打开。第二个性能问题是列表滚动卡顿。活动列表和签到记录列表的数据量大了之后滚动明显掉帧。原因是每次滚动都触发 DOM 重绘。解决方案是用虚拟列表只渲染可视区域内的元素。我手写了一个简单的虚拟列表实现核心逻辑是监听滚动事件计算当前可视区域的起始索引和结束索引只更新这部分 DOM。function renderVirtualList(container, data, itemHeight) { const scrollTop container.scrollTop; const visibleCount Math.ceil(container.clientHeight / itemHeight); const startIndex Math.floor(scrollTop / itemHeight); const endIndex Math.min(startIndex visibleCount 1, data.length); const fragment document.createDocumentFragment(); for (let i startIndex; i endIndex; i) { const item document.createElement(div); item.style.height itemHeight px; item.textContent data[i].title; fragment.appendChild(item); } container.innerHTML ; container.appendChild(fragment); container.style.height data.length * itemHeight px; }第三个性能问题是Supabase 实时订阅的回调频率过高。签到数据频繁更新时每次变化都会触发前端重新渲染。解决方案是加一个防抖函数把短时间内的多次更新合并成一次渲染。function debounce(fn, delay) { let timer null; return function (...args) { if (timer) clearTimeout(timer); timer setTimeout(() fn.apply(this, args), delay); }; } const debouncedRender debounce(renderDashboard, 300); supabase .channel(checkins) .on(postgres_changes, { event: *, schema: public, table: checkins }, debouncedRender) .subscribe();3.6 第六阶段打包、签名与上线发布这个阶段花了两天主要是处理打包和签名的问题。Android 打包的流程本身不复杂在 Android Studio 里点Build Generate Signed Bundle / APK创建一个签名密钥然后生成 APK 或 AAB 文件。但有几个细节容易出错签名密钥的保管。这个密钥文件.jks和密码一旦丢失你就无法更新已上架的 App。我的做法是把密钥文件放在一个加密的云盘里密码记在密码管理器里同时在项目的build.gradle里用环境变量引用密码而不是硬编码在文件里。signingConfigs { release { storeFile file(System.getenv(KEYSTORE_PATH) ?: release.jks) storePassword System.getenv(KEYSTORE_PASSWORD) keyAlias System.getenv(KEY_ALIAS) keyPassword System.getenv(KEY_PASSWORD) } }版本号和版本名的管理。versionCode是整数每次更新必须递增versionName是给用户看的字符串。我一开始忘了改versionCode导致新版本无法覆盖安装。后来在build.gradle里用了一个自动递增的脚本每次打包自动加一。混淆和压缩。发布版本一定要开启minifyEnabled和shrinkResources否则 APK 体积会很大。但开启混淆后WebView 的JavascriptInterface方法可能被混淆掉导致前端调用失败。解决方案是在proguard-rules.pro里加保留规则-keepclassmembers class com.example.app.NativeBridge { public *; } -keepattributes JavascriptInterface上架流程。如果只是内部使用可以直接分发 APK 文件。如果要上应用商店需要准备应用截图、描述、隐私政策等材料。我这次是内部使用所以直接生成了 APK通过企业微信分发给团队成员安装。实操心得内部使用的 App 建议生成 APK 而不是 AAB。AAB 是给应用商店用的不能直接安装到手机上。另外APK 的文件名最好带上版本号和日期比如WorkBuddyApp_v1.2.0_20250115.apk方便管理和回溯。4. 十六个坑的完整复盘与排查技巧4.1 环境配置类坑坑 1-4坑 1Android Studio 下载和安装。这个看似简单但国内网络环境下经常卡在下载 SDK 组件上。我的解决方案是先安装 Android Studio 本体然后在设置里配置代理或者手动下载 SDK 组件放到对应目录。另外android studio 能不能设置成中文这个问题答案是可以装中文语言包插件但我建议用英文原版因为大部分文档和报错信息都是英文的用中文界面反而增加沟通成本。坑 2Gradle 同步失败。最常见的原因是依赖版本不匹配。WorkBuddy 生成的build.gradle里的版本号可能已经过时需要去 Maven Central 查最新版本。另一个原因是 Gradle 本身的版本和 Android Gradle Plugin 版本不兼容这个在 Android Studio 的升级提示里会有说明。坑 3minSdk 设置过低导致 API 不可用。我一开始把 minSdk 设成了 21结果用某些新 API 时编译报错。后来改成了 24覆盖了 98% 以上的设备同时能用大部分现代 API。如果你的目标用户中有大量老设备可以设成 21但要做好版本判断。坑 4WebView 版本兼容性。这个问题在android8.1支持的webview版本这个搜索词里体现得很明显。Android 8.1 内置的 WebView 内核版本较老不支持某些现代 JS 语法和 CSS 特性。解决方案有两个一是用 Babel 转译 JS用 PostCSS 处理 CSS二是直接写兼容代码。我选了后者因为项目不大引入构建工具反而增加复杂度。4.2 Supabase 配置类坑坑 5-8坑 5RLS 策略导致查询返回空。前面已经讲过Supabase 默认开启 RLS不写策略就查不到数据。排查方法是在 SQL Editor 里执行select * from your_table;如果返回空但表里确实有数据那就是 RLS 的问题。坑 6auth.users 外键关联失败。前面也讲过不能直接关联auth.users要建profiles表。这个坑的排查方法是看 Supabase 的日志如果报foreign key constraint violation那就是关联错了表。坑 7实时订阅不触发。Supabase 的 Realtime 功能需要手动开启。在 Supabase 控制台的Database Replication里要把对应的表加到 publication 里。我一开始没开订阅一直没反应查了半天文档才发现。坑 8免费额度的限制。Supabase 免费版有 500MB 数据库和 1GB 存储对于中小项目够用。但要注意免费版的项目如果一周没有活动会被自动暂停。我的做法是设置一个定时任务每周调用一次 API保持项目活跃。4.3 WebView 集成类坑坑 9-12坑 9本地文件加载路径错误。前面讲过用file:///android_asset/前缀。另外如果页面里有 AJAX 请求跨域问题在 WebView 里更严格。解决方案是要么把数据请求都走原生接口要么在 Supabase 里配置 CORS 允许file://来源。坑 10JavascriptInterface 不生效。检查三个地方方法有没有加JavascriptInterface注解注入的对象名有没有冲突WebView 有没有开启 JavaScript。我一开始忘了加注解调了半天没反应。坑 11返回键直接退出 App。WebView 默认不处理返回键按返回键会直接退出 Activity。解决方案是重写onBackPressed判断 WebView 能不能回退。override fun onBackPressed() { if (webView.canGoBack()) { webView.goBack() } else { super.onBackPressed() } }坑 12WebView 内存泄漏。WebView 如果不正确销毁会导致 Activity 泄漏。解决方案是在onDestroy里先调用webView.loadUrl(about:blank)然后webView.destroy()最后把引用置空。4.4 文件与权限类坑坑 13-16坑 13文件下载失败。前面讲过用DownloadManager。另外Android 10 以上需要在AndroidManifest.xml里加android:requestLegacyExternalStoragetrue否则下载的文件找不到。坑 14图片上传路径错误。WebView 的onShowFileChooser返回的 URI 在不同 Android 版本里格式不一样。Android 4.4 返回content://com.android.providers.media.documents/document/image%3A123Android 10 返回content://com.android.providers.media.documents/document/image%3A456。需要用ContentResolver解析成真实路径。坑 15相机权限被拒绝后无法再次请求。Android 6.0 以上需要动态申请权限。如果用户拒绝了再次请求时系统可能不再弹窗。解决方案是在请求权限前先检查shouldShowRequestPermissionRationale如果返回 false说明用户勾选了“不再询问”需要引导用户去设置页手动开启。坑 16APK 安装失败。最常见的原因是签名不一致。如果你之前用调试签名安装过再用发布签名安装会报INSTALL_FAILED_UPDATE_INCOMPATIBLE。解决方案是先卸载旧版本再安装新版本。另外Android 8.0 以上需要在AndroidManifest.xml里加android:requestLegacyExternalStoragetrue才能安装未知来源的 APK。5. 可复用经验与工具链沉淀5.1 WorkBuddy 使用技巧怎么问才能得到可用的代码用 WorkBuddy 这段时间我总结了几条提问技巧第一给上下文不要只给一句话。比如不要只问“帮我写一个登录页面”而是说“帮我写一个登录页面用 HTML/CSS/JS包含手机号输入框、验证码输入框、发送验证码按钮、登录按钮样式简洁适配移动端验证码按钮点击后倒计时 60 秒”。第二指定技术栈和版本。比如“用 KotlinminSdk 24targetSdk 34WebView 加载本地 assets 目录下的 HTML 文件”。这样它生成的代码更贴近你的实际环境。第三要求它解释关键决策。比如“为什么用 DownloadManager 而不是直接写文件”这样你能理解背后的逻辑遇到类似问题时能自己判断。第四生成的代码一定要审查。特别是涉及权限、网络请求、文件操作的部分WorkBuddy 可能给出不完整或不安全的实现。我的习惯是把它生成的代码当成草稿自己再过一遍该加的异常处理加上该改的版本号改掉。5.2 Supabase 的最佳实践清单经过这个项目我整理了一份 Supabase 的使用清单后续项目可以直接复用建表时一定要建profiles表用触发器关联auth.users。RLS 策略按“最小权限”原则写默认拒绝按需开放。实时订阅的表要手动加到 publication 里。免费版项目要定期保活避免被暂停。数据库查询尽量用 Supabase 的客户端库不要手写 REST 请求。文件存储用 Supabase Storage不要自己搭文件服务器。边缘函数可以用来处理敏感逻辑比如支付回调、数据校验。5.3 WebView 混合架构的适用边界WebView 混合架构不是万能的。根据我的经验它适合以下场景内部工具类 App用户量不大对性能要求不高。快速验证产品想法需要快速迭代。团队里 Web 开发人员多移动端开发人员少。页面数量不多交互逻辑不复杂。它不适合以下场景对性能要求极高的 App比如游戏、视频编辑。需要大量原生动画和手势交互的 App。需要上架应用商店且对用户体验有严格要求的 App。如果你不确定选哪个方案我的建议是先用 WebView 混合架构快速做出 MVP验证需求后再决定要不要重写成原生。这样试错成本最低。5.4 上线检查清单最后附上一份我每次上线前都会过一遍的检查清单检查项检查内容是否通过签名发布签名是否正确配置密钥是否备份版本号versionCode 是否递增versionName 是否更新混淆proguard 规则是否保留 JavascriptInterface权限所有需要的权限是否在 Manifest 里声明网络是否所有请求都走 HTTPS存储文件下载路径是否正确权限是否申请兼容是否在 Android 8/10/13 上测试通过性能首屏加载时间是否小于 3 秒崩溃是否有未捕获的异常导致崩溃数据Supabase RLS 策略是否测试通过这份清单看起来简单但每次上线前过一遍能避免 90% 的低级错误。我这次上线前就靠这份清单发现了一个权限遗漏的问题省了一次紧急修复。这个项目后续还可以这样扩展把前端页面用 Vue 或 React 重写提升开发效率把 Supabase 的边缘函数用起来处理更复杂的业务逻辑如果用户量涨了可以考虑把 WebView 换成 React Native 或 Flutter提升性能体验。但那是下一步的事了当前这个版本已经能满足需求稳定运行了三个月没出过大问题。 
长河君 · 2026/10/15 7:49:01 · 阅读 1.2k AI辅助开发实战：三周用WorkBuddy+Supabase上线Android App
1. 为什么我选择 WorkBuddy 来搭一个真正能上线的 App去年年底我接了个私活帮一个做线下活动策划的团队做内部工具。需求不复杂活动排期、人员签到、物料清单、简单的数据看板。但对方提了一个硬性要求——必须是一个能装到手机上的 App而不是丢个网页链接让大家在浏览器里点来点去。预算有限工期三周团队里就我一个人。这个场景其实很典型。大量中小团队、个人开发者、甚至大公司里的创新小组都会遇到“需要一个 App但不值得养一个移动端团队”的情况。传统的路子是 React Native 或者 Flutter学习成本、构建链路、上架流程随便哪一环都能卡住你。我当时的判断是用 WorkBuddy 这类 AI 辅助开发工作台来搭骨架把精力集中在业务逻辑和上线流程上而不是耗在环境配置和样板代码里。WorkBuddy 本质上是一个 AI 驱动的开发工作台你可以把它理解成一个“懂代码的搭档”。它不是一个低代码拖拽平台也不是一个纯粹的代码生成器而是介于两者之间——你用自然语言描述需求它帮你生成结构化的项目代码、配置文件、甚至部署脚本然后你在它的基础上做修改和调试。这个定位决定了它特别适合“有明确需求、有一定技术基础、但不想从零搭架子”的场景。我最终交付的是一个 Android 原生壳 WebView 混合架构的 App后端用 Supabase 做数据存储和鉴权前端页面用 HTML/CSS/JS 写通过 WebView 加载。这个方案的好处是开发速度快、调试方便、后续维护成本低。整个项目从零到能装到手机上跑通用了大概两周半中间踩了十六个坑有些坑差点让我推翻重来。这篇文章我会把这六个阶段、十六个坑、以及最终沉淀下来的可复用经验完整拆开讲。适合谁看如果你是一个独立开发者、小团队的技术负责人、或者想快速验证一个 App 想法的产品经理这篇文章里的每一步你都可以直接抄作业。如果你是完全零基础的小白也没关系我会把关键概念用生活化的方式解释清楚你跟着走也能跑通。2. 整体方案设计与技术选型拆解2.1 为什么是 Android 原生壳 WebView而不是纯原生或纯跨平台先说结论我选 Android 原生壳 WebView核心原因是开发效率和调试便利性的平衡。纯原生开发Kotlin/Java的问题是每一个页面、每一个交互都要写原生代码UI 调整要重新编译调试周期长。对于一个只有三周工期的项目来说这个路子太慢了。纯跨平台方案React Native、Flutter虽然能复用代码但环境配置本身就是一道坎而且遇到原生能力调用时还是要写平台特定代码学习曲线并不平缓。WebView 混合架构的逻辑是用 Web 技术写界面和业务逻辑用原生壳提供容器和原生能力。这样做的好处非常直接前端页面用 HTML/CSS/JS 写改一行代码刷新就能看到效果调试速度和写网页一样快。原生壳只需要处理几件事加载 WebView、处理文件下载、调用相机/定位等原生能力、管理应用生命周期。后续如果要上 iOS理论上可以复用大部分 Web 代码只需要换一个 iOS 原生壳。当然这个方案也有代价。WebView 的性能不如原生复杂动画和大量列表滚动时会有卡顿感。但对于内部工具类 App 来说这个代价完全可以接受。我当时的判断是用户不会因为一个签到按钮的动画不够丝滑就弃用这个工具他们关心的是能不能快速完成签到、数据能不能实时同步。2.2 Supabase 在后端扮演什么角色Supabase 是我在这个项目里做的最正确的一个决定。它是一个开源的 Firebase 替代品提供 PostgreSQL 数据库、用户鉴权、实时订阅、文件存储、边缘函数等能力。对于我这种一个人干全栈的场景来说它几乎解决了所有后端需求。具体来说我用到了这几个能力数据库活动排期、人员名单、物料清单、签到记录全部存在 PostgreSQL 里。Supabase 提供了一个可视化的表编辑器建表和改字段非常方便。鉴权用 Supabase Auth 做手机号验证码登录。它内置了短信发送能力我只需要配置好模板就行不用自己接短信服务商。实时订阅签到数据需要实时同步到看板页面。Supabase 的 Realtime 功能可以监听数据库变化推送到前端省了我自己搭 WebSocket 的功夫。行级安全策略RLS这个后面会详细讲是 Supabase 最强大的功能之一也是我踩坑最多的地方。Supabase 的免费额度对于中小型项目来说完全够用500MB 数据库、1GB 文件存储、每月 200 万次 API 请求。即使后续用户量涨了升级到 Pro 版也只要 25 美元一个月比养一个后端服务器便宜得多。2.3 WorkBuddy 在开发流程中的定位WorkBuddy 在这个项目里的角色不是“帮你写完所有代码”而是“帮你跳过所有样板代码和配置地狱”。我具体用它做了这几件事生成 Android 项目的基础结构包括build.gradle、AndroidManifest.xml、MainActivity 的 WebView 初始化代码。生成 Supabase 的客户端封装代码包括登录、查询、实时订阅的调用示例。生成前端页面的 HTML/CSS/JS 骨架我在此基础上调整样式和交互。排查报错时把错误日志丢给它让它给出可能的原因和修复方案。这里要强调一点WorkBuddy 生成的内容必须经过你的审查和修改。它给的代码不一定完全符合你的项目配置特别是版本号、依赖库、API 调用方式这些细节经常需要手动调整。我的经验是把它当成一个“高级代码补全工具”来用而不是“一键生成完整 App”的魔法按钮。3. 六个阶段的完整实操记录3.1 第一阶段需求梳理与项目骨架搭建这个阶段我花了大概两天。第一天跟需求方开了两次会把功能清单确定下来。第二天用 WorkBuddy 生成项目骨架。需求清单最终确定如下功能模块具体需求优先级登录手机号验证码登录P0活动排期列表展示、详情查看、创建/编辑P0人员签到扫码签到、手动签到、签到记录P0物料清单列表展示、勾选确认、备注P1数据看板签到率、物料完成率、实时更新P1消息通知活动变更通知、签到提醒P2P0 是必须上线的P1 是尽量上线P2 可以后续迭代。这个优先级划分很重要因为后面遇到坑的时候你需要知道哪些功能可以砍掉来保上线时间。用 WorkBuddy 生成项目骨架时我给的提示词大概是这样的帮我生成一个 Android 项目的基础结构要求使用 KotlinminSdk 24targetSdk 34主 Activity 使用 WebView 加载本地 assets 目录下的 index.html开启 JavaScript 和 DOM Storage处理返回键回退网页配置网络权限和文件下载权限。WorkBuddy 返回的代码基本可用但有几个地方需要手动改build.gradle里的依赖版本号是它训练数据里的旧版本我改成了当时最新的稳定版。AndroidManifest.xml里缺少android:usesCleartextTraffictrue这个在开发阶段加载本地 HTTP 服务时需要上线前要改成 HTTPS。WebView 的WebViewClient和WebChromeClient需要自己补充WorkBuddy 只给了最基础的版本。注意WorkBuddy 生成的build.gradle文件里compileSdk和targetSdk的版本号一定要根据你本地安装的 Android SDK 版本来改。我一开始没改直接同步失败报了一堆找不到 SDK 的错误。3.2 第二阶段Supabase 后端配置与数据建模这个阶段花了三天其中两天在踩坑。Supabase 的配置本身不复杂但有几个关键决策会影响后续开发效率。首先是数据表设计。我建了五张表events活动信息字段包括 id、title、description、start_time、end_time、location、created_by。attendees参与人员字段包括 id、event_id、name、phone、status。checkins签到记录字段包括 id、event_id、attendee_id、checkin_time、method。materials物料清单字段包括 id、event_id、name、quantity、checked、note。profiles用户信息字段包括 id关联 auth.users、name、role。这里第一个坑来了Supabase 的auth.users表不能直接外键关联。你需要建一个profiles表用触发器在用户注册时自动插入一条记录。我一开始不知道这个直接在events表里用created_by关联auth.users.id结果 RLS 策略怎么写都不对。正确的做法是-- 创建 profiles 表 create table profiles ( id uuid references auth.users on delete cascade primary key, name text, role text default user, created_at timestamp with time zone default timezone(utc::text, now()) ); -- 创建触发器用户注册时自动插入 profiles create function public.handle_new_user() returns trigger as $$ begin insert into public.profiles (id, name) values (new.id, new.raw_user_meta_data-name); return new; end; $$ language plpgsql security definer; create trigger on_auth_user_created after insert on auth.users for each row execute procedure public.handle_new_user();第二个坑是RLS 策略的编写。Supabase 默认开启 RLS如果你不写策略所有查询都会返回空。我一开始以为是自己代码写错了查了半天才发现是 RLS 没配置。RLS 策略的逻辑是针对每一张表、每一种操作select/insert/update/delete定义什么条件下允许访问。比如events表的查询策略-- 允许所有登录用户查看活动 create policy Allow logged-in users to view events on events for select using (auth.role() authenticated); -- 允许创建者编辑自己的活动 create policy Allow creators to update their events on events for update using (auth.uid() created_by);实操心得RLS 策略写完之后一定要在 Supabase 的 SQL Editor 里用set role authenticated;和set request.jwt.claims来模拟不同用户测试。我一开始只在客户端测试结果因为用的是 service_role key绕过了 RLS一直没发现问题。3.3 第三阶段前端页面开发与 WebView 集成这个阶段花了四天是工作量最大的部分。前端页面我用的是原生 HTML/CSS/JS没有上框架。原因很简单页面数量不多六个页面交互逻辑不复杂上框架反而增加构建步骤和调试复杂度。页面清单login.html登录页手机号输入、验证码发送、登录按钮。index.html首页活动列表、创建活动入口。event-detail.html活动详情参与人员列表、签到入口、物料清单入口。checkin.html签到页扫码签到、手动签到。materials.html物料清单页勾选、备注。dashboard.html数据看板签到率、物料完成率、实时更新。WebView 集成时踩了三个坑坑一本地文件加载路径问题。我把前端文件放在assets/www/目录下WebView 加载时用file:///android_asset/www/index.html。但页面之间的跳转链接如果写相对路径在 WebView 里会解析错误。解决方案是统一用绝对路径或者在WebViewClient里拦截 URL 请求手动映射到 assets 目录。坑二JavaScript 接口调用。前端需要调用原生能力比如扫码需要通过addJavascriptInterface注入一个 Java 对象。这里要注意注入的方法必须加JavascriptInterface注解否则在 Android 4.2 以上版本不会被识别。另外注入的对象名不要用window或document这种保留字我一开始用了app结果和某些页面的全局变量冲突了改成了NativeBridge才正常。坑三WebView 历史版本兼容性。不同 Android 版本内置的 WebView 版本差异很大。Android 8.1 可能还在用 Chrome 60 左右的内核不支持某些 ES6 语法。我一开始用了可选链操作符?.在测试机上直接白屏。解决方案是要么用 Babel 转译要么老老实实写 ES5 兼容代码。我选了后者因为项目不大没必要引入构建工具。// 不兼容的写法 const name user?.profile?.name; // 兼容的写法 const name user user.profile user.profile.name;3.4 第四阶段原生能力对接与文件处理这个阶段花了三天主要处理扫码、文件下载、图片上传这三个原生能力。扫码用的是 ZXing 库集成方式很简单在build.gradle里加依赖然后在 Activity 里启动扫码 Intent。但这里有个坑扫码结果的回调处理。如果你是在 WebView 里触发扫码需要先通过JavascriptInterface调用原生方法原生方法启动扫码 Activity扫码完成后通过evaluateJavascript把结果回传给 WebView。// 原生侧 JavascriptInterface fun startScan() { val intent Intent(this, ScanActivity::class.java) startActivityForResult(intent, REQUEST_CODE_SCAN) } override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) { if (requestCode REQUEST_CODE_SCAN resultCode RESULT_OK) { val result data?.getStringExtra(scan_result) ?: webView.evaluateJavascript(onScanResult($result), null) } }// WebView 侧 function triggerScan() { NativeBridge.startScan(); } function onScanResult(result) { // 处理扫码结果 document.getElementById(checkin-code).value result; }文件下载是另一个坑。WebView 默认不支持下载链接需要设置DownloadListener。但 Android 10 以上版本的文件存储权限变了不能直接往外部存储写文件。解决方案是用DownloadManager把下载任务交给系统处理。webView.setDownloadListener { url, userAgent, contentDisposition, mimetype, contentLength - val request DownloadManager.Request(Uri.parse(url)) request.setMimeType(mimetype) request.setNotificationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_COMPLETED) request.setDestinationInExternalPublicDir(Environment.DIRECTORY_DOWNLOADS, URLUtil.guessFileName(url, contentDisposition, mimetype)) val dm getSystemService(DOWNLOAD_SERVICE) as DownloadManager dm.enqueue(request) }图片上传用的是WebChromeClient的onShowFileChooser方法。这里要注意Android 不同版本返回的 Intent 不一样需要做兼容处理。我参考了网上流传的webview 历史版本合集里的兼容方案核心逻辑是判断系统版本分别处理ACTION_GET_CONTENT和ACTION_PICK。注意文件上传和下载的权限配置在AndroidManifest.xml里要写全。我一开始只写了INTERNET和CAMERA结果下载功能一直失败后来加了WRITE_EXTERNAL_STORAGE和READ_EXTERNAL_STORAGE才正常。Android 13 以上还需要加READ_MEDIA_IMAGES和READ_MEDIA_VIDEO。3.5 第五阶段调试、测试与性能优化这个阶段花了三天其中大部分时间在解决 WebView 的性能问题。第一个性能问题是首屏加载慢。WebView 加载本地 HTML 文件本身很快但如果页面里引用了外部 CDN 的 JS/CSS 库就会受网络影响。我的解决方案是把所有第三方库下载到本地放在assets/www/lib/目录下页面里用相对路径引用。这样即使断网App 也能正常打开。第二个性能问题是列表滚动卡顿。活动列表和签到记录列表的数据量大了之后滚动明显掉帧。原因是每次滚动都触发 DOM 重绘。解决方案是用虚拟列表只渲染可视区域内的元素。我手写了一个简单的虚拟列表实现核心逻辑是监听滚动事件计算当前可视区域的起始索引和结束索引只更新这部分 DOM。function renderVirtualList(container, data, itemHeight) { const scrollTop container.scrollTop; const visibleCount Math.ceil(container.clientHeight / itemHeight); const startIndex Math.floor(scrollTop / itemHeight); const endIndex Math.min(startIndex visibleCount 1, data.length); const fragment document.createDocumentFragment(); for (let i startIndex; i endIndex; i) { const item document.createElement(div); item.style.height itemHeight px; item.textContent data[i].title; fragment.appendChild(item); } container.innerHTML ; container.appendChild(fragment); container.style.height data.length * itemHeight px; }第三个性能问题是Supabase 实时订阅的回调频率过高。签到数据频繁更新时每次变化都会触发前端重新渲染。解决方案是加一个防抖函数把短时间内的多次更新合并成一次渲染。function debounce(fn, delay) { let timer null; return function (...args) { if (timer) clearTimeout(timer); timer setTimeout(() fn.apply(this, args), delay); }; } const debouncedRender debounce(renderDashboard, 300); supabase .channel(checkins) .on(postgres_changes, { event: *, schema: public, table: checkins }, debouncedRender) .subscribe();3.6 第六阶段打包、签名与上线发布这个阶段花了两天主要是处理打包和签名的问题。Android 打包的流程本身不复杂在 Android Studio 里点Build Generate Signed Bundle / APK创建一个签名密钥然后生成 APK 或 AAB 文件。但有几个细节容易出错签名密钥的保管。这个密钥文件.jks和密码一旦丢失你就无法更新已上架的 App。我的做法是把密钥文件放在一个加密的云盘里密码记在密码管理器里同时在项目的build.gradle里用环境变量引用密码而不是硬编码在文件里。signingConfigs { release { storeFile file(System.getenv(KEYSTORE_PATH) ?: release.jks) storePassword System.getenv(KEYSTORE_PASSWORD) keyAlias System.getenv(KEY_ALIAS) keyPassword System.getenv(KEY_PASSWORD) } }版本号和版本名的管理。versionCode是整数每次更新必须递增versionName是给用户看的字符串。我一开始忘了改versionCode导致新版本无法覆盖安装。后来在build.gradle里用了一个自动递增的脚本每次打包自动加一。混淆和压缩。发布版本一定要开启minifyEnabled和shrinkResources否则 APK 体积会很大。但开启混淆后WebView 的JavascriptInterface方法可能被混淆掉导致前端调用失败。解决方案是在proguard-rules.pro里加保留规则-keepclassmembers class com.example.app.NativeBridge { public *; } -keepattributes JavascriptInterface上架流程。如果只是内部使用可以直接分发 APK 文件。如果要上应用商店需要准备应用截图、描述、隐私政策等材料。我这次是内部使用所以直接生成了 APK通过企业微信分发给团队成员安装。实操心得内部使用的 App 建议生成 APK 而不是 AAB。AAB 是给应用商店用的不能直接安装到手机上。另外APK 的文件名最好带上版本号和日期比如WorkBuddyApp_v1.2.0_20250115.apk方便管理和回溯。4. 十六个坑的完整复盘与排查技巧4.1 环境配置类坑坑 1-4坑 1Android Studio 下载和安装。这个看似简单但国内网络环境下经常卡在下载 SDK 组件上。我的解决方案是先安装 Android Studio 本体然后在设置里配置代理或者手动下载 SDK 组件放到对应目录。另外android studio 能不能设置成中文这个问题答案是可以装中文语言包插件但我建议用英文原版因为大部分文档和报错信息都是英文的用中文界面反而增加沟通成本。坑 2Gradle 同步失败。最常见的原因是依赖版本不匹配。WorkBuddy 生成的build.gradle里的版本号可能已经过时需要去 Maven Central 查最新版本。另一个原因是 Gradle 本身的版本和 Android Gradle Plugin 版本不兼容这个在 Android Studio 的升级提示里会有说明。坑 3minSdk 设置过低导致 API 不可用。我一开始把 minSdk 设成了 21结果用某些新 API 时编译报错。后来改成了 24覆盖了 98% 以上的设备同时能用大部分现代 API。如果你的目标用户中有大量老设备可以设成 21但要做好版本判断。坑 4WebView 版本兼容性。这个问题在android8.1支持的webview版本这个搜索词里体现得很明显。Android 8.1 内置的 WebView 内核版本较老不支持某些现代 JS 语法和 CSS 特性。解决方案有两个一是用 Babel 转译 JS用 PostCSS 处理 CSS二是直接写兼容代码。我选了后者因为项目不大引入构建工具反而增加复杂度。4.2 Supabase 配置类坑坑 5-8坑 5RLS 策略导致查询返回空。前面已经讲过Supabase 默认开启 RLS不写策略就查不到数据。排查方法是在 SQL Editor 里执行select * from your_table;如果返回空但表里确实有数据那就是 RLS 的问题。坑 6auth.users 外键关联失败。前面也讲过不能直接关联auth.users要建profiles表。这个坑的排查方法是看 Supabase 的日志如果报foreign key constraint violation那就是关联错了表。坑 7实时订阅不触发。Supabase 的 Realtime 功能需要手动开启。在 Supabase 控制台的Database Replication里要把对应的表加到 publication 里。我一开始没开订阅一直没反应查了半天文档才发现。坑 8免费额度的限制。Supabase 免费版有 500MB 数据库和 1GB 存储对于中小项目够用。但要注意免费版的项目如果一周没有活动会被自动暂停。我的做法是设置一个定时任务每周调用一次 API保持项目活跃。4.3 WebView 集成类坑坑 9-12坑 9本地文件加载路径错误。前面讲过用file:///android_asset/前缀。另外如果页面里有 AJAX 请求跨域问题在 WebView 里更严格。解决方案是要么把数据请求都走原生接口要么在 Supabase 里配置 CORS 允许file://来源。坑 10JavascriptInterface 不生效。检查三个地方方法有没有加JavascriptInterface注解注入的对象名有没有冲突WebView 有没有开启 JavaScript。我一开始忘了加注解调了半天没反应。坑 11返回键直接退出 App。WebView 默认不处理返回键按返回键会直接退出 Activity。解决方案是重写onBackPressed判断 WebView 能不能回退。override fun onBackPressed() { if (webView.canGoBack()) { webView.goBack() } else { super.onBackPressed() } }坑 12WebView 内存泄漏。WebView 如果不正确销毁会导致 Activity 泄漏。解决方案是在onDestroy里先调用webView.loadUrl(about:blank)然后webView.destroy()最后把引用置空。4.4 文件与权限类坑坑 13-16坑 13文件下载失败。前面讲过用DownloadManager。另外Android 10 以上需要在AndroidManifest.xml里加android:requestLegacyExternalStoragetrue否则下载的文件找不到。坑 14图片上传路径错误。WebView 的onShowFileChooser返回的 URI 在不同 Android 版本里格式不一样。Android 4.4 返回content://com.android.providers.media.documents/document/image%3A123Android 10 返回content://com.android.providers.media.documents/document/image%3A456。需要用ContentResolver解析成真实路径。坑 15相机权限被拒绝后无法再次请求。Android 6.0 以上需要动态申请权限。如果用户拒绝了再次请求时系统可能不再弹窗。解决方案是在请求权限前先检查shouldShowRequestPermissionRationale如果返回 false说明用户勾选了“不再询问”需要引导用户去设置页手动开启。坑 16APK 安装失败。最常见的原因是签名不一致。如果你之前用调试签名安装过再用发布签名安装会报INSTALL_FAILED_UPDATE_INCOMPATIBLE。解决方案是先卸载旧版本再安装新版本。另外Android 8.0 以上需要在AndroidManifest.xml里加android:requestLegacyExternalStoragetrue才能安装未知来源的 APK。5. 可复用经验与工具链沉淀5.1 WorkBuddy 使用技巧怎么问才能得到可用的代码用 WorkBuddy 这段时间我总结了几条提问技巧第一给上下文不要只给一句话。比如不要只问“帮我写一个登录页面”而是说“帮我写一个登录页面用 HTML/CSS/JS包含手机号输入框、验证码输入框、发送验证码按钮、登录按钮样式简洁适配移动端验证码按钮点击后倒计时 60 秒”。第二指定技术栈和版本。比如“用 KotlinminSdk 24targetSdk 34WebView 加载本地 assets 目录下的 HTML 文件”。这样它生成的代码更贴近你的实际环境。第三要求它解释关键决策。比如“为什么用 DownloadManager 而不是直接写文件”这样你能理解背后的逻辑遇到类似问题时能自己判断。第四生成的代码一定要审查。特别是涉及权限、网络请求、文件操作的部分WorkBuddy 可能给出不完整或不安全的实现。我的习惯是把它生成的代码当成草稿自己再过一遍该加的异常处理加上该改的版本号改掉。5.2 Supabase 的最佳实践清单经过这个项目我整理了一份 Supabase 的使用清单后续项目可以直接复用建表时一定要建profiles表用触发器关联auth.users。RLS 策略按“最小权限”原则写默认拒绝按需开放。实时订阅的表要手动加到 publication 里。免费版项目要定期保活避免被暂停。数据库查询尽量用 Supabase 的客户端库不要手写 REST 请求。文件存储用 Supabase Storage不要自己搭文件服务器。边缘函数可以用来处理敏感逻辑比如支付回调、数据校验。5.3 WebView 混合架构的适用边界WebView 混合架构不是万能的。根据我的经验它适合以下场景内部工具类 App用户量不大对性能要求不高。快速验证产品想法需要快速迭代。团队里 Web 开发人员多移动端开发人员少。页面数量不多交互逻辑不复杂。它不适合以下场景对性能要求极高的 App比如游戏、视频编辑。需要大量原生动画和手势交互的 App。需要上架应用商店且对用户体验有严格要求的 App。如果你不确定选哪个方案我的建议是先用 WebView 混合架构快速做出 MVP验证需求后再决定要不要重写成原生。这样试错成本最低。5.4 上线检查清单最后附上一份我每次上线前都会过一遍的检查清单检查项检查内容是否通过签名发布签名是否正确配置密钥是否备份版本号versionCode 是否递增versionName 是否更新混淆proguard 规则是否保留 JavascriptInterface权限所有需要的权限是否在 Manifest 里声明网络是否所有请求都走 HTTPS存储文件下载路径是否正确权限是否申请兼容是否在 Android 8/10/13 上测试通过性能首屏加载时间是否小于 3 秒崩溃是否有未捕获的异常导致崩溃数据Supabase RLS 策略是否测试通过这份清单看起来简单但每次上线前过一遍能避免 90% 的低级错误。我这次上线前就靠这份清单发现了一个权限遗漏的问题省了一次紧急修复。这个项目后续还可以这样扩展把前端页面用 Vue 或 React 重写提升开发效率把 Supabase 的边缘函数用起来处理更复杂的业务逻辑如果用户量涨了可以考虑把 WebView 换成 React Native 或 Flutter提升性能体验。但那是下一步的事了当前这个版本已经能满足需求稳定运行了三个月没出过大问题。