不是程序员或者工程师的你，怎么走出AI vibe coding的困境?

TL;DR ❤️

太长不看版本

AI vibe coding的核心原则

分清楚”什么是我知道的，什么是我不知道的；尤其在「不知道」里面，哪些是我知道的，哪些是我不知道的”：known-knowns, known-unkonwns, unknown-unknowns

AI vibe coding 的六大陷阱和解决方案

第一步：从已知领域出发，而不是空想“我要让 AI 包办一切”

第二步：未知盲区最可怕，不要“只看结果”，要让聊天对话成为核心

第三步：Be comfortable with 已知盲区，不要陷入看具体的每行code的陷阱，在关键时候，要敢于“往下挖”一点，但也别挖太深。

第四步：cursor的Claude喜欢execute，别陷入“回天乏术”的陷阱。充分利用版本控制，创造你的时光胶囊。

第五步：未知盲区，搞不清楚“AI 直接在编辑器里改完”与“项目真正拥有了对应功能”之间的差别

第六步：建立自己的“人类 history”，而不只是依赖 AI 的对话记忆

---

<🤖>如果你并不擅长编程，但已经开始接触用 AI（例如 Cursor、ChatGPT 等）来完成各种 APP 开发任务，恐怕会经历一个既兴奋又挫败的过程：AI 经常能立刻输出大段你看不太懂的代码，功能似乎像变魔术一般一下子就“实现”了，可往往稍微深一点就千疮百孔，或是 debug 几次都找不到头绪，让人陷入“到底是我不会，还是 AI 不行”的两难。更要命的是，你可能连问题在哪里都说不清楚，因为自己对代码和项目结构并没有足够的了解。

如果你也有这样的苦恼，不妨先跳出“要不要自学编程”的纠结，更务实地想一想：我在用 AI 写代码时，为什么总感觉“心里没底”？究其根本，并不在于你是不是程序员，而在于我们对“AI 可以做什么、不可以做什么”缺少清晰的认知，再加上自己对开发流程、项目结构理解不足，两者就会形成一个“黑箱叠加黑箱”的局面。其实，只要掌握一些核心要领，你同样能够顺利地利用 AI 辅助完成不少开发工作，还能在这个过程中慢慢积累“编程思维”，让你在没有专业背景的情况下依然能够游刃有余。

AI vibe coding的核心思路

<👩‍🔧>这里我觉得有个很重要的思路就是分清楚”什么是我知道的，什么是我不知道的；尤其在「不知道」里面，哪些是我知道的，哪些是我不知道的”，就是我们经常说的三块同心圆：

1. 已知领域（known‑knowns） ——你的专业积累：SQL 怎么写、业务指标怎么读、产出的样子应该长什么样。

2. 已知盲区（known‑unknowns） ——你知道有很多AI写的具体细节function你不会看，也看不懂，也不想看，到底什么时候dive in? 什么时候跳出来？

3. 未知盲区（unknown‑unknowns） ——你连问题都说不出来，只是隐约觉得“这里不对劲”。AI 在这里最容易把人绕晕。

我认为在AI vibe coding的时候，其实最可怕的是我们不知道的东西，并不是相关领域的domain expert，而且CS的分支众多，一句大家是程序员，并不能告诉我们到底谁在行什么，谁不在行什么。其实分的很细的话，编程这块儿是需要很多实践和不断练习，积累的一个过程。比较可怕的是，作为对这个领域不熟悉的人，其实连这些分类都搞不清楚，更何况去解决这些领域里的问题，并且知道出了问题如何debug呢？

所以，如果你开始尝试AI vibe coding， 需要很清晰的知道哪些任务和问题是落在哪个圆里，才是可以帮助你进阶vibe coding的关键。</👩‍🔧>

---

AI vibe coding 的六大陷阱和解决方案

第一步：从已知领域出发，而不是空想“我要让 AI 包办一切”

很多初学者最大的陷阱，就是想让 AI 直接从零带自己做一个非常复杂或陌生的项目。可当 AI 抛出一堆你完全看不懂的概念时，你会手足无措，既没法判断对错，也无法提出更精确的改进意见。最好的方式是先挑一个你有一定业务经验的小任务、简单的功能、或日常使用的数据分析场景，让 AI 生成脚本或界面来自动化你的工作。因为你对目标和需求足够熟悉，AI 输出任何不合理的地方，你能第一时间发现并让它修正。你不需要会写代码的细节，但必须知道“我要的结果是什么”。如此一来，你的反馈就更准确，AI 的改动也更贴合实际需求。

<👩‍🔧>这里我可以分享的小例子就是譬如说原来做analytical的工作，很多时候都是用SQL来写group by, summarize, select, where (filter) 这些功能；我一开始学编程，刚开始的作业时让我写一个可以在ATM贩卖机里怎么去选择自己想要的商品，然后付钱，提取该商品，然后让ATM吐出该商品的程序。

这个任务分解对我来说就挺难的，所以我虽然觉得这个任务分解可以很好的锻炼编程思维，但是怎么判断哪里分解任务不对，哪里出错，如何改错，会挺难的。

我的建议就是其实可以从你最熟悉的场景和任务出发，譬如说现在用AI来写python，完成同样是SQL做得工作，还是group by, summarize, select, where这些功能， 你可以把你SQL的语言作为给AI喂的信息，然后看出来的成果怎么样，因为时你熟悉的场景，你也知道如何评判，就可以很好的判断出到底对不对。

特别是这样的练习可以帮助你建立信心, 逐渐学会和AI互动上到底怎么沟通可以达到我想要的效果，我有非常多的自学经验 （感兴趣的可以看这篇 Adult Learning 里最难的3点：Learn to Unlearn, RFR cycle, and Take it Slow - 从我学吉他，学游泳，和读2nd AI MS degree 谈起 ) 。我觉得不要一开始太ambitious，做非常复杂和不熟悉的任务，这个很打击信心和动力，要适当的给自己安排合适的任务来进行练习。</👩‍🔧>

第二步：未知盲区最可怕，不要“只看结果”，要让聊天对话成为核心

很多人会觉得，只要我告诉 AI“来吧，写一个表单加后端 API！”然后看它贴出大段代码就行了。但在复杂一点的需求里，这往往行不通。要想让 AI 真正理解你的项目，必须经常在聊天对话里给它足够的上下文，反复沟通需求、用途、运行环境。更重要的是，碰到反复报错或修不好的 bug 时，不要只是催它“再修一次”，而应该要求它先解释“这个错误的根源是什么”“为什么之前能跑，现在跑不了”，让它自我剖析思路，给出可能的原因或方案，再逐一排查。用对话去逼 AI 先思考，再动手，这样就能大大减少你在调试时的盲目性。

<👩‍🔧>这里我可以给的小例子是到底怎么和AI协作，可以更好的进行沟通呢？

譬如说我经常会用的和cursor进行沟通的prompt是这样的

The same error returned, but it seems to stem from different specific problems; can you investigate the error and outline your debug thinking before doing anything? Reflect on your reasoning, check the corresponding files and errors to confirm whether it’s a solid debug plan, and consider whether you might be missing something

我也会经常让cursor的agent转换成consultant的角色，让它给提出几种方案，然后自己recommend，这个会让它自己给出几种方案的优劣，然后选择最适合的方式。当然这个时候其实也是给我们人类的一个intervention的机会，因为我发现AI 特别是Claude倾向去先execute，这个时候很容易犯初级的错误就是：没想清楚，先瞎干，用“瞎忙”来替代真实的思考：

what are the different options and what would you recommend ?

我觉得很多时候，AI vibe coding无法进行下去，其实是我们自己也没有思考好，或者指导怎么帮助AI去思考。这个和带实习生或者带初级的同事或者下属会碰到的问题，怎么授人以渔，而不是授人以鱼。其实很关键是我们自己要有这个哪儿有鱼，怎么去找鱼的问题，特别是AI这个时候其实已经掌握钓鱼的十八般武艺了，但是缺乏好的判断力。

其实我甚至觉得cursor的核心界面应该是chat history， 而不是具体的scripts，因为怎么和AI协作，可能是以后编程的重心，那么看AI如何behave，还有总结AI到底干了个啥，才是我们注意力应该在的地方。如果还是以具体的code为核心，那我们可能永远无法放弃这个需要control的心态，反而会成为和AI协作路上的最大的拦路虎。</👩‍🔧>

第三步：Be comfortable with 已知盲区，不要陷入看具体的每行code的陷阱，在关键时候，要敢于“往下挖”一点，但也别挖太深。

作为没有编程背景的用户，你无需在所有代码细节上跟 AI 较真，但当项目出现顽固 bug 或逻辑对不上的时候，你至少要去查一查是哪几段脚本在相互调用，输入输出之间为什么会不匹配，甚至可以让 AI 把数据流图画给你看。只要你关注到“每个模块拿到什么输入，输出给谁”，就能帮它找到矛盾点。在这个层面上调试你不一定要能手写所有语法，但必须有自己对流程的基本判断。毕竟 AI 并不知道你整体业务想要实现什么样的逻辑，只有当你能指出疑点时，它才能在局部更有针对性地修复。

<👩‍🔧>这个其实可以回到我们的核心原则上，怎么判断什么时候我要具体的看AI写得code，看多细？什么时候我是PM， 站在什么样的高度上来指导AI写code呢？

这里我经常用的原则是I-P-O思维：Input → Process → Output（I‑P‑O）

把每段脚本或 API 调用想成一粒“胶囊”，你只需关心 I/O 是否对得上，无需沉到每一行语法。

• Input：谁提供？格式、样例是什么？

• Process：用什么库？调用哪一步 LLM？依赖何种环境变量？

• Output：类型、下游接受者、验证方法。
  当 bug 一直复现时，八成是两粒胶囊的接口没对齐——先核对 I/O，再决定要不要深入代码。 所以，我现在并不会看具体的每一个scripts里的每一个function怎么写得，而是会让AI去思考他自己写的每一个得script的IO到底有没有对齐。然后会让他document，并且以此为准则，下次就不会瞎改，导致程序上一轮还跑得通，下一轮加了个新功能，就报废了。</👩‍🔧>

第四步：cursor的Claude喜欢execute，别陷入“回天乏术”的陷阱。充分利用版本控制，创造你的时光胶囊。

很多人只把 Cursor 当作写代码的地方，忽略了 GitHub 或其他版本管理工具的重要性。可一旦 AI 在编辑器中直接把你的某个文件覆盖，或者你手滑保存了不正确的改动，再想回退就会非常麻烦。最好的做法是：在 GitHub 上建立一个远程仓库，每次让 AI 改完代码，你都要先在本地或 staging 区对比一下差异，然后再选择要不要提交。要做大改动时，可以新建分支，这样就算走入死胡同也能随时回到上一个版本。哪怕你自己对 Git 操作也不熟，至少也得知道“提交”、“分支”、“回滚”这些核心概念，因为它们直接决定了你能不能在不断试验的过程中有序推进。

<👩‍🔧>如果说AI vibe coding有一个必学的东西的话，我可能会首选GitHub的version control，因为这是在AI vibe coding里把你从AI乱改的代码库救回来的神奇时间胶囊。而且形成一个好的documentation和掌握整个code base的发展脉络，和控制不同方向和不同功能的实现，其实是锻炼编程思维的最好的方式。并且有了AI之后，原来大家都很痛斥的某些程序员不写documentation这种诟病，也完全消除了，变成写documentation so easy。 那么好好利用起来更是和AI协作上最重要的一环</👩‍🔧>

第五步：CursorAI vs API AI 的未知盲区，搞不清楚“AI 直接在编辑器里改完”与“项目真正拥有了对应功能”之间的差别

对于初次体验 AI 开发环境（特别是 Cursor）的人而言，很容易搞不清楚“AI 直接在编辑器里改完”与“项目真正拥有了对应功能”之间的差别。Cursor 的做法往往是帮你做一次自动化的文本编辑或生成，但如果你不知道这些改动最终落到了项目的哪些文件里，也不知道是否经过编译、部署、测试，就会产生“我以为功能已经实现，怎么跑起来还和原来一样”的错觉。

如果一开始没有太多编程经验，更难分辨“这段改动只是 AI 在编辑器中帮我局部替换了代码”还是“我实际在项目里集成并运行了这些改动”。通常以下几点有助于建立清晰的界限感：

首先，每次让 AI 做完改动，你都要在代码层面仔细查看差异。比如用 Git 做版本管理时，可以在提交前先看看 diff，确认具体哪几行代码、哪个文件发生了变化。如果你对其中的改动不理解，就先别着急提交，而是去问 AI“能解释一下你改了哪几处，背后的理由是什么吗”，等自己心里有数了再落地到仓库里。

其次，真正让功能生效，得保证改动过的代码已经在本地或服务器上编译、运行、或者部署成功。别忘了在本地起服务或跑测试。尤其在 Cursor 这样的环境里，AI 可能会修改多个文件，但如果你只保存了一个文件、或者只把它粘到了别处而没在实际项目中引用，那么你的程序依然不会“知道”那段逻辑被更新了。很多人以为“AI 直接操作编辑器就等于我改好项目了”，其实还缺少最后那一步手动确认或自动化流水线的执行。

所以，如果有人完全没编程基础，最好把 AI 在编辑器里的改动和在项目里跑实际功能的过程分成两个心智步骤。先在对话中让 AI 解释清楚它想改什么、为什么要改，再手动去检查、保存，然后启动或者重新编译，让程序真实运转起来。哪怕这看起来有点慢，却能让你对每次改动的缘由和效果都更有把握。随着熟练度提高，就会自然地缩短这个检查过程，但依然要保留那份“确认到底落没落到项目”的意识，避免 Cursor 或任何 AI 工具“在后台默默改完”，你却不知道。

总之，别被 Cursor 编辑器那种“一键生成或一键替换”的便捷界面冲淡了对真实项目状态的关注。要让某个功能真正在你的应用里生效，始终需要你自己（或自动化管线）来承认并部署那些改动，亲手在运行时环境里做验证，而不仅仅是让 AI 在对话里告诉你“搞定啦”。一旦建立起这种分辨能力，你就不会再把“AI 界面上的改动”与“功能已实现”这两件事混为一谈。

<👩‍🔧>这里我想分享的其实是之前社群里的一个小伙伴跟我分享的她的案例，然后我意识到她没有意识到cursor的AI自动完成的东西，如果我们脱离了cursor到底又怎么实现。

具体的例子就是她用Cursor 很快速的做了一个可以展示Weekly business review的网站，然后给公司的人看了，大家都很惊艳，希望复刻。可是她很头疼到底怎么复刻？

她的核心问题不是说不知道给大家宣传和介绍试用cursor，而是说如果我们也想可以实现这样的自动化的reporting和insights，到底怎么可以实现，这样大家都不用手动分析，也不用coding，更用不到cursor。

这其实是就是没有分清楚“AI 直接在编辑器里改完”与“项目真正拥有了对应功能”之间的差别。 这里的AI是指的是cursor的AI agent。如果我们想要复刻cursor可以一键到位生成report site，其实是需要自己设计agentic AI workflow 和很强的engineering搭配，infrastructure跟上，才能实现的。</👩‍🔧>

第六步：建立自己的“人类 history”，而不只是依赖 AI 的对话记忆

AI 会记得你在对话里说过的事，但不见得能分辨哪些是最重要的上下文，也不会自动记录你下过的所有尝试。尤其是当项目规模扩大，或者你更换了聊天环境时，很多已有的暗示可能丢失。这时候你自己要保持记录：
• 哪些需求和功能是已经完成并验证过的；
• 哪些是修到一半，AI 还没给到稳定方案；
• 哪些尝试在实践中失败了，可以当做负面经验；
最好使用 README 或项目文档（甚至是笔记）把这些东西列出来，以后回头就知道如何跟 AI 衔接。当 AI 不断推新方案时，你也能用最简洁的方式告诉它：“这些地方已经行得通，那些方式我们试过了不行。” 而不至于重复浪费时间。

最后，这些做法的意义并不是让你“逼自己成为程序员”，而是在 AI 辅助的大环境下，学会如何与它配合完成有条理的开发。你确实可以比过去更快地构建出有用的应用或自动化脚本，但也需要把握好项目管理、版本控制、以及对逻辑流程的把关。如果你抱着完全甩手的态度，AI 写出来的代码可能在某些小场景能跑通，但一旦遇到需求升级或各种异常，就容易直接崩塌。如果你仅做一个没有深入思考的“指令发出者”，那你所搭建的系统就会是脆弱的。

<👩‍🔧>这里我想分享的是，其实如果debug的时候出现了两到三次的 back and forth， 这时候其实可以take a step back, 不要硬PUA AI。 这个时候其实应该换个思路，我现在会做的是换一个更高层级的，或者别家的AI， 喂给它相应的context和信息，让它帮忙指导一下：特别是我不熟悉，不知道的领域。又回到核心原则上面了， 一定要判断好三个同心圆里，我现在遇到的问题落在了哪个圆里。

这样做，往往可以帮你打开解题的思路，而不是一味地在cursor里死磕，陷入无尽debug地循环里。</👩‍🔧>

---

Punch Line Time , Happy Vibe Coding~

<👩‍🔧>上一个我让4o画得Vibe coding 的小漫画：

吐槽我自己，不是应该画个帅哥，然后再画个女性程序员么？the truth is, 我并不想让我的女性程序员秃头🤷，还是把这个安排给男性程序员吧…

最近开始也写linkedin post （how to use LLM to analyze unstructured data and realize expert decision making) , 顺道画AI的冷笑话漫画：AI的冷笑话咋看很有趣，细看全是问题🤪，乐趣之一是分析AI写得冷笑话…

然后给 陈然 的vibe coding 的曲子宣传一下，太好笑了:

本文是我用鸭哥的小工具brainwave 哔哔哔（ 打破设备限制，让Brainwave实现跨设备语音输入 ），然后把我的learnings和o1-pro还有o3共同讨论，总结出来的。杂揉了我自己的讨论和AI的文字，AI的文字很清晰，我觉得写这种技术博文，其实AI写得比我自己写得要好，我就决定尝试发看看，欢迎大家提供反馈和阅读感受。

我之前也写过一篇文章 简单分享一下最近用cursor作为很初步的AGI入口的工具感受 ，那时候的感受是刚开始用AI vibe coding， 还处在非常惊艳，想要告诉全世界的心情；现在的心态就变化许多，感觉也经历很多改AI写得code，改到吐血，非常frustration的时刻，觉得有必要总结和分享一下我的体验。也欢迎资深的各位engineer们分享你们的经验和总结！

自来水广告

从当初参加maven的build课程 , 到现在自己也build了一个阶段了，工作上也build了一个enterprise scale的innovative application。 最大的体会可能是对自己的scope上的拓展和对自己build能力的信心增长。

参加课程的时候，对于作业里的例如扒CVPR论文, 下载Instagram的图片，browser as a developer tool, image 分析，画Pi，这些都是我平时根本不会想要自己去做的任务，所以一开始做这些作业很吃力且方向也不对。而且当时也完全不知道cursor（全年compose的功能也才刚出来），还是chatgpt一轮轮copy and paste.

直到现在，我已经开发了很多各种各样的小工具了来给自己用 （还把饺子导演在微博发的哪吒的海报宣传，给扒了下来做了一副电子扑克牌，涉及版权，不好分享这个）。

在工作上也转型开始完全专注于开发LLM-powered decision making application, 再到现在自己开发了一个end-to-end的web app （打个小广告就是AI-tailored resume的小工具）。

这是我之前在课代表的评论，我的看法并没有变，我自己发懒且脸皮厚，quote一下我自己吧：

我是cohort4的学员，当时八月份到现在今年三月份，半年过去了，AI的发展真的可以用日新月异来形容，在这个变化莫测，人人FOMO的时候，学会一套可以以不变应万变的思维模式和价值准则变得尤为重要！ 鸭哥和课代表一直致力于实时更新自己对这个领域和技术的最新理解，并且走在最前沿的部分，同时大量的实践和总结。这半年来看到他们的updates和development都觉得很神奇，这门课的价值不只是one time的，而是长期的！希望感兴趣的小伙伴们可以从长远的角度来投资自己！ 而且superlinear academy里的AI community 也有超多有价值的分享和应用，学到超级多，每天都会去看。我觉得在AI时代，不管是原来的职业和学业上的成就和积累如何，会有一种又是初学者的状态，有很多新的思考的方式和处理问题的方式，开卷有益~

哈哈，通读全文的话，还有一个很简单的小彩蛋，你发现了么？

欢迎🔗LinkedIn

</👩‍🔧>

</🤖>