会用 AI 和不会用 AI，已经是两种工程师

在过去一年里，AI 从“工具”迅速变成“合作者”。但很多工程师在使用过程中，会逐渐产生一种危险的错觉：AI 可以替代决策，甚至替代责任。

现实恰恰相反。越是能力强的 AI，越要求人类具备更强的约束能力、判断能力和信息表达能力。

如果把 AI 当成一个“无限放大的初级工程师”，那如何正确使用它，其实可以抽象成一套信息流设计问题。

我会在这篇文章中尝试用工程视角，重新定义人与 AI 的协作边界。

一、输入不是越多越好，而是越精确越好

很多人使用 AI 的第一反应是：把所有上下文一股脑丢进去。

但在工程系统里，我们很清楚一件事——冗余信息会污染信号。

AI 也是一样。

当你提供：

• 模糊需求

• 无关上下文

• 未经过滤的日志或代码

• 多轮叠加但未整理的信息

你实际上是在增加“推理噪音”。

更好的方式是：

• 提供最小完备信息（Minimum Sufficient Context）

• 明确任务边界（输入 / 输出 / 约束）

• 删除与目标无关的信息

举个例子：

错误方式： “这是我整个项目代码，帮我看看哪里有问题。”

正确方式： “在 Next.js App Router 中，Server Component 调用某 API 时出现 hydration mismatch，以下是最小复现代码 + 报错日志，请分析原因。”

AI 的质量，很大程度取决于你是否像设计 API 一样设计输入。

二、不要让 AI 决定交付结果

一个常见误区是： “帮我设计一个系统” “帮我实现一个完整方案”

然后直接复制结果进入生产。

这本质上是把“决策权”外包给 AI。

问题在于： AI 擅长生成“合理答案”，但不保证是“最优解”或“适用于你场景的解”。

工程上有一个重要原则：决策必须由责任主体做出。

正确的协作方式应该是：

• AI 提供候选方案（Options）

• AI 给出 trade-offs（优缺点）

• 人类做最终选择

例如：

让 AI： “给我 3 种实现 MCP server routing 的方案，并分析复杂度、扩展性、部署成本。”

而不是： “帮我写一个 MCP server routing 系统。”

前者是增强你的判断能力，后者是在削弱它。

三、AI 用于“理解问题”，而不是“替你完成任务”

AI 最强的能力，其实不是写代码，而是：

• 拆解问题

• 提供知识路径

• 解释复杂概念

• 构建解决空间

但“选择路径 + 验证结果”必须由人完成。

一个健康的工作流应该是：

1. 用 AI 探索问题空间

2. 自己确定方案

3. 再让 AI 辅助实现

4. 人类负责验证和收敛

如果跳过第 2 和第 4 步，就会出现典型问题：

• 代码能跑，但你不知道为什么

• 系统能用，但不可维护

• 出现问题，你无法 debug

本质上，你把“认知闭环”交给了 AI。

四、重新设计信息流：谁负责什么

可以把人与 AI 的协作抽象成一个信息流系统：

AI → 人类：

• 提供提示（insights）

• 提供方案（approaches）

• 提供可选路径（options）

人类 → AI：

• 定义明确目标（clear objective）

• 设定约束条件（constraints）

• 提供验证结果（feedback / evaluation）

关键在于：AI 负责“发散”，人类负责“收敛”。

一旦这个方向反过来，就会出现：

• AI 输出越来越随机

• 人类越来越依赖

• 最终系统不可控

五、工程化使用 AI 的核心原则

如果要总结成几条工程原则，可以是：

1. 把 Prompt 当作接口设计，而不是聊天

2. 把 AI 当作“候选生成器”，而不是“决策者”

3. 永远保留人类的最终裁决权

4. 强制建立验证环（test / review / benchmark）

5. 优先提升“提问能力”，而不是“复制能力”

从长期来看，真正的差异不会来自：“谁用 AI 写代码更快”，而是来自：“谁更懂得如何约束 AI”。

结语

AI 不会取代工程师，但会放大工程师之间的差距。

不会提问的人，会得到看似正确的答案；会设计信息流的人，会得到真正可用的系统。

在这个阶段，真正重要的能力已经不是“写代码”，而是：定义问题、约束系统、做出判断。

这三件事，短期无法外包，而这正是普通工程师和优秀工程师的分界线。