说句实话用 AI 工具“搭一个 App”和“搭一个能上线的 App”完全是两码事。前者只要让 WorkBuddy 生成几个页面、跑通一个 demo半小时就能收获一堆彩虹屁后者要处理环境依赖、缓存目录、签名证书、隐私合规、审核打回、线上崩溃……每一项都足够让人想骂人。这个项目我用了三周左右把 WorkBuddy 从“问答助手”重新定位成了“带流程的研发队友”走了六个阶段踩了十六个坑最后成品真的上了应用商店。下面这些经验不是通用教程是我这二十多天里一点点试出来的希望对打算用 AI 工作台真正交付产品的朋友有点用。1. 先说结论WorkBuddy 在我这儿不是“聊天窗”是一套能约束 AI 的工作台1.1 为什么“一句话生成 App”走不到上架不管底层接了多强的模型只要把 AI 当聊天窗它就只会给你“看起来合理”的代码。它能帮你写出漂亮的页面和接口但不会替你回答“这个依赖会不会拉不下来”“这个权限声明会不会被打回”“这台机器的 Gradle 版本为什么和 CI 不一样”。上架是一个系统性工程要求的是稳定和可复现不是单点能力。我把 WorkBuddy 定位成“带流程的研发队友”它负责按我的规则拆任务、调用合适的 Skill、生成代码和命令并在关键节点停下来让我确认。说白了模型负责写WorkBuddy 负责组织我负责验收。这一步想明白之后后面所有阶段都顺了。1.2 WorkBuddy 的三层能力模型、Skill 与全局规则实际使用时WorkBuddy 不是某个大模型本身而是一个整合层。它内部可以接不同的模型同时提供了三层关键机制模型层决定生成质量的底座我日常用代码能力更强的模型做生成用轻量模型做格式化和总结Skill 层可复用的能力包每个 Skill 相当于“预置了提示词 脚本 检查清单”比如 android-build、api-client、code-review规则层全局规则文件对所有任务生效解决“同一个错误反复犯”的问题。很多人拿 WorkBuddy 和 CodeBuddy、Cursor 这类编辑器插件对比但 WorkBuddy 更强调任务编排和 Skill 复用。这个设计对我来说最大的价值是AI 的行为可以被约束、被沉淀、被复用。团队里其他人接手时只要导入同一份 Skill 和规则就能复现我的大部分流程。2. 六个阶段从想法到应用商店的完整路线2.1 阶段一需求收敛先把“能上线”定义清楚做这个项目的第一步不是写代码是把“能上线”翻译成可检查的硬指标。我选的是一个个人效率工具 App功能砍到只剩三个页面首页数据概览、录入页、设置页。功能少不代表好做反而是每一个按钮都要经得起推敲。我用 WorkBuddy 生成了项目简报重点写了五条非功能需求Android 最低支持 API 26iOS 最低支持 13太老的系统直接放弃不为小众设备浪费调试时间首次冷启动不超过 3 秒APK 包体积控制在 20MB 以内不采集用户敏感信息权限只保留网络和通知隐私政策必须有哪怕没有账号体系也要有一页说明所有页面必须有空态、错误态和弱网提示不能因为接口失败就白屏。这一阶段容易犯的错是“什么都想要”。如果一开始就把社区、推送、分享都塞进去后面每个阶段都会被人为放大坑根本踩不完。2.2 阶段二环境准备与项目骨架搭建技术选型上我选了 Android 原生 Kotlin 后端 Django。原因很简单这个 App 以列表和表单为主原生写不复杂同时团队对 Kotlin 和 Gradle 足够熟后端用 Django 造 API 很快自带 Admin 后台方便在开发期直接看数据。创建 Django 项目和 appdjango-admin startproject timesheet_server cd timesheet_server python manage.py startapp report创建 Android 工程后我让 WorkBuddy 检查了一轮 build.gradle重点看三件事Gradle 插件版本和 Gradle 发行版是否匹配、依赖的坐标是否能在内部镜像拉取、签名配置是否占位。这三件事后面果然都出过问题第一个就对应第三部分的坑 2。环境准备的核心原则是让本机和后续的打包机尽量一致。我在项目根目录放了一个docs/environment.md把 JDK 版本、Gradle 版本、Android SDK 路径、Python 版本全部写清楚。WorkBuddy 每次做环境类任务前都会先去读这个文件。2.3 阶段三把规则和 Skill 配置成“对所有任务生效”这个阶段是我觉得 WorkBuddy 和普通聊天工具最大的分水岭。你不需要每次对话都重复“你要注意什么”而是把规则放在全局配置里让后续所有任务都自动带上。我写了一份全局规则文件简化后大概是这样# workbuddy-global-rules 1. 每个任务开始前先阅读 PROJECT.md、CHANGELOG.md 和 docs/environment.md。 2. 不擅自修改依赖版本必须升级时先在 CHANGELOG 里列出影响面。 3. 所有代码改动必须给出可执行的验证步骤不允许只说“已测试”。 4. Android 构建失败时优先用依赖报告定位问题禁止无脑执行 clean。 5. 涉及权限、隐私、外部链接、分享文案时先完成合规检查再提交。 6. 每次任务结束更新 CHANGELOG.md并标记验证结果。规则不要写“要写高质量代码”这种废话要写成能二分判断对错的动作。比如“禁止无脑 clean”就是一条动作规则模型可以照着执行审查时也能一眼看出违没违反。Skill 方面我一开始装了十几个后来删到只剩五六个。因为 Skill 一旦多起来会出现“两个 Skill 改同一个配置文件”的情况后面坑 6 会详细说。2.4 阶段四核心功能开发与联调这一阶段是体力活也是最容易失控的地方。我的做法是把所有任务拆成任务卡每张卡必须写“完成定义DoD”比如后端新增/api/report/接口支持 POST 提交一条工时记录前端录入页调用该接口成功后回首页刷新数据统计断网时给出错误提示不做静默失败重试后能恢复。WorkBuddy 先生成 Django 侧的 model 和接口# report/models.py class TimeEntry(models.Model): user models.CharField(max_length64) minutes models.PositiveIntegerField() note models.TextField(blankTrue) created_at models.DateTimeField(auto_now_addTrue) def __str__(self): return f{self.user} - {self.minutes}min再生成 Android 侧的 Retrofit 接口interface ReportApi { POST(api/report/) suspend fun submit( Body body: TimeEntryRequest ): ApiResponseTimeEntryResult }联调阶段我养成了一个习惯每次真机联调必抓包。抓包的目的不是偷数据而是确认请求头、域名、超时时间、HTTP 状态码和预期一致。这里踩过 HTTPS 证书问题具体在坑 10。2.5 阶段五缓存、安全、性能与兼容性收尾很多 demo 项目死在“正常路径能用”但用户真实环境千奇百怪。这个阶段我花了两天主要做了四件事。第一把 WorkBuddy 的系统缓存目录改到独立位置。默认情况下缓存目录可能在临时目录里系统清理或权限不足时会丢失。我通过环境变量和配置项把缓存指到了项目目录下的.wb_cache并加到.gitignore里。第二App 内部统一走缓存封装。Android 用context.cacheDiriOS 用Caches目录不写死任何绝对路径。很多旧设备问题都是因为开发者把/sdcard/xxx写死了。第三安全与合规。权限只留了网络和通知加了代码混淆隐私政策页面独立上线。涉及外部链接时WorkBuddy 会自动加一条合规检查防止运营位链接出问题。第四性能。首页列表做了分页和缓存弱网时先展示缓存再刷新。冷启动时间压到了 2.8 秒APK 包体积 18MB都过了线。2.6 阶段六签名打包、上架与更新机制到了这里技术和业务已经不重要了流程才是主角。Android 侧我准备了独立的 keystore把签名文件放到安全目录密码放在环境变量里而不写进仓库。然后是加固、多渠道打包、生成渠道包。iOS 侧证书和描述文件总是出各种幺蛾子。我的做法是把证书的申请、导出、安装步骤整理成 checklist让 WorkBuddy 在每次打包前自动核对一遍防止过期。上架材料包含应用名称、一句话简介、5 张截图、隐私政策链接、权限说明。截图最容易被打回不要用模拟器截图要真机截图且尺寸严格按平台要求。发布前我在项目里接入了崩溃监控和版本更新接口确保用户拿到新版不是“开盲盒”。这步对应了坑 16——如果上线后才发现问题代价会大得多。3. 十六个坑现场回放与修复记录3.1 首批四坑环境、依赖与缓存坑 1Win7 上安装 WorkBuddy 卡在启动界面。我一开始在一台老机器上试过系统是 Win7。安装过程没报错但启动时白屏。排查后确认是系统缺少现代运行库和证书链补了相应组件后能启动但后续个别功能还是不稳定。后来我直接换到 Win10/Win11 环境这部分时间不值得省。如果你的机器特别老优先升级系统而不是跟安装器较劲。坑 2Gradle 任务依赖解析失败。这是出现频率最高的报错Could not determine the dependencies of task :app:compileDebugJavaWithJavac. Could not resolve all task dependencies for configuration :app:debugCompileClasspath.我第一次遇到时直接执行了clean结果当然没用因为问题根本不在缓存而在依赖坐标和仓库源。正确做法是用依赖报告命令./gradlew :app:dependencies --configuration debugCompileClasspath把报错坐标在依赖树里定位出来再看是不是版本冲突、仓库地址不可达或者依赖被公司内网策略拦截。挨个解决后再编译基本一遍过。坑 3默认缓存目录被系统清理。安装完 WorkBuddy 后如果之前用过其他版本缓存目录可能指向系统的临时目录被磁盘清理或权限限制后模型和 Skill 的缓存会丢失表现为“怎么回答变慢了”“每次任务像第一次见面”。解法是把缓存目录改成项目内的独立目录再设置环境变量固定住位置。坑 4本机模拟器跑得好好的打包机一构建就失败。这类问题十有八九是版本不一致。打包机 JDK 是 8本机是 17Gradle 插件要求的 JDK 版本就不满足。别急着改代码先比对java -version和./gradlew --version把两边对齐。3.2 第二批坑规则与 Skill 配置坑 5规则只写在单次任务里下次又犯同样的错。早期我用 WorkBuddy 时总会说“这次注意不要改依赖版本”但新任务开启后它完全不知道。这是上下文隔离机制导致的不是模型笨。解法是把长期规则写进全局配置文件让它在任务开始前自动加载。从那以后规则才真正“对所有任务生效”。坑 6Skill 装太多互相打架。我一度装了十几个 Skill结果两个 Skill 同时改 Gradle 配置一个要升插件版本一个要锁版本任务一多就冲突。Skill 不是收藏夹每多一个就多一份被误用的概率。最终我把 Skill 精简成了五个android-build、api-client、code-review、cache-manager、release-checklist。坑 7Skill 和规则没有版本管理。有一次我改了一份规则文件结果后续任务全变了味想回滚发现没有历史。现在我把规则和 Skill 放进 Git 仓库每次修改都走提交记录。回滚问题变成了git revert十分钟解决。坑 8任务链路太长模型“失忆”。开发阶段我把一个完整模块塞给 WorkBuddy让它一口气完成结果进行到一半时它忘了前面的约束。后来我把大任务拆成小任务每张任务卡只做一件事并且把关键结论写回 PROJECT.md相当于给模型“写笔记”失忆问题基本消失。3.3 第三批坑开发与联调坑 9模拟器一切正常真机白屏。模拟器环境和真机差距最大的地方在系统字体、屏幕尺寸和网络策略。白屏问题最后定位到混淆规则漏了一个类Release 包在真机上找不到页面入口。从那时起我每次发布前都会跑一遍“真机 Release 包”冒烟测试把这个动作变成硬性规则后这类问题很少再翻车。坑 10抓包失败。联调时我用抓包工具看接口但屏幕上始终没有请求记录。原因是 App 开启了 HTTPS 校验证书抓包工具的自签证书没被信任。处理方法是把抓包工具的 CA 证书安装到设备如果不想影响真机环境就用临时包或者用加白名单的 debug 配置。记住抓包不是看流量是验证“客户端到底发了什么”。坑 11Django 的 ALLOWED_HOSTS 和 CSRF 导致请求被拒。后端明明写好了接口App 一请求就 400/403。多数情况不是路由问题而是ALLOWED_HOSTS没把 App 请求的域名加进去或者 POST 请求触发 CSRF 校验。开发调试时可以把 CSRF 暂时关掉但上线前必须改成正式方案比如使用 token 校验。别为了省事把 CSRF 永久关闭。坑 12字体设置后中文乱码还差点踩到版权线。为了界面好看我让 WorkBuddy 引入了一个字体结果部分设备上中文显示为方块原因是字体文件不包含中文字形。后来换用系统默认字体或开源字体才解决。另外商业 App 用字体要看授权不能随便从网上扒一个 woff/ttf 就往包里塞。3.4 第四批坑发布前后坑 13iOS 浏览器唤起安装 App 失败。在网页里放一个“在 App 中打开”的按钮点击后无法唤起安装或跳转。排查后发现是 Universal Link 没有配置关联域名或者 App 的 URL Scheme 和网页不一致。正确做法是同时维护 universal link 和 scheme并保证网页上的链接与 App 侧注册的 team ID/bundle ID 匹配。真机测试时也要注意模拟器对 universal link 的支持并不完整。坑 14隐私权限说明不一致被审核打回。我明明只申请了网络和通知权限却在某个页面弹了一个存储权限弹窗审核人员一句话就打回。后来我把所有权限调用点列成清单和隐私政策逐条对齐并让 WorkBuddy 在每次新增权限时强制弹出确认避免“代码和文档两张皮”。坑 15升级后旧缓存不清理导致崩溃。新版本改了一个字段但没有做缓存兼容。老用户升级后本地缓存里旧字段读取失败直接闪退。现在的做法是每次发布前写清楚缓存版本号启动时做迁移迁移失败就清空缓存不能让用户卡死。坑 16上线后没有监控反馈只能靠商店评论。这个最隐蔽。App 上架第一天商店评分还行但第二天开始有一星评论我才知道部分机型启动崩溃。如果早点接入崩溃监控和日志上报不至于被动。现在所有核心事件都有埋点崩溃率和留存数据每天看一眼。4. 一份可复用的经验包规则模板、Skill 清单与验收检查表4.1 全局规则模板可以直接抄前面给过一个简化版这里给完整版我已经从项目里抽出来了[project] 项目上下文 - 读取 PROJECT.md 后再动手不要凭空假设。 - 改动前对比当前分支与主分支差异。 [engineering] - 依赖版本变更必须给出影响面说明。 - 构建失败时先做诊断再决定是否 clean。 - 任何新增配置都需要在 docs/environment.md 中登记。 [delivery] - 每个任务结束时更新 CHANGELOG.md。 - 打 Release 包前必须跑真机冒烟。 - 涉及权限、隐私、外部链接时输出合规说明。注意规则的价值在于“可以被检查”所以每一条都应该允许别人说“你违反了”。如果你写的规则无法判真假就别怪模型不遵守。4.2 我最后留下的 5 个 SkillSkill作用什么时候用android-buildAndroid 工程构建、Gradle 诊断、签名配置检查改完代码需要验证时api-client接口设计、Retrofit/OkHttp 配置、Django 路由任何前后端联调前code-review代码审查和隐患扫描每个任务完成后cache-manager缓存目录、缓存版本、迁移逻辑涉及本地存储时release-checklist上架材料、权限清单、隐私政策核对发版前必跑装得少的好处是WorkBuddy 每次自动选择 Skill 时不会纠结冲突也少了。如果真的需要新能力临时装一个用完就删保持工作台干净。4.3 上架前验收清单我每次发版前都会用这张表过一遍检查项通过标准功能测试核心流程在真机走通Release 包跑完冒烟用例兼容性Android 最低 API 26 与 iOS 13 以上各取一台真机缓存升级前数据可迁移迁移失败能自动清空兜底隐私权限申请点与隐私政策逐条对应包体积安装包不超过预设上限性能冷启动和页面切换在目标机达到预期监控崩溃监控已接入核心事件有埋点这张表不是给审核员看的是给我自己看的。它能让“我觉得差不多”变成“我有证据说可以发”。4.4 任务依赖类问题的标准排查流程如果你也遇到坑 2 或类似的依赖问题按这个顺序操作保留完整报错信息不要只截最后一行使用./gradlew :app:dependencies --configuration config导出依赖树检查冲突坐标优先采用更高的稳定版本检查仓库源顺序把内部稳定源放在前面修改后重新编译不要一上来就 clean如果仍然失败再考虑清理~/.gradle/caches中对应的坐标缓存。这套流程两次就帮我定位了问题比闭眼 clean 效率高太多了。5. 一口气解决我在这个项目里遇到最多的 5 个问题5.1 规则要怎样设置才能对所有任务生效把规则放在全局配置目录里而不是放在某个任务对话里。WorkBuddy 在每次新建任务时会自动加载全局规则我验证过只要不手动关闭它就是“对所有任务生效”的。如果某条规则只在特定的项目里需要就放项目级规则不要混入全局。如果你已经把它写在一次对话里了那它只对那一次对话有效。这个问题的标准答案就是写进配置文件让加载动作前置。判断是否生效可以故意写一条临时规则测试一下。5.2 缓存目录可以随便改吗可以但要注意三个点一是新目录要有稳定的环境变量或配置入口二是目录要加入项目版本控制和.gitignore的正确取舍三是应用内缓存一定要通过系统提供的标准目录接口获取不能写死绝对路径。改 WorkBuddy 的缓存目录是为了避免系统清理导致重复下载模型或技能包。改 App 的缓存目录是为了兼容升级和权限变化。两类问题别混在一起我在项目里是分开处理的。5.3 抓包看不到 App 请求是 App 有问题吗大概率不是 App 有问题是证书信任链断了。市面上的抓包工具都依赖设备安装 CA 证书并信任它App 如果开启了安全校验自签证书会被拒绝。解决办法是用 debug 包 安装调试 CA 证书或者临时关闭 SSL 校验定位后再恢复。我后来直接在 debug 配置里加了“信任用户证书”的开关Release 包保持严格校验既不影响联调也不牺牲线上安全。5.4 Django 创建了 app 但接口一直 404怎么办先查路由注册再查ALLOWED_HOSTS最后查 urls.py 的 include 路径。404 大多是路由没 include403 大多是 CSRF400 可能是请求体格式问题。用 WorkBuddy 生成代码后我会要求它把“接口访问路径”和“请求示例”一并写出来方便我在浏览器和抓包工具里快速验证。5.5 iOS 浏览器唤起 App 失败有哪些坑主要是 Universal Link、URL Scheme 和证书三处。Universal Link 要配置apple-app-site-association并放到 HTTPS 根目录URL Scheme 要唯一且和页面链接一致证书要用有效的 Team ID不能只看 bundle ID。最好在真机上测模拟器对 universal link 的支持并不完整。我在项目里就是漏了关联域名的声明补上之后唤起就正常了。这个项目做完后我最大的体会不是“AI 编程真厉害”而是“AI 工作台让流程管理变得可能了”。WorkBuddy 真正改变我的是它把规则、Skill、缓存这些工程概念引入 AI 协作让我能把经验固化成文件而不是只存在脑子里。如果你准备用 WorkBuddy 搭一个能上线的 App我的建议是先写规则再装 Skill再做第一个最小功能每一步都让 AI 给出验证步骤。别急着让它一口气生成全部代码把坑一个个填平上线的路比想象中长但也比想象中清晰。最后一个小技巧把这份规则文件保存好下一个项目直接复用你会感谢现在的自己。