半年前我第一次打开 WorkBuddy心态很天真把 App 需求往输入框一贴它就该把能跑的代码全吐出来。试了一下午demo 确实跑起来了但 UI 丑、逻辑乱、一加功能就崩离“能上线”三个字隔着十万八千里。后来我把 WorkBuddy 当成一个真正的协作者来管——给它定规则、配工作台、拆任务、做代码评审前后三周把一个工具型 App 推到应用商店顺利过审。这篇文章就把这条路线完整拆给你六个阶段、十六个坑外加一份可以直接抄走的交付清单。不管你是第一次用 WorkBuddy 做真实项目还是已经在用它写 demo 但不知道怎么收尾成产品按这套流程走能少绕很多弯。1. 先说结论WorkBuddy 能不能扛起“上线”这件事1.1 WorkBuddy 不是普通聊天框而是一个需要“管理”的工作台先聊一个容易混淆的问题WorkBuddy 和 CodeBuddy 到底是什么关系这两年社区里两个名字经常一起出现教程也常常混着讲。按我的使用体会可以粗暴理解成同源不同定位——CodeBuddy 更偏向编辑器里的“程序猿助手”而 WorkBuddy 强调的是可配置的工作台你可以在里面搭建不同的 Workspace给每个 Workspace 挂上不同技能Skill和规则Rules让它在既定边界里干活。提示如果你只用它聊天等于买了一台有自动驾驶的车却一直手动推着走。我第一次用的时候完全没有这个概念把需求整段丢进去让它“给我做一个记账 App”。它确实能干生成了页面、数据库和接口调用但所有代码挤在一个会话里散落各处——没有分层、没有统一错误处理、没有设计约束后续每加一个小功能都会改动好几个文件改完一个崩一个。那一刻我明白了WorkBuddy 的定位本来就不是“一句话生成整个项目”的黑盒而是一个需要你定规则、分任务、做验收的智能劳动力。1.2 我判断“能上线”的三个标准既然目标是“能上线”就不能用跑通 demo 的标准来验收。我自己定义了三把尺子稳定性核心功能不闪退、数据不丢、弱网和异常输入下不崩。AI 生成代码最容易缺的正是失败分支这部分必须重点盯。可维护性代码结构能让人看懂、能继续改。如果生成完只有 AI 自己看得懂下一次迭代就是灾难。可发布性构建、签名、审核、商店后台配置这一套流程能走通包括图标、隐私政策、权限说明这些看起来不起眼但缺一个就上不了架的东西。拿这三把尺子去量你会发现很多“demo 跑通了”的兴奋瞬间其实还很远。这也决定了后面每一个阶段我都用“产出物是否达标”来判定能否进入下一步。1.3 六个阶段到底怎么划分的整条链路我拆成了六个阶段顺序可以调整但“上一阶段没验收完不进入下一阶段”这条铁律不要破阶段目标核心产出物对应坑阶段一需求拆分与技术选型需求清单 技术栈决策坑 13阶段二环境搭建与工作台配置可复现的开发环境坑 46阶段三规则、技能与对话策略Rules Skill 配置坑 79阶段四核心功能开发可运行的功能版本坑 1012阶段五联调、构建与出包可安装的包坑 1314阶段六上架审核与上线后运营商店在架的 App坑 1516我把“上架后”也放进阶段六是因为很多人以为提交成功就结束了结果第一天就被用户反馈打回原形。上线不是终点是新一轮迭代的起点这个后面细说。2. 阶段一把需求磨碎再动手坑 132.1 坑 1需求没拆碎整段丢给 AI这是最普遍的一个坑我自己也踩得很扎实。把“帮我做一个记账 App”这种需求整体丢给 WorkBuddy它确实会给你生成一个完整项目但问题在于代码看起来都全实际却是一锅粥。生成出来的页面动辄上千行状态管理和 UI 混在一起数据库字段和页面字段互相纠缠。你想让它改一个统计逻辑它可能把列表也一起动坏了。后来我把需求拆成了一个一个“一句话任务”新建项目搭建基础目录结构配置数据库表用户表、账单表、分类表实现登录页手机号 验证码实现账单列表页实现账单新增表单实现统计页。每拆完一个任务单独开一次对话让 WorkBuddy 去完成完成后先人工看一遍代码再进入下一个任务。整个开发节奏一下子可控了。有一个我自用的拆分模板可以抄功能账单新增表单 验收标准 1. 用户可输入金额、分类、备注、日期 2. 金额只允许数字且大于 0 3. 表单校验失败时给出中文提示不提交 4. 提交成功后返回列表页并刷新列表 5. 网络失败时保留输入内容允许重试。提示验收标准写得越具体AI 生成出来的东西越接近你要的。别把“能跑”当验收标准要把“符合这 5 条”当验收标准。2.2 坑 2技术栈选错AI 生成的质量先天打折这个坑很多人不会意识到。大模型训练时对不同技术栈的“见过程度”完全不同越是主流、社区资料越多的技术栈AI 生成质量越稳越是小众或者文档混乱的框架AI 越容易一本正经地写出错误代码看起来没问题一运行就报错。我当时的取舍逻辑是三点团队熟不熟、生态强不强、AI 数据多不多。工具型 App 最终选了 WebView 壳 Web 内页的方案原因很现实这个技术栈我熟、调试快、WorkBuddy 生成质量相对稳定而且后续迭代成本低。项目开始前花一个半小时做个技术栈对比表能避免后面半个月返工。对比维度至少要有AI 生成质量、生态成熟度、真机调试难度、上线门槛。别只选“最酷的”要选“AI 最会写的”。2.3 坑 3没把“要上线”写进需求后面全是补课我最初的需求清单全是功能描述“能登录”“能记账”“能统计”。看起来没毛病但“上线”这两个字背后还有一堆需求没说出口首次启动要不要隐私协议弹窗申请相机或相册权限时要不要解释理由没网的时候页面怎么办用户清缓存后本地数据会不会丢这些不写进需求WorkBuddy 就默认不管它不管审核阶段和用户手里就会出问题。我后面为了这些补课花了不亚于开发的时间。正确的做法是在需求清单里单列一栏“上线约束”上线约束 - 首次启动展示隐私协议用户同意后才可以进入主流程 - 获取定位、相册、麦克风等敏感权限前必须弹窗说明用途 - 所有页面必须有网络异常状态和重试按钮 - 关键操作删除、支付、清空数据需要有二次确认。把这些约束固定成全局规则之后AI 生成的每一个功能都会自动带上对应处理相当于在源头过滤掉了一大批审核风险。阶段一总结需求拆得越碎AI 干得越稳技术栈选得大众生成质量越高上线约束想得越早返工越少。3. 阶段二环境搭建与工作台配置坑 463.1 坑 4版本装错普通版和国际版不是一回事WorkBuddy 的安装阶段就有坑。我在网上顺手找了个版本装上界面看着和教程里差不多但模型入口、设置项、技能市场都对不上很多 Skill 根本没有。我一度以为是自己的使用方法问题浪费了大半天才反应过来是版本装错了。教训是先查版本号再开工。我的下载流程现在是这样的只从官方渠道下载不顺手用别人网盘里转发的版本安装完第一步到“关于”页确认版本号和更新渠道上网搜该版本的官方说明确认 Skill 市场和 Rules 功能开关齐全老机器比如 Win7先看兼容说明别装到一半才发现装不上。市面上流传的“国际版”和“普通版”差异并不小教程作者用的是哪个版本你最好就跟哪个版本不然很多命令和设置项都对不上。3.2 坑 5缓存目录默认躺在系统盘项目一多又慢又占地方WorkBuddy 会在本地产生不少缓存项目索引、模型上下文、技能模板、历史会话数据。默认路径一般落在系统盘的用户目录下。做两三个项目之后我发现启动和切换项目明显变慢系统盘空间也一路飘红。解决办法就是显式改缓存目录把缓存挪到空间充裕的盘。以我用的版本为例设置入口里能找到缓存路径也可以尝试命令行方式workbuddy config set cacheDir D:/workbuddy/cache不同版本命令行写法可能不一样拿不准就先在设置面板里找改完以后重启并重新索引第一次会比较慢后面就正常了。提示缓存目录改完之后旧缓存最好手动清一次但别在 WorkBuddy 正在运行时删容易损坏索引。退出后清理再启动最稳。3.3 坑 6模型连接和上下文参数没有校准输出忽好忽坏进入 WorkBuddy 之后一般会看到一个模型连接配置界面里面有模型选择、上下文长度、生成温度这类参数。很多人直接默认值就开干结果输出质量像抽奖。我建议先花一顿午饭的时间做校准用同一个固定小任务去测不同参数的效果比如“给这个列表页写一个空数据占位组件”。关注两件事上下文长度设得太短长文件改不动设得太长对话一多就超窗口报错。我一般选“够用就好”需要改大文件时临时调高。温度这个参数直接决定生成结果的“随机性”。写代码我通常压到比较低让输出更稳定做文案或者命名建议时可以稍微调高。我最终固定下来的初始配置是这样的只是参考不是最优答案配置项我的初始值说明模型项目默认模型以你的账号可用模型为准上下文长度中档基础开发够用温度偏低代码稳定优先自动生成开启配合 Rules 使用这些参数调完之后我没再频繁动过后面所有项目都先以这套为基线再按需调整。4. 阶段三规则、技能和对话策略坑 794.1 坑 7没有预设 RulesAI 越写越“野”如果只给 WorkBuddy 一个功能任务不给行为边界它就会用自己的“习惯”写代码而这个习惯未必是你想要的。比如它可能会在页面组件里直接写网络请求可能会一开始就引入一个你没打算用的第三方库可能函数命名风格前后不一致。等代码量上来这些问题就会变成不可维护。WorkBuddy 的 Rules 机制就是干这个的——给所有后续任务定边界一旦配置后续任务全部生效。我把自己项目的全局规则固化成了下面这份你可以直接改# Global Rules 1. 所有新增函数必须写明用途、输入参数和返回值说明。 2. 禁止引入依赖清单中未声明的第三方库。 3. 网络请求统一走 api 层禁止在页面组件中出现裸请求。 4. 所有用户输入必须做合法性校验失败时给出中文提示。 5. 涉及敏感权限相册、定位、麦克风时必须先说明申请用途。 6. 全局变量必须经过状态管理禁止跨组件直接修改。写好 Rules 之后我发现一个明显的改变同样的任务生成代码的“野性”小了很多函数注释、错误处理、命名风格都规矩了。这一步效果比换更强的模型还明显。4.2 坑 8Skill 同时挂多个规则互相打架WorkBuddy 的 Skill 可以理解为“预制的流水线模板”比如页面生成 Skill、数据库建模 Skill、代码评审 Skill。我一开始图效率把几个 Skill 同时挂在一个 Workspace 上结果生成的页面里混进了数据处理层的模板代码两边规则互相打架改起来非常难受。后来我总结出两条一个任务只挂一个最相关的 Skill做完再换不确定某个 Skill 干了什么的时候先全部关闭用一个标准小任务测一遍再逐个打开对比输出差异。这样排查效率高很多也不会出现“两个规则在打架”的玄学问题。4.3 坑 9对话上下文没有策略聊久了就“失忆”这个坑其实比前两个更隐蔽。WorkBuddy 的对话上下文是有限的一个会话里来回改十几轮之后它会“忘记”最开始的要求。最典型的表现是你让它改列表页它把登录页的条件判断也顺手改了你让它保留 A 逻辑它回你一个已经删掉 B 逻辑的新版本。我的解决方案是三句话一个任务一个会话任务完成立刻开新会话关键约束每次开头贴一遍不要默认 AI 记得上一轮的内容长任务拆成多个子任务分别开会话最后再合起来联调。我每次开会话之前会复制一段固定的开场模板见下把当前任务和红线约束写清楚实测下来“失忆”概率降低非常多请基于当前项目配置工作。 当前任务实现【任务标题】。 注意 1. 只修改与任务相关的文件 2. 遵守项目全局 Rules 3. 完成后先自查再给出变更说明 4. 不要新增依赖。阶段三的经验是规则定边界技能管流程会话控记忆。三条都做到AI 的输出就从“随机发挥”变成“稳定执行”。5. 阶段四核心功能开发节奏比速度重要坑 10125.1 坑 10一次让 AI 生成整页代码改起来怀疑人生到了真正写功能的时候最大的诱惑是“一次全部生成”。我试验过一次让 WorkBuddy 直接生成整个首页它确实一分钟给完页面能跑数据也能加载但代码乱到我不敢动——布局、状态、接口、样式全在一个文件里纠缠。改一个字体大小都要影响别的地方。后来我把“页面开发”拆成四步每一步都跑通验证再继续生成静态布局骨架先不看逻辑确认结构对填充静态元素和样式确认视觉对接状态和交互逻辑确认操作对接接口数据确认数据流对。每一步都单独开会话用一句话说清这一步的目标。不要跨步骤让 AI“顺便改一下”它的多任务处理能力没有想象中好。5.2 坑 11跳过代码评审小问题攒成大事故AI 生成代码的另一个问题是局部正确、整体埋雷。比如两个组件用了两个不同的日期格式化方式同一个接口被封装了三层退出页面时定时器没有清理。这些问题单看一次生成的代码不容易发现但攒多了就会在某次改动时一起爆。我的做法是每完成一个功能就开一个独立的“代码评审”会话用固定的评审 prompt 让 AI 先自己过一遍请对这个功能相关代码做一次严格评审 1. 找出潜在 bug尤其是状态更新和异步处理 2. 检查是否违反项目全局 Rules 3. 检查是否有安全隐患输入未校验、明文传输等 4. 检查是否有重复代码和不一致命名 5. 输出按“严重问题 / 一般问题 / 建议”分类。AI 评完之后我再人工扫三个关键位置网络请求有没有错误处理、用户输入有没有校验、本地数据读写有没有异常分支。这一轮做完一个功能才算真正能入库。5.3 坑 12错误处理与边界条件缺失用户一操作就崩AI 生成的代码一般“主路径”很完整——正常输入、正常点击、正常返回它都能走通但一遇到异常输入、弱网、重复点击、超长文本这些边界条件就开始露怯了。我的记账表单就出过这种问题金额输入“abc”直接崩连错误提示都没有提交按钮没做防重复用户连点三下账单多出三条。解决的办法不是让 AI 更聪明而是在任务描述里明确要它补边界。我自己总结了一份“边界检查清单”每次功能开发完成之后专门开一个会话让 WorkBuddy 按清单自查空数据列表为空、搜索无结果时有没有占位提示超时接口请求超时后有没有提示和重试超长/非法输入输入框有没有限制和校验重复操作提交按钮有没有防重复权限拒绝用户拒绝授权后流程能不能正常继续页面卸载定时器、订阅、监听有没有及时清理。把这份清单作为 Rules 的一部分固化下来之后同类问题大幅减少。阶段四的经验很简单小块提交、先评审后入库、边界单独查。速度看起来慢了实际上返工少了总时间是省的。6. 阶段五联调、构建与出包前夜坑 13146.1 坑 13只在模拟器跑通真机上一测试全是问题模拟器是我们开发时的好朋友但也是发布前的“障眼法”。我在模拟器上跑得很顺的页面第一次装到真机上就露馅了权限弹窗流程完全不一样存储路径对不上列表滚动掉帧图片加载卡顿。真机和模拟器的差异主要有三类权限与系统交互真机的权限弹窗、相册、定位逻辑更复杂模拟器常常直接放行性能表现真机渲染和内存限制更真实模拟器跑得动不代表真机跑得动网络与存储真机网络切换、后台恢复等场景模拟器很难模拟。所以我的建议是从第一个可用版本开始就做真机安装测试不要等到最后才想起来“真机试一下”。我给自己定的节奏是每周一次真机回归宁可频率低不能没有。真机测试清单至少包括冷启动和热启动不闪退登录态持久化杀进程后仍保留弱网环境下请求失败有提示权限拒绝后功能可用前后台切换不丢页面状态。6.2 坑 14Gradle 构建依赖解析失败被报错卡了快一天出包阶段最容易让人怀疑人生的就是构建问题。我遇到过一个非常典型的报错片段Could not determine the dependencies of task :app:compileDebugJavaWithJavac. Could not resolve all task dependencies for configuration :app:debugCompileClasspath.这类报错表面上是“依赖解析失败”实际原因往往五花八门。按下面的顺序排查效率最高先定位是哪个依赖出了问题不要盯着报错最后一行猜。执行./gradlew :app:dependencies --configuration debugCompileClasspath看输出里哪个依赖标红或标 FAILED。检查版本写法。如果是latest.或这类动态版本先改成固定版本号动态版本最容易在不同时间构建出不同结果。清理缓存再试./gradlew clean如果还不行可以删除本地 Gradle 缓存目录下对应模块的缓存注意备份别全删。检查仓库地址确认仓库配置的顺序对不对、地址能否正常访问必要时换一个备用仓库地址。我们项目里曾经就是因为某个仓库地址挡在前面后面的依赖全部解析不出来。善用版本对比如果昨天还能构建今天突然失败用版本管理工具对比依赖配置文件看这两天改了什么多数时候能直接找到元凶。另外一条经验不要选择在发版前夜第一次跑完整构建。构建问题应该在你还留有三四天余量的时候集中踩完否则小问题也会变成发布日期的大事故。6.3 出包前夜清单这些边角料真的不能省这个环节不单独算坑了但它和坑 14 一样容易让人通宵包名、签名、图标、启动图、版本号。包名一旦发布就改不了签名文件丢了就只能换身份重新上架图标和启动图必须准备全尺寸。我的发布前自查清单供参考包名确定并全局统一不包含拼写错误签名文件生成并加密备份记录 keystore 口令图标和启动图按各商店要求准备全尺寸版本名和版本号递增隐私政策链接可以在后台配置时访问构建产物在至少两台真机上安装验证。这些“边角料”在 WorkBuddy 生成代码的过程中几乎不会出现但上架的时候缺一个都会被卡。提前准备好出包当天就能从容很多。7. 阶段六上架审核与上线后的第一天坑 15167.1 坑 15被安全审核或格式要求拦下各平台标准还不一样提交审核是“能上线”的最后一关也是最容易让人心态崩掉的一关。我第一次提审被拒理由写的是“权限用途说明不足”。我检查了一下发现 App 会在首次启动时申请存储权限但没在授权弹窗之前向用户解释为什么要这个权限也没有在后台配置里写清楚用途。这本该是阶段一“上线约束”里就有的内容我当时没写于是回来补。各个应用商店的审核侧重点不完全一样有的特别重视隐私合规必须补充用户隐私政策、权限申请理由有的重视内容分级要求填写分级问卷有的会要求提供测试账号方便审核员体验完整功能。被拒之后不要慌先按驳回理由逐条对应到具体页面和处理代码改完再提交不要“换个姿势碰运气”反复提交。我给自己整理的审核自查清单是这样的隐私政策链接在 App 内可访问且与 App 实际行为一致每个敏感权限都有对应的申请时机和用途说明登录功能有可用的测试账号提供给审核员无网络、空数据等状态的文案不含歧义截图和宣传语与实际功能一致不夸大版本说明写清楚本次改动内容。7.2 坑 16上线后没有反馈闭环下一轮迭代只能靠猜上架成功那一刻我非常兴奋第二天就开始规划新功能。几天后看到用户评论说“登录有时候会失效”但我完全不知道发生了什么——因为我没有接入崩溃统计也没有用户反馈入口只能靠用户发截图和日志来猜。上线后的第一天应该做两件事一是把崩溃统计和用户反馈入口打开二是给关键操作加上埋点。这样用户说“提交失败”你至少能查到是接口超时还是参数错误。后续每次迭代我会在发版说明里把“本次修复的问题”连同崩溃日志一起列出来用 WorkBuddy 去分析日志里的异常堆栈定位到具体代码位置比肉眼翻日志快多了。迭代节奏上我的建议是上线第一周每天看一次崩溃率和新用户反馈之后降到每周一次每两周出一个小的修复版本稳住基本盘再开始加功能。这样做的好处是无论用户怎么用你总能在 72 小时内知道自己的 App 有没有出问题而不是在评论区里被反复教育。8. 十六个坑速查总表与一份可复用清单8.1 十六个坑速查总表下面是全文十六个坑的速查表按阶段排列可以打印出来贴在工位上。阶段坑典型症状一句话解法一1. 需求没拆碎生成代码一锅粥改一处崩一处拆成一句话任务带验收标准一2. 技术栈选错AI 生成质量差、报错多选 AI 训练数据最多的主流方案一3. 上线约束缺失审核被拒、隐私/权限问题多把隐私、权限、网络约束写进需求二4. 版本装错设置项对不上、Skill 缺失官方渠道下载先核对版本号二5. 缓存目录在系统盘启动慢、系统盘空间告急显式改缓存目录重启后重建索引二6. 模型参数没校准生成质量忽高忽低固定任务测温度/上下文记录基线三7. 规则没预设代码风格乱、越写越野写 Global Rules固化行为边界三8. Skill 同时挂多个输出混入无关代码一个任务只挂一个 Skill三9. 会话上下文失控AI 失忆、改错位置一任务一会话关键约束每次贴一遍四10. 一次生成整页代码纠缠改不动布局、样式、交互、接口四步拆开写四11. 跳过代码评审小问题攒成大事故每功能一次独立评审会话四12. 边界条件缺失非法输入、弱网、重复点击崩溃用边界清单让 AI 自查一遍五13. 只用模拟器验证真机权限/性能/存储出问题每周一次真机回归测试五14. 构建依赖解析失败构建报错看不懂定位依赖、固定版本、清缓存、查仓库六15. 审核标准不统一各商店驳回理由不同按驳回理由逐条改不自作聪明六16. 上线后无反馈闭环用户反馈无法定位第一天接崩溃统计和埋点8.2 项目交付自查清单把上面的坑倒过来就是一份可以直接抄走的交付清单需求每个功能都有验收标准上线约束隐私、权限、网络、错误处理全部写清环境官方版本号确认缓存目录已调整模型参数已有基线规则Global Rules 已配置Skill 按任务切换会话策略已统一开发每个功能小步提交完成后有 AI 评审和人工扫关键点边界条件单独查构建真机回归通过依赖版本固定签名和图标齐全版本号递增上架隐私政策可访问测试账号可用各商店要求逐条对照反馈闭环已打开。8.3 一点个人体会如果你完整走完这一遍可能会和我有同样的感受WorkBuddy 不是帮你省掉了思考而是把思考变成了可以被机器执行的要求。你给它的规则、拆解、约束越清楚它交付的质量就越稳定你指望它自己理解“能上线”三个字它大概率只会给你一个能跑的 demo。这十六个坑我每一个都真金白银花过时间。工具会越来越强但这套“拆需求、定规则、分阶段、做验收”的流程不会过时。希望这份经验能帮你把第一个能上线的 App 跑得更顺一点。 从0到上架：用 WorkBuddy 管好 AI 编程全流程的16个避坑指南
半年前我第一次打开 WorkBuddy心态很天真把 App 需求往输入框一贴它就该把能跑的代码全吐出来。试了一下午demo 确实跑起来了但 UI 丑、逻辑乱、一加功能就崩离“能上线”三个字隔着十万八千里。后来我把 WorkBuddy 当成一个真正的协作者来管——给它定规则、配工作台、拆任务、做代码评审前后三周把一个工具型 App 推到应用商店顺利过审。这篇文章就把这条路线完整拆给你六个阶段、十六个坑外加一份可以直接抄走的交付清单。不管你是第一次用 WorkBuddy 做真实项目还是已经在用它写 demo 但不知道怎么收尾成产品按这套流程走能少绕很多弯。1. 先说结论WorkBuddy 能不能扛起“上线”这件事1.1 WorkBuddy 不是普通聊天框而是一个需要“管理”的工作台先聊一个容易混淆的问题WorkBuddy 和 CodeBuddy 到底是什么关系这两年社区里两个名字经常一起出现教程也常常混着讲。按我的使用体会可以粗暴理解成同源不同定位——CodeBuddy 更偏向编辑器里的“程序猿助手”而 WorkBuddy 强调的是可配置的工作台你可以在里面搭建不同的 Workspace给每个 Workspace 挂上不同技能Skill和规则Rules让它在既定边界里干活。提示如果你只用它聊天等于买了一台有自动驾驶的车却一直手动推着走。我第一次用的时候完全没有这个概念把需求整段丢进去让它“给我做一个记账 App”。它确实能干生成了页面、数据库和接口调用但所有代码挤在一个会话里散落各处——没有分层、没有统一错误处理、没有设计约束后续每加一个小功能都会改动好几个文件改完一个崩一个。那一刻我明白了WorkBuddy 的定位本来就不是“一句话生成整个项目”的黑盒而是一个需要你定规则、分任务、做验收的智能劳动力。1.2 我判断“能上线”的三个标准既然目标是“能上线”就不能用跑通 demo 的标准来验收。我自己定义了三把尺子稳定性核心功能不闪退、数据不丢、弱网和异常输入下不崩。AI 生成代码最容易缺的正是失败分支这部分必须重点盯。可维护性代码结构能让人看懂、能继续改。如果生成完只有 AI 自己看得懂下一次迭代就是灾难。可发布性构建、签名、审核、商店后台配置这一套流程能走通包括图标、隐私政策、权限说明这些看起来不起眼但缺一个就上不了架的东西。拿这三把尺子去量你会发现很多“demo 跑通了”的兴奋瞬间其实还很远。这也决定了后面每一个阶段我都用“产出物是否达标”来判定能否进入下一步。1.3 六个阶段到底怎么划分的整条链路我拆成了六个阶段顺序可以调整但“上一阶段没验收完不进入下一阶段”这条铁律不要破阶段目标核心产出物对应坑阶段一需求拆分与技术选型需求清单 技术栈决策坑 13阶段二环境搭建与工作台配置可复现的开发环境坑 46阶段三规则、技能与对话策略Rules Skill 配置坑 79阶段四核心功能开发可运行的功能版本坑 1012阶段五联调、构建与出包可安装的包坑 1314阶段六上架审核与上线后运营商店在架的 App坑 1516我把“上架后”也放进阶段六是因为很多人以为提交成功就结束了结果第一天就被用户反馈打回原形。上线不是终点是新一轮迭代的起点这个后面细说。2. 阶段一把需求磨碎再动手坑 132.1 坑 1需求没拆碎整段丢给 AI这是最普遍的一个坑我自己也踩得很扎实。把“帮我做一个记账 App”这种需求整体丢给 WorkBuddy它确实会给你生成一个完整项目但问题在于代码看起来都全实际却是一锅粥。生成出来的页面动辄上千行状态管理和 UI 混在一起数据库字段和页面字段互相纠缠。你想让它改一个统计逻辑它可能把列表也一起动坏了。后来我把需求拆成了一个一个“一句话任务”新建项目搭建基础目录结构配置数据库表用户表、账单表、分类表实现登录页手机号 验证码实现账单列表页实现账单新增表单实现统计页。每拆完一个任务单独开一次对话让 WorkBuddy 去完成完成后先人工看一遍代码再进入下一个任务。整个开发节奏一下子可控了。有一个我自用的拆分模板可以抄功能账单新增表单 验收标准 1. 用户可输入金额、分类、备注、日期 2. 金额只允许数字且大于 0 3. 表单校验失败时给出中文提示不提交 4. 提交成功后返回列表页并刷新列表 5. 网络失败时保留输入内容允许重试。提示验收标准写得越具体AI 生成出来的东西越接近你要的。别把“能跑”当验收标准要把“符合这 5 条”当验收标准。2.2 坑 2技术栈选错AI 生成的质量先天打折这个坑很多人不会意识到。大模型训练时对不同技术栈的“见过程度”完全不同越是主流、社区资料越多的技术栈AI 生成质量越稳越是小众或者文档混乱的框架AI 越容易一本正经地写出错误代码看起来没问题一运行就报错。我当时的取舍逻辑是三点团队熟不熟、生态强不强、AI 数据多不多。工具型 App 最终选了 WebView 壳 Web 内页的方案原因很现实这个技术栈我熟、调试快、WorkBuddy 生成质量相对稳定而且后续迭代成本低。项目开始前花一个半小时做个技术栈对比表能避免后面半个月返工。对比维度至少要有AI 生成质量、生态成熟度、真机调试难度、上线门槛。别只选“最酷的”要选“AI 最会写的”。2.3 坑 3没把“要上线”写进需求后面全是补课我最初的需求清单全是功能描述“能登录”“能记账”“能统计”。看起来没毛病但“上线”这两个字背后还有一堆需求没说出口首次启动要不要隐私协议弹窗申请相机或相册权限时要不要解释理由没网的时候页面怎么办用户清缓存后本地数据会不会丢这些不写进需求WorkBuddy 就默认不管它不管审核阶段和用户手里就会出问题。我后面为了这些补课花了不亚于开发的时间。正确的做法是在需求清单里单列一栏“上线约束”上线约束 - 首次启动展示隐私协议用户同意后才可以进入主流程 - 获取定位、相册、麦克风等敏感权限前必须弹窗说明用途 - 所有页面必须有网络异常状态和重试按钮 - 关键操作删除、支付、清空数据需要有二次确认。把这些约束固定成全局规则之后AI 生成的每一个功能都会自动带上对应处理相当于在源头过滤掉了一大批审核风险。阶段一总结需求拆得越碎AI 干得越稳技术栈选得大众生成质量越高上线约束想得越早返工越少。3. 阶段二环境搭建与工作台配置坑 463.1 坑 4版本装错普通版和国际版不是一回事WorkBuddy 的安装阶段就有坑。我在网上顺手找了个版本装上界面看着和教程里差不多但模型入口、设置项、技能市场都对不上很多 Skill 根本没有。我一度以为是自己的使用方法问题浪费了大半天才反应过来是版本装错了。教训是先查版本号再开工。我的下载流程现在是这样的只从官方渠道下载不顺手用别人网盘里转发的版本安装完第一步到“关于”页确认版本号和更新渠道上网搜该版本的官方说明确认 Skill 市场和 Rules 功能开关齐全老机器比如 Win7先看兼容说明别装到一半才发现装不上。市面上流传的“国际版”和“普通版”差异并不小教程作者用的是哪个版本你最好就跟哪个版本不然很多命令和设置项都对不上。3.2 坑 5缓存目录默认躺在系统盘项目一多又慢又占地方WorkBuddy 会在本地产生不少缓存项目索引、模型上下文、技能模板、历史会话数据。默认路径一般落在系统盘的用户目录下。做两三个项目之后我发现启动和切换项目明显变慢系统盘空间也一路飘红。解决办法就是显式改缓存目录把缓存挪到空间充裕的盘。以我用的版本为例设置入口里能找到缓存路径也可以尝试命令行方式workbuddy config set cacheDir D:/workbuddy/cache不同版本命令行写法可能不一样拿不准就先在设置面板里找改完以后重启并重新索引第一次会比较慢后面就正常了。提示缓存目录改完之后旧缓存最好手动清一次但别在 WorkBuddy 正在运行时删容易损坏索引。退出后清理再启动最稳。3.3 坑 6模型连接和上下文参数没有校准输出忽好忽坏进入 WorkBuddy 之后一般会看到一个模型连接配置界面里面有模型选择、上下文长度、生成温度这类参数。很多人直接默认值就开干结果输出质量像抽奖。我建议先花一顿午饭的时间做校准用同一个固定小任务去测不同参数的效果比如“给这个列表页写一个空数据占位组件”。关注两件事上下文长度设得太短长文件改不动设得太长对话一多就超窗口报错。我一般选“够用就好”需要改大文件时临时调高。温度这个参数直接决定生成结果的“随机性”。写代码我通常压到比较低让输出更稳定做文案或者命名建议时可以稍微调高。我最终固定下来的初始配置是这样的只是参考不是最优答案配置项我的初始值说明模型项目默认模型以你的账号可用模型为准上下文长度中档基础开发够用温度偏低代码稳定优先自动生成开启配合 Rules 使用这些参数调完之后我没再频繁动过后面所有项目都先以这套为基线再按需调整。4. 阶段三规则、技能和对话策略坑 794.1 坑 7没有预设 RulesAI 越写越“野”如果只给 WorkBuddy 一个功能任务不给行为边界它就会用自己的“习惯”写代码而这个习惯未必是你想要的。比如它可能会在页面组件里直接写网络请求可能会一开始就引入一个你没打算用的第三方库可能函数命名风格前后不一致。等代码量上来这些问题就会变成不可维护。WorkBuddy 的 Rules 机制就是干这个的——给所有后续任务定边界一旦配置后续任务全部生效。我把自己项目的全局规则固化成了下面这份你可以直接改# Global Rules 1. 所有新增函数必须写明用途、输入参数和返回值说明。 2. 禁止引入依赖清单中未声明的第三方库。 3. 网络请求统一走 api 层禁止在页面组件中出现裸请求。 4. 所有用户输入必须做合法性校验失败时给出中文提示。 5. 涉及敏感权限相册、定位、麦克风时必须先说明申请用途。 6. 全局变量必须经过状态管理禁止跨组件直接修改。写好 Rules 之后我发现一个明显的改变同样的任务生成代码的“野性”小了很多函数注释、错误处理、命名风格都规矩了。这一步效果比换更强的模型还明显。4.2 坑 8Skill 同时挂多个规则互相打架WorkBuddy 的 Skill 可以理解为“预制的流水线模板”比如页面生成 Skill、数据库建模 Skill、代码评审 Skill。我一开始图效率把几个 Skill 同时挂在一个 Workspace 上结果生成的页面里混进了数据处理层的模板代码两边规则互相打架改起来非常难受。后来我总结出两条一个任务只挂一个最相关的 Skill做完再换不确定某个 Skill 干了什么的时候先全部关闭用一个标准小任务测一遍再逐个打开对比输出差异。这样排查效率高很多也不会出现“两个规则在打架”的玄学问题。4.3 坑 9对话上下文没有策略聊久了就“失忆”这个坑其实比前两个更隐蔽。WorkBuddy 的对话上下文是有限的一个会话里来回改十几轮之后它会“忘记”最开始的要求。最典型的表现是你让它改列表页它把登录页的条件判断也顺手改了你让它保留 A 逻辑它回你一个已经删掉 B 逻辑的新版本。我的解决方案是三句话一个任务一个会话任务完成立刻开新会话关键约束每次开头贴一遍不要默认 AI 记得上一轮的内容长任务拆成多个子任务分别开会话最后再合起来联调。我每次开会话之前会复制一段固定的开场模板见下把当前任务和红线约束写清楚实测下来“失忆”概率降低非常多请基于当前项目配置工作。 当前任务实现【任务标题】。 注意 1. 只修改与任务相关的文件 2. 遵守项目全局 Rules 3. 完成后先自查再给出变更说明 4. 不要新增依赖。阶段三的经验是规则定边界技能管流程会话控记忆。三条都做到AI 的输出就从“随机发挥”变成“稳定执行”。5. 阶段四核心功能开发节奏比速度重要坑 10125.1 坑 10一次让 AI 生成整页代码改起来怀疑人生到了真正写功能的时候最大的诱惑是“一次全部生成”。我试验过一次让 WorkBuddy 直接生成整个首页它确实一分钟给完页面能跑数据也能加载但代码乱到我不敢动——布局、状态、接口、样式全在一个文件里纠缠。改一个字体大小都要影响别的地方。后来我把“页面开发”拆成四步每一步都跑通验证再继续生成静态布局骨架先不看逻辑确认结构对填充静态元素和样式确认视觉对接状态和交互逻辑确认操作对接接口数据确认数据流对。每一步都单独开会话用一句话说清这一步的目标。不要跨步骤让 AI“顺便改一下”它的多任务处理能力没有想象中好。5.2 坑 11跳过代码评审小问题攒成大事故AI 生成代码的另一个问题是局部正确、整体埋雷。比如两个组件用了两个不同的日期格式化方式同一个接口被封装了三层退出页面时定时器没有清理。这些问题单看一次生成的代码不容易发现但攒多了就会在某次改动时一起爆。我的做法是每完成一个功能就开一个独立的“代码评审”会话用固定的评审 prompt 让 AI 先自己过一遍请对这个功能相关代码做一次严格评审 1. 找出潜在 bug尤其是状态更新和异步处理 2. 检查是否违反项目全局 Rules 3. 检查是否有安全隐患输入未校验、明文传输等 4. 检查是否有重复代码和不一致命名 5. 输出按“严重问题 / 一般问题 / 建议”分类。AI 评完之后我再人工扫三个关键位置网络请求有没有错误处理、用户输入有没有校验、本地数据读写有没有异常分支。这一轮做完一个功能才算真正能入库。5.3 坑 12错误处理与边界条件缺失用户一操作就崩AI 生成的代码一般“主路径”很完整——正常输入、正常点击、正常返回它都能走通但一遇到异常输入、弱网、重复点击、超长文本这些边界条件就开始露怯了。我的记账表单就出过这种问题金额输入“abc”直接崩连错误提示都没有提交按钮没做防重复用户连点三下账单多出三条。解决的办法不是让 AI 更聪明而是在任务描述里明确要它补边界。我自己总结了一份“边界检查清单”每次功能开发完成之后专门开一个会话让 WorkBuddy 按清单自查空数据列表为空、搜索无结果时有没有占位提示超时接口请求超时后有没有提示和重试超长/非法输入输入框有没有限制和校验重复操作提交按钮有没有防重复权限拒绝用户拒绝授权后流程能不能正常继续页面卸载定时器、订阅、监听有没有及时清理。把这份清单作为 Rules 的一部分固化下来之后同类问题大幅减少。阶段四的经验很简单小块提交、先评审后入库、边界单独查。速度看起来慢了实际上返工少了总时间是省的。6. 阶段五联调、构建与出包前夜坑 13146.1 坑 13只在模拟器跑通真机上一测试全是问题模拟器是我们开发时的好朋友但也是发布前的“障眼法”。我在模拟器上跑得很顺的页面第一次装到真机上就露馅了权限弹窗流程完全不一样存储路径对不上列表滚动掉帧图片加载卡顿。真机和模拟器的差异主要有三类权限与系统交互真机的权限弹窗、相册、定位逻辑更复杂模拟器常常直接放行性能表现真机渲染和内存限制更真实模拟器跑得动不代表真机跑得动网络与存储真机网络切换、后台恢复等场景模拟器很难模拟。所以我的建议是从第一个可用版本开始就做真机安装测试不要等到最后才想起来“真机试一下”。我给自己定的节奏是每周一次真机回归宁可频率低不能没有。真机测试清单至少包括冷启动和热启动不闪退登录态持久化杀进程后仍保留弱网环境下请求失败有提示权限拒绝后功能可用前后台切换不丢页面状态。6.2 坑 14Gradle 构建依赖解析失败被报错卡了快一天出包阶段最容易让人怀疑人生的就是构建问题。我遇到过一个非常典型的报错片段Could not determine the dependencies of task :app:compileDebugJavaWithJavac. Could not resolve all task dependencies for configuration :app:debugCompileClasspath.这类报错表面上是“依赖解析失败”实际原因往往五花八门。按下面的顺序排查效率最高先定位是哪个依赖出了问题不要盯着报错最后一行猜。执行./gradlew :app:dependencies --configuration debugCompileClasspath看输出里哪个依赖标红或标 FAILED。检查版本写法。如果是latest.或这类动态版本先改成固定版本号动态版本最容易在不同时间构建出不同结果。清理缓存再试./gradlew clean如果还不行可以删除本地 Gradle 缓存目录下对应模块的缓存注意备份别全删。检查仓库地址确认仓库配置的顺序对不对、地址能否正常访问必要时换一个备用仓库地址。我们项目里曾经就是因为某个仓库地址挡在前面后面的依赖全部解析不出来。善用版本对比如果昨天还能构建今天突然失败用版本管理工具对比依赖配置文件看这两天改了什么多数时候能直接找到元凶。另外一条经验不要选择在发版前夜第一次跑完整构建。构建问题应该在你还留有三四天余量的时候集中踩完否则小问题也会变成发布日期的大事故。6.3 出包前夜清单这些边角料真的不能省这个环节不单独算坑了但它和坑 14 一样容易让人通宵包名、签名、图标、启动图、版本号。包名一旦发布就改不了签名文件丢了就只能换身份重新上架图标和启动图必须准备全尺寸。我的发布前自查清单供参考包名确定并全局统一不包含拼写错误签名文件生成并加密备份记录 keystore 口令图标和启动图按各商店要求准备全尺寸版本名和版本号递增隐私政策链接可以在后台配置时访问构建产物在至少两台真机上安装验证。这些“边角料”在 WorkBuddy 生成代码的过程中几乎不会出现但上架的时候缺一个都会被卡。提前准备好出包当天就能从容很多。7. 阶段六上架审核与上线后的第一天坑 15167.1 坑 15被安全审核或格式要求拦下各平台标准还不一样提交审核是“能上线”的最后一关也是最容易让人心态崩掉的一关。我第一次提审被拒理由写的是“权限用途说明不足”。我检查了一下发现 App 会在首次启动时申请存储权限但没在授权弹窗之前向用户解释为什么要这个权限也没有在后台配置里写清楚用途。这本该是阶段一“上线约束”里就有的内容我当时没写于是回来补。各个应用商店的审核侧重点不完全一样有的特别重视隐私合规必须补充用户隐私政策、权限申请理由有的重视内容分级要求填写分级问卷有的会要求提供测试账号方便审核员体验完整功能。被拒之后不要慌先按驳回理由逐条对应到具体页面和处理代码改完再提交不要“换个姿势碰运气”反复提交。我给自己整理的审核自查清单是这样的隐私政策链接在 App 内可访问且与 App 实际行为一致每个敏感权限都有对应的申请时机和用途说明登录功能有可用的测试账号提供给审核员无网络、空数据等状态的文案不含歧义截图和宣传语与实际功能一致不夸大版本说明写清楚本次改动内容。7.2 坑 16上线后没有反馈闭环下一轮迭代只能靠猜上架成功那一刻我非常兴奋第二天就开始规划新功能。几天后看到用户评论说“登录有时候会失效”但我完全不知道发生了什么——因为我没有接入崩溃统计也没有用户反馈入口只能靠用户发截图和日志来猜。上线后的第一天应该做两件事一是把崩溃统计和用户反馈入口打开二是给关键操作加上埋点。这样用户说“提交失败”你至少能查到是接口超时还是参数错误。后续每次迭代我会在发版说明里把“本次修复的问题”连同崩溃日志一起列出来用 WorkBuddy 去分析日志里的异常堆栈定位到具体代码位置比肉眼翻日志快多了。迭代节奏上我的建议是上线第一周每天看一次崩溃率和新用户反馈之后降到每周一次每两周出一个小的修复版本稳住基本盘再开始加功能。这样做的好处是无论用户怎么用你总能在 72 小时内知道自己的 App 有没有出问题而不是在评论区里被反复教育。8. 十六个坑速查总表与一份可复用清单8.1 十六个坑速查总表下面是全文十六个坑的速查表按阶段排列可以打印出来贴在工位上。阶段坑典型症状一句话解法一1. 需求没拆碎生成代码一锅粥改一处崩一处拆成一句话任务带验收标准一2. 技术栈选错AI 生成质量差、报错多选 AI 训练数据最多的主流方案一3. 上线约束缺失审核被拒、隐私/权限问题多把隐私、权限、网络约束写进需求二4. 版本装错设置项对不上、Skill 缺失官方渠道下载先核对版本号二5. 缓存目录在系统盘启动慢、系统盘空间告急显式改缓存目录重启后重建索引二6. 模型参数没校准生成质量忽高忽低固定任务测温度/上下文记录基线三7. 规则没预设代码风格乱、越写越野写 Global Rules固化行为边界三8. Skill 同时挂多个输出混入无关代码一个任务只挂一个 Skill三9. 会话上下文失控AI 失忆、改错位置一任务一会话关键约束每次贴一遍四10. 一次生成整页代码纠缠改不动布局、样式、交互、接口四步拆开写四11. 跳过代码评审小问题攒成大事故每功能一次独立评审会话四12. 边界条件缺失非法输入、弱网、重复点击崩溃用边界清单让 AI 自查一遍五13. 只用模拟器验证真机权限/性能/存储出问题每周一次真机回归测试五14. 构建依赖解析失败构建报错看不懂定位依赖、固定版本、清缓存、查仓库六15. 审核标准不统一各商店驳回理由不同按驳回理由逐条改不自作聪明六16. 上线后无反馈闭环用户反馈无法定位第一天接崩溃统计和埋点8.2 项目交付自查清单把上面的坑倒过来就是一份可以直接抄走的交付清单需求每个功能都有验收标准上线约束隐私、权限、网络、错误处理全部写清环境官方版本号确认缓存目录已调整模型参数已有基线规则Global Rules 已配置Skill 按任务切换会话策略已统一开发每个功能小步提交完成后有 AI 评审和人工扫关键点边界条件单独查构建真机回归通过依赖版本固定签名和图标齐全版本号递增上架隐私政策可访问测试账号可用各商店要求逐条对照反馈闭环已打开。8.3 一点个人体会如果你完整走完这一遍可能会和我有同样的感受WorkBuddy 不是帮你省掉了思考而是把思考变成了可以被机器执行的要求。你给它的规则、拆解、约束越清楚它交付的质量就越稳定你指望它自己理解“能上线”三个字它大概率只会给你一个能跑的 demo。这十六个坑我每一个都真金白银花过时间。工具会越来越强但这套“拆需求、定规则、分阶段、做验收”的流程不会过时。希望这份经验能帮你把第一个能上线的 App 跑得更顺一点。