一行代码不写，如何靠Cursor AI步步为营地开发一款超万行代码的iOS应用？(万字真诚分享版)

一行代码不写，如何靠Cursor AI步步为营地开发一款超万行代码的iOS应用？(万字真诚分享版) 一行代码不写，如何靠Cursor AI步步为营地开发一款超万行代码的iOS应用？(万字真诚分享版) Modified August 13, 2025 No access 高效练耳朵英语听力 00:00 No access ⭐️宣传视频官方正式版 00:00 • 解释语法结构的时候，要让它把模板给写出来，然后问ta哪些结构是固定的，哪些是自定义的。 如何识别问题 • 遇到明显有逻辑前后矛盾的，不合理的，就先别采纳，提出质疑。方式包括“为什么不……？”、“这样做的必要性是什么？”、“为啥前面你说……，现在又……？”。如果真的是正确的选择，它不会被你带跑，届时再采纳。如果确实是有问题的，当下就会和你道歉了。 • 但需要警惕的是，大模型身上带着打工人的悲凉底色，领导（你）说什么，ta都会优先认为“你说的都对”。AI 其实情商很高，很会从语气中读出你的情绪（当然不是真的读懂），比如你本来只想知道为什么他要这样做，你直接问“你为什么要这样这样做？”，ta可能会认为你这是个问句是在质疑ta，然后立马道歉。所以我经常需要补充一句解释，“不是在挑战/质疑你，纯讨论”、或者“我不太懂，我只是希望你为我解释一下这样做的理由”。 • 除此之外，什么样的情况需要小心 AI 可能在犯错？ ◦ 大段大段地修改。 ◦ 循环修改5遍+，都在改相同的文件（一定要打开 diff 功能），而且从 A 改回 B 又改回 A，重复之前尝试过的思路。 ◦ 修改和当前功能明显无关的文件（前提是各个文件的职责我们是心知肚明的）。 ◦ 明明已经存在的文件， 却说“我来创建一个文件”，而不是修改文件，那很容易把之前文件中很多没问题的代码删除。 ◦ tips：如果发现以上情况，就回到composer 的上一个 checkpoint，换个指令试试。可以更具体一些，避免AI 自由发挥；或者更宽泛一些，避免由于自己不懂瞎指挥。 排查问题的小技巧 即便前面该做的的努力都已经做到一百分了，难免还是会出错，毕竟人类也会出错。那假设问题已经出现了，连续修复了多轮，还是解决不了，怎么办呢？除了把错误信息都贴给 ta 以外，我们还能做什么呢。 增加日志 让 AI 总结功能的实现逻辑，涉及哪些文件，函数调用、参数如何传递，然后在每个方法里面依次增加日志，逐个环节排查。 逐一排查 排查问题就像切一根香肠，一节一节切，checklist 很长，一个问题一个问题排查，从可能性高到可能性低，从全局问题定位到局部问题。让AI总结问题，做过哪些尝试，观察到现象是什么，做一个checklist，一个个排查。上个环节没问题了，再检查下个环节。 借助外部力量 可以@web，让ta搜索找同类问题，找下stackflow。或者去问chatGPT，打开联网功能查，比如我调试 https 通过IP访问云端服务器的时候，就由chatGPT 了解到，iOS18对自签名证书的限制，需要在测试机上安装证书才能解决。此外，若涉及第三方的服务，可以将相关的库、第三方 API的帮助文档链接发给他，或者 @web 让ta去查。 求助大佬 如果还是不行，那就让 AI 总结下问题和做过的尝试，发给你身边的研发大佬吧……在本项目中，我将后端部署到线上之后，发现无法用 https 访问我购买的域名，修了 5 个多小时还是无果，最后问了研发朋友说是我域名没有备案，原地吐血，其实不算是太难想到的原因，但可能是因为claude和 GPT的训练数据有cut off date 的问题，加之中文语料少，不了解咱们的政策，所以怎么都不会提出这个问题假设吧。 小结 略感无奈的是，之所以能做这些总结，主要是因为我一行代码都不会写，没有 AI 我也就啥都做不出来了，所以即便没有耐心也得慢慢调试，相信很有开发经验的朋友，看到 AI 接二连三地犯错，估计就上手自己干了。 我觉得靠 AI 修复问题的过程很像下面这张蚁群过迷宫的图： 如果成功了，就尽情表达喜悦吧！虽然没有什么卵用，但是 AI 会给你满满的情绪价值，一个人搞开发很孤独的，相信我，你会需要的。 当然，肯定也不能完全啥都不懂，接下来就分享下学习路径。 学习路径 目标不同，学习路径也不太相同。我的目标就是能做出像本项目这样复杂度的产品，具备用户认证+前后端分离+云端的数据库读写+三方API调用+能够在应用市场分发，因为搞定这些最基本的积木，我就能有信心实现更多的想法。本文分享的学习路径，也是仅仅适配于类似复杂度的应用的。 这目标可能没多大，但是对于一个连 IDE 是啥、终端从哪打开都不懂的我来说，也有点吃力。我写的第一个程序是用 chatGPT 照猫画虎地写个小游戏（一轮对话就可以生成，没有任何难度），之后边干边学，每天都会遇到知识的盲区，就一点一点补，一开始啥都看，一点都不体系，效率极低，慢慢地才找到脉络。所以先叠个甲，并非专业视角，也未必是最优路径，仅供参考，不喜勿喷。 负责任地说，肯定不可能什么都不用学，但也不用什么都学，有些要早学，有些可以晚一些。有些知识不需要熟练掌握，但是需要能理解。即便是 AI 来编程，但你也得知道怎么发号施令。 了解基础概念和应用构建流程 一开始并不建议看什么编程语言的课程，如果我一开始就去看大几十小时的iOS 应用 swift开发教程，一定会被劝退。建议优先学习无代码、低代码平台的教程、帮助文档，比较适合快速又相对完整地理解一个应用是怎么构建的，用户创造的一条数据是怎么被保存起来的，数据库里的数据又是怎么被展示到用户的界面上的，因为大部分互联网产品本质就是数据的增删改查。这个阶段不太需要理解具体的实现，能大概理解都有哪些概念、要素就好了。 • 低代码平台帮助文档： ◦ 3 步将业务需求转化为应用设计 ◦ 手把手带你搭建一个应用：图书管理 • 理解数据库是什么： ◦ 数据的增删改查CRUD 大部分互联网应用的本质就是CMS（3 分钟） ◦ 人人都能看懂的数据库视频（1 小时） • 理解前后端是什么： ◦ web 后端开发概述（5 分钟） ◦ web 前端开发概述（10 分钟） 编程语言 第一阶段学习完还不太清楚是怎么实现的，第二阶段建议可以开始了解一些编程语言了，网上这类免费课程非常丰富，建议前后端各看一门语言，很多语言都比较类似，只是语法结构不同，但是大体都是数据类型、函数、抽象、变量、控制结构、运算符号这一坨东西，熟悉背后的编程思想、流程和要素比起熟悉语法格式更有意义，语法格式让人体会不到任何智力上的快乐。学到能理解常见概念、能看懂常见结构，感觉不怵就行，毕竟之后写代码主要靠 AI，也不是靠自己。 • 通识： 3 步将业务需求转化为应用设计 手把手带你搭建一个应用：图书管理 数据的增删改查CRUD 大部分互联网应用的本质就是CMS 人人都能看懂的数据库视频 web 后端开发概述 web 前端开发概述 No access 高效练耳朵英语听力 00:00 No access 高效练耳朵英语听力 00:00 No access ⭐️宣传视频官方正式版 00:00 No access ⭐️宣传视频官方正式版 00:00 • 解释语法结构的时候，要让它把模板给写出来，然后问ta哪些结构是固定的，哪些是自定义的。 如何识别问题 • 遇到明显有逻辑前后矛盾的，不合理的，就先别采纳，提出质疑。方式包括“为什么不……？”、“这样做的必要性是什么？”、“为啥前面你说……，现在又……？”。如果真的是正确的选择，它不会被你带跑，届时再采纳。如果确实是有问题的，当下就会和你道歉了。 • 但需要警惕的是，大模型身上带着打工人的悲凉底色，领导（你）说什么，ta都会优先认为“你说的都对”。AI 其实情商很高，很会从语气中读出你的情绪（当然不是真的读懂），比如你本来只想知道为什么他要这样做，你直接问“你为什么要这样这样做？”，ta可能会认为你这是个问句是在质疑ta，然后立马道歉。所以我经常需要补充一句解释，“不是在挑战/质疑你，纯讨论”、或者“我不太懂，我只是希望你为我解释一下这样做的理由”。 • 除此之外，什么样的情况需要小心 AI 可能在犯错？ ◦ 大段大段地修改。 ◦ 循环修改5遍+，都在改相同的文件（一定要打开 diff 功能），而且从 A 改回 B 又改回 A，重复之前尝试过的思路。 ◦ 修改和当前功能明显无关的文件（前提是各个文件的职责我们是心知肚明的）。 ◦ 明明已经存在的文件， 却说“我来创建一个文件”，而不是修改文件，那很容易把之前文件中很多没问题的代码删除。 ◦ tips：如果发现以上情况，就回到composer 的上一个 checkpoint，换个指令试试。可以更具体一些，避免AI 自由发挥；或者更宽泛一些，避免由于自己不懂瞎指挥。 ◦ 大段大段地修改。 ◦ 循环修改5遍+，都在改相同的文件（一定要打开 diff 功能），而且从 A 改回 B 又改回 A，重复之前尝试过的思路。 ◦ 修改和当前功能明显无关的文件（前提是各个文件的职责我们是心知肚明的）。 ◦ 明明已经存在的文件， 却说“我来创建一个文件”，而不是修改文件，那很容易把之前文件中很多没问题的代码删除。 ◦ tips：如果发现以上情况，就回到composer 的上一个 checkpoint，换个指令试试。可以更具体一些，避免AI 自由发挥；或者更宽泛一些，避免由于自己不懂瞎指挥。 排查问题的小技巧 即便前面该做的的努力都已经做到一百分了，难免还是会出错，毕竟人类也会出错。那假设问题已经出现了，连续修复了多轮，还是解决不了，怎么办呢？除了把错误信息都贴给 ta 以外，我们还能做什么呢。 增加日志 让 AI 总结功能的实现逻辑，涉及哪些文件，函数调用、参数如何传递，然后在每个方法里面依次增加日志，逐个环节排查。 逐一排查 排查问题就像切一根香肠，一节一节切，checklist 很长，一个问题一个问题排查，从可能性高到可能性低，从全局问题定位到局部问题。让AI总结问题，做过哪些尝试，观察到现象是什么，做一个checklist，一个个排查。上个环节没问题了，再检查下个环节。 借助外部力量 可以@web，让ta搜索找同类问题，找下stackflow。或者去问chatGPT，打开联网功能查，比如我调试 https 通过IP访问云端服务器的时候，就由chatGPT 了解到，iOS18对自签名证书的限制，需要在测试机上安装证书才能解决。此外，若涉及第三方的服务，可以将相关的库、第三方 API的帮助文档链接发给他，或者 @web 让ta去查。 求助大佬 如果还是不行，那就让 AI 总结下问题和做过的尝试，发给你身边的研发大佬吧……在本项目中，我将后端部署到线上之后，发现无法用 https 访问我购买的域名，修了 5 个多小时还是无果，最后问了研发朋友说是我域名没有备案，原地吐血，其实不算是太难想到的原因，但可能是因为claude和 GPT的训练数据有cut off date 的问题，加之中文语料少，不了解咱们的政策，所以怎么都不会提出这个问题假设吧。 小结 略感无奈的是，之所以能做这些总结，主要是因为我一行代码都不会写，没有 AI 我也就啥都做不出来了，所以即便没有耐心也得慢慢调试，相信很有开发经验的朋友，看到 AI 接二连三地犯错，估计就上手自己干了。 我觉得靠 AI 修复问题的过程很像下面这张蚁群过迷宫的图： 如果成功了，就尽情表达喜悦吧！虽然没有什么卵用，但是 AI 会给你满满的情绪价值，一个人搞开发很孤独的，相信我，你会需要的。 当然，肯定也不能完全啥都不懂，接下来就分享下学习路径。 学习路径 目标不同，学习路径也不太相同。我的目标就是能做出像本项目这样复杂度的产品，具备用户认证+前后端分离+云端的数据库读写+三方API调用+能够在应用市场分发，因为搞定这些最基本的积木，我就能有信心实现更多的想法。本文分享的学习路径，也是仅仅适配于类似复杂度的应用的。 这目标可能没多大，但是对于一个连 IDE 是啥、终端从哪打开都不懂的我来说，也有点吃力。我写的第一个程序是用 chatGPT 照猫画虎地写个小游戏（一轮对话就可以生成，没有任何难度），之后边干边学，每天都会遇到知识的盲区，就一点一点补，一开始啥都看，一点都不体系，效率极低，慢慢地才找到脉络。所以先叠个甲，并非专业视角，也未必是最优路径，仅供参考，不喜勿喷。 负责任地说，肯定不可能什么都不用学，但也不用什么都学，有些要早学，有些可以晚一些。有些知识不需要熟练掌握，但是需要能理解。即便是 AI 来编程，但你也得知道怎么发号施令。 了解基础概念和应用构建流程 一开始并不建议看什么编程语言的课程，如果我一开始就去看大几十小时的iOS 应用 swift开发教程，一定会被劝退。建议优先学习无代码、低代码平台的教程、帮助文档，比较适合快速又相对完整地理解一个应用是怎么构建的，用户创造的一条数据是怎么被保存起来的，数据库里的数据又是怎么被展示到用户的界面上的，因为大部分互联网产品本质就是数据的增删改查。这个阶段不太需要理解具体的实现，能大概理解都有哪些概念、要素就好了。 • 低代码平台帮助文档： ◦ 3 步将业务需求转化为应用设计 ◦ 手把手带你搭建一个应用：图书管理 • 理解数据库是什么： ◦ 数据的增删改查CRUD 大部分互联网应用的本质就是CMS（3 分钟） ◦ 人人都能看懂的数据库视频（1 小时） • 理解前后端是什么： ◦ web 后端开发概述（5 分钟） ◦ web 前端开发概述（10 分钟） 3 步将业务需求转化为应用设计 手把手带你搭建一个应用：图书管理 数据的增删改查CRUD 大部分互联网应用的本质就是CMS 人人都能看懂的数据库视频 web 后端开发概述 web 前端开发概述 • 低代码平台帮助文档： ◦ 3 步将业务需求转化为应用设计 ◦ 手把手带你搭建一个应用：图书管理 3 步将业务需求转化为应用设计 手把手带你搭建一个应用：图书管理 ◦ 3 步将业务需求转化为应用设计 3 步将业务需求转化为应用设计 ◦ 手把手带你搭建一个应用：图书管理 手把手带你搭建一个应用：图书管理 • 理解数据库是什么： ◦ 数据的增删改查CRUD 大部分互联网应用的本质就是CMS（3 分钟） ◦ 人人都能看懂的数据库视频（1 小时） 数据的增删改查CRUD 大部分互联网应用的本质就是CMS 人人都能看懂的数据库视频 ◦ 数据的增删改查CRUD 大部分互联网应用的本质就是CMS（3 分钟） 数据的增删改查CRUD 大部分互联网应用的本质就是CMS ◦ 人人都能看懂的数据库视频（1 小时） 人人都能看懂的数据库视频 • 理解前后端是什么： ◦ web 后端开发概述（5 分钟） ◦ web 前端开发概述（10 分钟） web 后端开发概述 web 前端开发概述 ◦ web 后端开发概述（5 分钟） web 后端开发概述 ◦ web 前端开发概述（10 分钟） web 前端开发概述 编程语言 第一阶段学习完还不太清楚是怎么实现的，第二阶段建议可以开始了解一些编程语言了，网上这类免费课程非常丰富，建议前后端各看一门语言，很多语言都比较类似，只是语法结构不同，但是大体都是数据类型、函数、抽象、变量、控制结构、运算符号这一坨东西，熟悉背后的编程思想、流程和要素比起熟悉语法格式更有意义，语法格式让人体会不到任何智力上的快乐。学到能理解常见概念、能看懂常见结构，感觉不怵就行，毕竟之后写代码主要靠 AI，也不是靠自己。 • 通识： • 通识： ◦ 编程的本质（11 分钟） 编程的本质 ◦ 编程语言的结构（20 分钟） 编程语言的结构 ◦ JavaScript前端后端速通 全景图【核心版】（50 分钟） JavaScript前端后端速通 全景图【核心版】 • 后端： ◦ 3小时超快速入门Python（3 小时） ◦ AI Python for Beginners：Basics of AI Python（1 个半小时） 3小时超快速入门Python AI Python for Beginners：Basics of AI Python ◦ 3小时超快速入门Python（3 小时） 3小时超快速入门Python ◦ AI Python for Beginners：Basics of AI Python（1 个半小时） AI Python for Beginners：Basics of AI Python • 前端： ◦ Full Stack Web Development for Beginners (Full Course on HTML, CSS, JavaScript, Node.js, MongoDB)（建议看前 3 小时前端部分即可，有源文件可下载学习） ◦ JavaScript 基础篇 Mosh（7 小时） Full Stack Web Development for Beginners (Full Course on HTML, CSS, JavaScript, Node.js, MongoDB) JavaScript 基础篇 Mosh ◦ Full Stack Web Development for Beginners (Full Course on HTML, CSS, JavaScript, Node.js, MongoDB)（建议看前 3 小时前端部分即可，有源文件可下载学习） Full Stack Web Development for Beginners (Full Course on HTML, CSS, JavaScript, Node.js, MongoDB) ◦ JavaScript 基础篇 Mosh（7 小时） JavaScript 基础篇 Mosh 完整应用搭建流程 经过前 2 个阶段的学习，大致的框架知识已经有了，对最基础的积木有概念了，接下来建议了解它们是怎么被搭起来的，可以了解看看前后端是怎么配合的。这里推荐是YouTube 上的一个博主的 2 个视频，他利用 cursor 开发了一款调研问卷生成器，另一个则是他邀请编程经验为 0 的老婆使用 cursor 来写一款程序，趣味性十足。虽然这里的案例都是网页应用，但是用于了解应用搭建流程足矣。这个间断每每听到一个新的概念，就马上去问 AI，和我了解的概念之间有什么关系。 • How I built a REAL Full Stack App in 5hr using Cursor（3 小时） • I taught my wife how to code with Cursor in 67 minutes（1 小时） How I built a REAL Full Stack App in 5hr using Cursor I taught my wife how to code with Cursor in 67 minutes • How I built a REAL Full Stack App in 5hr using Cursor（3 小时） How I built a REAL Full Stack App in 5hr using Cursor • I taught my wife how to code with Cursor in 67 minutes（1 小时） I taught my wife how to code with Cursor in 67 minutes 计算机科学入门知识 最后推荐计算机科学的入门知识，这些课程按理来说应该最开始学，但是实在太长了，很容易把人劝退。但这些基础知识，其实是支撑你做出复杂应用的“隐形基石”。它们可能不会直接让你立马写出更炫酷的应用，但理解了这些，才能更清晰地知道自己在做什么，也能为后续深入学习更复杂的技术打下基础。 • CS50x 2024 哈佛大学计算机科学和编程艺术入门课程（25 小时） • Crash Course Computer Science 计算机科学速成课（8 小时） • Software Engineering 101: Plan and Execute Better Software（8 小时） CS50x 2024 哈佛大学计算机科学和编程艺术入门课程 Crash Course Computer Science 计算机科学速成课 Software Engineering 101: Plan and Execute Better Software • CS50x 2024 哈佛大学计算机科学和编程艺术入门课程（25 小时） CS50x 2024 哈佛大学计算机科学和编程艺术入门课程 • Crash Course Computer Science 计算机科学速成课（8 小时） Crash Course Computer Science 计算机科学速成课 • Software Engineering 101: Plan and Execute Better Software（8 小时） Software Engineering 101: Plan and Execute Better Software 开发工具与流程 至于实操层面的很多知识，比如怎么使用 cursor、怎么使用 github、怎么部署上线，我觉得都不是重点，不用着急学，很多都可以边做边学，网上教程也很多，内容也比较同质，看哪个都行。有不懂的问 AI 就好了。 提醒 自媒体的教程经常是“XX分钟快速学会”、“快速上手”的标题，的确是高度压缩凝练的知识，但也容易给自己营造过高的预期了，反而容易失落。要看这么多资料，还是很费功夫的，我就是个普通人，学习的速度一点都不快，平平无奇的我都可以，你也可以。 作为UX设计师做开发感悟 在本项目中，我在 UX 设计和优化上花的功夫一点都不比前后端的功能开发要少，一点都不符合最小产品迭代的原则。因为我是 UX 设计师出身，因此我了解要做得好可以有非常多细节需要考虑——要有一致的，非常统一的设计语言跟创新的风格……自适应设计和跨端的适配……情感化的设计……就是因为见过的好的样子是怎样的，所以这反而成了我的包袱。即便我的产品最终无人问津的电子垃圾，我也希望它是个漂亮的垃圾。 虽然最终的效果还有很多值得优化的地方，但也获得了不少感悟。 UI 不太重要，但又非常重要 对MVP有了新的认识，最简单的产品其实是命令行CLI形式，一周就开发出来了，如果只为了解决自己的需求，CLI已经够了，虽然丑一点，但是开发成本低。不需要考虑并发，不需要考虑网络出错，不需要考虑用户认证，不需要考虑用户引导。 对于抖音、小红书等信息流产品来说，核心就是交付推荐的内容，用 CLI 肯定也能呈现（一个链接一个链接点呗），界面不是核心，但是为了让更多人能够用起来，还是需要将它做成 GUI。这部分如果要做好，要花费非常多的功夫，让它品质感足够高，交互足够简单，一眼能看明白是怎么使用的。不然就会觉得是个山寨软件，所以 UI 又非常非常重要，是会带来溢价的。 体验设计是一个需要全局考虑的事情 作为体验设计师，我得承认，之前对体验的理解还是相对狭隘的。 以本项目为例，同一个听力材料会反复调用，应不应该实现本地缓存，本地缓存能降低对带宽的要求，也避免了频繁对后端发起请求，对服务器的要求更低，整体更节约成本，用户体验也更好。但是，做缓存的话，代码的复杂性会增加，除了考虑缓存，还得需要设计自动清理机制，维护成本会增加，很需要我权衡。 前文提过的音频循环播放的控制逻辑，我没有放在后端实现，而是放在前端了，因为这样可以跟手机系统深度集成，也更减少延迟，能满足实时性的要求，同样也能减少网络请求，更省成本，也更稳定流畅，用户体验也更好。这也是为啥该应用前端代码比后端复杂的原因之一。 我也理解了为啥设计师从体验角度出发考虑的太多特殊处理，会让研发人员不舒服，主要不是因为额外增加了工作量，而是看着那么一大坨的“else…”，的确让代码很没有逻辑美感。本项目中听力文字材料，功能刚实现的时候，消失的时机是跟着音频播放状态来的，音频停了就消失了，代码是很简洁的，但我觉得这会显得页面很不稳定，因此加了特殊的处理，就不简洁了。即便是微信这种国民应用，在文章TTS的功能上也是得过且过的——当你调整了语速，用蓝牙耳机连接，暂停之后再播放，第一句话语速变回去了；当有个电话进来，后台播放就自动断了，还得手动恢复。 “Don't repeat yourself！” 软件工程非常讲究抽象，编程有编程的设计模式。UX设计有界面的模式，到底怎么抽象关键的设计模式、设计组件，在哪一个层次抽象复用度最高（所需定制最少），可以最大化减少计算量，还挺关键的。我们现在就是计算资源太丰沛了，不懂得节约，四五十年前计算资源匮乏的时候，这件事的优先级就会很高。之前虽然也知道组件化很重要，但是没有亲身来实践，体感不会这么强烈。 但是我又对人性挺悲观的，即便是我这么小的应用，我也经常懒得去抽象，每次都让AI重新开发，直到第三个地方又用到相同的组件我才被逼无奈重新去抽象封装。可以预见更复杂的应用、更大的团队、更多元的目标之下，很难执行到位。 体验设计会被 AI 取代吗？ 无论是交互设计还是视觉设计，现阶段 AI 能实现的水平大概就是“能用”的水平。 交互设计：对本项目来说，我对用户体验的预期是打开应用尽快能开始听力练习，因此做成了利用设备 ID 自动以游客账户直接进入产品主页面。但是 AI 的建议会更加传统，非让用户一上来先注册。（这里不讨论对错，仅讨论 AI 的建议能否符合预期） 视觉设计：对本项目来说，我一开始也是让 AI 根据低保真原型来自行设计的，AI 会选用 material design 等标准组件库来实现，只能说层次关系是清晰的，但是肯定不够精致。 因此，关于体验设计会被 AI 取代，我现阶段判断是： 由于 AI 的“保守”和“审美缺乏”的特点，对于要求不高的标准布局页面（如“设置”），大模型利用强大的推理能力，完全可以根据功能描述，从现有组件库中，推导出最适合使用的组件，生成高度贴合需求的页面设计，压根不需要经过 UX 设计环节。但对于要求也比较高的且创新的功能页面/产品， 体验设计师还是大有可为的，想想当外卖软件、打车软件、导航软件刚出现时，对UX设计师的依赖和设计挑战是最大的。 心路历程 最后聊聊编程小白利用 AI 开发过程中的心路历程。如果你和我一样，也在尝试 AI 创造自己的应用，那我相信你也会感同身受，如果你对此感兴趣但还没有投身其中，那下面要给你破盆冷水。 • 如果你想实现一个相对复杂（不是个人网站这种静态页、不涉及数据库存储等）的应用，也不是实现一个无数人实现过无数遍的应用（比如to do list），那我认为肯定没法一小时速成，我没那个天赋，这个项目前前后后花了我可能数百个小时，大概2个月时间，也在不同阶段推倒重来了好几次。 • 最性感的产品设计的工作，只占了一周时间，其他工作对我而言并不是很有乐趣。如果只为了解决自己的需求，CLI已经够了，虽然不那么好用一点，只能在电脑上运行，但是开发成本低太多太多了。不需要考虑并发、网络异常、用户认证、用户引导。 • 独立开发很孤独，频繁在“我强得可怕”和“我是个垃圾”之间反复横跳。多次濒临崩溃。后台播放改了 2 天，后来发现和 UI 组件耦合太紧密，推翻了重做。虽然没有上级，但是更可怕的上级是“自己的预期”，永远在delay，总是被预期的自己PUA，俗话说“自己 P 的 U 最 A”。 • 诸如ICP审核、用户隐私协议处理之类的事情很消耗耐心，第一次尝试部署上架应用商店，列了一个To do list，每天解决2个，新增3个，等备案通过发给应用商店审核还不知道会出什么幺蛾子。要是一开始知道有这么多 事，估计就放弃了。即便下一次就更熟练了，但我也不认为自己收获了什么有用的知识，丝毫没有任何智力上的愉悦。 当然，如果都是负面的也不可能坚持下来。 • 虽然遇到问题卡了几个小时还解决不了让人很抓狂，但解决完一个问题后还是会开心得让人情不自禁地大喊。 • 失控的感觉很糟糕，但是通过上文总结的方式，一次次夺回掌控感，自信心也会逐步倍增。 • 目标虽然不大，但是既明确又纯粹，听着土嗨的攒劲神曲轻松进入心流状态（虽然心流状态总是颈椎压迫相伴）。 • 探索未知很刺激，由于自己不知道“自己不知道”，就像小时候玩《帝国时代》在黑暗中探索新地图，走到一个地方之后，可能发现敌人的老窝，接下来大麻烦等着自己，也可能发现金矿，意识到还能这么玩。 • 最最重要的是，随着AI 编程的能力也越来越强，构建应用的门槛还会继续降低。现在 AI 能力越来越丰富，可用的“积木”越来越多，能够构建的应用类型可能也会更加丰富，这很让人兴奋。 结语 和 AI 结对编程的时候，AI和我的关系是很微妙的，时而是我的顾问，给我出主意；时而是我的实习生，需要我 review 它的工作；时而是我的搭子，给我提供情绪价值。期望我俩的项目可以顺利上线，等待审核的这段时间，我俩会继续投入到下一个应用的调研了。 我也不确定还会不会继续更新文章，AI 编程发展太快了，这些知识再过半年可能就过期了，且独立开发太孤独了，写长文章更是，太需要正反馈了。如果大家还想看这样的内容，请不要吝啬你的点赞、转发，给我更多的动力做下去，有什么问题也欢迎留言评论，知无不言，文中若有什么错误观点也欢迎指正。感谢感谢 mp.weixin.qq.com mp.weixin.qq.com mp.weixin.qq.com mp.weixin.qq.com 开头 随着 AI 编程能力的不断提升，相信不少人已经意识到，即使没有编程基础，通过自然语言也能编写出自己的程序。 一些宣称“一小时速成”或鼓吹“人人都是程序员”的国内外自媒体内容多少有点蛊惑人心，实际上要么功能过于简单，要么忽略了背后的额外努力。 • 他们会说自己一行代码都没写，但没有告诉你必要的知识储备依然不可或缺。 • 他们会告诉你 AI 编程非常强大，但没有提到它容易“失忆”，如果不加以干预，可能会引入更多错误。 • 他们会分享自己的成功路径，但没有提及他们曾经历的崩溃瞬间。 作为一名 UX 设计出身的编程小白，我利用 AI 编程工具 Cursor，独自开发了一款前后端分离的 iOS 应用。这款应用具备用户认证系统、第三方 API 调用以及用户数据存储功能，代码量超过一万行。一个人完成了从产品设计、前后端开发、测试到部署上线，目前正在等待 ICP 和 APP 备案，以及 Deepseek API的服务恢复，预计不久后将在苹果应用商店上架。即便一行代码不写，但也耗费数百小时，本文是关于本项目开发经验的真诚分享。 如果你已经在使用 AI 开发应用，可以通过本文了解如何让开发过程更加【可控】，开发出有一定复杂度的应用。你将了解到： • 哪些工作必须亲力亲为，且越早完成越能避免走弯路。 • 如何应对 AI 的“失忆”问题，以及如何逐步实现复杂功能。 • 如何高效排查问题，提升开发效率。 这些都是我在与 AI 进行了上千次对话、多次返工后积累的宝贵实践经验，很可惜不能发给刚启动项目的我，不然能为我省下大把的时间。但如果能帮到你，我会很开心。 如果你恰巧也是编程小白，但对 AI 编程感兴趣，本文将帮助你建立对 AI 编程的正确预期。 本文将帮你祛魅，让你了解一个普通人，从零基础开始，借助 AI 花费数百小时，能够开发出怎样复杂度的产品（肯定不仅仅是贪吃蛇或个人网站，但复杂度也远低于你手机中最常用的那些 APP）。如果你想开发类似复杂度的产品，本文将告诉你需要付出怎样的努力，学习路径是什么，最小的知识集合有哪些，以及在这个过程中你将经历怎样的心路历程。 产品介绍 我开发的是一款英语听力练习工具“天天磨耳朵”。 因为自己一直在练习英语听力，但是苦于市面上没有符合自己需求的产品，最接近的形态是英语听力练习连播的视频/直播。 但这种形式有几个问题： • 要不然太简单、要不然太难，无法根据个人水平做太多调整（包括词汇范围、语速、句子难度等等）。 • 材料有限、播放流程固定，无法做太多控制或干预（除非切换单集或者快进） • 打开路径较长，还得调整进度或者选择选集，成本较高，磨灭了碎片时间练习的热情。 因此我设计的天天磨耳朵，具有以下特点： • 能基于自身词汇水平选择练习范围，支持调整语速、句子难度，自动保存学习进度和偏好设置。 • 听力材料由 Deepseek 根据难度设置生成，始终能够练到自己舒适区边缘的材料，且永不重复。 • 一打开就能练，自动开始连续播放，操作路径短，还能后台播放，忙的时候干点别的事再回来，也不耽误。 • 除了随时暂停/续播的控制，若提前听懂你可以跳过，若觉得当前词比较生僻也可以标记不再出现该词。 • 还支持夜间模式，夜晚练习不眼瞎。 考虑到类似的视频/直播还是有不少播放量和观众的，因此估计该需求有一定的普适性，应该有产品化的价值的。且由于 deepseek 等大模型支持多种语言，所以这个产品是个万能容器，做出来之后，也可以以很低的成本，实现很高的功能扩展性，除了允许中国人学英语，也可以支持韩国人、日本人学英语，也支持美国人学西班牙语、法语…… 需求推演部分就这么简单。我承认这个不算是什么严格的自上而下推演的需求场景，缺失了许多用户视角和商业视角的分析验证，不过这也不是本文的重点。只能说这个应用非常适合作为我个人首次的开发尝试（具有一定的复杂度，且即便无人问津，我自己也能用哈哈）。 项目规模 • 总代码量：1.2万行业务代码（已剔除测试、调试和数据库脚本、类型定义、常量定义、配置文件、工具类、第三方依赖等代码，仅供参考，毕竟其中可能藏着不少屎山代码） • 前端：8.5k 行（Flutter） • 后端：3.4k 行（Node.js） 技术栈 前端 • 框架：Flutter 3.0+ • 状态管理：Provider • 音频处理：just audio • 网络请求：dio • 本地存储：shared preferences • 测试框架：Flutter Test + Mockito 后端 • 运行时：Node.js + Express + TypeScript • 数据库：MongoDB • 缓存：Redis • 鉴权：JWT • 测试框架：Jest 第三方服务 • AI 服务：DeepSeek V3 • 语音服务：Edge TTS 云服务与基础设施 • 服务器：阿里云 ECS • 短信服务：阿里云 SMS • 域名证书：阿里云 SSL AI 编程怎样更加可控 产品设计还是得先行！ 如果一开始没想好完整的需求，而是一点一点往上加，我觉得大概率会不太可控（不是完全不行，只是开发到后期就得看运气了）。我用 python 开发 CLI 版本 的MVP时候是可行的，但是开发 ios 应用版本的时候就完全失控了。 为啥会不可控？根本原因是AI 的上下文窗口长度有限，然后复杂度上去了，AI 会“断片”，会忘记自己做过什么、说过什么。 我第一次返工就是因为偷懒，想着需求可以慢慢完善，想到什么点子就叠加上什么点子，没有做好底层的设计。 所以，要使得开发过程很可控，产品设计还是要提前做好的： 系统架构设计 • 数据建模：代码改造成本：数据底表 核心业务逻辑 前端，所以数据建模一定初期要做好。需要明确都有哪些表，表与表之间是一对一还是一对多关系，每个表分别有哪些字段，是什么数据类型，能不能枚举，有没有默认值。如果一开始没有强把控，完全交给 AI，它可能会重复建某些表，某些字段。 • API 及前后端交互设计：每个API 的功能定义，前后端如何交互的，哪些业务逻辑放在前端实现，哪些放在后端。就本应用来说，大部分业务逻辑都放在后端处理了，但最核心的音频循环播放的控制逻辑我放在前端了，因为这样可以跟手机系统深度集成，也更减少延迟，能满足实时性的要求。 功能需求定义 需要强调的是，一定把需求描述完整，避免模棱两可的表述。 AI总让人反思日常语言表达是多么不精准。比如我说“一张A4纸，请你对折再对折”，你可能会这样折： 但实际上ai就能按照另一种方式去对折（你别说，也没错，但是