1. 项目全景六个阶段和十六个坑怎么排布先说结论用 WorkBuddy 搭一个能上线的 App和用它在本地跑通一个 Demo是两回事。前者是一条从想法到商店上架的完整生产线后者只是生产线上的一个环节。我把整个过程压缩成六个阶段踩了整整十六个坑最后沉淀出一套可以复制到下一个项目的工作流。如果你正准备用 AI 编程工作台加速 App 开发这篇文章值得你花十分钟看完。我拿这个项目做了个样板一个面向中小团队的轻量任务协作 App覆盖登录、任务列表、详情、评论、消息推送这些最常见模块。之所以选这个方向是因为它几乎包含了大多数上架 App 的共性难点——账号体系、跨端适配、网络请求、本地缓存、权限声明以及最磨人的应用市场审核。模板本身不是重点重点是这套六个阶段 十六个坑的流程能直接迁移到你自己的项目里。下文的每一个阶段、每一个坑我都会说清楚当时怎么想的、怎么踩的、最后怎么解的。1.1 WorkBuddy 解决的到底是什么问题先说清楚 WorkBuddy 的定位。它不是 IDE 的替代品也不是单纯的代码补全插件而是一个以任务为单位的 AI 编程工作台。你可以给它安装技能包skill让它在 Vue、uni-app、测试脚本、上架检查这些特定领域里有更专业的表现你还可以写一份全局规则文件让它后续处理所有任务时都遵循同样的技术栈和代码规范。这种形态最核心的价值是把上下文固定下来技术栈、目录结构、命名规范、质量门槛都不用你反复交代它自己知道。选它的原因其实很现实。传统开发一个 App要经历环境搭建、脚手架初始化、页面编写、接口联调、多端编译、打包签名、上架审核每一环都需要人工盯任何一个环节出问题都会卡住整条链路。而用 WorkBuddy 这类工作台最理想的状态是你负责拆解任务和做验收它负责把重复劳动吃掉。但最理想三个字是要打引号的因为现实里坑远比想象中多。这套工具能帮你把薄弱的环节补上但它也会非常高效地把你的坏习惯放大比如需求不清、边界模糊、代码不设防。这也是我为什么要写下这篇总结的原因。1.2 为什么必须要分六个阶段我一开始没分阶段一口气把需求全部扔给它结果产出质量断崖式下跌。后来才明白AI 工作台和人类团队有个共同点任务边界越清晰交付质量越高。于是我把整个项目拆成了六个阶段需求冻结与方案定型、工作台初始化与全局规则沉淀、核心功能逐块开发、数据链路与联调、测试与收边、上架发布与善后。每个阶段都有明确的入口和出口。阶段一没做完不进阶段二阶段四没搞定不碰阶段六。这种门禁式的推进方式能有效防止 AI 在一个没想清楚需求的项目里自由发挥。反过来如果阶段一偷懒省事后面所有阶段都会为这个决定买单。后文里的十六个坑至少有五个的根源都在阶段一。1.3 十六个坑的速览表为了让你对后文有个整体感知我先把十六个坑按阶段列成一张速览表。这张表在我项目里贴在墙上当作战地图用每完成一个阶段就对着它检查一遍确认没有遗留坑再往前走。你会发现坑的分布很不均匀——需求阶段虽然一个代码都没写却埋了三个大雷开发联调阶段集中了最多的问题这也很正常毕竟那是代码量和交互路径最密的地方。编号所在阶段坑点一句话1需求需求没有冻结边界中途叠加功能导致返工2需求技术栈只看热度没考虑目标机型与审核政策3需求低估能上线和能用的差距资质、隐私协议、软著4环境WorkBuddy 安装后环境变量没配对第一个任务就挂在路径5环境skill 缓存目录残留旧配置新规则不生效6环境全局规则没写对位置每个任务都要重新解释背景7环境一次喂太多需求上下文被撑爆产出质量崩了8开发UI 组件库选错和业务形态不匹配后期改动伤筋动骨9开发状态管理没提前约定页面数据不同步10开发AI 写出幻觉 API编译通过但一运行就崩11联调token 过期策略不一致唤起 App 时回调参数丢失12联调本地缓存与远端数据冲突冷启动拉回旧数据13联调抓包工具配置问题HTTPS 请求始终抓不到明文14测试真机调试证书混乱模拟器正常但真机装不上15测试只测主流机型小屏与旧系统被忽略16上架包体积过大、权限描述含糊审核反复被打回这张表建议你保存下来对照后文逐条看效果会好很多。1.4 这套流程能省什么、不能省什么很多人问开发一个能上架的 App 大概要多少钱、多久这个问题的答案在 AI 工作台下已经和传统开发完全不同了。传统模式下一个双端工具型 App 从零到上架两个人全职大概要 4 到 6 周成本大头是开发工时和反复联调。用 WorkBuddy 这套流程我一个人在两三周内走完六个阶段而且上架后两周没出现需要紧急修复的问题。要强调的是省掉的是重复劳动不是思考。需求判断、边界控制、验收标准、合规检查这些事AI 目前替代不了它们恰恰是决定项目生死的关键。所以我的观点是把 WorkBuddy 当作能稳定供能的队友不要当成什么都知道的教练。它可以加速你的执行但决策权必须留在你自己手里。这也是后文所有经验和模板的底层逻辑。2. 逐阶段实操从需求冻结到商店上架2.1 阶段一需求冻结方案定型这个阶段没有代码但它是整个项目里我最后悔没做足的一环。所谓冻结不是想清楚而是写下来并确认边界。我给项目定了第一版需求清单账号登录App 内账号 团队邀请、任务管理的增删改查、任务评论、消息推送、个人中心。每一类我都标注了本期必须做 / 本期不做 / 后续版本做三类状态。本期不做往往是很多人不好意思写下来的但恰恰是它保住了整个项目的交付节奏。具体操作上我让 WorkBuddy 根据需求清单自动生成了技术方案候选原生、uni-app、Flutter 三种方案并让它列出每种方案在双端上架、开发速度、AI 生成代码的适配度三个维度上的对比。最后选了 uni-app Vue 3。理由是一个小团队的工具型 App 不需要原生级的性能uni-app 的 API 封装比较统一AI 训练语料里含有大量相关代码生成的代码可复用率更高后续如果要接微信小程序同一套代码还能继续用。这里重点解释为什么这么选。原生开发在两端的 UI 细节上最灵活但 AI 工作台要同时维护两套代码出问题的概率翻倍Flutter 的渲染能力强但在国内上架时涉及到的打包链路更长uni-app 的编译链路相对成熟HBuilderX 和 CLI 方案都有大量现成实践。交付速度是第一优先级时它是最稳的选择。当然这不是说 uni-app 完美后面阶段里很多坑恰恰是跨端框架带来的但至少在让 AI 快速上手这一项上它是当时的最优解。2.2 阶段二工作台初始化与全局规则沉淀安装 WorkBuddy 后第一件事不是写代码而是配环境。我当时踩的坑从环境变量开始后面会详细说。这里讲正确做法。首先把 Node、JDK、Android SDK、Xcode Command Line Tools 这些底层依赖装齐并把它们的路径写进终端配置。然后给 WorkBuddy 单独指定项目缓存目录避免系统盘被 node_modules 和编译产物塞满。这里对应的就是很多人经常问的WorkBuddy 怎么更改系统缓存目录——在配置里设置 cache_dir 指向一个专门的大分区即可。第二步是安装 skill。这一步类似给编辑器装插件但强很多。比如安装 Vue3 技能包、uni-app 技能包、代码审查技能包之后它生成代码时会自动带上对应框架的写法习惯而不是用纯前端思路写不适配的代码。我还会装一个上架检查技能包在阶段六用来做元数据和权限声明的自查省了不少事。第三步是最重要的一步写全局规则文件。这个文件的作用相当于给这个 AI 工作台立团队章程。我用的模板长这样project: task-note stack: uni-app Vue 3 Pinia language: zh-CN build_target: ios, android rules: - 组件统一使用组合式 API - 页面放 src/pages组件放 src/components - 禁止凭空捏造不存在的 API 和组件方法 - 每次改完代码必须执行 type-check - 接口请求统一走 src/utils/request.js - 未经确认不允许修改全局入口文件这份文件写好之后后续所有任务都会自动携带这些约束条件。换句话说你不需要在每个任务描述里重复我是 Vue3 项目这句话它自己知道。这套机制很省心但前提是写对位置——不是写在某个任务的提示词里而是写进工作台级的全局配置中。很多用户都在搜给 WorkBuddy 定几条规则后续对所有任务都生效其实就是这一步。2.3 阶段三核心功能逐块开发阶段三的核心纪律是一次只做一件事。我把任务列表拆成粒度很小、可独立验收的单元先做登录页 UI再写登录接口请求再写 token 存储再做任务列表页再做任务详情页……每一块完成、验证、提交后再开下一块。这种节奏有点笨但非常适合 AI 工作台。你把任务拆得越细它越不会跑偏你验收起来也越轻松。比如登录页我给 WorkBuddy 的任务描述是在 src/pages/login 下生成登录页包含手机号输入、验证码输入、登录按钮调用 POST /auth/login 接口成功后把 token 存入 storage参考设计稿的主色为 #2D6CDF按钮禁用态和 loading 态都要有。这样它产出的代码有明确的验收标准你不需要在一堆需求里猜它到底完成了什么。这个阶段最常见的反弹是AI 太能瞎编。它可能写出一个并不存在的 uni-app API然后编译成功但运行报错。我的止损办法是让它输出代码前先列出一个本次任务会用到的 API 清单我快速确认一遍再让它继续。看似多了一步实际上节省了后面的调试时间。第二个经验是组件粒度要控制。如果页面和组件都放在一个大文件里AI 后续改一个功能时经常连带破坏无关代码。所以我强制要求每个页面文件不超过 300 行超出就拆组件。这个规则写进全局文件后后续生成的代码天然更整洁。2.4 阶段四数据链路与联调功能页面能跑起来之后真正的硬仗是数据和接口。这个阶段我定了一个数据流约定所有请求必须经过统一的 request 工具函数统一处理 token 注入、过期刷新、错误码所有响应先走一层拦截器再到页面。这个约定写进了全局规则因此 AI 生成的每个接口请求都天然合规。// src/utils/request.js 的核心思路 // 统一注入 token拦截错误码避免每个页面重复处理 const request (options) { const token uni.getStorageSync(token) return new Promise((resolve, reject) { uni.request({ ...options, url: BASE_URL options.url, header: { Authorization: Bearer ${token} }, success: (res) { if (res.statusCode 401) { // 触发统一刷新登录态流程 return refreshLogin().then(resolve).catch(reject) } resolve(res.data) }, fail: reject, }) }) }联调时最大的坑出现在登录态上。我们的后端 token 有效期是 2 小时而前端刷新 token 的机制在浏览器唤起 App的场景下没有兜底。具体说用户在分享页点击链接iOS 通过 scheme 唤起 App 时回传了一个短期授权 code但 App 因为缓存策略问题没能正确消费它回调参数丢失导致登录静默失败。排查了很久最后的解法是在 App 冷启动场景下先检查 URL 参数再走一次刷新登录态的完整流程而不是直接信任本地缓存。同一阶段本地缓存策略也出过问题。任务列表接口返回了新数据但页面冷启动时优先读了本地缓存的旧数据造成用户看到的数据比服务器落后。修法很笨但有效给缓存加版本号字段如果远端数据 version 高于本地就直接覆盖。后来我把这个逻辑沉淀成模板函数所有列表页复用问题再没出现过。2.5 阶段五测试与收边AI 工具能大幅提速开发但测试这件事它不会替你做。我在阶段五做了三类测试逻辑测试重点覆盖登录、新建任务、修改任务状态、兼容性测试模拟器和真机、iOS 和 Android、大小屏、异常测试弱网、接口报错、token 过期。说实话AI 生成的代码在正常路径上通常没有大问题可一旦跑到异常路径各种边界问题就会冒出来所以异常测试反而是我最看重的。兼容性测试里最隐蔽的问题是模拟器能跑真机装不上。原因通常是证书、描述文件或包名不一致。这里需要非常严格地把开发证书、打包证书、包名、版本号四者统一。我的经验是切到真机调试时先把打包配置里的 bundle id 与开发者后台的注册包名逐字核对空格都不能差。另一个教训是机型覆盖。我最初只在 iPhone 14 和一台小米上测试结果发到测试群后有同事在小屏手机上发现按钮溢出、键盘遮挡输入框。这类问题在 AI 生成的页面里尤其常见因为它的默认布局是按标准屏宽写的。补救办法是在全局规则里加上所有页面必须适配 320pt 宽度并且在验收时用模拟器切到小屏机型过一遍。这个规则一旦加上后续 AI 生成的页面基本不会再犯同类错误。2.6 阶段六上架发布与善后这是最容易被新手低估的阶段。打包、签名、上传、填写元数据、隐私政策、权限用途说明每一项都能让审核打回。我的项目在 iOS 端被审核打回过一次原因是权限描述写得模棱两可——允许访问相册这种写法会被判定为含糊。改正方案是写清楚用途允许访问相册用于选择任务附件图片并上传给团队成员查看。除权限文案外还有一类特别常见的问题是设置了权限但代码里没有对应调用。审核员会把未使用的权限当作潜在隐私风险所以打包前要把所有动态权限清单过一遍用不到的直接去掉。Android 端则要关注包体积和渠道包。默认打包如果不做裁剪体积很容易超过 80 MB这在部分应用市场会影响审核和下载转化。我做了三件事移除未使用资源、按 AB 架构分包、把不必要的动态权限去掉。最终包体积从 92 MB 降到 46 MB效果非常明显。善后工作是很多教程不会提的上架后不是结束而是监控和告警的开始。崩溃日志、用户反馈、版本回滚预案这三样必须在发布前准备好。用 WorkBuddy 生成一个发布检查任务也能帮上忙它会自动核对版本号、更新说明、隐私链接是否齐全。3. 十六个坑逐个拆解现象、原因、解法这一章是全文最值钱的部分。前两章是按流程走这一章是按坑走。十六个坑我会按需求—环境—开发联调—测试上架四个区间逐条说每条都包含现象、原因和解法尽量不写废话。如果你时间有限可以直接拉到这一章对着你自己的项目阶段找对应的坑。3.1 需求阶段的三颗雷坑 1需求没有冻结边界。项目做了一半产品同学其实是我自己觉得加个标签筛选也不难于是需求从 5 个模块变成 8 个。AI 的代码结构是围绕原需求生成的新增功能时它不会主动帮你重构结果就是打补丁式的代码越来越多。我们后来统计这次需求蔓延直接让开发周期多出 40%而且 AI 生成的代码在新增功能时经常和已有结构冲突。教训是所有需求写成清单标注本期 / 下期新增内容一律进下期天塌下来也不动摇。坑 2技术栈选型只看热度。最初我倾向 Flutter因为渲染效果好社区讨论多。但冷静评估后发现团队里没人写过 Dart而 AI 工作台在 Vue 生态的训练语料明显更丰富。比如 Flutter 在桌面端的优势在我们项目里毫无用处却要为它的编译链路付出额外成本。选型不是选最好的而是选工具链 团队经验 AI 适配度三者平衡的。后来我把为什么选 uni-app这条判断写进了项目文档避免中途反复动摇。坑 3低估能上线的门槛。功能做完才发现 iOS 需要隐私协议Android 部分市场需要软著ICP 备案等要求也都指向同一件事你是在发布产品不是发 Demo。这些资质准备周期很长必须在阶段一就并行启动。我认识不少开发者功能做得漂漂亮亮最后卡在资质上一等就是一个月。软著办理至少要预留三周别等代码写完再去办那时候每一周都是煎熬。3.2 环境配置期的四个坑坑 4环境变量路径问题。第一次跑任务时WorkBuddy 的终端任务报找不到 Android SDK原因是 ANDROID_HOME 只在交互 shell 里生效没写进全局配置。排查后用 export 写入配置并 source 生效再验证就通了。具体命令很简单echo export ANDROID_HOME$HOME/Library/Android/sdk ~/.zshrc echo export PATH$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools ~/.zshrc source ~/.zshrc坑 5skill 缓存与旧配置残留。我换了一个新版本 skill 后规则和缓存还是旧的导致新风格不生效。解决办法是找到缓存目录手动清理旧版本的 skill 缓存重启工作台加载新配置。这里也建议大家定期检查缓存目录换版本后不要直接沿用旧缓存否则你会以为新版本没效果其实是旧缓存一直在干扰。坑 6全局规则没写对位置。我把规则写在了当前会话的任务说明里结果新建会话语境就丢了。正确做法是把规则写到 WorkBuddy 的全局配置中让后续所有任务都能读取。这一点对应了很多用户都在搜的给 WorkBuddy 定几条规则后续对所有任务都生效。判断标准很简单新建一个会话随便说一句话看它是否还带着你写的规则。如果丢了说明你写错位置了。坑 7上下文被撑爆。有一次我一次性丢给它 12 个需求输出质量断崖式下跌甚至出现了把登录页逻辑拼到任务列表里的错乱。从此我把需求拆成最小任务单元每个任务控制在 150 行以内的产出好验证、好回滚。这条经验不仅适用于 WorkBuddy适用于所有 AI 编程工具——它的上下文窗口再大也不等于你可以不讲结构地野蛮输入。3.3 开发与联调的六个坑坑 8组件库选型不匹配。起初用了较复杂的 UI 库结果在 uni-app 编译到小程序时大量组件不兼容。我换成了更轻量、专为跨端设计的组件方案页面重写了一遍。这个教训是先确认目标平台再选组件库不要因为组件库好看就用它。而且换库的成本不是改两个组件那么简单公共样式、主题变量、通用弹窗全都要跟着动AI 又不会主动维护这些依赖关系最后还是人工收拾。坑 9状态管理混乱。Pinia 的 store 没有提前设计导致多个页面各自维护了一份任务数据。后果是列表页改完状态详情页不刷新。修正为单一 store 统一管理数据源页面只通过 store 读写彻底解决了数据不同步的问题。这个经验对 AI 编程特别重要AI 生成代码时只盯着局部如果你不给它一个统一的 store 约定它会在每个页面里重复造轮子。坑 10AI 幻觉 API。它生成过一个 uni.navigateToBack 的自定义参数写法文档里根本没有。编译通过一跑就报错。后来我强制要求输出前列出 API 清单把幻觉拦截在写码之前。如果你不想每次都被这种低级错误浪费 20 分钟这个流程一定要加上而且要在全局规则里写死。坑 11token 与唤起回调问题。前面阶段四里提过iOS 浏览器唤起 App 时回调参数丢失根因是冷启动逻辑里没有处理 URL 参数而 token 刷新又依赖本地旧状态。解法是冷启动时统一走解析参数 刷新登录态的流程。这里多说一句凡涉及从外部唤起 App的场景务必把回调参数的消费放在 App 启动生命周期的第一步优先级高于本地缓存恢复。坑 12本地缓存与远端冲突。本地缓存旧数据直接渲染视觉上像改了个寂寞。加了缓存版本号机制后本地和远端总能对齐。我把这个机制做成通用工具函数后写进全局规则里所有列表页都会自动带上。具体就是每次写入缓存时存一个 version 字段读取时比较版本过期就丢。别小看这个字段它解决的是用户信任感级别的体验问题。坑 13抓包失败。一开始抓不到 App 的 HTTPS 请求是因为工作台的代理配置和系统代理没统一。正确做法将终端代理、系统代理、抓包工具三者配置成同一地址并信任抓包工具的 CA 证书。这个问题排查了我一个下午最后发现只是代理没同步属于典型的配置不连通。遇到抓不到包先按代理链路上每个环节都指向同一端口这个原则去查通常比怀疑代码更高效。3.4 测试与上架期的三个坑坑 14真机证书混乱。模拟器正常真机提示无法安装。最终定位到描述文件过期且打包证书与后台 Bundle ID 不一致。核对并替换后解决。这里建议做一张证书信息对照表把证书名、有效期、bundle id、描述文件这四列全列出来发布前逐项核对能省掉很多无头绪的排查。别相信自己的记忆人多手杂时只有表格靠得住。坑 15小屏兼容性漏测。只验了主流机型小屏上按钮溢出。在全局规则里强制小屏适配宽度后AI 下一轮生成的页面自动规避了这个问题。这个坑很典型AI 默认按标准屏宽布局所以你的验收清单里必须包含 320pt 宽度和小字号显示这两项。改规则比改代码划算得多因为规则是全局的代码是局部的。坑 16审核被打回。iOS 因为权限描述含糊被打回Android 因为收集用户信息但隐私政策链接位置不明显被警告。两者都是合规细节却足以卡住整个发布。改完文案、补全链接、重新提交后通过。审核不是玄学它遵循公开的准则你只要把该写清楚的写清楚该放页面的放页面就能稳定通过。我后来把权限描述的写法固定成用于……以便……的句式再也没在这个问题上栽过。4. 可以直接复用的落地模板4.1 全局规则模板我把第二阶段用到的规则文件稍微泛化了一下你可以直接复制改改看。重点不是里面写了什么而是你要理解全局规则是 AI 工作台最重要的团队章程。project: your-app-name stack: uni-app Vue 3 Pinia language: zh-CN build_target: ios, android rules: - 组件统一使用组合式 API - 页面进 src/pages公共组件进 src/components - 列表页统一使用缓存版本号机制 - 所有请求必须通过 request 工具函数 - 禁止使用未经验证的 API编写前先列 API 清单 - 每个页面文件不超过 300 行超出则拆组件 - 所有页面适配 320pt 小屏宽度这份规则我建议在项目第一天就初始化后续根据踩坑情况不断补充。坑 15 和坑 12 就是从实践中沉淀进规则的典型案例。先有三条能跑的再慢慢完善比憋一份大而全的规则文件更现实。4.2 任务拆解与提交流程结合这十六个坑我把提交流程固定成五步写清楚任务目标和验收标准一句话说不清就继续拆。让 AI 先输出 API 清单和技术方案确认无误再写代码。生成代码后立即跑 type-check 和编译出错第一时间回滚不补丁式修复。功能验证通过后同步更新全局规则或更新文档。每个阶段完成时对照速览表检查一遍确认没有遗留坑再进入下一阶段。这套流程看起来简单但能稳定提升 AI 生成的代码质量。核心思路是AI 负责高效产出人负责验收和卡边界。步骤 3 的第一时间回滚尤其重要AI 修复 bug 时常常会引入新问题与其让它越修越乱不如直接回到上一个可用版本再重试。4.3 上架前的最终检查清单发布前一天我一般会拿着这张表逐项打勾隐私政策页面是否有独立链接且能在应用内打开每个权限都有明确的用途说明写法是用于……以便……版本号与构建号在所有平台保持一致包体积做过分包 / 资源裁剪崩溃收集与日志上报已接入版本回滚预案已写好数据接口在上架环境可用测试域名已切换为正式域名这些条目没有一条涉及复杂技术但任何一条漏掉审核都有可能打回。把这七条打印出来贴在工位上比刷十篇上架攻略都管用。4.4 最后想分享的心得说实话这套流程第一次跑通的时候我最大的感受不是AI 帮我写了多少代码而是AI 把开发的门槛从写代码拉到了做决策。需求该怎么切边界在哪里验收标准是什么这些判断最终还是要人来拍板。十六个坑里至少一半不是因为 WorkBuddy 不行才踩的而是因为我自己在阶段一偷了懒。所以如果你打算照这套流程走我的建议是在需求阶段多花两天把方案、边界、资质全部定死后面会一路顺反过来前面省过的功夫后面都会在某个坑里加倍还回来。另外规则文件记得从第一天就写好哪怕刚开始只有三条也比等到被坑教育了再补强得多。