企业官网建设流程全解析

我们团队上个月接了一个内部工具App的活，原计划两个月的工期，最后15天就交付了。不是因为我们突然全员进化成了架构大师，而是整个研发流程换了一种全新的写法：vibe coding。如果你过去一年也一直在关注AI编程，肯定见过这个词，但对移动端到底怎么用、怎么不翻车，网上大多是Web端或Python脚本的案例，真正给Android、iOS、Flutter开发的落地经验少得可怜。这篇就专门写给移动开发者，用我自己踩了三个月坑之后的真实经历，把vibe coding的环境准备、全局md文档设计、逐轮对话工作流和移动端特有的雷区一次性说清楚。

这篇文章适合三类人：一是想尝试AI主导编码但还没找到门道的移动端开发，二是已经被vibe coding折腾得怀疑人生、觉得这玩意儿只能写写Demo的中级工程师，三是需要带团队、想评估能不能把AI协作引进业务项目的Tech Lead。内容不从理论开始，从怎么配环境开始，一直聊到怎么把AI从“生成代码的键盘侠”变成“懂你项目的同事”。

1. vibe coding是什么，以及它凭什么在移动开发圈吵翻天

1.1 这个概念是怎么来的，它和“AI辅助编程”有什么不同

“vibe coding”这个词冒头是2025年初的事，核心意思是：你不再逐行敲代码，而是用自然语言描述需求，让AI生成代码，你负责给方向、看结果、提反馈，甚至允许自己不完全理解每一行代码。最早提出这种说法的人打了个比方：像听一首歌沉浸进氛围里一样，跟着感觉走，代码有错就交给AI去改，你别一条条地读。这和过去我们玩的“AI辅助编程”有本质区别——辅助编程是AI帮你补全、你主导；vibe coding是AI主导生成、你主导意图和验收。

我在最初听到这个定义的时候，第一反应是“这不就是把身家性命交给一个语言模型了吗”。但真正跑完几个项目后，我意识到它并不是让你彻底躺平，而是把工作重心从“手写每一行”转移到“说清楚要什么、判断AI给的对不对”上。这个过程对移动开发者来说，比Web端要难受很多，因为移动端有编译、签名、模拟器、多机型适配这些硬约束，AI再“vibe”，最终也得过一个冷冰冰的编译器。

1.2 移动开发者对vibe coding的两极分化到底在争什么

我观察下来，移动端对这个概念的态度差不多是三个阵营。第一阵营是重度拥护派，主要是一些独立开发者，他们的感受是“一个人的团队终于有了实习程序员”，日常用AI把SwiftUI页面和Compose页面糊出来，省掉大量样板代码，效率翻倍。第二阵营是强烈抵触派，多数是有过几次糟糕体验的工程师，AI给出的代码要么编译不过、要么为了一个按钮引入了三个新依赖、要么完全无视了项目的架构约定，最后收拾烂摊子比自己做还累。第三阵营是观望派，觉得这玩意儿只能写写教学项目，离生产级代码差得远。

这三派吵来吵去，其实都忽视了一个事实：vibe coding不是银弹，也不是骗局，它是一套需要环境、文档和流程支撑的工程方法。Web端的vibe coding教程之所以看起来顺滑，是因为JavaScript生态容错率高，改个bug直接刷新页面就知道了；移动端不行，一次build就要几十秒到几分钟，AI的试错成本被成倍放大。所以你需要的不是更聪明的AI，而是让AI“少犯错”的工程护栏——这就是后面几章要解决的问题。

2. 环境准备：一次配好Trae Code和项目的“AI工作区”

2.1 为什么选Trae Code作为移动端vibe coding的主阵地

工欲善其事，必先利其器。vibe coding的核心是“频繁对话、快速迭代、上下文一致”，移动开发者最怕的三件事就是：对话上下文突然丢失、AI读不懂整个工程结构、生成代码和本地SDK对不上。我尝试过在Copilot侧边栏直接聊、在ChatGPT网页端复制粘贴项目代码再生成，体验都很割裂。后来切到Trae Code，才算是把“对话”和“代码仓库”放到了同一个工作台里。

Trae Code本身是一个AI原生IDE，和VS Code同源，所以移动端开发者上手几乎没有学习成本。它真正好用的点是：AI能直接读取整个工程目录，而不只是你粘贴给它的一段代码。这意味着你问“帮我看看这个模块为什么编译报错”，它能自己找到build.gradle、找到那个报错的Kotlin文件、甚至翻出对应的资源xml来综合判断。这不光是省了手动粘代码的功夫，更重要的是AI的回答天然带有项目上下文。

另外，Trae Code对国内开发者的网络环境和中文提示词的支持都更友好，不用折腾模型代理这一层，装上就能用。对我这种不想花时间在环境配置上的移动端老油条来说，这比什么都重要。当然，你也可以用其他AI IDE，只要是能读整个项目的、支持自定义全局提示词的，思路都一样。

2.2 十几分钟的初始化配置，让AI真正认识你的项目

我在这里把第一次配置Trae Code的完整路径走一遍，照着做基本十分钟能搞定，而且是“一次性配置、长期受益”的那种。

第一步，下载并安装Trae Code，导入现有移动端工程。注意，工程的根目录最好是Clean Architecture的项目根目录，也就是说AI能看到app模块、core模块、data模块那一层，而不是只打开一个子目录。你给AI的视野越完整，它对“依赖方向在哪里、哪一层该放什么代码”的判断就越准。

第二步，在IDE设置里找到AI对话区的“全局自定义指令”或“全局提示词”入口。不同版本的入口位置略有差异，但逻辑都是同一个：把定义好的全局md文档路径填进去，或者直接把文本复制到对应的配置框里。这一步的作用是让AI在每次对话和生成代码时自动携带你写的项目规范。

第三步，确认模型和上下文长度。Trae Code里的多个模型我都试过，我的经验是日常生成代码用响应快的模型，遇到疑难编译错误再切到带有长上下文能力的旗舰模型。方案是把长上下文模型作为默认，因为它要能吞下整个项目的关键文件。上下文长度直接决定了AI能不能记住多个文件之间的依赖关系，这一点对移动端特别重要。

2.3 移动端特有的环境变量和SDK提示词

项目正式开跑前，还有一件事必须做，否则AI会到处“踩雷”：把移动端特有的SDK路径、架构约束和编译工具链信息写进全局文档。比如Android项目，AI需要知道你的compileSdk、targetSdk、minSdk是多少，用的是Java还是Kotlin，是Groovy DSL还是Kotlin DSL的Gradle，Widget用原生View还是Jetpack Compose。这些参数不写清楚，AI很容易按它脑子里的大众模板生成一套“默认值”，而那个默认值十有八九和你的工程对不上。

iOS项目同理，AI得知道自己面对的是SwiftUI还是UIKit，最低支持iOS版本是多少，是用CocoaPods、SPM还是直接手动管理依赖。Flutter则要说明是否会用到原生平台通道。这些信息聚合在一起，构成了AI理解你项目的第一层滤镜。写好了这层滤镜，AI生成的代码才不是“泛电商后台管理系统”那种一股异味的东西，而是“确实长在我们这个Android项目里”的代码。

3. 项目宪法：用一份全局md文档把AI调教成懂你项目的同事

3.1 什么是全局md文档，为什么在vibe coding里它是刚需

全局md文档，你可以理解为放在项目根目录的一份“给AI看的工作手册”。它通常叫GLOBAL_GUIDE.md、PROJECT_GUIDE.md或AGENTS.md，内容是项目技术栈、架构约定、编码规范、模块划分、已知坑位。为什么说它是刚需？因为大模型最大的毛病是“没有长期记忆”——每次新开对话，它对你的项目几乎一无所知。如果没有这份文档，你每轮都要重复“我们这个项目是MVVM、用Compose、别用Activity里写逻辑”这些背景，AI还是大概率会忘。

而全局md文档的本质是给AI提供稳定的静态记忆。只要设置了自动加载，它每轮对话都会先读一遍你的规则，相当于入职第一天就给了实习生一本《项目红线手册》。我甚至把全局md文档叫“项目宪法”，因为它的地位比对话更高，对话里AI说“我觉得这样挺好的”，一翻宪法，不行，这个模块不允许直接依赖network库，那AI就得按宪法来。有了宪法，vibe coding的容错率会高一个量级。

3.2 一份能落地的全局md文档长什么样

直接给一个我最近在Android项目中使用的精简模板，涵盖技术栈、目录结构、编码约束、指令规则四大块。

# 项目全局指南 ## 项目定位 这是一个面向C端用户的每日短句App，核心价值是“轻量、快速、离线可用”。 ## 技术栈 - 语言: Kotlin - UI: Jetpack Compose - 架构: MVVM + Clean Architecture - 网络: Retrofit + OkHttp - 异步: Coroutines + Flow - 依赖注入: Hilt - 构建: Gradle Kotlin DSL ## 目录结构 - app/src/main/java/com/example/dailyquote/: 入口和UI层 - core/: 通用网络、数据库、工具类 - feature/daily/: 每日短句业务模块 - feature/collection/: 收藏业务模块 ## 编码规范（强制） - 所有UI状态放在ViewModel中，使用StateFlow暴露 - Activity/Fragment中禁止写业务逻辑 - Repository是唯一的数据源入口，ViewModel只依赖Repository接口 - 不新增任何依赖，除非在对话中明确申请并说明原因 - AndroidManifest中不要新增权限，除非说明场景 ## 已知技术债 - compileSdk = 34，不要升级到35 - 项目使用Gradle 8.x，不要修改wrapper版本 - compose-bom请使用2024.xx.xx版本，不要使用beta版本 ## AI操作守则 - 生成代码前先简述实现思路 - 不确定的API请标注[待确认]，不要直接写进代码 - 修改build.gradle或新增依赖前，先输出变更计划 - 每个功能完成后，生成对应单元测试

这份文档我实测下来效果极好。理由很简单，AI所有的“自由发挥”空间都被压缩在了你允许的范围内。它知道哪些事情碰都不能碰，哪些步骤要先请示再动手。文件不用长，关键是把约束写透。对于iOS项目，把技术栈换成SwiftUI、依赖管理方式、最低版本、编码规范写清楚，逻辑完全一样。

3.3 文档怎么迭代，避免它变成一纸空文

全局md文档最大的坑是“写完就忘”。很多项目第一天写了宪法，第二天AI就违反了一条，第三天团队发现文档和真实代码结构对不上了，第四天大家都懒得更新了。要让文档持续生效，我的做法是把文档更新纳入每个迭代的收尾动作：每次一个功能模块做完，顺手把新增的目录、新的架构约束、踩到的坑追加进去，时间不超过五分钟。

另外，我自己会定期在全局md里增加“AI最近容易犯的错”一节。比如有一次AI连续两轮在Compose的State中使用普通MutableList导致UI不刷新，我就在文档里写了一条：UI层状态必须使用collectAsStateWithLifecycle配合StateFlow。写完之后，这个问题再也没出现过。文档是动态的，它是你和AI之间不断磨合后沉淀下来的“团队约定”，不是一份应付检查的设计文档。

4. 完整跑通一个移动端需求的实操工作流

4.1 案例背景：做一个“每日短句”离线收藏App

理论说了不少，现在拿一个真实例子走一遍完整流程。假设项目已经搭好了基础架构，我们要做一个新功能：每日短句页面，用户能看到更新的句子，可以点击收藏，收藏后离线也能查看。这个功能不算难，但涉及UI、网络请求、本地数据库、跨模块通信，非常适合演示vibe coding的工作流。

开工之前，我的做法是先不急着让AI写代码，而是把需求拆成几个检查点：第一，数据从哪里来，需要什么样的Repository接口；第二，UI如何展示加载中、成功、失败、空数据四种状态；第三，收藏的数据存在哪里，是Room还是DataStore；第四，离线如何判断，需要监听网络状态还是直接错误降级。这些检查点我并不会全部自己实现，但它们是我用来验收AI产出物的标尺。

4.2 第一轮对话：让AI搭骨架，而不是堆代码

第一轮对话非常关键，因为它奠定了整个功能的骨架。我的首个提示词大概是这样的：“在现有的Clean Architecture结构下，实现每日短句功能。数据层新建RemoteNewsRepository接口和NewsRepository接口，UI层使用Compose实现DailyQuoteScreen。先不要写具体实现，告诉我你打算怎么拆分文件、数据流是怎么走的。”注意，我特意要求它先讲思路再写代码，这一步能提前过滤掉AI一半的幻想。

这时候AI给出的通常是实现计划：data层加一个实现类，domain层加一个UseCase，UI层建Screen和ViewModel。我看了思路，觉得合理，就只说了一句“可以，按这个思路开始写，注意遵循全局指南”。然后它就开始噼里啪啦生成文件。生成完毕后，我不会急着运行，而是先扫一眼关键文件：Repository接口有没有依赖具体实现、ViewModel是不是通过StateFlow暴露状态、Compose里有没有直接把Context当参数往下传。只要没有违背架构红线，我就会进入下一轮。

4.3 编译报错的处理：这是vibe coding和纯聊天最大的区别

一次写了十几个文件，编译能一次过几乎是不可能的。这里的处理方式和过去完全不一样。我的习惯是：直接把构建错误输出扔给Trae Code的AI，同时附带一句“我只要编译通过，不要重构无关代码，不要动其他模块”。这句话很重要，否则AI很可能为修复一个类型错误，顺手把你Activity的布局文件也改了一遍。

第一轮报错往往是版本或API问题。比如AI生成了一段用旧API的代码，编译提示已经废弃了。AI看到错误后会自己定位到对应文件，给出修复方案。如果它改了三次还编译不过，这时候我会给出更具体的指令：“别管其他文件，只看app/src/main/java/com/example/dailyquote/.../DailyQuoteViewModel.kt，把第64行的类型问题修掉。”把范围缩小、把目标锁定在单一文件，AI的修复成功率会提升很多。整个过程来回大概四到六轮，半小时内功能编译通过，这个速度已经远超手写。

4.4 收尾检查：让AI补测试和边界条件

编译过了，功能能跑了，不代表vibe coding结束，一半的工作才刚刚开始。移动端最容易犯的问题是：AI只会写“快乐路径”的代码，网络层失败、数据库空数据、内存回收、Activity重建，这些边界条件它默认忽略。所以我的最后一轮提示词是：“给这个新功能补充单元测试，覆盖成功、失败、空数据三种情况，并检查ViewModel在onCleared时有没有取消协程，文件里是否有硬编码字符串，是否需要抽取到strings.xml。”

AI收到这个提示后，通常会主动补上几个测试文件，把硬编码字符串抽出来。这时候你不用自己动手写测试，但要检查测试的逻辑断言是不是真的有效。有些AI写的测试很水，为了不失败，断言一个永远为真的条件。所以在验收阶段，我会抽空把测试代码读一遍。这轮做完，功能才算真正进入“可以提交MR”的状态。

5. 移动端落地最容易翻车的5类坑

5.1 依赖版本地狱：AI根本不认识你的AGP和Kotlin版本

移动端与Web最大的差异在于：它有一个强约束的构建系统，版本之间有一张互相咬合的兼容性网络。AI的训练数据里塞满了不同时期的项目模板，它可能上一秒还在用compileSdk 33的写法，下一秒就给你生成一段要求compileSdk 35的代码。我见过最离谱的是一次AI为了用一个新API，自行把gradle文件中的compileSdk从34改到35，还说“这样就没有编译错误了”。问题是，那个改动可能影响了整个团队的构建环境。

对付这个坑，最有效的就是在全局md文档里写死版本号，并加一句“AI无法升级或修改版本，只能基于现有版本寻找兼容API方案”。如果AI真的遇到一个当前版本解决不了的API，它会主动反馈说“当前依赖版本不支持这个特性，需要加新依赖或升级”，而不是自作主张去改动关键配置。这堵墙筑好，依赖地狱至少能挡住一半。

5.2 “建议”式的API幻觉：它会把不存在的接口写得煞有介事

AI的第二个坑是“一本正经地编API”。大模型在遇到没见过的框架接口时，倾向于按语言模式“猜”一个相近的写法，而且语气非常笃定。比如我让AI生成一段Room数据库操作，它可能会写一个实际上并不存在的@RawQuery注解的使用方式，编译不过之后改三次还是不过，最后我翻了文档才确认这个API根本不存在。

我的应对方法是两条腿走路。第一，在全局md里加一条“AI操作守则：不确定的API请标注[待确认]，不要直接写进代码”，让AI在生成时有所收敛。第二，当同一个编译错误反复出现三次以上时，我会手动去查一下官方文档，把正确的API片段复制进对话，并附上一句“少用你记忆中的写法，以我贴给你的这个为准”。把AI当成一个记性很好但偶尔会记串行的实习生，你得经常帮它“校准记忆”。

5.3 权限越加越多：AI的“贴心”是合规隐患

移动端权限是非常敏感的合规点，滥用权限在应用商店审核阶段会被重点关注。AI的默认操作是“需要什么能力就加什么权限”，而且它不会考虑你的隐私政策有没有覆盖这个权限。有一次AI在生成一个图片分享功能时，顺手在AndroidManifest里加了READ_EXTERNAL_STORAGE权限，理由是“要读取相册图片”。但实际上我这个功能用的是系统分享面板，根本不需要这个权限。如果我没发现就提交审核，这就是一个合规风险点。

我从那次之后，就在全局md文档里加了一条硬性规则：新增任何权限前，必须向开发者单独输出一段说明，包括权限名称、使用场景、触发条件，经过确认后才能加入代码。这个规则帮我把关了三次。vibe coding里，AI只对你的功能需求负责，不对应用隐私合规负责，这条底线必须由人来守。

5.4 UI还原度失控：Compose代码对了但看着就是不对

还有一个高频翻车点是UI。AI生成的Compose代码逻辑完全正确，但视觉效果很糙：间距用的8.dp或16.dp比较随意，颜色没有走主题色而是直接写死了#FF0000，字体没有用TypeScale体系。在Web端这看起来问题不大，但在移动端，UI一旦走样，设计师一眼就能看出来，返工成本极高。

解决方案是在全局md里附上项目的Design Token清单，比如“主色用MaterialTheme.colorScheme.primary”“间距只允许用Spacing类的预定义值”“列表项的圆角统一为12.dp”等等。有了这些约束，AI生成的UI代码至少是符合设计规范的。如果项目里有现成的可复用Compose组件，我会在文档里明确列表，比如“按钮一律使用PrimaryButton、卡片一律使用BaseCard”，AI就会去调用组件而不是每次重新画一个。

5.5 长对话失忆：聊到后面它忘了自己改过什么

最后一个坑是“长对话失忆”。vibe coding进行到第30轮的时候，AI会慢慢忘记它自己在第10轮的时候是怎么命名这个函数的、在第22轮的时候有没有给某个数据类加过字段。你让它改一个文件，它可能把另一个已经调通的接口签名给悄悄改了，导致其他模块连环报错。

应对办法是“及时分割对话”。每个子任务尽量控制在十到十五轮对话以内，做完一个功能就新开一个对话，让AI重新从全局md里读取那份稳定的上下文。新对话并不会丢失项目规则，因为全局md会重新加载。之前跑通的代码已经固化在文件里了，AI看不到就改不到。这个习惯对移动端尤其重要，因为一个文件被AI无意中改坏，发现的时机往往是在半小时后的一次build里，排错成本非常高。

6. 进阶协作姿势，以及我踩了三个月后的真实心态

6.1 把AI当“实习生”而不是“许愿机”

跑完多个项目之后，我自己对vibe coding的定义收敛成一句话：一项“AI主导编码、人主导工程判断”的协作艺术。最坏的用法是把它当许愿机，说一句“做个高并发消息推送模块”就等着收货；最好的用法是把它当实习生，先给手册、再定目标、过程中频繁review、有问题当场指正。AI生成100行代码，可能70行能用，20行要小改，10行必须推翻重写，这很正常。你要练的是快速判断哪些该留、哪些该砍的能力。

我发现能稳定用好vibe coding的中高级移动开发者，都有一个共同点：他们不是不会写代码，而是故意不写那些重复性样板代码。把时间省下来去思考架构、性能、合规和产品交互，这其实才是vibe coding对移动开发最实在的价值。它不会取代你，但它会把你的核心竞争力逼到更高维度去。

6.2 让AI做review和写测试的进阶玩法

进阶之后，我除了用AI写功能代码，还会让它做代码review。方法很简单：贴一版自己手写的代码，或者将AI自己之前生成的完整模块发给它，加一句“从崩溃安全、内存泄漏、边界条件、可读性四个角度对这个文件做代码审查，列出问题清单和修改建议”。这套玩法的效果意外地好，AI常常能揪出一些我习以为常的问题，比如Compose里非必要的重组、协程作用域使用不当、异常吞掉没有日志等。

写测试也是AI的强项。移动端开发者普遍不爱写测试，而现在我可以把写单测的活直接外包给AI。我的固定句式是：“给这个Repository新增单元测试，用MockWebServer模拟成功和超时两种情况，断言状态是否按照预期更新。”它会连mock依赖的测试代码一起生成。虽然我还是会扫一遍断言逻辑，但整体效率已经是手写的三倍以上。

6.3 我现在的日常节奏和一点点忠告

现在我处理移动端需求的日常节奏是：早上新开对话，让AI读全局md，上午跑通主干功能，下午修编译错误和补边界测试，晚上自己过一遍代码，把新踩的坑追加到全局md里。这样一天下来，能完成过去两三天的工作量。但我也必须承认，vibe coding并没有让我变成“随时随地都能60倍速开发”的超人，它只是把身体的重复劳动变少了，脑力的判断要求反而更高。

最后一个忠告是关于心态的。如果你第一次尝试vibe coding就遇到了“AI生成了几百行不能用的代码”这类崩溃时刻，千万别急着给这个工作流判死刑。大概率是你还没有给它立好规矩、写好宪法。把全局md补完整、把需求拆得更细、把对话切得更短，再来一轮，你会发现同一个AI的表现完全不一样。这套方法论不需要高端算法，也不需要追新版本，它就是一套“你怎么和同事协作，就怎么和AI协作”的朴素逻辑。我用三个月证明它在移动端能走通，你也可以。