为什么我写了 AI 编码指南，你也应该写

Source: Dev.to

招聘经历

我们最近聘用了一个我们已经很熟悉的人。
我们之前一起工作过，信任他，也喜欢他解决问题的方式。他拥有那种创业者的思维——看到需要做的事就直接去做。这正是我们雇用他的主要原因。

他经验并不是非常丰富，而且经常使用 Cursor。这并不是问题，因为我们也在使用。Cursor 是一个很棒的工具，它显著加快了开发速度。速度是每个创业公司的圣杯。

不过我们开始注意到的，并不是速度或产出。事情在运行。PR 能顺利通过。但解释有时变得很薄弱。改动更快了，但当出现问题时，推理和解释并不明确。

这不仅仅是他——我觉得我们所有人都有同样的感受。

AI 让人很容易在没有彻底思考代码到底在做什么的情况下继续前进。这是一把双刃剑，不能随意使用。

问题不在于使用 AI——而在于对 AI 的依赖

有很多公司直接禁止团队使用 AI 的恐怖案例。这并不是要限制任何人或告诉大家“少用 AI”。那样的做法偏离了重点。

当然，AI 有时会输出糟糕的代码——所谓的AI slop——但风险并不在这里。

真正的风险是逐渐失去思考、推理以及解释自己决策的习惯。

如果你无法解释一段代码的作用以及它存在的原因，那么它是多快生成的也无关紧要。

我写指南的原因

我写 AI 指南主要是为自己——也是为我们的团队。

• 不要让任何人变慢。
• 不要限制工具的使用。
• 确保我们不会把思考外包。

核心思想很简单：

即使代码是 AI 写的，你仍然对交付的代码负责。

AI 的优势在于：

• 加速实现
• 减少样板代码
• 帮助探索解决方案

但它不应取代理解。

我想要保留的东西

我们招聘人是因为他们会思考、推理并承担责任。AI 应该是对这些能力的提升和放大，而不是慢慢侵蚀它们。

这些指南的存在是为了让我们保持有意图，并且在六个月后仍能解释我们的系统，而不是仅仅交付“今天能用”的东西。

就这些。

差点忘了，这里是阅读实际指南的链接：