企业官网建设流程全解析

如果你在三年前的某个晚上，看到群里有人晒出自己用Cursor改完一个脚本的截图，你大概率不会想到，这玩意后来会彻底改变一小群个人开发者的生产方式。我就是那种最典型的样本：三年前下载 Cursor 完全出于顺手，当时我对App开发的理解，停留在“能改一点前端样式、但从来没有独立上架过任何应用”的阶段。三年之后，我的名下躺着 8 个已上架应用商店的 App，有的日活不高但稳定运行，有的帮我 cover 掉了服务器费用，还有两个已经停止维护——但无论如何，我确实靠“Cursor 辅助开发”这条路，走完了一个半路出家的人从 0 到上架的完整闭环。

这篇不打算给你画大饼，就讲我这几年的真实路径：怎么用 Cursor 写 App、怎么踩坑、怎么过审、哪些环节 AI 真的靠谱、哪些环节它一定会坑你。无论你是完全没写过代码的纯小白，还是写过几年业务代码但没独立上架过产品，这篇文章应该都能给你一些可以直接拿来用的思路。

1. 一个“半路出家”的人，是怎么靠 Cursor 做出 8 个 App 的

1.1 三年前的起点：会改别人代码，但写不出一整个项目

先交代一下背景。三年前我在一家不需要写代码的岗位工作，日常最多用 Python 处理点 Excel 表格，对前端三大件的了解停留在“能看懂、能复制粘贴改颜色”的级别。那时候看到 Cursor 的推荐，第一反应是“又一个套壳的编辑器”，下载完全是因为它免费，而且网上说能直接和 AI 对话改代码，听起来省事。

真正让我意识“这次不一样”的，是第一周我用它写了一个本地的小工具脚本：需求是我每天要整理某个报表，重复操作恶心到不行。我给 Cursor 描述需求，它给我生成了一段代码，我复制运行，居然跑通了。那一瞬间我突然意识到：以前我一个月都憋不出一个能运行的东西，现在我只需要把需求说清楚，剩下的 AI 可以帮我完成一大半。

这个起点很关键，它决定了我后面用 Cursor 的姿势——不是把它当“高级补全工具”，而是把它当“一个能把需求变成代码的实习生组长”。说得难听一点，三年前的我写代码的水平，连实习生都算不上，所以只要 Cursor 能达到实习生的水平，对我来说就是巨大的杠杆。

1.2 Cursor 真正改变的不是写码速度，而是“试错成本”

很多技术圈的人喜欢讨论 Cursor 和别的 AI 编程工具谁补全更准、谁上下文更长，我觉得这些对个人开发者来说都不是核心。核心在于：Cursor 把“从想法到能运行的代码”这条路的成本，压到了几乎可以随便试的程度。

以前我脑子里冒出一个 App 想法，第一反应是“要学这个、要学那个”，三分钟热度很快会被现实浇灭。现在我的反应是“先让 Cursor 给我生成一个最小的 Demo 看看”。一个 Demo 不行就换个思路，反正生成一次的成本几乎为零。这种心态上的变化，比任何生产力工具都重要。

我自己统计过，三年里用 Cursor 写得最多、迭代最快的项目，全是最先“让 AI 搭一个能跑的最小版本”，然后在这个基础上一点点加功能。反过来，那些一上来就想“把所有功能想清楚再动手”的项目，几乎全烂尾了。因为 App 开发里的很多问题，只有在你真正打开一个能运行的工程、在模拟器里点两下之后，才会暴露出来。想是想不明白的，你得先跑起来。

1.3 8 个 App 的定位：在小需求里做减法

很多人会问我：你做了 8 个 App，是不是都是那种“一个按钮发通知”的玩具？我不否认有几个确实很小，但恰恰是这些“小”救了它们。

我复盘过这 8 个 App 的共同点：

• 单一需求，目标明确。比如“批量生成二维码”“喝水打卡”“极简计算器”“本地网速测速”，没有一个是“一站式”的大平台。
• 工具属性优先，不需要复杂的用户系统。不需要社交关系、不需要内容审核、不需要实时推送，只要用户打开能用就行。
• 两周内能上线第一版。凡是我判断要做一个月的，基本都没做出来。

这个策略说起来有点反直觉，但对于个人开发者，尤其是靠 AI 辅助开发的个人开发者来说，**“小”不是妥协，是生存策略。**因为你的维护精力有限，你的排错能力有限，你更没有运营团队帮你做冷启动。与其做一个大而全的产品然后卡在上架或者更新路上，不如做一堆小而准的工具，每个都能独立存活，哪怕某个挂了也不影响整体。

这 8 个 App 里，表现最好的其实是一个我当时最看不上的“二维码批量生成”工具。它没有什么技术含量，但它是真的被人用、真的被人搜到。后来我总结出一个规律：个人开发者最该碰的，不是那些看起来很酷但需要大量运营支撑的需求，而是那些“用户搜到这个关键词，下载下来，用完就走”的刚需。这类需求不需要用户留下来，所以你也不需要开发复杂的后端。

2. 用 Cursor 做 App 的完整流程：从想法到上架的每一步

2.1 先聊清需求：把想法拆成“人能执行、AI 能生成”的颗粒度

很多人第一次用 Cursor 写 App 的体验很差，原因不是 Cursor 不行，而是他描述需求的方式，AI 根本无从下手。比如一上来就写“帮我做一个记账 App”，信息量大到任何模型都会懵，生成出来的东西要么是一堆骨架代码，要么就是看着能用但一编译全是错误。

我的做法是，先自己做一道“需求拆解”的题。拿“记账 App”举例，我不会直接让 Cursor 写，而是先在心里把它拆成这些可以独立描述的子任务：

1. 先做一个底部 Tab 页面，分别是“账单”“统计”“我的”三个标签页。
2. 在“账单”页做一个列表，展示每笔记录的金额、分类、时间。
3. 做一个新增记录的弹出框，包含金额输入框、分类选择器、备注输入框。
4. 用本地数据库保存记录，App 重启之后数据不丢。
5. 在“统计”页按月份做一个简单的柱状图。

每个子任务都是一个可验收的颗粒度。描述到这个程度，AI 才能生成真正能跑的代码。我自己有个经验：如果你没法把需求拆成 5 到 10 个这种子任务，说明你还没想清楚这个 App 到底该怎么做，这时候别急着让 Cursor 写，先继续想。

2.2 代码生成阶段：让 Cursor 动手之前，先把规则说清楚

确定子任务之后，我会在 Cursor 里面建一个项目，然后用对话的方式开始写代码。这里有一个很重要的习惯：不要每次只丢一句话让 AI 自己猜，而是先给它“角色 + 语言 + 框架 + 目录 + 文件路径 + 功能描述 + 验收标准”。

我常用的提示词模板大概是这样的（以 Flutter 为例）：

你是一名 Flutter 开发工程师，请帮我实现一个页面：登录页。 要求： 1. 页面文件放在 lib/pages/login_page.dart 2. 使用 Provider 做状态管理 3. 用户名和密码输入框，带基础校验：用户名不能为空，密码长度不能少于6位 4. 包含一个“登录”按钮，点击后调用 AuthService.login() 方法 5. 生成代码中全部使用中文注释 6. 请告诉我哪些地方需要我手动补充配置

这个模板看着啰嗦，但它能很大概率避免“AI 给你自由发挥、结果和你项目其它代码完全对不上”的问题。尤其是“文件路径”这一条，很多新手会忽略，结果 AI 在某个奇怪目录下生成一个页面，你 import 的时候一脸懵。

另外，一定要养成“一次只做一件事”的习惯。让 Cursor 把一个页面从 0 到 1 写完，是 OK 的；但让 Cursor“顺手把登录逻辑也写了、把数据库表也建了、把网络请求也封装了”，生成出来的东西大概率是一锅粥。AI 生成代码的质量，和你下指令的颗粒度强相关。你给它越清晰的边界，它给你的就越可控。

2.3 调试和改 Bug：让 AI“先解释、后动手”

代码写出来之后，真正的挑战才开始。我用 Cursor 三年，最想分享给新手的经验是：报错信息不要自己硬读，也不要直接复制给 AI 让它“直接改”，而是先让它解释原因。

我习惯的流程是这样的：把报错信息贴给 Cursor，然后加一句“先别改代码，请告诉我这个报错的原因是什么，可能涉及哪几个文件，我确认之后再给修改方案”。很多时候，AI 的解释会让你发现根本不是代码问题，而是环境问题、依赖版本问题或者 key 配错的问题。如果不加这句话，AI 往往会“自作聪明”地给你的代码打补丁，结果就是按下葫芦浮起瓢，改了三处地方，报错从 A 变成 B。

我还碰到过一种很头疼的情况：AI 为了“修复”一个界面小 bug，把一大段相关逻辑全都重构了。从那以后，我每次让 Cursor 改代码都会加一句“尽量只改必要的地方，不要动无关代码”。这句话简直是我的保命符。

注意：对任何一个 AI 编程工具，都要把它当成一个“有想法的实习生”，而不是搜索引擎。它会犯错，它会在你不知道的地方偷偷改东西。你必须给它明确边界，并且经常检查它到底动了哪些文件。

2.4 版本管理与工程化：别让 AI 代码变成一坨“一次性面条”

这是我踩过最大的坑，没有之一。

前两个 App 我完全没有用版本管理，全靠 Cursor 改完就接着往下写。结果某天 AI 在一次重构里把整个项目的依赖配置搞乱了，我花了整整一个周末都没恢复，最后只能推倒重来。从第三个 App 开始，我老老实实把 Git 用起来，规则也极其简单：

• 每个功能开发前，先创建一个新分支。
• AI 每一次“较大规模改动”完成、并且能编译通过之后，就提交一次。
• 提交信息写得清楚一点，比如“feat: 新增账单列表页”，方便以后回滚。
• 如果 AI 越改越乱，直接git checkout .回到上一次能运行的状态，重新来。

这套流程看起来是常识，但对一个刚接触编程的人来说，很容易觉得“反正代码不是我写的，先跑起来再说”。实际上，AI 时代版本管理的重要性不是变低了，而是变高了，因为 AI 改坏代码的概率，比你手写改坏的概率高多了。没有版本管理，你就是在裸奔。

除了 Git，我还会定期检查工程里的依赖版本和目录结构。Cursor 在生成代码时，偶尔会把一些不该提交的文件塞进来，或者把应该在配置文件里的东西写死在代码里。这些都是隐患，能早发现就早发现。

3. 八个 App 背后的技术选型、审核避坑与常见报错

3.1 技术栈怎么选：为什么我选了 Flutter 而不是三套原生代码

个人开发者做一个 App，第一个要面对的问题就是：做什么平台？我的答案很简单：能做跨平台就一定做跨平台。

我前后试过 React Native 和 Flutter，目前主力是 Flutter。理由很实际：

• 一套代码同时出 Android 和 iOS，省下的是整整一倍的开发量。
• Flutter 的 UI 写法相对直观，尤其适合让 AI 生成界面代码，因为它本质上就是用 Dart 描述“这个页面长什么样”。
• 出问题的时候，社区资料多，AI 训练数据里相关代码也足够多，生成出来的代码质量更稳。

当然，跨平台框架不是没有代价。它打包出来的安装包体积比原生大一些，某些靠硬件交互特别深的功能（比如协议级蓝牙）会比较折腾。但对我来说，这些代价和“省掉一套代码”的收益相比，完全值得。

注意：如果你做的 App 没有 iOS 证书，或者暂时没条件注册 iOS 开发者账号，也可以先只上 Android 市场。等验证需求之后再做 iOS，这时候因为核心代码是同一套，工作量也不会太大。我自己就有两个 App 是先安卓后苹果的，整个适配过程比想象中顺利。

3.2 上架审核的重点检查项：权限、隐私、图标与截图

代码写完、本地能跑，只是万里长征第一步。真正让“8 个上架 App”这个数字变得有分量的，是上架审核这一关。说实话，我前两个 App 被拒的次数加起来比后面六七个都多。

我整理过一套自己的“上架前检查清单”，照着过一遍，被拒概率会低很多：

每次提交新版本前，我会把这份清单过一遍，基本能做到一次通过。但我还是想提醒一句：每个平台的审核标准都在变化，上架之前最好去官方文档和开发者论坛里看一眼最新动态，别只看老教程。

3.3 常见报错排查速查表：从 app is not defined 到环境变量

用 Cursor 开发三年，我见过最多的 AI 生成代码问题其实不是逻辑问题，而是“运行环境类”问题。这些问题看起来吓人，但大部分都有固定的排查套路。下面是我整理的一个速查表，遇到类似问题可以直接照着查。

另外一个看起来很小但特别容易卡住的情况：模拟器里一切正常，一到真机就崩。这种基本可以排查内存、权限、网络地址这三类问题。我前几个 App 都是只做了模拟器测试，结果真机一打开就闪退，后来养成了“每个功能都在真机跑一遍”的习惯；真机调试不完全是为了测性能，更是为了测权限和网络环境。

3.4 免费额度不够用怎么办：把提问拆碎、把重复工作交给模板

很多刚接触 Cursor 的人都会问一个问题：免费额度用完了怎么办？我的答案可能和很多人想的不一样：别急着充钱，先反思自己是不是在浪费额度。

我观察到的“额度杀手”主要有三种：

• 把一大段项目源码直接贴进对话，让 AI 通读后再改一个很小的点。这种非常费 token，而且大部分上下文根本用不上。
• 同一个问题反复问。AI 回答不满意，什么都不调整，换个问法继续问。其实改一下约束条件往往一次就过。
• 让 AI 从 0 到 1 生成一个完整大项目。生成出来的东西又长又不一定符合预期，反复改几次额度就空了。

我的应对策略是：

1. 需要 AI 理解整个项目的时候，让它先读关键文件夹结构，不要一次贴几十个文件。
2. 遇到不满意的结果，先想想是“需求描述不清”还是“代码确实有 bug”，针对性地调整提示词，而不是原样重问。
3. 把常用、重复的场景做成自己的模板。比如“帮我新写一个 Flutter 页面”这套模板，我优化过好几版，现在无论生成什么页面，都能一步到位。

注意：不要在对话里粘贴任何密钥、密码、隐私数据，也不要让 AI 把生产环境的配置项写到代码里。Cursor 的对话记录和云服务策略一直在变化，你无法保证所有内容完全不被留存。涉及敏感信息，一律手动处理。

我在开发第 5、6 个 App 的时候，还试过用 Cursor 顺带处理后端服务。比如有一个小工具需要简单的云端同步，我让它基于 Django 生成了一整套用户注册、登录和同步数据的接口。这个经历告诉我：Cursor 不只适合写 App 前端，它也可以帮你把一个简单后端快速搭起来，前提是你自己得知道你在干什么，出了错能看懂日志。

4. Cursor 的边界：这 8 个 App 之后，我开始区分“能写”和“该写”

4.1 哪些项目不适合交给 AI

我可以很负责任地说，这几年我也有过用 Cursor 写“看起来很复杂”项目然后崩溃的经历。不是能力不够，而是有些项目的核心价值在于“长期维护架构的稳定性”，AI 在这类事情上帮不了你。

具体来说，三类项目不适合完全依赖 AI：

第一类是实时性要求极高、质量要求极严的系统，比如支付核心、即时通讯底层、音视频编解码相关。这类代码错误代价极高，AI 生成的代码你不敢直接上生产。

第二类是业务逻辑特别复杂、状态多到爆炸的管理系统。AI 生成的代码在初期很爽，但到了后期，你会发现它自己生成的代码连自己都看不懂，改一行可能引发三个隐藏 bug。

第三类是严重依赖线下硬件或特定环境的项目。比如要用 App 直接和某款硬件通过协议通信，这种项目调试排障需要大量经验，AI 给不了你现场的判断力。

我的判断标准很简单：**如果一个功能我自己想不出清晰的验收标准，那就不适合交个 AI。**AI 只能帮你实现你已经想明白的东西，不能帮你做出你压根看不懂的决策。

4.2 零基础用户真正要练的，不是背语法，是“拆需求”

总有人问我：零基础想学 App 开发，是不是该先学两个月的 Python 或者 JavaScript 再来用 Cursor？我的答案是不需要。以我的经验，AI 编程工具真正考验你的，不是你会不会写代码，而是你会不会把“想要的东西”讲清楚。

打个比方。你去餐厅点菜，说“来点好吃的”，厨师再厉害也不知道该给你做什么。但你说“来一份辣子鸡，少放盐，多放花生米，不要太辣”，厨师就知道怎么做了。跟 Cursor 打交道也是这个道理：你能拆出一份足够具体的“需求订单”，它就能给你做出八九不离十的菜。

那怎么练拆需求呢？我有个笨办法：随便打开一个你手机里常用的 App，把它的某个页面当成“需求”，试着用文字把它描述出来。比如打开一个天气 App，把首页拆成“顶部城市名、中间当前温度、下方未来 7 天列表、背景色根据温度变化”。这种练习做多了之后，你再让 Cursor 去写页面，会觉得特别顺。

所以，与其焦虑自己不会写代码，不如先练怎么“像产品经理一样思考”。洞察需求、定义需求、验证需求，这些能力在 AI 时代比写语法重要得多。

4.3 上架只是开始：维护、反馈、迭代是另一道题

8 个 App 上架之后，你并不会迎来“躺着收钱”的时刻，而是进入另一种更琐碎的生活：要关注用户的评价，要修复新版本带来的兼容问题，要处理一些莫名其妙的 1 星差评。

我第一次收到差评的时候心里很难受，后来想通了：有人愿意花时间打差评，说明他们真的用了你的产品。差评里最宝贵的信息是“用户到底卡在哪了”。我有一个 App 更新之后收到好几条“闪退”反馈，但我自己怎么测试都没事，后来才发现是某些系统版本下的权限弹窗处理逻辑有问题。这种问题，没有真实用户反馈，我永远不会发现。

所以我现在的做法是：每个 App 都留一个非常简单的反馈入口，哪怕只是一个邮件地址。上架不是终点，它是一个永久的责任。你要决定自己的精力分配给谁，哪些 App 继续维护、哪些停更下架。8 个 App 听起来很多，但如果全部都要长期维护，其实压力不小。

4.4 最后一个忠告：把“用 AI 做产品”本身当技能来练

写到这儿，我想把最实在的经验放在最后。铅笔出现之后，会写字的人没有消失，但不会写字、不练表达的人被淘汰了；计算器出现之后，会算账的人没有消失，但连基本数感都没有的人变少了。AI 编程工具也是一样，它不会让“开发者”这个角色消失，但它会重新定义“谁能成为开发者”。

我身边有不少人下载了 Cursor，试了两天，让 AI 生成一个计算器 Demo，跑通了，然后就没有然后了。为什么？因为“让 AI 生成一个 Demo”和“让 AI 产出一个能上架、能维护、能接受用户反馈的产品”之间，隔着巨大的一段路。这段路包括需求判断、工程管理、审核合规、问题排查、产品迭代，这些能力没有任何一个工具能替你学会。

三年过去，我依然写不出特别优雅的算法，依然会在看到复杂报错时心里一紧。但我不再害怕“写代码”这件事了，因为我知道有一条可行的路径能让我抵达目标。如果你也想像我一样，从一个随手下载开始，做出自己第一个上架的应用，我最真诚的建议是：不要等所有东西都学好了再动手，就像我当初一样，先让 Cursor 帮你搭一个最丑但能跑的 Demo，然后从那个点开始，一遍一遍地改下来。你会在这条路上，长成你以前不敢想的样子。