写过代码的人都知道，使用Cursor编程的水有多深

原文： mp.weixin.qq.com/s/3OKkV5exH… 转载请联系作者

善用 Cursor = 快速、整洁的代码。

用错 Cursor = 一团乱麻的 AI 代码，你要花一周来收拾烂摊子。

两个月前，在被免费的 trae 排队编程虐了无数遍后，决定斥巨资开 Cursor

没有选择白嫖，太麻烦了，找到了一个便宜点的稳定渠道

感受了 Cursor 的丝滑后，我脑海里也闪过一个念头：“学编程=49年进国军”...

Cursor 写代码、解释代码、Debug、重构... 很多以往需要冥思苦想、反复查阅文档的工作，现在用自然语言和 Cursor 聊几句，就可以一次代码成型，甚至用 Cursor 开始写小说、写文档。

上一篇：mp.weixin.qq.com/s/wAoHMTv_4…

然而，随着使用 Cursor 的深入，从最初的惊艳到后来的日常依赖，我反而更加深刻地体会到—— 在大模型时代，编程思维和基础的编程能力， #技术分享不仅没有过时，反而变得更加至关重要。 Cursor 不是让我们告别编程，而是把我们推向了更高阶的“编程思考”。

刚开始用 Cursor，我简直像得到了一把“屠龙刀”，用 Cursor 做了几个脚本：

使用yolo8s实现车辆、行人识别；提取excel中指定的字段处理后输出新文件；爬取某个网站数据，导出Excel文件等；

Cursor 写的很快，运行很顺利，体验很爽。但是有一次，我让 Cursor 帮我写一个稍微复杂点的 Web 后端 API 接口，涉及数据库操作和一些业务逻辑，发现等 Cursor 熟悉项目、写代码、自检、人工调试纠错一套连招的时间，我已经可以搓完代码，并且仔细看代码会发现：

缺乏长远规划： 一个代码文件上千行，这谁受得了，并且代码可能没有很好地考虑扩展性。细节处的“坑”： 生成的代码有时会有细微的逻辑错误，或者不符合项目已有的编码规范，需要人工甄别和修正，如果让它自己修正，又进入了写代码、自检、纠错的循环...

和2023年的大模型是一个“学霸实习生”一样，Cursor 像一个能力极强、不知疲倦的初级/中级程序员，它可以完美执行明确的指令，但它需要一个经验丰富的“项目总监”或“架构师”来把控方向、定义需求、甄别结果。 而这个“总监”的核心能力，正是编程思维。

用 Cursor 越多，我就越发现，它对使用者的“编程思维”提出了更高的要求。

“垃圾进、垃圾出”和代码量成正比，项目代码量越大，使用 Cursor 一次写的代码越多，Cursor 使用时产出垃圾代码的概率更高。

给 Cursor 的指令（Prompt）越模糊，它给的代码就越不靠谱。如果对想实现的功能、步骤、边界条件都没有清晰的思考，那 AI 生成结果大概率是胡扯，甚至在不审查的时候误删重要代码。

以前自己写代码，思路不清时会卡住，然后被迫去梳理。现在用Cursor，如果思路不清就直接“说”，它可能会给个似是而非的东西，反而可能把我带偏。 我必须先在脑子里把问题分解、抽象，想清楚逻辑流程，才能给Cursor下达精准的指令。 这不就是编程思维里的“分解”和“算法设计”吗？

从“怎么写”到“写什么，为什么这么写”，Cursor 极大地解放了我在开发过程中对具体语法细节的记忆负担，可以把思考从如何实现中解放出来，但是在写代码过程中遇到了很多此 Cursor 进入某个插件的死胡同。

不断的运行检查、修改、再检查，直到我提出换一种实现方式。

使用 AI 编程，需要更广的知识储备，如果没有，可以向 AI 提问“还有什么实现方式？”，把开发的思路变为聚焦“What”（实现什么功能）和“Why”（为什么选择这个方案）。

开发的过程不再需要纠结某个API参数名是 size 还是 length ，Cursor会帮我搞定。但我需要更清晰地思考：“这个功能模块应该如何设计才能低耦合、高内聚？”“这里的数据结构用列表还是字典更合适，为什么？”“这个算法的时间复杂度和空间复杂度如何？” 这些决策，AI可以提供建议，但最终的判断和选择权在我，而这依赖于我对编程原理和设计模式的理解。

在开发过程中我的角色转变了，从“编码人”，转变为了“代码评审员”和“测试员”。

Cursor 生成的代码，哪怕是它自己“Debug”过的，也并非100%完美：细节优化过度、Thinking 想的过多、上下文理解不足等会出各种各样问题。这些问题需要我更多的去阅读代码，去评审它生成的逻辑是否正确、高效、安全。

当出现问题时如果指望它解决所有的 Bug，可能又会陷入无限循环。有几次 Cursor 生成了看起来很完美的代码，但运行时就是有 Bug。我让它“再想想”，它可能会给出一些修改，但解决不了根本问题。最后还是得靠自己沉下心来，单步调试，分析变量，才定位到 BUG（这比找我自己代码的 BUG 要难了很多），而出现这种问题通常是因为我最初的需求描述或者对问题边界的理解有偏差。

AI 能加速这个过程，但不能替代我对代码的掌控力和判断力。 不去指望它全自动解决所有 Bug，很多时候需要根据它的提示，结合自己的经验去定位和修复深层次的问题。对问题理解越透彻，编程思维越扎实，就越能发挥出 AI 工具的威力。

广度，广度，还是广度。

深度，深度，还是深度。

（感觉和没说一样）

数据结构、算法、设计模式、计算机网络、操作系统这些基础知识，反而更加重要。这些基础知识可以让我知道为什么要这么设计，以及如何评价 AI 生成代码的优劣。

“Prompt 工程”能力依然重要（R1出来后被怀疑过），与 AI 高效对话、准确提问，本身就是一种“编程”。把需求清晰、准确、无歧义地传达给 AI，才能让它给出高质量的输出。

拥抱工具，Cursor 是个好帮手，但不能替代开发者，真正有效的代码，需要开发者的审慎和批判。而且 Cursor 本身也具有开发的局限性，多尝试、多体验工具，多问几个“为什么”，多思考几种可能性。

“小胜到大胜”，从小处着手，在实践中学习，利用 Cursor 去尝试做一些小项目（一句话可以实现的需求），在与 AI 协作的过程中，去了解编码过程中哪些是 AI 可以代劳的，哪些是自己必须掌握的。

最近我用 Cursor 协助重构了一个以前写的自动写文、发文的小工具，对于一些模式化的重构（比如把回调改成 Promise，或者把一些重复代码抽成函数），Cursor 做得又快又好。但对于一些涉及复杂业务逻辑的调整，我必须先自己梳理清楚逻辑，然后把清晰的需求用 Nodepad 告诉它，它才能给出有用的代码。我负责整体设计、逻辑把控和最终测试，Cursor 负责大量具体的代码编写和初步查错，效率大大提升。