也可以说最近很火的 code Agent，注意就是一些辅助编程
AI 编辑器
认识到这类编辑器的优点和缺点
我们是应该追求先想清楚再动手，还是先动手搞出东西来之后再慢慢改？
我见过两种极端的使用方式。第一种是“规划魔”：进入 Plan Mode 后，和 AI 讨论个把小时，上下文用光两三次，从架构设计到具体实现，从错误处理到性能优化，事无巨细地规划每一个细节。等到真正开始写代码时，基本上 AI 就是照着计划一步步执行。另一种则是“莽夫流”：上来就是一句“给我实现一个 XXX 功能”，然后就看着 AI 噼里啪啦地写代码，写完了发现不对再改，改完了又发现新问题，如此循环往复。
哪种方式更好？也许乍看下来先规划再执行更好？但我的答案可能会让你失望：要看情况。
如果你是个经验丰富的开发者，对项目架构已经有了清晰的认识，那么先进行充分的规划确实能让后续的实现更加顺畅。特别是对于那些需要遵循特定架构模式的既有项目，Plan Mode 能帮你确保 AI 生成的代码符合项目规范。我自己就经常在 Plan Mode 里和 AI 讨论：“我们的项目使用了 MVVM 架构，新功能应该怎么拆分到各个层？” “这部分内容已经有类似实现了，你需要参考现有实现和模式”， 这种讨论能让 AI 更好地理解项目的整体结构，生成的代码质量更高，开发者对具体代码的掌控也更好。
但如果你对某个技术栈完全不熟悉，或者正在做一个全新的探索性项目，那么“先干起来”可能反而是更好的选择。这种情况下，很多时候你根本不知道自己不知道什么。所以与其空想，不如让 AI 先写个原型出来，跑起来看看效果，发现问题再迭代。这种方式特别适合那些“短平快”的项目，或者你只是想快速验证一个想法。
我个人的偏好？我更喜欢先进入 Plan Mode，和 AI 讨论后再开始实施。对我来说，日常维护已有代码库的工作是占大头的，我需要更稳定和可靠的迭代，先 plan 有利于我掌控全局。但在接触新技术栈时，我也不太愿意直接莽起来。不同技术栈下，很多开发的理念是共通的：如何组织可维护的架构（不仅为了人类，也为了 AI 今后进行维护，合理的组织结构还是必要的），如果调度和安排代码以保证高效，各个模块的连接方式等。就算是新技术栈，适当的讨论相比无脑梭哈，也提供了一种更有效的学习方式。但是这样做的代价是慢，如果着急上线功能，或者写的是可以无视代码质量的“快消品”，那么事无巨细的 plan 可能就不太适用了。
最后想说的是，Plan Mode 还有个隐藏的好处：它能帮你整理思路。有时候你觉得自己想清楚了，但真要说出来或者写下来，才发现还有很多细节没考虑到。和 AI 的对话过程，其实也是一个自我梳理的过程。这算是“橡皮鸭调试法”的变种，在 vibe coding 时代依然很有价值。
另外在使用上一派是“小步快跑”：每次只让 AI 完成一个小功能，验证没问题后再进行下一步。另一派是“一步到位”：直接把整个需求扔给 AI，让它一次性生成所有代码。更极端的，还有人会开启 --dangerously-skip-permissions 模式（也就是所谓的 yolo 模式），让 AI 可以不经确认就执行任何操作。
两种方式我都深度尝试过，结论是：如果能选，小步迭代往往总是更好的选择。
认清不足
使用经验
如果是一个新项目，可以先和他认真的讨论下使用的技术，状态管理和项目规范
rules 用法
分为 projectrules 和userrules
维护在 cursor/.rules 下，注意文件名的统一，方便维护