1. 从零到上线为什么我选择 WorkBuddy 作为主力开发工具去年年底我接手了一个内部工具类 App 的开发任务需求很明确两周内出一个能装到同事手机上、能跑通核心流程的可用版本。团队没有专职的 Android 和 iOS 开发只有我一个写过几年后端、偶尔碰前端的人。摆在面前的选择无非是原生开发、跨端框架或者干脆套个 WebView 壳子。原生开发周期太长跨端框架学习成本不低最后我选了 WorkBuddy 这条路线——用 AI 辅助生成代码骨架再自己补齐业务逻辑和打包流程。这个项目最终上线了内部两百多人在用从立项到发版一共踩了十六个坑。我把整个过程拆成六个阶段每个阶段该做什么、容易在哪里翻车、怎么绕过去都整理在这篇里。如果你也是那种“一个人要顶一个团队”的开发者或者想用 AI 工具快速把想法变成能安装的 App这篇内容应该能帮你省下不少试错时间。WorkBuddy 本质上是一个 AI 编程助手和 CodeBuddy 属于同一类工具核心能力是根据自然语言描述生成代码片段、补全函数、解释报错。它不是一个完整的 App 开发框架但配合 Android Studio 和 WebView 容器可以大幅压缩从零搭建到可运行的时间。我用的版本是国际版界面语言和代码提示风格跟国内版略有差异但核心功能一致。下面所有操作都基于这个版本展开。2. 第一阶段环境搭建与工具链选型2.1 Android Studio 安装与 WorkBuddy 插件配置Android Studio 是绕不开的。我下载的是当时最新的稳定版安装过程没什么好说的一路下一步就行。真正需要注意的是 SDK 版本的选择。我一开始选了最新的 API 级别结果发现部分老旧测试机跑不起来后来降到 API 28 才覆盖了全部目标设备。如果你不确定目标设备的系统分布建议先查一下后台统计数据或者直接选 API 26 以上、API 30 以下这个区间兼容性和新特性支持比较平衡。WorkBuddy 的安装有两种方式独立客户端和 IDE 插件。我两种都试过最后留在插件方案上。独立客户端适合快速生成代码片段然后手动粘贴插件方案则可以直接在 Android Studio 里补全和修改上下文理解更准确。安装插件的过程很简单在 Android Studio 的插件市场搜索 WorkBuddy点击安装后重启 IDE登录账号就能用。这里有个小坑如果你的网络环境对某些域名有限制插件登录可能会失败需要提前确认网络策略。注意WorkBuddy 国际版和国内版的账号体系不互通插件市场里搜到的版本可能和你的账号不匹配。建议先确定用哪个版本再统一安装对应的插件和客户端。2.2 项目初始化用 AI 生成第一版骨架环境就绪后我直接在 Android Studio 里新建了一个 Empty Activity 项目。包名、项目名这些按实际需求填语言选 Kotlin最小 SDK 选 API 26。建完之后我打开 WorkBuddy 的对话窗口输入了第一段提示词“帮我生成一个包含底部导航栏、三个 Fragment 的 Android 项目结构使用 Material Design 组件。”WorkBuddy 返回了完整的目录结构和关键文件代码包括 MainActivity、三个 Fragment 的骨架、底部导航的菜单资源文件。我对照着把代码复制到对应位置编译一次通过。这一步省掉了我至少半天查文档和试错的时间。但要注意AI 生成的代码默认用的是较新的依赖版本如果你的 Gradle 版本较旧可能会报依赖冲突。我的做法是先把 Gradle 升级到与依赖匹配的版本再同步项目。2.3 WebView 容器的引入时机这个项目里有一个核心页面需要加载外部网页内容所以 WebView 是必须的。我在第一阶段就把 WebView 的基础配置写好了而不是等到后面再补。原因很简单WebView 的初始化、权限配置、缓存策略这些如果后期才加很容易和现有页面生命周期冲突改起来更麻烦。基础配置包括在 AndroidManifest.xml 里添加网络权限在布局文件里放置 WebView 控件在 Activity 或 Fragment 里设置 WebSettings。我开启的选项有 JavaScript、DOM Storage、数据库存储关闭了缩放按钮。另外记得处理返回键逻辑否则用户按返回会直接退出 App 而不是网页后退。这些细节 WorkBuddy 都能生成但你需要明确告诉它“处理 WebView 返回键”否则它默认不写。3. 第二阶段核心功能开发与 AI 辅助编码3.1 用 WorkBuddy 生成业务逻辑代码的实操方法进入业务开发阶段后我基本把 WorkBuddy 当成了一个“高级代码补全器”。具体做法是先自己写好函数签名和注释描述清楚输入输出和业务规则然后让 WorkBuddy 补全函数体。比如有一个“根据用户输入的关键词过滤列表”的功能我写了这样的注释// 输入原始列表 ListItem关键词 String // 输出过滤后的列表匹配规则为标题包含关键词忽略大小写 // 如果关键词为空返回原始列表 fun filterItems(items: ListItem, keyword: String): ListItem {WorkBuddy 补全的代码逻辑正确还自动加了空值判断。这种用法比直接让它“写一个过滤函数”要准确得多因为注释里已经把边界条件说清楚了。我的经验是给 AI 的提示越具体生成的代码越可用。模糊的需求描述只会得到模糊的代码改起来比自己写还累。3.2 处理 WebView 与原生页面的数据交互这个项目里WebView 加载的页面需要调用原生的一些能力比如获取设备信息、调用相机。这就涉及到 JavaScript 与原生代码的互调。我在 WebView 里注入了 JavaScript 接口通过addJavascriptInterface把原生对象暴露给网页。网页端用window.AndroidBridge.方法名()调用。这里踩了一个坑注入的对象方法必须在主线程执行否则会抛异常。我一开始在子线程里调用了 UI 相关操作直接崩溃。后来在方法内部用runOnUiThread包了一层才解决。另外注入接口的名字不要用Android这种太通用的词容易和网页里的变量冲突我用的是NativeBridge加项目前缀。提示WebView 的addJavascriptInterface在 API 17 及以上需要加JavascriptInterface注解否则方法不会被识别。这个注解很容易漏漏了之后网页调用没有任何反应也不报错排查起来很费时间。3.3 进度条与加载状态的处理WebView 加载网页需要时间用户需要看到加载状态。我在布局里加了一个水平进度条在onPageStarted时显示在onPageFinished时隐藏。但实际测试发现有些网页的onPageFinished触发时页面上的图片和异步内容还没加载完进度条消失后页面还是空白的。后来我加了一个延迟隐藏的逻辑在onPageFinished后再等 500 毫秒才隐藏进度条体验好了很多。另外如果网页加载失败需要给用户一个反馈。我重写了onReceivedError方法在失败时显示一个错误提示页面并提供重试按钮。这个错误页面也是用 WorkBuddy 生成的我描述了需求后它给出了完整的布局和逻辑代码我只需要调整一下样式和文案。4. 第三阶段打包、签名与安装包优化4.1 生成签名证书与配置构建类型开发完成后要打包成正式安装包。第一步是生成签名证书。在 Android Studio 的 Build 菜单里找到 Generate Signed Bundle / APK选择 APK然后创建新的密钥库。密钥库路径、密码、别名这些信息一定要记好后续更新版本必须用同一个证书否则用户无法覆盖安装。我创建了两个构建类型debug 和 release。debug 用于日常测试release 用于正式分发。在 build.gradle 里配置签名信息时我把密码和别名放在了本地的一个 properties 文件里没有直接写在构建脚本中。这样做的好处是构建脚本可以提交到代码仓库而敏感信息不会泄露。WorkBuddy 帮我生成了读取 properties 文件的代码片段省去了查 Gradle 文档的时间。4.2 混淆与资源压缩的取舍release 构建默认开启混淆和资源压缩。我一开始直接用了默认配置结果打包后运行崩溃日志显示某个类被混淆后找不到。原因是 WebView 的 JavaScript 接口类不能被混淆需要在 proguard 规则里保留。我加了这样一行-keepclassmembers class com.example.app.NativeBridge { public *; }加完之后重新打包问题解决。资源压缩方面我开启了shrinkResources但发现有些动态引用的资源被误删了。后来在keep.xml里手动保留了这些资源。如果你的项目里也有动态加载的资源建议先关闭资源压缩等确认没有误删后再开启。4.3 安装包体积优化的几个实用手段第一版安装包打出来有 18MB对于一个工具类 App 来说偏大。我做了三件事来瘦身一是移除未使用的依赖库用./gradlew dependencies查看依赖树把没有用到的库删掉二是把图片资源换成 WebP 格式体积平均减少 30%三是开启 ABI 拆分只保留 armeabi-v7a 和 arm64-v8a 两个架构安装包直接降到 11MB。ABI 拆分的配置在 build.gradle 里加几行代码就行WorkBuddy 可以根据你的描述生成对应的 splits 配置。需要注意的是拆分后不同架构的设备需要下载对应的安装包如果你只有一个通用包的需求就不要开拆分。5. 第四阶段测试、分发与上线前检查5.1 真机测试中发现的兼容性问题模拟器上跑得好好的一到真机就出问题这是常态。我遇到的第一个兼容性问题是 WebView 版本差异。测试机里有一台老设备系统 WebView 版本很低导致部分 CSS 和 JavaScript 特性不支持页面布局错乱。解决办法是在 App 内提示用户升级 WebView或者使用第三方 WebView 内核。我选了前者因为项目周期不允许引入额外依赖。第二个问题是文件下载。网页里有下载链接点击后没有反应。排查后发现是 WebView 默认不处理下载链接需要设置DownloadListener并手动处理。我加了一个下载监听器把下载任务交给系统下载管理器处理。这里要注意 Android 10 以上的存储权限变化需要适配分区存储。5.2 内部分发的几种方式对比因为是企业内部使用我没有上应用商店而是选择了直接分发 APK。分发方式试过三种邮件附件、内部文件服务器、第三方分发平台。邮件附件最方便但很多邮箱对 APK 附件有限制经常被拦截。内部文件服务器需要配置访问权限但可控性最强。第三方分发平台有现成的下载页面和版本管理但需要考虑数据安全。最后我选了一个折中方案把 APK 放在内部文件服务器上生成一个短链接通过内部通讯工具发给同事。同时在 App 里加了一个检查更新的功能启动时请求版本接口如果有新版本就提示下载。这个检查更新的逻辑也是 WorkBuddy 生成的我只需要提供一个版本接口的 URL 和返回格式。5.3 上线前的检查清单正式分发前我列了一个检查清单逐项确认检查项确认内容状态签名证书使用 release 证书密码已备份完成混淆规则WebView 接口类已保留完成权限声明只声明必要的权限完成网络配置支持 HTTPS无明文流量完成崩溃日志接入崩溃收集工具完成版本号versionCode 和 versionName 已更新完成测试覆盖主流机型真机测试通过完成这个清单看起来简单但每一项都对应着实际踩过的坑。比如网络配置这一项Android 9 以上默认禁止明文 HTTP 流量如果后端接口还是 HTTP 的需要在 manifest 里加usesCleartextTraffic或者配置网络安全策略。我一开始没注意测试时接口全部请求失败排查了半天才发现是这个原因。6. 第五阶段踩过的十六个坑与排查实录6.1 环境与构建类问题坑一Gradle 版本与插件不匹配。新建项目时 Android Studio 自动生成的 Gradle 版本和 WorkBuddy 生成的依赖版本不一致导致同步失败。解决办法是统一版本号或者让 WorkBuddy 根据当前 Gradle 版本生成兼容的依赖配置。坑二SDK 路径包含中文或空格。这个问题在老版本 Android Studio 上很常见导致构建失败。解决办法是把 SDK 安装到纯英文路径下。坑三缓存导致的诡异报错。有时候代码没问题但构建就是失败。执行File Invalidate Caches / Restart清一下缓存大部分情况下能解决。坑四依赖冲突。多个库引用了同一个库的不同版本导致编译通过但运行崩溃。用./gradlew app:dependencies查看依赖树找到冲突的库用exclude排除旧版本。6.2 运行时与兼容性类问题坑五WebView 白屏。原因可能是网页加载失败、JavaScript 报错、或者硬件加速冲突。排查方法是开启 WebView 的调试模式在 Chrome 里查看控制台输出。坑六返回键直接退出 App。没有重写onBackPressed或onKeyDown导致用户按返回键时直接退出而不是网页后退。解决办法是判断 WebView 是否可以后退可以则后退不可以则执行默认行为。坑七文件上传无响应。WebView 默认不支持文件选择需要重写onShowFileChooser方法启动系统文件选择器并把结果返回给网页。坑八下载链接点击无反应。需要设置DownloadListener并处理下载任务的创建和通知。坑九跨域请求被拦截。WebView 里的网页发起的 AJAX 请求可能因为跨域策略失败。解决办法是在后端配置 CORS或者使用原生接口代理请求。坑十本地存储丢失。如果开启了 DOM Storage 但用户清理了 App 数据本地存储的内容会丢失。重要数据建议同步到服务端。6.3 打包与分发类问题坑十一签名证书丢失。一旦丢失无法发布更新版本。解决办法是备份证书文件并记录密码和别名。坑十二混淆导致反射失败。使用了反射的代码在混淆后找不到类或方法。需要在 proguard 规则里保留相关类。坑十三资源压缩误删动态资源。通过keep.xml手动保留或者关闭资源压缩。坑十四安装包解析失败。通常是签名问题或架构不匹配。检查签名配置和 ABI 拆分设置。坑十五覆盖安装失败。新旧版本的签名不一致或者 versionCode 没有递增。确保每次发版都递增 versionCode。坑十六部分机型安装被拦截。某些手机厂商的安全中心会拦截非应用商店来源的安装包。需要引导用户开启“允许安装未知来源应用”的权限。7. 第六阶段可复用经验与后续扩展方向7.1 把重复劳动交给 AI 的边界在哪里用 WorkBuddy 这段时间我最大的体会是AI 适合做“有明确输入输出”的事情不适合做“需要理解业务上下文”的事情。比如生成一个网络请求的封装类、写一个列表适配器、补全一个工具函数这些它做得很好。但涉及到业务规则判断、用户交互流程设计、异常情况的处理策略还是得自己来。我的做法是把开发任务拆成两类一类是“模板化代码”直接让 WorkBuddy 生成另一类是“业务逻辑”自己写注释和签名让 WorkBuddy 补全函数体然后自己审查和调整。这样既提高了效率又保证了代码质量。7.2 项目结构组织的几点建议这个项目我采用了按功能模块划分包结构的方式而不是按类型划分。比如webview包下放所有和 WebView 相关的类network包下放网络请求相关的类。这样做的好处是找代码方便改一个功能只需要在一个包内操作。另外我把 WorkBuddy 生成的代码统一放在一个generated包下方便区分哪些是 AI 生成的、哪些是自己写的。后续维护时如果发现 generated 包里的代码有问题可以快速定位和替换。7.3 后续可以继续优化的方向这个 App 目前还是以 WebView 为主原生页面只占了很小一部分。后续如果要做大可以考虑把核心页面逐步原生化提升流畅度。另外检查更新、崩溃收集、用户反馈这些基础设施还可以继续完善。如果你也在用 WorkBuddy 或者类似的工具做 App 开发我的建议是不要指望 AI 帮你写完整个项目但可以把它当成一个随时在线的结对编程伙伴。你负责想清楚要做什么它负责帮你写出第一版代码然后你再改。这个分工模式下效率提升是实实在在的。
AI辅助开发实战：WorkBuddy从零搭建Android应用与避坑指南
1. 从零到上线为什么我选择 WorkBuddy 作为主力开发工具去年年底我接手了一个内部工具类 App 的开发任务需求很明确两周内出一个能装到同事手机上、能跑通核心流程的可用版本。团队没有专职的 Android 和 iOS 开发只有我一个写过几年后端、偶尔碰前端的人。摆在面前的选择无非是原生开发、跨端框架或者干脆套个 WebView 壳子。原生开发周期太长跨端框架学习成本不低最后我选了 WorkBuddy 这条路线——用 AI 辅助生成代码骨架再自己补齐业务逻辑和打包流程。这个项目最终上线了内部两百多人在用从立项到发版一共踩了十六个坑。我把整个过程拆成六个阶段每个阶段该做什么、容易在哪里翻车、怎么绕过去都整理在这篇里。如果你也是那种“一个人要顶一个团队”的开发者或者想用 AI 工具快速把想法变成能安装的 App这篇内容应该能帮你省下不少试错时间。WorkBuddy 本质上是一个 AI 编程助手和 CodeBuddy 属于同一类工具核心能力是根据自然语言描述生成代码片段、补全函数、解释报错。它不是一个完整的 App 开发框架但配合 Android Studio 和 WebView 容器可以大幅压缩从零搭建到可运行的时间。我用的版本是国际版界面语言和代码提示风格跟国内版略有差异但核心功能一致。下面所有操作都基于这个版本展开。2. 第一阶段环境搭建与工具链选型2.1 Android Studio 安装与 WorkBuddy 插件配置Android Studio 是绕不开的。我下载的是当时最新的稳定版安装过程没什么好说的一路下一步就行。真正需要注意的是 SDK 版本的选择。我一开始选了最新的 API 级别结果发现部分老旧测试机跑不起来后来降到 API 28 才覆盖了全部目标设备。如果你不确定目标设备的系统分布建议先查一下后台统计数据或者直接选 API 26 以上、API 30 以下这个区间兼容性和新特性支持比较平衡。WorkBuddy 的安装有两种方式独立客户端和 IDE 插件。我两种都试过最后留在插件方案上。独立客户端适合快速生成代码片段然后手动粘贴插件方案则可以直接在 Android Studio 里补全和修改上下文理解更准确。安装插件的过程很简单在 Android Studio 的插件市场搜索 WorkBuddy点击安装后重启 IDE登录账号就能用。这里有个小坑如果你的网络环境对某些域名有限制插件登录可能会失败需要提前确认网络策略。注意WorkBuddy 国际版和国内版的账号体系不互通插件市场里搜到的版本可能和你的账号不匹配。建议先确定用哪个版本再统一安装对应的插件和客户端。2.2 项目初始化用 AI 生成第一版骨架环境就绪后我直接在 Android Studio 里新建了一个 Empty Activity 项目。包名、项目名这些按实际需求填语言选 Kotlin最小 SDK 选 API 26。建完之后我打开 WorkBuddy 的对话窗口输入了第一段提示词“帮我生成一个包含底部导航栏、三个 Fragment 的 Android 项目结构使用 Material Design 组件。”WorkBuddy 返回了完整的目录结构和关键文件代码包括 MainActivity、三个 Fragment 的骨架、底部导航的菜单资源文件。我对照着把代码复制到对应位置编译一次通过。这一步省掉了我至少半天查文档和试错的时间。但要注意AI 生成的代码默认用的是较新的依赖版本如果你的 Gradle 版本较旧可能会报依赖冲突。我的做法是先把 Gradle 升级到与依赖匹配的版本再同步项目。2.3 WebView 容器的引入时机这个项目里有一个核心页面需要加载外部网页内容所以 WebView 是必须的。我在第一阶段就把 WebView 的基础配置写好了而不是等到后面再补。原因很简单WebView 的初始化、权限配置、缓存策略这些如果后期才加很容易和现有页面生命周期冲突改起来更麻烦。基础配置包括在 AndroidManifest.xml 里添加网络权限在布局文件里放置 WebView 控件在 Activity 或 Fragment 里设置 WebSettings。我开启的选项有 JavaScript、DOM Storage、数据库存储关闭了缩放按钮。另外记得处理返回键逻辑否则用户按返回会直接退出 App 而不是网页后退。这些细节 WorkBuddy 都能生成但你需要明确告诉它“处理 WebView 返回键”否则它默认不写。3. 第二阶段核心功能开发与 AI 辅助编码3.1 用 WorkBuddy 生成业务逻辑代码的实操方法进入业务开发阶段后我基本把 WorkBuddy 当成了一个“高级代码补全器”。具体做法是先自己写好函数签名和注释描述清楚输入输出和业务规则然后让 WorkBuddy 补全函数体。比如有一个“根据用户输入的关键词过滤列表”的功能我写了这样的注释// 输入原始列表 ListItem关键词 String // 输出过滤后的列表匹配规则为标题包含关键词忽略大小写 // 如果关键词为空返回原始列表 fun filterItems(items: ListItem, keyword: String): ListItem {WorkBuddy 补全的代码逻辑正确还自动加了空值判断。这种用法比直接让它“写一个过滤函数”要准确得多因为注释里已经把边界条件说清楚了。我的经验是给 AI 的提示越具体生成的代码越可用。模糊的需求描述只会得到模糊的代码改起来比自己写还累。3.2 处理 WebView 与原生页面的数据交互这个项目里WebView 加载的页面需要调用原生的一些能力比如获取设备信息、调用相机。这就涉及到 JavaScript 与原生代码的互调。我在 WebView 里注入了 JavaScript 接口通过addJavascriptInterface把原生对象暴露给网页。网页端用window.AndroidBridge.方法名()调用。这里踩了一个坑注入的对象方法必须在主线程执行否则会抛异常。我一开始在子线程里调用了 UI 相关操作直接崩溃。后来在方法内部用runOnUiThread包了一层才解决。另外注入接口的名字不要用Android这种太通用的词容易和网页里的变量冲突我用的是NativeBridge加项目前缀。提示WebView 的addJavascriptInterface在 API 17 及以上需要加JavascriptInterface注解否则方法不会被识别。这个注解很容易漏漏了之后网页调用没有任何反应也不报错排查起来很费时间。3.3 进度条与加载状态的处理WebView 加载网页需要时间用户需要看到加载状态。我在布局里加了一个水平进度条在onPageStarted时显示在onPageFinished时隐藏。但实际测试发现有些网页的onPageFinished触发时页面上的图片和异步内容还没加载完进度条消失后页面还是空白的。后来我加了一个延迟隐藏的逻辑在onPageFinished后再等 500 毫秒才隐藏进度条体验好了很多。另外如果网页加载失败需要给用户一个反馈。我重写了onReceivedError方法在失败时显示一个错误提示页面并提供重试按钮。这个错误页面也是用 WorkBuddy 生成的我描述了需求后它给出了完整的布局和逻辑代码我只需要调整一下样式和文案。4. 第三阶段打包、签名与安装包优化4.1 生成签名证书与配置构建类型开发完成后要打包成正式安装包。第一步是生成签名证书。在 Android Studio 的 Build 菜单里找到 Generate Signed Bundle / APK选择 APK然后创建新的密钥库。密钥库路径、密码、别名这些信息一定要记好后续更新版本必须用同一个证书否则用户无法覆盖安装。我创建了两个构建类型debug 和 release。debug 用于日常测试release 用于正式分发。在 build.gradle 里配置签名信息时我把密码和别名放在了本地的一个 properties 文件里没有直接写在构建脚本中。这样做的好处是构建脚本可以提交到代码仓库而敏感信息不会泄露。WorkBuddy 帮我生成了读取 properties 文件的代码片段省去了查 Gradle 文档的时间。4.2 混淆与资源压缩的取舍release 构建默认开启混淆和资源压缩。我一开始直接用了默认配置结果打包后运行崩溃日志显示某个类被混淆后找不到。原因是 WebView 的 JavaScript 接口类不能被混淆需要在 proguard 规则里保留。我加了这样一行-keepclassmembers class com.example.app.NativeBridge { public *; }加完之后重新打包问题解决。资源压缩方面我开启了shrinkResources但发现有些动态引用的资源被误删了。后来在keep.xml里手动保留了这些资源。如果你的项目里也有动态加载的资源建议先关闭资源压缩等确认没有误删后再开启。4.3 安装包体积优化的几个实用手段第一版安装包打出来有 18MB对于一个工具类 App 来说偏大。我做了三件事来瘦身一是移除未使用的依赖库用./gradlew dependencies查看依赖树把没有用到的库删掉二是把图片资源换成 WebP 格式体积平均减少 30%三是开启 ABI 拆分只保留 armeabi-v7a 和 arm64-v8a 两个架构安装包直接降到 11MB。ABI 拆分的配置在 build.gradle 里加几行代码就行WorkBuddy 可以根据你的描述生成对应的 splits 配置。需要注意的是拆分后不同架构的设备需要下载对应的安装包如果你只有一个通用包的需求就不要开拆分。5. 第四阶段测试、分发与上线前检查5.1 真机测试中发现的兼容性问题模拟器上跑得好好的一到真机就出问题这是常态。我遇到的第一个兼容性问题是 WebView 版本差异。测试机里有一台老设备系统 WebView 版本很低导致部分 CSS 和 JavaScript 特性不支持页面布局错乱。解决办法是在 App 内提示用户升级 WebView或者使用第三方 WebView 内核。我选了前者因为项目周期不允许引入额外依赖。第二个问题是文件下载。网页里有下载链接点击后没有反应。排查后发现是 WebView 默认不处理下载链接需要设置DownloadListener并手动处理。我加了一个下载监听器把下载任务交给系统下载管理器处理。这里要注意 Android 10 以上的存储权限变化需要适配分区存储。5.2 内部分发的几种方式对比因为是企业内部使用我没有上应用商店而是选择了直接分发 APK。分发方式试过三种邮件附件、内部文件服务器、第三方分发平台。邮件附件最方便但很多邮箱对 APK 附件有限制经常被拦截。内部文件服务器需要配置访问权限但可控性最强。第三方分发平台有现成的下载页面和版本管理但需要考虑数据安全。最后我选了一个折中方案把 APK 放在内部文件服务器上生成一个短链接通过内部通讯工具发给同事。同时在 App 里加了一个检查更新的功能启动时请求版本接口如果有新版本就提示下载。这个检查更新的逻辑也是 WorkBuddy 生成的我只需要提供一个版本接口的 URL 和返回格式。5.3 上线前的检查清单正式分发前我列了一个检查清单逐项确认检查项确认内容状态签名证书使用 release 证书密码已备份完成混淆规则WebView 接口类已保留完成权限声明只声明必要的权限完成网络配置支持 HTTPS无明文流量完成崩溃日志接入崩溃收集工具完成版本号versionCode 和 versionName 已更新完成测试覆盖主流机型真机测试通过完成这个清单看起来简单但每一项都对应着实际踩过的坑。比如网络配置这一项Android 9 以上默认禁止明文 HTTP 流量如果后端接口还是 HTTP 的需要在 manifest 里加usesCleartextTraffic或者配置网络安全策略。我一开始没注意测试时接口全部请求失败排查了半天才发现是这个原因。6. 第五阶段踩过的十六个坑与排查实录6.1 环境与构建类问题坑一Gradle 版本与插件不匹配。新建项目时 Android Studio 自动生成的 Gradle 版本和 WorkBuddy 生成的依赖版本不一致导致同步失败。解决办法是统一版本号或者让 WorkBuddy 根据当前 Gradle 版本生成兼容的依赖配置。坑二SDK 路径包含中文或空格。这个问题在老版本 Android Studio 上很常见导致构建失败。解决办法是把 SDK 安装到纯英文路径下。坑三缓存导致的诡异报错。有时候代码没问题但构建就是失败。执行File Invalidate Caches / Restart清一下缓存大部分情况下能解决。坑四依赖冲突。多个库引用了同一个库的不同版本导致编译通过但运行崩溃。用./gradlew app:dependencies查看依赖树找到冲突的库用exclude排除旧版本。6.2 运行时与兼容性类问题坑五WebView 白屏。原因可能是网页加载失败、JavaScript 报错、或者硬件加速冲突。排查方法是开启 WebView 的调试模式在 Chrome 里查看控制台输出。坑六返回键直接退出 App。没有重写onBackPressed或onKeyDown导致用户按返回键时直接退出而不是网页后退。解决办法是判断 WebView 是否可以后退可以则后退不可以则执行默认行为。坑七文件上传无响应。WebView 默认不支持文件选择需要重写onShowFileChooser方法启动系统文件选择器并把结果返回给网页。坑八下载链接点击无反应。需要设置DownloadListener并处理下载任务的创建和通知。坑九跨域请求被拦截。WebView 里的网页发起的 AJAX 请求可能因为跨域策略失败。解决办法是在后端配置 CORS或者使用原生接口代理请求。坑十本地存储丢失。如果开启了 DOM Storage 但用户清理了 App 数据本地存储的内容会丢失。重要数据建议同步到服务端。6.3 打包与分发类问题坑十一签名证书丢失。一旦丢失无法发布更新版本。解决办法是备份证书文件并记录密码和别名。坑十二混淆导致反射失败。使用了反射的代码在混淆后找不到类或方法。需要在 proguard 规则里保留相关类。坑十三资源压缩误删动态资源。通过keep.xml手动保留或者关闭资源压缩。坑十四安装包解析失败。通常是签名问题或架构不匹配。检查签名配置和 ABI 拆分设置。坑十五覆盖安装失败。新旧版本的签名不一致或者 versionCode 没有递增。确保每次发版都递增 versionCode。坑十六部分机型安装被拦截。某些手机厂商的安全中心会拦截非应用商店来源的安装包。需要引导用户开启“允许安装未知来源应用”的权限。7. 第六阶段可复用经验与后续扩展方向7.1 把重复劳动交给 AI 的边界在哪里用 WorkBuddy 这段时间我最大的体会是AI 适合做“有明确输入输出”的事情不适合做“需要理解业务上下文”的事情。比如生成一个网络请求的封装类、写一个列表适配器、补全一个工具函数这些它做得很好。但涉及到业务规则判断、用户交互流程设计、异常情况的处理策略还是得自己来。我的做法是把开发任务拆成两类一类是“模板化代码”直接让 WorkBuddy 生成另一类是“业务逻辑”自己写注释和签名让 WorkBuddy 补全函数体然后自己审查和调整。这样既提高了效率又保证了代码质量。7.2 项目结构组织的几点建议这个项目我采用了按功能模块划分包结构的方式而不是按类型划分。比如webview包下放所有和 WebView 相关的类network包下放网络请求相关的类。这样做的好处是找代码方便改一个功能只需要在一个包内操作。另外我把 WorkBuddy 生成的代码统一放在一个generated包下方便区分哪些是 AI 生成的、哪些是自己写的。后续维护时如果发现 generated 包里的代码有问题可以快速定位和替换。7.3 后续可以继续优化的方向这个 App 目前还是以 WebView 为主原生页面只占了很小一部分。后续如果要做大可以考虑把核心页面逐步原生化提升流畅度。另外检查更新、崩溃收集、用户反馈这些基础设施还可以继续完善。如果你也在用 WorkBuddy 或者类似的工具做 App 开发我的建议是不要指望 AI 帮你写完整个项目但可以把它当成一个随时在线的结对编程伙伴。你负责想清楚要做什么它负责帮你写出第一版代码然后你再改。这个分工模式下效率提升是实实在在的。