★ FEATURED ARTICLE 1. 项目概述与整体阶段拆解先说结论我最近做完了一个能从零推到应用商店的跨平台 App核心开发工具是 WorkBuddy。整个项目从需求文档到 iOS/Android 双端上线一共走了六个阶段过程中我记录了十六个高发坑位最后还沉淀了一份可以复用的规则模板和自检清单。这篇复盘就是把「怎么用 WorkBuddy 把 App 真正做上线」这件事讲透。先说清楚 WorkBuddy 在我项目里扮演什么角色。它可以看作一个 AI 编程工作台能读项目文件、写代码、改配置、跑命令也支持把项目级别的规则提前写进去让后续所有任务都按同一套标准执行。这跟单纯用对话窗口聊代码是两个完全不同的体验前者是「带团队的实习生」后者是「随问随答的搜索引擎」。如果你还在把 AI 工具当问答工具用那这篇内容对你应该更有价值。我这次的目标是一个工具类 App覆盖 iOS 和 Android功能不复杂登录、数据列表、详情页、设置项、消息推送外加一个后台管理接口的对接。但越是这种看似常规的需求越容易忽略一堆工程细节。上线前被应用市场打回两次、真机上崩溃一次、审核被卡一周这些问题都不是功能难度造成的而是「流程坑」和「工程坑」。为什么特意强调「能上线」而不是「能跑起来」因为本地跑通和真正发布之间隔着一整条工程化链路证书签名、隐私合规、权限声明、兼容性、包体积、崩溃监控、灰度发布……这些东西用 AI 工具不会自动帮你解决但 AI 工具可以帮你快速补齐链路里每一环的代码和配置。前提是你自己脑子里有这条链路的地图。我打算按下面这条主线来展开先拆六个阶段我是怎么划分的再把十六个坑逐个说清楚最后把可复用的规则模板和检查清单完整放出来方便你直接抄。2. 六个阶段从零到上线的实操路径整个项目我拆成了六个阶段不是按传统瀑布流那样严格串行而是每个阶段都有明确的「产出物」和「退出标准」。这样做的好处是WorkBuddy 生成的代码可以被分阶段审查和验证出了问题能快速定位是哪一段冒烟了不会滚雪球。2.1 阶段一需求收敛与最小闭环定义这个阶段我花了两天产出物是一份一页纸需求文档外加一个核心路径图。很多人觉得做 App 可以上来就让 AI 生成页面我的建议恰恰相反先用文字把「用户从打开 App 到完成核心动作」这条路径写清楚最好手写不要用 AI。比如我这个 App 的核心闭环是用户下载安装 → 手机号登录 → 查看首页数据列表 → 点击进入详情 → 收藏/分享 → 退出。就这么简单的一条线把它定义清楚后面所有页面和接口都围绕它展开。WorkBuddy 在需求明确的前提下生成页面和交互的速度会快很多因为它不需要反复猜你要什么。这个阶段还要做技术选型决策。跨平台我选了 Flutter 配合 WorkBuddy 使用理由也很现实一套代码交付双端模板语法清晰AI 生成 UI 代码的错误率比某些脚本方案低。另外Flutter 的构建产物在 Android 和 iOS 上都很标准出问题容易排查。选型这件事最容易犯的错是贪多。什么热更新、微前端、动态化、服务端渲染对于第一个版本统统不要。你只需要保证「核心路径跑得通、双端能构建、审核能过」。技术栈越简单AI 辅助开发的稳定性越高。2.2 阶段二环境初始化与项目骨架搭建这个阶段的目标是在 WorkBuddy 里拉起来一个能编译的空壳工程。我用的流程是先手动创建项目骨架再让 WorkBuddy 帮忙补齐配置和目录结构。不要一上来就让它从零生成整个项目因为生成器对最新版本 SDK 的适配可能滞后容易把依赖版本写歪。实际操作上我是先在本机安装了 Flutter 稳定版 SDK然后用官方命令创建了项目模板。创建完成之后让 WorkBuddy 干这些事整理目录结构、写统一的网络层封装、加路由表、配置主题和通用组件。这些都是重复性高、规则明确的工作AI 做起来效率极高。这里有一个关键细节项目路径绝对不能放在系统盘默认缓存目录下。我最初没注意WorkBuddy 的工作区缓存和依赖下载全都堆到了 C 盘用户目录几天时间就占了 20 多 GB。后来专门改了系统缓存目录和环境变量才把磁盘空间救回来。如果你已经遇到了类似情况可以去设置里把缓存目录改到独立数据盘再把旧缓存清理掉。退出标准很简单flutter build apk --debug能跑通iOS 模拟器能启动。注意只要这一条达成就可以进入下一个阶段了。2.3 阶段三用 WorkBuddy 迭代页面与交互第三个阶段是整个项目里产出最高、也最需要纪律的阶段。我会把页面任务拆成小块一次只让 WorkBuddy 完成一个页面的静态结构和样式不在同一轮对话里塞「给我做一个首页顺便把详情页和设置页也做了」。更好的做法是每个页面建立一个独立任务描述包含页面功能、布局结构、交互状态加载、空态、错误态、参考风格。WorkBuddy 生成完第一版后我会用模拟器截图快速过一遍视觉和间距再让它按修改意见调整通常两三轮就能稳定。有一个技巧值得分享让 WorkBuddy 把页面样式抽成通用组件比如卡片组件、列表项组件、空状态组件。第一次生成可能每个页面都写一遍需要你主动提要求让它抽取。这一步做完后续新增页面会非常快而且双端视觉一致性有保证。这个阶段最容易翻车的地方是「UI 细节的无限循环」。AI 调整颜色和圆角非常方便但你不能让它反复微调十几次收益极低。我给自己的规定是单个页面调整不超过三轮三轮后如果还不满意直接自己改或者重新描述需求重新生成不要陷入微观调整的泥潭。2.4 阶段四业务逻辑与状态管理页面能看之后就要接数据和业务逻辑了。这阶段是整个项目里最考察架构能力的部分。我的做法是先定状态管理方案再写接口层最后处理缓存和异常。状态管理我选了适合中小项目的 Provider原因很朴素心智负担低、AI 生成相关代码的错误率低、社区资料多WorkBuddy 对它的理解也最成熟。如果你用特别冷门或版本极新的状态管理库AI 给出的代码很可能是旧版 API 混着新版 API排查成本会高很多。在这个阶段我给 WorkBuddy 定了几条硬规则网络层统一走封装好的 Dio 实例所有接口请求必须解析错误码页面内不直接写 HTTP 调用统一走 RepositoryToken 存储必须走安全存储不能存明文。这些规则写进项目级的规则配置里后续所有会话任务都会遵循。这是我认为 WorkBuddy 比普通对话式 AI 强的最重要一点项目级规则可以约束每个任务不需要每次重复强调。业务逻辑阶段还有一件事本地缓存。列表页这类数据要加缓存策略避免每次打开都白屏等接口。我给 App 加了「缓存先展示、后台刷新」的策略代码量不大但对用户体验的提升非常明显。WorkBuddy 用十分钟就写完了缓存模块但前提是你把策略描述清楚什么接口缓存、缓存多久、什么情况下强制刷新。2.5 阶段五真机调试、性能与安全自检模拟器上跑得顺不代表真机没问题。第五阶段是项目里耗时最长、也最枯燥的。我把这个阶段单独列出来是因为太多人在这里「踩坑而不自知」模拟器正常、一上真机就闪退或者功能正常但流畅度很差。具体执行上我先用一台 Android 真机和一台 iPhone 做基础功能验证覆盖最核心的路径登录、首页加载、详情页跳转、分享唤起、前后台切换。WorkBuddy 在这一阶段主要用于快速定位代码问题比如某个页面在低端 Android 机型上崩溃把崩溃日志贴给它它能很快定位到是某个 UI 组件的问题。性能检查不能只看崩溃。我用了内存占用、启动耗时、列表滑动帧率三个指标。其中「列表滑动帧率」最容易出问题典型原因是图片没有缓存、列表项没有复用、不必要的整个页面重建。遇到这类问题我的排查顺序是先看日志和 profiler 数据再定位到具体页面最后才交给 WorkBuddy 改代码。让 AI 盲猜性能瓶颈是低效的做法。安全和隐私自检也得在这个阶段做掉。检查点包括是否申请了不必要的权限、用户协议和隐私政策里是否明确列出采集的数据类型、第三方 SDK 是否有合规清单。这些内容不要指望 AI 自动帮你想全它最多帮你起草文案具体是否符合各家应用市场的要求还是得人工核对。退出标准是双端真机跑通核心路径 10 次不崩溃、无内存持续增长、隐私合规自查通过。2.6 阶段六构建发布与上架配置最后一个阶段是「把包打出来、把材料准备齐、把审核流程走完」。这一步在技术难度上不高但流程琐碎且每个应用市场的要求都不一样。先说 Android 侧。需要生成签名密钥配置混淆规则检查包体积确保 targetSdkVersion 满足市场要求。WorkBuddy 可以帮你把签名脚本和混淆规则写出来但签名密钥一定要你自己保管千万别放在项目代码里更别提交到公开仓库。这个我后面会在坑位里细说。iOS 侧相对更严格。证书、描述文件、Bundle ID、权限用途描述、隐私清单任何一项不对都会被卡在审核环节。这里我的经验是提前把「隐私政策网址」准备好并在 App 内嵌一处可访问的入口。应用商店审核时如果找不到隐私入口大概率会被拒。发布前最后一步是配置 App 图标、启动页、应用名称和简介。图标不能有 alpha 通道启动页不能是纯白空屏但也不能展示过多信息名称不能带「测试」「Demo」字样。这些都是常见拒审原因我这次也踩到了。3. 十六个坑从需求到审核的完整踩坑记录下面按阶段顺序把十六个坑完整列出来。每个坑我都尽量说清楚是什么现象、根因是什么、我是怎么解决的。3.1 需求与选型阶段的坑3 个坑 1需求没有最小闭环AI 帮你快速做了一版错误的东西。我在项目初期让 WorkBuddy 直接生成首页结果功能看起来挺全但产品逻辑是错的用户不做登录也能看到个人数据。这不是 AI 的问题是我自己需求没写清。解决方案是回到文字需求把「谁在什么场景下完成什么动作」写清楚再动手生成页面。坑 2技术栈中途摇摆导致 AI 生成文档和代码风格混乱。我一度想从 Flutter 换到原生方案在 WorkBuddy 里测试了一堆页面效果结果项目目录里留下了大量废弃文件后续审查成本极高。最后我直接删掉那些实验代码确立了「主技术栈绝对不摇摆」的原则。坑 3没给 AI 建立项目记忆每轮对话都在重复交代背景。早期我每打开一个新会话都要重新写一遍「我们的项目是做什么的、技术栈是什么、有哪些约定」效率很低而且容易产生风格不一致的代码。后续我把这些信息固化成了项目说明文件和规则配置WorkBuddy 每次都能主动读取沟通成本显著下降。3.2 工程与环境相关的坑4 个坑 4本地环境版本不一致本机跑通一打包就挂。我有一次升级了本机 Flutter SDK但 CI 和打包机还是旧版本结果生成的产物在部分机型上直接崩溃。解决方案是锁版本在项目里记录精确版本号并保证预览、调试、打包用同一套工具链。坑 5依赖版本没有锁死多次构建结果不一致。某个第三方库升级了 minor 版本导致 Android 构建失败。后来我把所有依赖固定到精确版本号不随便升小版本构建稳定了很多。坑 6缓存目录默认位置导致磁盘爆炸。前面说过WorkBuddy 的缓存和依赖下载一直在系统盘两周之后占用 20 多 GB直接拖慢编译速度。解决办法是修改环境变量和工具配置把缓存迁移到数据盘并把旧缓存清理掉。坑 7模拟器运行正常真机直接白屏。原因是页面路由表里注册了缺失的组件模拟器上因为之前打开过缓存页面所以没暴露真机冷启动直接崩。这类问题模拟器很难测出来如果你只依赖模拟器会拖到很晚才发现。真机调试应该在早期就开始而不是留到最后。3.3 AI 辅助开发阶段的坑4 个坑 8没有给 WorkBuddy 定全局规则每个功能的代码风格完全不一致。前期我让它随手写代码结果有的页面用了 StatefulWidget有的用了函数式组件有的页面自己管理状态有的依赖全局状态。后期维护成本极高。解决方法是写出项目级规则强制统一命名规范、状态管理方式、目录结构并且在新会话里验证规则真的生效。坑 9把 AI 生成的结果当最终答案没有逐行审查。有一回 WorkBuddy 生成了一个网络请求封装看着挺正规但里面把 Token 附加到了公开日志里。这种问题只有在代码审查时才能发现。我的教训是AI 生成的每一段核心代码都要过一遍自己的脑子尤其涉及安全、数据、支付的逻辑。坑 10一轮对话里堆太多需求结果哪个都没做好。试过让 WorkBuddy 一次性生成「首页 详情页 设置页 网络层 缓存」输出结果大规模发散能用的大概只有三分之一。后来切割任务时遵循一个原则每个任务只包含一个明确目标可以引用其他代码文件但不跨模块。坑 11密钥信息写进了代码。某个第三方平台的 App Secret 被我顺手写在了配置文件里提交到仓库前才被发现的。这属于安全事故了。解决办法是所有密钥一律走环境变量或安全存储WorkBuddy 规则里明确规定「密钥类内容禁止出现在代码和配置文件中」。3.4 联调与上架阶段的坑5 个坑 12用内网 IP 联调接口打完包之后用户根本连不上。开发阶段我一直连的是本地后端服务地址提交前差点忘记切换正式环境。解决方案是用统一的配置入口管理不同环境地址发布前必须核对当前构建 Environment 是 production。坑 13抓包失败导致排查进入死胡同。有段时间接口报错真机上抓不到任何 HTTP 日志怀疑是证书或网络安全策略阻断。后来才发现是代理没配好加上 App 启用了网络安全配置不允许明文。建议联调阶段先关闭正式环境的网络安全约束等上线前再强制开启并且用日志文件辅助观察网络链路。坑 14权限申请没有做用途说明审核被拒。我申请了相机权限但用途描述写得含糊。应用市场审核要求权限用途必须具体。整改方案是把权限用途描述细化到实际场景并且在隐私政策里补充对应说明。坑 15图标、启动页、签名配置细节出错。Android 图标有 alpha 通道导致部分机型显示黑底iOS 启动页尺寸不全导致 UI 布局错位。这些不涉及代码逻辑但在审核阶段同样会被打回。建议发布前用官方工具核对全尺寸资源。坑 16审核材料准备不足来回折腾了一周。包括隐私政策 URL、账号注销功能入口、截图尺寸规范、应用分类选择每一项都可能成为卡点。我的心得是在准备发布的前三天就把材料清单列出来逐项核对不要等提交后被打回再补。4. 可复用的经验包规则模板与自检清单这部分的含金量最高。我不讲大道理直接把我这一次实践验证过可用的模板和清单放出来你可以按需修改后直接用。4.1 WorkBuddy 项目级规则模板我建议你在项目里专门建一个规则文件让 WorkBuddy 每次启动任务时自动读取让所有后续任务都受这套规则约束。下面是我这个项目的核心规则你可以直接参考# 项目通用规则 1. 技术栈Flutter 3.x状态管理使用 Provider。 2. 命名规范类名使用大驼峰变量和方法使用小驼峰常量使用全大写加下划线。 3. 目录结构页面放在 lib/pages组件放在 lib/widgets网络层放在 lib/api数据模型放在 lib/models。 4. 网络请求所有 HTTP 请求必须统一走 lib/api/http_client.dart 中的实例禁止在页面里直接创建请求。 5. 错误处理每个网络请求都必须解析统一错误码并给用户可读的提示信息禁止静默失败。 6. 安全规范密钥、Token、证书等机密信息严禁出现在代码文件和配置文件中必须通过环境变量读取。 7. 日志规范禁止在日志中打印 Token、手机号、密码等敏感信息。 8. 状态管理列表页统一使用 FutureBuilder 或 Provider 管理状态页面私有不重复造轮子。 9. 兼容性UI 布局禁止使用硬编码像素值必须适配小屏和全面屏。 10. 注释规范关键业务逻辑必须写注释说明意图UI 代码不强制注释。这条规则里最核心的是第 6 条和第 7 条属于安全红线。一旦你在规则里写清楚WorkBuddy 在后续任务里就不会主动生成「把密钥直接写死」的代码。即使它在某个特殊场景下还是写出来了你的审查也会更快发现。我还建议在工作区里建立一份PROJECT.md项目说明文件把产品目标、核心路径、技术栈、目录结构、重要决策都写进去。然后在规则的「项目背景」节中引用这个文件这样 WorkBuddy 的每个会话都能自动了解项目上下文不需要你重复描述。要给这套规则配上「验收逻辑」也就是规则不是写给自己看的要确保它真的生效。我的习惯是新建会话后随便让 WorkBuddy 生成一个小组件看看它是否遵守命名规范、是否用了统一网络层、有没有把密钥写进代码。三分钟就能验证规则配置是否有效比后期发现问题强太多。4.2 六个阶段的发布前自检清单下面是我每次发布前都会逐项核对的清单。别看它简单我这次上线的很多坑都是靠它兜住的。阶段检查项通过标准需求核心路径定义一句话说清用户闭环需求功能范围无「以后再说」的未实现入口工程编译环境双端 debug 和 release 构建均通过工程依赖锁定所有依赖为精确版本号页面页面状态加载态/空态/错误态均有处理页面组件抽取常用组件已复用无大量重复布局业务Token 管理已使用安全存储无明文业务缓存策略核心数据页有缓存先展示业务错误上报全局异常入口已接入安全密钥排查仓库内无任何真实密钥安全日志审查无敏感信息打印安全权限申请权限用途描述清晰隐私政策齐全性能启动耗时冷启动不超过 3 秒性能内存占用连续操作后无明显内存增长兼容真机覆盖Android/iOS 真机核心路径通过上架资源文件图标无 alpha、启动页全尺寸上架审核材料隐私政策 URL、截图、分类齐全这个清单里每一项我都在实际项目里吃过亏。建议你把它当成发布流程的一部分而不是可选参考。4.3 上线后的维护建议上线不等于结束发布后的 72 小时是最容易出问题的窗口期。我的建议是至少做到三件事一是开启崩溃日志收集观察首次启动崩溃率二是发一个不打扰用户的版本引导让用户能快速反馈问题三是准备好「紧急回滚」的方案比如服务端开关或旧版本包留存。WorkBuddy 在上线后依然可以继续发挥作用。比如用户反馈了一个偶发崩溃你可以把堆栈日志丢给它让它先根据日志定位可疑代码位置再人工确认修复。我上线第三天就处理了一个 Android 低端机上的图片内存溢出问题从收到日志到给出修复分支整个过程不到半小时。另外建议每个迭代版本都重新跑一遍规则清单。很多时候第二版本改动虽然小但开发者容易放松警惕。我自己的体会是流程这种东西每少走一步最后都会以审核被拒或者线上事故的方式「提醒」你回来补齐。5. 写在最后的一点个人体会做完这个项目之后我最大的感受是WorkBuddy 这一类工具真正解决的不是「写代码」这一步而是把「从想法到可交付软件」这条长链路里的重复劳动压缩了。需求分析、架构设计、安全审查、上架合规这些东西它能帮你加速但不会帮你决策。我个人在实操中比较推崇的做法是把 AI 工具当成一个有很强执行力的初级工程师来带给它写清规范、拆细任务、验收产出而不是让它当项目经理。你心里要有一条完整的上线路线图它负责把路线图上的每一站快速跑完。如果你正准备用 WorkBuddy 搭自己的第一个 App可以从我这份规则模板和检查清单开始先跑通一个最小闭环的上线流程再逐步加功能。流程跑通一次后面接任何项目都会心态稳很多。
阅读完成 · 觉得有帮助？
