企业官网建设流程全解析

1. 从零到上线：为什么我选择用 WorkBuddy 走完整个 App 开发链路

去年年底我接了一个内部工具类 App 的活儿，需求不复杂但要求能真正上线跑起来——不是那种做完扔在本地跑个 demo 就完事的项目。团队里没人有完整的移动端上线经验，我自己虽然写过 Android 和 WebView 相关的东西，但真要独立扛一个从开发到上架的流程，心里还是没底。后来一个朋友推荐了 WorkBuddy，说这玩意儿能把 AI 辅助和实际工程流程串起来，我抱着试试看的心态用了一整套，结果从立项到拿到应用商店的审核通过通知，前后大概六周时间。这篇文章就是把这六周里踩过的坑、总结出来的可复用经验，完整地摊开讲一遍。

WorkBuddy 本质上是一个 AI 驱动的开发协作工具，它跟 CodeBuddy 属于同一套体系下的产品，但侧重点不太一样。CodeBuddy 更偏向纯代码生成和补全，而 WorkBuddy 的定位是覆盖项目全生命周期的助手——从需求梳理、技术选型、代码框架搭建，到调试排错、打包发布，它都能插一脚。我个人的感受是，如果你是一个独立开发者或者小团队，想用 AI 提效但又不想被某个单一环节的工具绑死，WorkBuddy 这种全链路覆盖的思路确实更实用。它解决的核心问题是：让没有完整上线经验的人，也能按照一条相对清晰的路径把 App 推到用户手里。

这篇文章适合几类人看：一是跟我一样接过"能上线就行"这类需求的独立开发者；二是想了解 AI 辅助开发工具在实际项目中到底怎么用的技术同学；三是对 Android + WebView 混合开发模式感兴趣、想找一个可复用模板的人。我会把六个阶段拆开讲，每个阶段里遇到的坑单独拎出来说，最后给一份可以直接抄的检查清单。全文基于我自己的实操记录，涉及参数和配置的地方都会给出具体数值和选择理由。

2. 六个阶段的整体拆解与方案选型逻辑

2.1 为什么是六个阶段而不是五个或七个

我一开始想把流程压缩成四个阶段：需求、开发、测试、发布。但实际跑下来发现，AI 辅助开发引入了一个新的变量——工具本身的配置和调优需要单独占一个阶段。另外，WebView 混合开发模式下，前端资源和原生壳的联调又是一个独立的问题域。所以最终定型为六个阶段：需求梳理与工具配置、技术选型与框架搭建、核心功能开发、WebView 联调与优化、测试与问题排查、打包发布与上线。

这个划分方式的好处是每个阶段的边界清晰，出问题的时候能快速定位是哪个环节的锅。比如 App 闪退，可能是原生壳的问题，也可能是 WebView 加载的 H5 页面报错，分开阶段之后排查路径就短很多。另一个考虑是 WorkBuddy 在不同阶段的使用方式不一样——需求阶段用它做对话式梳理，开发阶段用它生成代码骨架，测试阶段用它辅助分析日志，每个阶段的提示词策略和输出预期都不同，混在一起容易乱。

2.2 技术选型的核心考量：为什么是 Android + WebView

这个项目最终选的是 Android 原生壳 + WebView 加载 H5 页面的混合方案。原因有几个：第一，团队里前端资源比原生开发资源多，用 WebView 能让前端同学直接参与核心页面开发；第二，需求里有大量表单和列表展示，H5 在这类场景下的开发效率远高于原生；第三，后续如果有 iOS 版本的需求，H5 部分可以直接复用，只需要换一个原生壳。

但 WebView 方案也有明显的代价。性能上，复杂动画和长列表的流畅度不如纯原生；体验上，WebView 的加载白屏、返回键处理、文件上传这些细节都需要额外处理。我踩过的坑里至少有五个跟 WebView 直接相关。所以如果你的项目对性能要求极高，或者交互复杂度很高，纯原生或者 Flutter 可能是更好的选择。WebView 方案适合的是：以内容展示和表单交互为主、对极致性能不敏感、需要快速迭代的项目。

2.3 WorkBuddy 在流程中的角色定位

WorkBuddy 在这个项目里主要承担三个角色：代码生成器、问题诊断助手、流程提醒器。代码生成方面，我用它生成了大概 60% 的样板代码，包括 Activity 基类、网络请求封装、WebView 配置类这些重复性高的部分。问题诊断方面，遇到报错日志看不懂的时候，直接把日志贴给它，它能给出几个可能的原因和排查方向，准确率大概七成左右，剩下三成需要自己判断。流程提醒方面，它会在你完成某个阶段后提示下一步该做什么，对于我这种第一次走完整流程的人来说挺有用的。

不过要注意，WorkBuddy 生成的代码不能直接无脑用。我遇到过它生成的 WebView 配置里漏掉了setDomStorageEnabled(true)，导致 H5 页面的 localStorage 完全用不了，排查了半天才发现。所以我的习惯是：AI 生成的每一段代码都要过一遍，特别是配置类和权限相关的部分。

3. 核心细节解析与实操要点

3.1 需求梳理阶段：怎么让 AI 真正理解你要做什么

这个阶段我犯的第一个错误是给 WorkBuddy 的需求描述太笼统。我一开始就说"做一个内部工具 App，能展示数据、能提交表单"，结果它生成的方案非常泛，几乎没法用。后来我改成结构化描述：目标用户是谁、核心功能有哪几个、每个功能的输入输出是什么、有没有特殊的业务规则。这样它给出的技术方案就具体多了。

具体操作上，我建议用"三段式"描述法：第一段说清楚这个 App 解决什么问题，第二段列出功能清单（用编号），第三段说明技术约束（比如必须用 Android、必须支持离线缓存）。这样 WorkBuddy 在后续生成代码时会有明确的边界，不会跑偏。我实测下来，用这种描述方式生成的代码骨架，直接可用的比例从三成提升到了六成左右。

注意：需求描述里不要用"等等"、"之类的"这种模糊词，AI 会自行脑补，补出来的东西往往不是你想要的。

3.2 框架搭建阶段：项目结构怎么定

Android 项目的目录结构我参考了 WorkBuddy 的建议，但做了一些调整。它默认生成的是一套比较标准的 MVC 结构，我改成了按功能模块划分的方式。具体来说，app/src/main/java/下面按feature包来组织，每个 feature 包里有自己的 Activity、Fragment、Adapter 和 ViewModel。这样后续加功能的时候不会出现一个包下面几十个文件的情况。

WebView 相关的配置我单独抽了一个WebViewConfig类，把常用的设置都封装进去。这里有个关键点：WebSettings的配置项很多，但不是所有项目都需要全开。我整理了一份常用配置对照表，放在下面。

这张表里的每一项我都在项目里实际验证过。特别是setAllowFileAccess，默认是 true，但如果不是必须读本地文件，建议关掉，否则会有安全风险。setMixedContentMode在 Android 5.0 以上默认就是 NEVER_ALLOW，但显式设置一下更稳妥。

3.3 核心功能开发：AI 生成代码的使用边界

WorkBuddy 在核心功能开发阶段帮我省了很多时间，但有几类代码我坚持手写：一是跟业务逻辑强相关的部分，比如表单校验规则、数据转换逻辑；二是涉及安全的部分，比如 token 存储、请求签名；三是跟第三方 SDK 交互的部分，因为不同版本的 SDK API 差异很大，AI 生成的代码经常对不上。

AI 生成代码最适合的场景是：样板代码（Activity 生命周期、Adapter 的 ViewHolder 模式）、工具类（日期格式化、字符串处理）、简单的网络请求封装。我统计了一下，这个项目里 AI 生成的代码大概占 60%，但其中需要修改后才能用的又占了生成量的 40% 左右。所以实际"直接可用"的比例大概是 36%，这个数字供你参考。

3.4 WebView 联调阶段：那些文档里不会写的细节

WebView 联调是这个项目里最耗时的部分，没有之一。我遇到的第一个问题是 H5 页面在 WebView 里加载时白屏时间过长。排查后发现是WebViewClient的onPageStarted和onPageFinished之间没有做任何过渡处理，用户看到的就是一片白。解决方案是在布局里加一个进度条，在onPageStarted时显示，onPageFinished时隐藏。这个进度条的实现很简单，但效果立竿见影。

第二个问题是返回键处理。WebView 默认的返回行为是直接关闭当前 Activity，但用户期望的是先回退网页历史。解决方案是重写onKeyDown，判断webView.canGoBack()，如果能回退就调webView.goBack()，否则再执行默认行为。这个逻辑不复杂，但如果不处理，用户体验会很割裂。

第三个问题是文件上传。H5 页面里的<input type="file">在 WebView 里默认是不工作的，需要重写WebChromeClient的onShowFileChooser方法，然后调起系统的文件选择器。这里有个坑：Android 不同版本的文件选择器回调方式不一样，需要做版本判断。我最后是参考了 WorkBuddy 给出的方案，加上自己查了一些资料才搞定。

4. 实操过程与核心环节实现

4.1 从零搭建项目骨架的完整步骤

第一步是创建项目。我用的是 Android Studio，版本是 Hedgehog 2023.1.1。创建项目时选的是 Empty Views Activity，语言选 Java（这个项目没用 Kotlin，因为团队里有人不熟）。minSdkVersion设的是 24，targetSdkVersion设的是 34。选 24 的原因是覆盖了大概 95% 以上的设备，同时避免了一些低版本特有的兼容性问题。

第二步是配置 Gradle。这里我踩了一个坑：WorkBuddy 生成的build.gradle里用的依赖版本比较旧，直接同步会报错。我手动把几个关键依赖升到了当时的最新稳定版：appcompat升到 1.6.1，constraintlayout升到 2.1.4，webkit升到 1.9.0。升级之后同步就正常了。这里建议每次创建新项目后都检查一下依赖版本，不要直接用模板里的默认值。

第三步是配置AndroidManifest.xml。需要加的权限有：INTERNET（网络请求）、ACCESS_NETWORK_STATE（网络状态检测）、READ_EXTERNAL_STORAGE和WRITE_EXTERNAL_STORAGE（如果涉及文件上传下载）。注意从 Android 6.0 开始，存储权限需要动态申请，不能只在 Manifest 里声明就完事。

第四步是创建 WebView 容器 Activity。这个 Activity 的布局很简单，就是一个FrameLayout里面放一个WebView和一个ProgressBar。ProgressBar默认设为GONE，在页面开始加载时设为VISIBLE。

4.2 WebView 配置类的完整实现与参数说明

WebViewConfig类是我封装的一个工具类，核心方法applySettings(WebView webView)里做了以下配置：

WebSettings settings = webView.getSettings(); settings.setJavaScriptEnabled(true); settings.setDomStorageEnabled(true); settings.setDatabaseEnabled(true); settings.setAllowFileAccess(false); settings.setAllowContentAccess(false); settings.setCacheMode(WebSettings.LOAD_DEFAULT); settings.setMixedContentMode(WebSettings.MIXED_CONTENT_NEVER_ALLOW); settings.setUserAgentString(settings.getUserAgentString() + " MyApp/1.0");

最后一行设置 UserAgent 是为了让 H5 页面能识别出请求来自 App 内嵌 WebView，方便前端做差异化处理。这个技巧在实际项目中很有用，比如前端可以根据 UserAgent 决定是否显示"在浏览器中打开"的提示。

另外，setAllowContentAccess(false)这个配置我犹豫了很久。关掉之后，H5 页面无法通过content://协议访问内容提供者的数据。但考虑到安全因素，最终还是关了。如果你的 H5 页面确实需要访问content://资源，再把它打开。

4.3 前后端联调的接口约定与调试技巧

前后端联调阶段，我建议先跟后端约定好接口的通用返回格式。我们这个项目用的是：

{ "code": 0, "message": "success", "data": {} }

code为 0 表示成功，非 0 表示各种错误。这个约定看起来简单，但能省很多事。前端只需要判断code是否为 0，不用每个接口都写一套判断逻辑。

调试技巧方面，我强烈建议在 WebView 里开启远程调试。具体做法是在WebView初始化时调用WebView.setWebContentsDebuggingEnabled(true)，然后用 Chrome 的chrome://inspect页面就能看到 WebView 里的页面，像调试普通网页一样调试 H5。这个功能在排查 H5 报错时简直是救命稻草。注意这个开关只在 debug 版本里开，release 版本要关掉。

4.4 打包发布前的检查清单

打包之前我整理了一份检查清单，每次发版前都过一遍：

• minSdkVersion和targetSdkVersion是否符合应用商店的要求
• 签名文件是否配置正确，keystore密码是否妥善保存
• build.gradle里的minifyEnabled是否按需开启（开启后要测试混淆规则是否完整）
• 所有硬编码的测试地址是否已替换为正式地址
• WebView.setWebContentsDebuggingEnabled是否已关闭
• 应用图标和启动页是否已替换为正式素材
• 版本号和版本名称是否已更新

这份清单看起来都是小事，但漏掉任何一项都可能导致发版失败或者线上问题。我第二次发版的时候就忘了关setWebContentsDebuggingEnabled，虽然不影响功能，但总归是个隐患。

5. 十六个坑的完整记录与排查思路

5.1 开发阶段踩的坑（坑 1 到坑 6）

坑 1：WorkBuddy 生成的代码里 WebView 配置不完整。前面提过，漏了setDomStorageEnabled，导致 H5 的 localStorage 用不了。排查方法是打开远程调试，在 Console 里看到localStorage is not defined的报错，才定位到问题。

坑 2：Gradle 依赖版本冲突。WorkBuddy 生成的build.gradle里appcompat和material的版本不匹配，同步时报Duplicate class错误。解决方法是统一用 BOM 来管理版本，或者手动对齐版本号。

坑 3：Android 12 以上的exported属性问题。如果 Activity 里有intent-filter，必须在 Manifest 里显式声明android:exported="true"，否则安装会失败。这个坑在 Android 12 之前不存在，升级targetSdkVersion之后才暴露出来。

坑 4：WebView 在 Android 5.0 以下的白屏问题。虽然minSdkVersion设的是 24，但测试机上有一台 Android 7.0 的设备也出现了白屏。排查后发现是硬件加速的问题，在 Activity 里加android:hardwareAccelerated="true"解决了。

坑 5：H5 页面里的alert不显示。WebView 默认不处理alert，需要重写WebChromeClient的onJsAlert方法。如果不处理，H5 里的alert调用会静默失败。

坑 6：网络请求在 Android 9 以上被拦截。Android 9 开始默认禁止明文 HTTP 请求，如果后端接口是 HTTP 的，需要在AndroidManifest.xml里配置networkSecurityConfig或者直接用 HTTPS。我们最后是把后端接口全部升级到了 HTTPS。

5.2 WebView 联调阶段踩的坑（坑 7 到坑 12）

坑 7：返回键直接退出 Activity。前面提过，需要重写onKeyDown处理网页回退。

坑 8：文件上传不工作。需要重写onShowFileChooser，并且处理 Android 不同版本的回调差异。

坑 9：H5 页面里的下载链接点击无反应。WebView 默认不处理下载，需要重写setDownloadListener，然后调起系统下载器或者用DownloadManager。

坑 10：WebView 内存泄漏。如果在 Activity 销毁时没有调webView.destroy()，会导致内存泄漏。解决方案是在onDestroy里先调webView.loadUrl("about:blank")，再调webView.destroy()。

坑 11：H5 页面里的tel:和mailto:链接无法唤起系统应用。需要重写shouldOverrideUrlLoading，判断 URL scheme，然后调起对应的系统 Intent。

坑 12：WebView 缓存导致页面不更新。如果 H5 页面更新了但 WebView 还加载旧缓存，需要调webView.clearCache(true)。但注意不要每次启动都清，否则缓存就失去意义了。

5.3 测试与发布阶段踩的坑（坑 13 到坑 16）

坑 13：应用商店审核被拒，原因是隐私政策不完整。现在国内应用商店对隐私政策的要求很严格，必须明确说明收集了哪些数据、用于什么目的。我们第一次提交时隐私政策写得太笼统，被拒了一次。

坑 14：64 位架构支持问题。如果应用里有原生库（.so文件），必须同时提供 32 位和 64 位的版本，否则在部分设备上会安装失败。我们项目里没有原生库，但这个坑值得注意。

坑 15：签名文件丢失导致无法更新。这个坑很致命。如果签名文件丢了，应用就无法覆盖安装，只能卸载重装。所以签名文件一定要备份，最好放在多个地方。

坑 16：版本号回退导致更新失败。应用商店要求新版本的versionCode必须大于旧版本，如果搞错了版本号，更新会失败。建议用脚本自动生成versionCode，避免手动出错。

6. 常见问题速查表与独家避坑技巧

6.1 问题排查速查表

6.2 独家避坑技巧

第一个技巧：在项目初期就建立一份"坑文档"。每次遇到问题、解决问题之后，花两分钟把问题和解决方案记下来。这个习惯看起来不起眼，但到了项目后期，这份文档就是最宝贵的财富。我这次记了十六个坑，下一个项目直接翻这份文档就能避开大部分。

第二个技巧：WorkBuddy 的对话记录要定期导出。它给出的方案和代码片段，有些当时没用到但后面可能有用。我习惯每周导出一次对话记录，按主题分类存档。这样后面遇到类似问题时，可以直接搜索历史记录，不用重新问一遍。

第三个技巧：WebView 的 UserAgent 里加上应用标识。前面提过，这个技巧能让 H5 页面识别出请求来源，方便前端做差异化处理。比如可以在 UserAgent 里加上版本号，前端根据版本号决定是否启用某些新功能。

第四个技巧：打包前用aapt dump badging检查 APK 信息。这个命令能看到 APK 的包名、版本号、权限、支持的架构等信息，比在 Android Studio 里看更直观。我每次发版前都会跑一遍，确认信息无误再上传。

6.3 关于 WorkBuddy 使用的几点体会

WorkBuddy 在这个项目里确实帮了大忙，但它不是万能的。我的体会是：它最擅长的是"有明确模式"的任务，比如生成样板代码、解释报错日志、提供排查方向。它不擅长的是"需要业务判断"的任务，比如决定某个功能该不该做、某个交互该怎么设计。所以我的用法是：把重复性的、有标准答案的工作交给它，把需要思考和判断的工作留给自己。

另外，WorkBuddy 和 CodeBuddy 配合使用效果更好。CodeBuddy 在写具体代码时补全更精准，WorkBuddy 在项目层面的规划和建议更全面。我通常是先用 WorkBuddy 做整体规划，再用 CodeBuddy 写具体代码，两者切换着用。

7. 可复用经验总结与后续扩展方向

这个项目跑下来，我觉得最有价值的经验不是某个具体的技术点，而是一套"从零到上线"的流程框架。这套框架的核心是：把大目标拆成小阶段，每个阶段有明确的输入输出，每个阶段结束后做一次检查。这样即使中间某个环节出了问题，也不会影响整体进度。

如果后续要扩展，我觉得有几个方向可以考虑。一是把 WebView 换成更现代的方案，比如 Jetpack Compose 的 WebView 封装，或者用 Flutter 的 WebView 插件。二是把 WorkBuddy 的使用流程标准化，形成一套提示词模板，这样下一个项目可以直接复用。三是把这份经验整理成团队内部文档，让其他人也能按照这个流程走一遍。

最后分享一个我在这个项目里养成的小习惯：每次完成一个阶段后，花十分钟写一段简短的复盘，记录这个阶段做了什么、遇到了什么问题、下次怎么改进。这个习惯让我在第二个项目里少踩了至少一半的坑。如果你也在做类似的事情，不妨试试。