VibeCoding 这股风最近吹得很猛：你不再从空工程、空页面开始一行行搭，而是先用自然语言描述目标、UI 结构和交互细节，让 AI 迅速生成 SwiftUI/Compose/Flutter 代码，跑起来以后再一边试、一边改、一边继续对话，直到界面“看着对”、流程“跑得通”。

我承认它很爽，尤其在客户端开发里，这种爽感更明显——过去你可能要折腾半天布局、状态管理、列表复用和埋点，才能做出一个可演示的页面；而现在，几十分钟就能把 Demo 做到像产品一样，甚至能直接装到真机上给人试用。问题也恰恰出在这里：VibeCoding 太容易把我们推到“能跑”这一步，于是很多人会自然地产生冲动：既然都能跑了，要不要干脆发个版？

在客户端语境里，“发版”不是把代码部署上去那么简单，它意味着要穿过 App Store/Google Play 的审核与隐私要求，要面对机型碎片化、弱网、低内存、后台切换等真实环境，更要承担崩溃率、ANR、OOM、差评和回滚成本；因此我越来越把 VibeCoding 当成一种“起步方式”，而不是“上线方式”——它负责把你带到创作的起点，但把你带到可以交付的终点，靠的是一套不那么爽、却很救命的底线。

“开工之前先提醒自己：快，不等于稳；能跑，不等于可用”

下面这份清单是我在客户端项目里反复验证过的：每一条都很“工程”，但它们恰好是 VibeCoding 最容易漏掉、也最容易出大事的地方。

1. 安全：VibeCoding 最危险的不是写错，而是把边界写没了

VibeCoding 的默认节奏是“先把快乐路径跑通”，而安全问题通常藏在边界里：越权、数据泄露、密钥泄露、调试信息暴露……这些往往不会出现在你演示的那条路径上，却会在真实用户手里以最意想不到的方式触发。

（1）别把“客户端限制”当成权限。

客户端最常见的幻觉是：我在 UI 上隐藏了入口、禁用了按钮、做了本地校验，所以别人就做不到。现实是，只要后端接口没有做授权校验，别人完全可以绕过 App，直接重放请求或改参数；你在客户端看到“只能看自己的订单/消息/云盘文件”，不代表攻击者也只能看到自己的。

因此我给自己的硬规则是：涉及用户数据的读取与写入，必须假设客户端不可信，权限校验必须在服务端完成；而当我让 AI 生成网络层或业务接口调用时，一定会追问两句：这次请求凭什么能拿到这份数据？如果把 id、cursor、userId 换掉会怎样？——你会惊讶地发现，很多“能跑”的代码就差这一问。

（2）输入、外部数据、文件，一律按“不可信”处理。

客户端的“输入”不只是文本框，还包括：Deep Link/Universal Link、剪贴板内容、系统分享进来的文件、二维码扫描结果、推送 payload、甚至服务端返回的数据。VibeCoding 很容易帮你写出“能解析就用”的逻辑，但你必须补上：长度与格式限制、枚举白名单、异常分支兜底、文件大小上限、MIME/内容嗅探而不是只看扩展名；如果你会在 WebView/富文本里渲染用户生成内容，更要警惕脚本注入与危险协议跳转。

（3）别盲信 AI 推荐的 SDK/依赖（小心包体积爆炸）。

AI 会很自信地推荐“某个库可以一键解决”，但在客户端生态里，这意味着你要把 App 的稳定性与合规风险，外包给一个你可能没见过的第三方：它维护得勤不勤、Issue 多不多、最近一年有没有更新、许可证能不能商用、是否存在“名字像但不是同一个”的冒名包（供应链/typosquatting 风险），这些都需要你确认。此外，AI 经常为了一个简单的功能，给你引入一个极其臃肿的重型框架，直接导致包体积（APK/IPA Size）剧烈膨胀；同时请务必固定版本（如 Podfile.lock、Gradle 依赖锁定），否则一次无感升级就可能把线上崩溃率推高。

（4）错误信息与日志：能帮你排查，也能帮别人攻击。

调试阶段你可能习惯把异常堆栈直接弹 Toast、把请求响应完整打印到控制台、把 token 写进日志方便对齐，但发版后这些都可能成为“内部地图”。正确的做法是：用户侧只给抽象提示（例如“网络异常，请稍后重试”），细节只进受控的日志与崩溃平台，并且明确禁止记录密钥与个人敏感信息（手机号、邮箱、身份证、精确定位等）；同时把 Debug/Release 的日志等级、开关、埋点 key、Crash 符号表处理流程提前理顺，不要等到线上出事才临时补。

（5）“内部 App 不用太安全”是错觉。

企业内部分发、灰度渠道、测试包并不会让风险消失：BYOD、越狱/Root、恶意软件、离职账号未清理、内网并非安全边界……这些因素叠加起来，往往让“内部系统”更容易被忽视、更不容易被发现。

（6）工作场景里用 AI，要用公司允许的工具与账号。

VibeCoding 的高频对话会诱导你“顺手贴一段日志/代码/接口文档”，但聊天记录与上传内容可能长期留存在外部服务里；在公司环境里，工具与账号的合规性是底线，别因为一时方便把敏感信息带出边界。

2. 成本：客户端的“费用”不只在账单，还在电量、流量与差评

很多人一提成本只想到云账单，但客户端同样有成本曲线：一次“智能总结/图片生成/语音转写”背后可能是多次 API 调用与重试；一个看似无害的“实时联想”可能在弱网下疯狂触发请求；一个没做节流的按钮，可能被连点成“无限请求机”。即使最终钱由服务端支付，用户也会用电量、流量和卡顿来给你投票。

我给 VibeCoding 的成本底线是三件事：先弄清计费与配额（按请求、按 token、按图片次数、按带宽……）；再做一个可解释的试算（DAU、调用频次、峰值并发、失败重试次数）；最后把“刹车”装上（预算告警、限流、缓存、去抖、幂等、远程开关/降级），不要把控制权押在“我应该不会写错循环”这种侥幸上。

3. 合规：发版不是交付终点，而是规则开始生效的那一刻

客户端要面对的合规更直观：权限申请、隐私弹窗、数据收集说明、第三方 SDK 披露、儿童隐私、广告标识、跨境传输、地区性法规，以及应用商店的审核条款。VibeCoding 可以帮你快速拼出功能，但它不会替你保证“这个功能在商店里过得去”。

我上线前会固定做一个 5 分钟检查：数据来源是否允许、是否涉及个人信息与跨境、依赖库许可证是否可商用、生成内容是否存在版权/授权隐患、是否进入金融/医疗/教育等强监管场景；越早做这件事，越不容易在临门一脚时推倒重来。

4. 不是 Demo 就要想清楚：数据结构、失败恢复、测试与可维护性

VibeCoding 特别适合做 Demo，但一旦你准备“给真实用户长期用”，系统的难点会从“把功能做出来”切换到“把功能长期跑稳”。

（1）数据结构的债，比 UI 更难还。

客户端的本地数据库（Core Data/Room/Realm/SQLite）一旦装进用户设备，再想改表结构就要面对版本升级与迁移：旧版本用户不一定立刻更新，迁移中途崩溃可能导致数据损坏，字段含义的变更更可能引发逻辑错乱。因此在你写第一行 CRUD 之前，最好先把核心实体、关系、可变字段、删除策略想清楚，并且把迁移方案当作功能的一部分来设计与测试。

（2）永远问两句：中间失败怎么办？重复执行怎么办？

客户端天然会遇到后台切换、进程被杀、网络抖动、请求超时、用户连点，这些都会把“能跑的流程”打成碎片；尤其涉及支付/订阅、订单提交、文件上传、同步队列时，事务边界与幂等性不是高级选项，而是必选项——同一个请求重放会不会重复扣费？恢复重试会不会重复提交？离线队列回放会不会乱序？这些问题不提前想，线上就会用最痛的方式提醒你。

（3）测试不要只覆盖演示路径。

VibeCoding 生成的测试往往倾向快乐路径；而客户端真正要命的场景是：升级迁移、弱网/断网、后台恢复、低内存、横竖屏切换、不同系统版本差异、权限被拒绝、推送数据异常。我的做法是先把需求写成可验证的规则，再从规则推导测试用例，最后落到单测/集成测试/UI 测试与必要的人工回归；同时把关键链路的“失败点用例”列出来，逼自己在发版前至少跑一遍。

（4）可维护性：三周后的自己就是陌生人。

VibeCoding 很容易堆出一团“能跑但说不清”的代码，而这种代码在客户端尤其危险，因为你需要长期适配系统版本、机型、性能指标与产品迭代。我的底线是：重复逻辑要收敛（DRY），关键模块要分层（网络/存储/业务/UI），以及任何你解释不清的代码都不要急着发版——你不需要把每行都背下来，但至少要能讲清它为什么存在、出了问题该从哪里查。

5. 性能：客户端的“吞吐量”就是帧率、内存与启动时间

服务器谈 QPS，客户端谈体验：列表滑动是否掉帧、首屏是否白屏、图片解码是否卡顿、内存是否持续增长、后台回来是否重建过慢、低端机是否 OOM。VibeCoding 会让 UI 代码生成得很快，但性能和稳定性问题往往来自“生成出来的默认写法”：在 bind/render 阶段做重 I/O、在列表里频繁查询本地库、无节制地创建对象、缓存策略缺失、图片未缩放就解码、无穷重组/重绘。更致命的是，AI 生成的异步回调或闭包往往缺乏生命周期（Lifecycle）感知，常常强持有 Activity 或 ViewController，导致严重的内存泄漏（Memory Leak）。

我会在发版前用三个问题做粗估：目标机型的内存与性能下限是多少？页面最坏情况下要渲染多少条数据与多少张图？关键路径能否在主线程之外完成？只要你能把这三件事说清，很多性能坑就能提前暴露，而不是等线上崩溃率和差评来“验收”。

6. 出事怎么办：客户端的止血手段要提前准备

在客户端世界里，事故往往以“崩溃率上升、ANR 变多、OOM 飙升、评分掉了”这种形式出现；如果你没有止血手段，唯一的选择就是紧急发版，而紧急发版又会受审核与渠道分发节奏影响。

因此我会提前准备几样东西：灰度/分阶段发布、远程开关与降级策略、关键路径的埋点与告警阈值、Crash 平台的常用查询与告警订阅；真正出事时先停扩散（暂停发布/回滚/关闭开关），再留证据（版本、机型、系统、堆栈、关键日志），同时尽快对外沟通影响范围，最后做根因分析并把改进沉淀成机制（测试补齐、监控补齐、发布流程补齐）。

7. 用 AI 做客户端 VibeCoding：把它当同事，用问题把工程补回来

我越来越少让 AI “一口气写完”，而更常让它做两件事：一是快速产出候选实现，二是把风险与盲点列出来。比起“帮我写页面”，我更常问的是：

• 这个页面在低内存/后台恢复/弱网下会有什么坑？
• 本地缓存应该怎么设计？数据一致性怎么保证？
• 哪些日志要打，哪些绝对不能打？
• 这个依赖是否值得引入？维护与许可证风险是什么？
• 这条链路如何保证幂等？如何避免重复提交？

VibeCoding 的关键从来不是“凭感觉写”，而是“凭感觉起步、靠问题收敛”；当你把这些问题问出口，AI 才可能成为加速器，而不是把你推向事故的助推器。

结语

VibeCoding 让客户端开发变得更像创作，这是好事；但当你准备把作品交给真实用户时，你需要的就不只是灵感与手感，而是对安全、成本、合规、稳定性与长期维护的敬畏。

愿你享受 VibeCoding 的爽感，也能守住发版前那几条最基本的底线：让 App 跑得起来，更让它撑得住。