Ask HN：AI 辅助编程需要哪些新的软件工程经验法则
以前我想成为更好的软件工程师时，会研究封装、关注点分离、组合优于继承、模块化与面向对象对比这些概念。但如今，随着 AI 辅助编码越来越普遍，我觉得缺少一套新的启发式方法，来帮助判断用 AI 写代码哪些做法对、哪些错。我自己就在改进中不断踩进一些新型反模式，再慢慢纠正。
举个例子：Cursor 默认没法直接联网，它对各种库的了解仅限于训练数据里包含的内容。作为一名软件工程师，你可能会发现，最短平快的方式是让 Claude 直接把代码写出来——但这样写的代码往往没考虑所有边界情况。如果你不主动引导 Claude 去选择合适的库，到头来你就会被自己复现的那些库代码里层出不穷的边界问题卡死，进退两难。
我很难用语言准确描述，但每次用 Composer 时我一定会逐行检查 diff，常常会冒出这样的念头：“这东西看着就不该出现在我的代码库里。”然后我会去找一个真正合适的库来替换。
如果让我指导一个第一次用 Cursor 的软件工程师，这就是我最想指出的那个表面上很诱人的反模式——有点像刚接触面向对象的新手容易过度抽象一样。
想解决这个问题，大概得先有一位比我更资深的人来写一篇深刻的长文。我很想读到这样的文章，也找过，但还没找到。
所以现在，我更想请大家来分享一下：当你大量使用 Cursor 以及同类编辑器之后，你学到了哪些最重要的软件工程经验？