會用 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 不會取代工程師，但會放大工程師之間的差距。

不會提問的人，會得到看似正確的答案；會設計資訊流的人，會得到真正可用的系統。

在這個階段，真正重要的能力已經不是「寫程式碼」，而是：定義問題、約束系統、做出判斷。

這三件事，短期無法外包，而這正是普通工程師和優秀工程師的分界線。