大多数工程师用 AI，但很少真正用 AI 工程化

搜索要运行的命令……

暂无评论。成为第一个评论的人。

Jeel Vankhede —— 构建、学习与工程笔记

记录开发者工具、软件系统以及更优工程工作流的构建实践。

我认识的大多数软件工程师，如今都在以某种形式使用 AI。

可能是用它调试、生成样板代码、编写测试和文档、查询 SQL、生成 shell 命令，或者快速做代码审查。有些人每天都用，有些人默默地用。即便是持怀疑态度的人，也很可能曾经把一段令人困惑的 stack trace 粘贴到聊天窗口里。

所以，我认为真正值得讨论的问题并不是：

“工程师是否在使用 AI？”

更好的问题是：

“AI 是否改变了他们做工程的方式？”

因为这并不是一回事。

真正借助 AI 做工程，要困难得多。

难点不在代码生成

我是在使用 AI 处理真实代码仓库任务时意识到这一点的。在这类任务中，一次错误的修改不只是“输出质量差”，它还可能破坏项目结构、测试、命名规范或未来的可维护性。

代码生成本身很容易。一条宽泛的 prompt 就能快速生成大量代码。有时，这些输出乍看之下甚至相当整洁。

但只有当我事先完成了那些枯燥的工程工作，结果才真正有用：明确需求、限制范围、解释约束，并决定如何验证这次修改。

难点不在于让 AI 编写代码。

难点在于提供足够的上下文，同时又不把所有东西一股脑塞进 prompt。难点在于把任务拆得足够小，在实现之前先询问各种权衡，并在审查输出时不被整洁的格式迷惑。

最重要的是，要检查这个解决方案是否真的适合放进当前系统。

这改变了我看待 AI 辅助开发的方式。

真正的能力并不是写 prompt。

而是塑造工作本身。

AI 加快的是输出，而不是验证

使用 AI 处理小任务并没有什么问题。

我会用它寻找调试方向、辅助命名、生成样板代码、构思测试、起草文档，以及探索陌生代码。这些都是很有用的任务，能够减少开发过程中的阻力。

但当人们误把更快的输出当成更好的工程时，风险就开始出现了。

AI 可以快速生成代码，也能产出看起来整洁的函数、结构清晰的文件、语气笃定的解释以及看似合理的测试用例。但它并不会自动知道这次修改是否符合你的产品、架构、约束条件，或者长期维护成本的要求。

这部分依然属于工程工作。

问题不只在于 AI 可能生成糟糕的代码。工程师本来就一直在应付各种糟糕代码——它们可能来自其他人、第三方库、教程、Stack Overflow 回答，甚至来自疲惫状态下的自己。

更大的问题是：AI 提高了输出速度，却没有同步提升验证质量。

如果代码生成得越来越快，那么模糊的需求就会变得更加昂贵，薄弱的审查会变得更加危险，缺失的测试会带来更大的痛苦，而糟糕的架构则更容易被复制，也更难以撤销。

AI 不会自动改善工程质量。

它只会放大原本就存在的工程闭环。

三思而后编码

AI 让我们更容易在尚未充分理解问题之前就开始生成代码。

任务明确时，这很有用。

任务模糊时，这很危险。

如果需求不清楚，AI 依然会生成某种结果。如果架构一团糟，AI 依然会照着这种混乱继续复制。如果工程师没有能力正确审查输出，速度就会转化为风险。

因此，我认为“AI 会取代工程师”是这场讨论中最没有意义的一种说法。

更值得讨论的问题是：

“当代码的生成成本越来越低时，工程中的哪些环节会变得更加重要？”

我的答案是：在实现之前进行清晰的思考。

AI 让那条古老的建议变得更加重要，而不是不再重要：

三思而后编码。

在要求 AI 构建之前，先定义问题。

在接受答案之前，先检查其中的权衡。

在合并修改之前，先验证其行为。

工程工作的价值正在从单纯编写代码，转向塑造一次正确的变更。

借助 AI 做工程是什么样的

对我来说，借助 AI 做工程，意味着少把它当作一个能给出神奇答案的盒子，多把它视为一个需要明确结构的协作者。

工作在实现之前就已经开始了：写清需求、缩小范围、提供有效的上下文、询问风险，并要求它先给出计划，再编写代码。

实现完成后，责任会重新回到工程师手中：审查 diff、运行检查，并判断这次修改是否真的适合放进系统。

一个有效的 AI 辅助工作闭环可以很简单：

需求 → 缺口 → 计划 → 小步修改 → 审查 → 检查 → 记录

这并不是 AI 开发最光鲜亮丽的版本。

但它更接近真正的工程。

因为真正的工程并不只是产出代码。

而是产出可靠的变更。

软件工程的下一次转变，不会围绕谁能生成最多的代码展开。

这种优势已经在变得越来越廉价。

更难获得的优势，是知道应该构建什么、它应该如何融入现有系统，以及如何验证它确实能够正常工作。

这正是 AI 辅助工程开始变得有趣的地方。

不是因为 AI 取代了工程判断。

而是因为它让工程判断变得更难以跳过。

大多数重要的工程工具，都是在团队围绕它们改变工作流之后，才真正发挥出价值。Git 改变了协作方式，Cloud 改变了基础设施，CI/CD 改变了软件交付。

AI 比这些变革涉及的范围更广、更混乱，发展速度也更快，因此我不想假装它一定会沿着完全相同的路径演进。

但其中的经验依然令人熟悉：

围绕工具构建的工作流更加重要。

从 AI 中获益最多的工程师，不一定是使用 AI 最频繁的人。他们会是那些能够围绕 AI 设计出更好闭环的人：更清晰的规格说明、更小的变更、更严格的审查、更完善的测试，以及更加审慎的决策。

所以没错，现在大多数工程师都在使用 AI。

但只有少数人开始真正借助 AI 做工程。

在这个阶段，最优秀的工程师可能并不是写 prompt 最快的人。

他们可能是那些能够先让问题慢下来，再让实现快起来的人。