开发者实战：AI 编码的助力与失效边界

AI 现在在开发者圈子里无处不在，但大多数关于 AI 的文章要么停留在兴奋，要么停留在恐惧。

这不是其中的某一类。

这是我在日常开发中实际如何使用 AI、它做得好的地方、哪些地方失败得很厉害，以及我必须用艰难的方式学到的规则。

没有炒作。没有供应商的宣传。只是在真实工作中存活下来的模式。

AI 每周都在帮助我的地方

1. 分解陌生的代码库

当我打开一个新项目时，AI 在一件事上很擅长——这件事是人类讨厌做的。

我粘贴代码的小部分，然后问：

这段代码解决的是什么问题？

这段代码做了哪些假设？

如果我删除这个，什么会崩溃？

这不是关于信任答案。这是关于加快理解速度。

这替代了第一小时的盯着看和猜测。

2. 生成初稿，而不是最终答案

AI 擅长生成初稿，但在最终决策上很糟糕。

初始函数签名

样板配置文件

我从不直接发布 AI 的输出。

我把它当作一个打字快但误解上下文的初级开发者。

3. 比搜索更快地解释错误

在堆栈跟踪和晦涩的错误方面，AI 才是最闪闪发光的。

与其将错误粘贴到搜索引擎中并跳过 2019 年的博客文章，我会粘贴：

我试图做的事

大多数时候，它在几秒内给我一个方向。

不是一个修复。是一个方向。

AI 实际上让事情变得更糟的地方

1. 自信地给出错误的架构建议

这是最危险的失败模式。

AI 会自信地建议：

过度工程的抽象

不符合你规模的模式

过时或不相关的库

如果你盲目跟随这些，你稍后要付出代价。

我学到的规则：除非你已经理解为什么它可能是错的，否则永远不要接受架构建议。

2. 幻觉的 API 和虚假的细节

这仍然比人们承认的更频繁地发生。

不存在的函数。看起来真实的标志。感觉合理的配置选项。

如果 AI 不能指向官方文档，我假设它在猜测。

3. 长期可维护性的盲点

AI 优化的是让东西现在工作。

人类仍然必须维护代码。

最终让 AI 对我有用的规则

这些是我希望有人更早告诉我的规则。

永远不要让 AI 做出决定。让它生成选项。

将输出视为草稿，永远不是答案。

保持上下文精简。大提示会产生自信的胡言乱语。

验证任何涉及安全、金钱或用户的东西。

如果你不能自己解释输出，你还没完成。

AI 加快了打字和思考的速度。

它不能替代判断。

没有人谈论的真正转变

最大的改变不是生产力。

是认知负荷。

AI 减少了开始、探索和实验的心理消耗。

但它增加了批判性思维的重要性。

你作为开发者越优秀，你从中获得的价值就越大。你越不够优秀，它就越危险。

AI 没有取代我的工作。

它取代了我对空白页的焦虑。

这很有用，只要我保持控制。

如果你以不同的方式使用 AI，或者你不同意其中任何一点，我真的很想听听你如何使用它。