这句话我曾经也深信不疑。于是，我带着“零经验”直接跳进了编程的世界，想靠 AI 一把梭。结果当然不出意料：三次推翻重来，三次重建应用，三次挫败感拉满。
但回过头来看，这段经历也让我真正理解了：AI 在编程里到底帮了什么忙，又在哪些地方反而放大了问题。
所以今天苏米就来聊聊我是如何用AI 学编程的~
从Vibe Coding聊起
工具的选择
起步时，我什么都不懂，只是听 ChatGPT 推荐就安装了 VS Code。老实说，惨烈。
我的操作模式是复制 ChatGPT 给的代码，粘贴到编辑器，运行，出错，再问，再粘贴。完全没有理解代码本身，更别说背后的逻辑。
后来试过 Lovable，界面更友好，但因为频繁提问和调 API，很快就跑光了额度。
再换到 Cursor，感觉便宜点，也自带 AI 辅助，但问题依旧：我根本不知道自己在“接线”。
比如第一次用 Supabase，连它是什么都没搞清楚，只是按着提示操作，心想：反正能跑就行。
结果呢？当然踩坑。
从工具选择中学会
这个工具迁移的过程让我意识到，选择开发工具就像选择产品架构一样，需要考虑成本、易用性、可扩展性等多个维度。
但对于初学者来说，最重要的是找到能让自己快速获得正反馈的工具，而不是一开始就追求最专业的解决方案。
第一次“翻车”
盲目堆砌
在产品管理中，我们经常谈到功能蠕变（Feature Creep）的危险，但直到自己编程时，我才真正体验到了技术层面的功能蠕变。
我的应用已经用Supabase搭建了完整的数据库、安全规则和登录系统，一切运行良好。但仅仅因为不喜欢Supabase默认的邮件样式，我就贸然引入了Resend服务。更糟糕的是，Cursor在集成Resend时还自动添加了NextAuth——而我的应用已经在使用Supabase的认证系统了。
恶性循环
结果可想而知，两套认证系统冲突，整个应用崩溃了。这让我想起了产品开发中的一个经典场景：为了解决一个小问题，引入了一个大方案，结果产生了更多问题。
最要命的是，我缺乏足够的代码阅读能力来诊断真正的问题所在。就像在房子建设中，我要求加隔热材料，AI给了我棉花糖，但我不知道这不是真正的隔热材料，直到要挂石膏板时才发现问题。
而此时，我只能看着Cursor不断尝试用"更大的钉子"或"不同的螺丝刀"来解决根本性的架构问题。
重构的痛苦
接下来的几天，我在修补和重建之间循环往复。先是试图修复现有系统，失败后完全推倒重来，换成Neon + Resend + NextAuth的组合，再次失败，最终又回到了Supabase。
三次重建，每次都是痛苦的过程，但每次重建也让我对代码有了更深的理解。
这个过程让我深刻理解了开发团队在面对需求变更时的痛苦。
作为产品经理，我们往往会说"这只是一个小改动"，但在技术层面，可能涉及的是整个架构的调整，也是从这一刻起，我理解了什么是“技术债务”
Vibe Coding实感
学习编程的真实感受
用AI学编程的感觉，就像在不了解建筑材料的情况下盖房子。我知道最终的房子应该是什么样子，也在慢慢学习建造的步骤，但我无法分辨"隔热材料"是真材实料还是棉花糖，直到问题暴露才恍然大悟。
这种体验让我对"MVP（最小可行产品）"有了全新的理解。在产品规划中，我们总是强调先做MVP验证核心假设，但在实际编程中，我才体会到什么是真正的"最小可行"——能跑起来就是胜利，能不崩溃就是成功。
小胜利的力量
在这个痛苦的学习过程中，一些看似微不足道的小胜利给了我继续下去的动力：
-
掌握Ctrl + C停止终端：虽然简单得有些愚蠢，但这让我第一次感觉自己真的在"控制"代码
-
识别重复出现的bug：当我能够预判某些错误并知道如何修复时，那种成就感难以言喻
-
理解数据库查询与代码的对应关系：不再只是盲目复制粘贴，而是开始思考为什么这样写
-
搞定Docker、CLI和Chromium：这些最初看起来完全不可能的任务，现在变得可以处理
-
真正理解Git的价值：起初我以为Cursor的撤销功能就够了，但Git就像项目的存档点，让我可以在"什么时候"（不是"如果"）搞砸的时候回滚
收获与感悟
AI加速失败，而非消除失败
最大的认知转变是理解了AI的真正价值：它不会阻止你失败，而是帮你更快地失败。这听起来像是负面的，但实际上这正是学习发生的地方。在产品管理中，我们讲"快速试错"，在编程学习中，这个概念变得更加具体和直观。
调试思维胜过重启思维
另一个重要教训是：不要总想着重新开始。我重启了三次应用才意识到，bug是不可避免的，你必须学会调试，而不是每次都核弹式清零。这对产品工作同样适用——当产品出现问题时，分析根因比推倒重来更有价值。
版本控制的重要性
Git的学习让我对产品版本管理有了新的理解。它不仅仅是代码的快照，更是思路的记录。在产品迭代中，我们同样需要清晰的里程碑和回滚机制。
从盲目到理性
三周的编程体验后，我仍然是个初学者，但心态发生了根本变化。现在当代码出现问题时，我会先尝试理解原因，而不是立刻求助于Cursor的自动修复。这种变化不仅体现在编程学习上，也影响了我处理产品问题的方式。
编程感悟
这次编程经历让我对开发团队有了更深的同理心。当我们提出一个"简单的需求变更"时，开发可能面临的是架构级的挑战。当我们催促修复bug时，可能忽略了诊断问题的复杂性。
更重要的是，我开始理解技术决策的权衡艺术。每一个工具选择、每一行代码、每一次重构，都是在成本、时间、维护性之间寻找平衡点。这种思维方式对产品策略制定同样宝贵。
写在最后
作为产品经理，我深刻感受到一点：学编程最大的价值，不是马上做出一个完美的应用，而是逐渐建立对系统的“心智模型”。
AI 确实让我们更容易入门，但它不会替你培养直觉。
直觉只能靠一次次失败和小胜利来积累。
在这个AI工具遍地开花的时代，真正的竞争优势不是会使用某个特定工具，而是拥有面对未知问题的解决思维。