Cursor 弃之可惜，食之无味？

摘要

1) 一句话总结 本文探讨了开发者在使用 Cursor 等 AI 编程工具时的痛点与顾虑，并提出了通过版本控制、代码审查、任务拆分和自动化测试来规避风险、扬长避短以提升开发效率的实用策略。

2) 关键要点

3) 风险与不足

现在使用 Cursor 这类 AI 编辑器有几种态度，一种是觉得非常好用离不开的；一种是不用的，要么嫌贵要么认为会产生依赖心理不利于技术成长；还有一种是想用却觉得不好用，“弃之可惜，食之无味”。

比如网友 Tang 的分享很有代表性：“不知道是不是因为我主要写后端。你们知道的，如果计算金额错一点，那都是灾难。所以，我对它生成得代码，如果不加思索的去接受，那可真不放心。如果一个个检查呢，又觉得费劲。然后，感觉还不如自己写。”

Tang 说的没错，不假思索接受不放心，一个个检查又费劲。

我在让 AI 帮我写代码时也有这种顾虑，但我会采取一些手段去规避这种问题：

使用 Git 管理代码版本，每次用 Cursor 之前 Commit 一下，这样可以清晰的跟踪和 Review AI 的变更，有问题也好回滚。
会对 AI 写的代码 Review，不是无脑接受，就像在团队协作时，团队成员之间相互 Review 代码一样，看看还是放心些。
每次任务比较单一，一次只是某个模块的特定修改，这样相对好 Review，大概看看就可以。
让 AI 写测试代码，像后端代码，如果金额错了会影响很大，但这不能仅仅依赖人工审查，无论是人写的代码还是 AI 写的代码都可能出错，最好的办法是写大量的自动化测试代码覆盖到各种场景。而且 AI 其实很擅长写测试代码，输入输出定义好就能帮你生成相应的测试代码，有了充足的测试覆盖，就不会担心 AI 出乱子，就算写错了也能及时发现。

这样当然也麻烦，但相对来说比起自己手写效率还是高多了。

今天和一个同学一起吃饭，问起他用不用 AI 编程，他说不用，因为他要实现的很多最新的金融相关的逻辑，AI 没训练过，用了 o1 pro 都做不对，所以就没用了。

其实这中规则没训练过的问题也好解决，只要在提示词中，将规则用文字描述清楚，然后一起提供给 AI，应该是能生成符合规则的代码的。另外也要配合充足的测试代码会比较好。

举的这两个例子，主要是想说明现阶段 AI 确实有其局限性，并没有网上吹的那么厉害，但同样的，不建议因为这种期望和现实的落差就放弃不用，而是看看能在哪些地方用它提升效率，哪些方面还不能依赖它，扬长避短是最好的。

想做一件事情总有办法，不想做一件事总有借口。如果我们认定 AI 是能提升效率的，那么遇到困难总能想办法克服，否则总能找到理由不去用它，而现在还没到 AI 迁就我们的时候，还得我们去迁就 AI，迁就一点能帮我们提升效率帮到自己也是很好的。