大多数工程师都在使用 AI，但很少有人能用 AI 进行工程化。
现在大多数软件工程师都在使用 AI。
他们用它来调试、编写测试或生成 SQL 查询。使用 AI 很简单，但利用 AI 进行工程化则难得多。
在处理真实的仓库任务时，我发现了一个问题。一个错误的改动不仅仅会导致糟糕的输出，它还会破坏你的架构、测试以及未来的可维护性。
代码生成部分很容易。一个宽泛的提示词（prompt）就能快速生成代码，乍一看还挺整洁。
只有当你先完成那些枯燥的工作时，才能获得有用的结果。你必须：
- 定义需求。
- 限定范围。
- 说明约束条件。
- 决定如何验证改动。
核心技能不在于编写提示词，而在于塑造工作内容。
AI 提高了输出速度，但并没有提高验证质量。如果代码生成变得更快，那么不明确的需求成本就会更高，而薄弱的代码审查（review）也会变得更加危险。
AI 会放大你现有的工程循环。
如果需求不明确，AI 依然会产出一些东西。如果架构很混乱，AI 也会复制这种混乱。如果你无法审查输出结果，那么速度就会变成一种风险。
问题不在于 AI 是否会取代工程师，而在于：当代码变得廉价时，工程中的哪些部分会变得更加重要？
我的回答是：在实现之前进行清晰的思考。
AI 让那些老生常谈的建议变得更加重要：
- 三思而后行，一次写对代码。
- 在让 AI 构建之前，先定义问题。
- 在接受答案之前，检查权衡（tradeoffs）。
- 在合并（merge）之前，验证行为。
工程正在从“编写代码”转向“塑造正确的改动”。
把 AI 当作一个需要结构化引导的协作伙伴。一个良好的循环应该是这样的： 需求 → 缺口 → 计划 → 微小改动 → 审查 → 检查 → 记录。
真正的工程不在于产出代码，而在于产出可靠的改动。
优势不在于生成最多的代码，而在于知道该构建什么，以及它如何融入你的系统。
最终胜出的工程师不会是写提示词最快的人，而是那些能围绕工具设计出更好工作流的人。
Source: https://dev.to/jeelvankhede/most-engineers-use-ai-few-engineer-with-it-3pd
Optional learning community: https://t.me/GyaanSetuAi