用 Cursor 的最大误区：不是你不会写代码，而是你太早写代码

大多数人一打开 Cursor，就急着敲提示词、改代码，结果越用越乱。Greg Isenberg 在这期教程里抛出一个反直觉结论：Cursor 的上限，不取决于你会不会写 Prompt，而取决于你在“还没打开 Cursor 之前”做了什么。这篇文章，把那些真正拉开差距的细节一次讲透。

真正的分水岭：Cursor 之前，你做了什么

这支视频里最反直觉的一点是：Cursor 本身并不是决定效率的关键变量。

Greg 反复强调一个看似“老派”的动作——规划（planning）。不是打开 Cursor 现想，而是在进 IDE 之前，就已经想清楚你要做什么、为什么做、边界在哪里。他说自己亲眼见过“night and day”的差别：同样的人、同样的模型，只是有没有提前规划，产出质量完全不同。

这和很多人对 AI 编程工具的期待是相反的。大家以为 Cursor 的价值在于‘替你思考’，但实际情况更像是：它会把你原本混乱的思路，放大十倍。如果你脑子里是模糊的，它只会生成更复杂的混乱。

别急着写代码：先对着“橡皮鸭”把问题讲清楚

视频里提到一个经典但常被忽视的方法：rubber ducking。

意思不是你真的需要一只鸭子，而是强迫自己把问题完整地“讲出来”——哪怕对象是一个虚构的听众。Greg 的意思很明确：如果你连问题都讲不清楚，就别指望 Cursor 能替你想明白。

他甚至建议：如果你不用 Figma 这种偏视觉的工具做规划，那至少要从文字开始。写 planning doc，拆目标、列假设、标清楚哪些是你确定的，哪些是开放问题。这一步，看起来和 Cursor 没关系，却直接决定了你后面跟 AI 的“对话质量”。

一句话总结就是：Cursor 不是用来帮你想“要做什么”的，而是用来帮你更快地做“你已经想清楚的事”。

新手最该从哪开始？不是写新功能，而是加注释

如果你已经在用 Cursor，但总觉得“也就那样”，Greg 给了一个非常具体、非常低门槛的起点：从给代码加注释开始。

这是他认为“probably the best place for people to start”的地方。原因很简单：

第一，加注释天然逼你理解现有代码，而不是幻想 AI 能无中生有；
第二，这是 Cursor 非常擅长的任务之一，反馈快、效果明显；
第三，它会在无形中建立你和代码库之间的上下文感。

很多人一上来就让 Cursor 写复杂逻辑，反而容易失控。但从注释、重构、解释现有代码开始，你会明显感觉到：AI 是在“放大你的理解”，而不是替你蒙答案。

Onboarding 阶段最容易被忽略的细节：文档和上下文

在讨论 onboarding 时，视频里抛出了两个容易被忽略的问题：tagging docs，以及“要不要问其他 AI”。

当有人问“什么叫 tagging docs”时，本质上问的是：你有没有在系统性地喂上下文？在 Cursor 里，零散的信息和结构化的信息，效果完全不同。文档是否被清晰标注、是否能被模型快速理解，直接影响它的输出质量。

至于“asking other AI”，Greg 的态度很微妙——他没有给确定答案，只是说“who knows”。这背后其实点出一个现实：Cursor 很强，但它并不是唯一答案。高手并不会把自己绑定在单一工具上，而是清楚每个 AI 在不同阶段的角色。

最后，他提到一句非常现实的建议：有些 Cursor 特别擅长的事，你就老老实实“stick to the pain for the next couple months”。意思是，别追求花活，先把那些真正痛、但高频的场景用熟。

总结

如果你只记住一件事，那就是：Cursor 不是魔法棒，而是放大器。它会放大你的清晰，也会放大你的混乱。

对 AI 从业者来说，真正的行动建议其实很朴素：下次打开 Cursor 之前，先写 10 分钟 planning doc；用 rubber duck 的方式把问题讲清楚；从加注释、理解旧代码这种“看起来不性感”的地方开始；在 onboarding 阶段，把文档和上下文当成第一优先级。

一个值得你思考的问题是：如果明天 Cursor 消失，你现在的工作方式，还有多少是站得住的？答案，往往决定了你能把 AI 工具用到什么层级。

关键词： Cursor， AI 编程， 规划思维， Rubber Ducking， 开发者效率

事实核查备注： 需要核查：视频发布时间（2024-09-13）；作者 Greg Isenberg 的原话表述是否为 night and day、probably the best place for people to start；视频整体时长与内容顺序。