別只用 AI 把事情做快一點，我們可以更有野心

工程師很習慣一步一腳印。

遇到問題，先把需求拆小、控制風險、完成可以驗證的部分，再慢慢往前推進。這套工作方式沒有錯，甚至是過去能夠穩定交付軟體的重要原因。

但在 AI 時代，它也可能成為一種絆腳石。

問題不在於我們做事太謹慎，而是我們可能仍然用過去的成本，決定今天值得嘗試什麼。

當寫程式、分析資料、製作介面、查找資訊與反覆驗證都需要大量人力時，縮小問題範圍很合理。然而，當 AI 已經能操作工具、執行程式、閱讀大量資料，甚至跨越不同專業完成工作，我們卻可能還只是請它「幫我補完這段程式碼」。

這等於拿到一種新的能力，卻只用來把舊工作做快一點。

不要只問下一步，要問最後想達成什麼

Felix Rieseberg 在〈How to be more ambitious: A tutorial for humans with models〉中，從速度、高度、深度與廣度四個方向，談如何更有野心地使用 AI。

📌 其中「速度」最容易理解：原本需要一天完成的工作，現在幾個小時就能完成。

但真正值得重新思考的，是另外三個方向。

📌 第一個是高度，也就是不要只讓 AI 執行眼前的步驟，而是讓它負責達成更上層的目標。

以前，我們可能會請 AI 修正應用程式的一個 Crash。再往上一層，則可以要求它持續找出並修正所有 Crash，讓應用程式維持穩定。

這兩個要求看起來只差一句話，實際上卻代表完全不同的工作方式。

AI 必須能取得錯誤報告、理解版本與 Commit 的對應關係、重現問題、修改程式碼，並在不同環境中驗證結果。人的工作也從逐項交辦，轉變成替 AI 建立一套可以持續完成任務的環境。

所以，在把工作交給 AI 之前，可以先問自己：

我現在要求的，是一個步驟，還是我真正想得到的結果？

不是把任務做大，而是往下做深

📌 第二個方向是深度。

請 AI「像資深工程師一樣思考」，通常只會讓回答多出一些專業詞彙，不一定真的改變工作方法。

要讓 AI 把事情做深，不能只指定角色，還要要求它使用專業人士真正會使用的資料、工具與驗證方式。

例如，不只是請 AI 根據整理過的報表提出看法，而是讓它接觸原始資料，使用適當的統計方法檢查假設；不只是問它系統為什麼變慢，而是讓它建立效能基準、執行 Profiling，找出瓶頸並驗證改善幅度。

更重要的是，不要讓 AI 自己宣告工作完成。

程式是否正確，可以透過測試驗證；效能是否改善，可以透過 Benchmark 確認；介面則可以透過實際操作與畫面檢查來評估。目標越有野心，越需要一個來自模型之外的判斷標準。

這並不是放棄工程師原本重視的嚴謹，反而是把這份嚴謹用在更大的目標上。

不要只交付名詞，先說清楚要發生什麼事

📌 第三個方向是廣度，也就是讓不同領域的方法共同處理一個問題。

我們很容易用產出物來描述工作：

• 做一份簡報
• 寫一篇報告
• 建立一個儀表板

但這些說的都只是要交付什麼，並沒有說明我們真正希望促成什麼結果。

一份季度簡報，真正的目的可能是：

讓一群時間有限的人，在三十分鐘內理解事情的因果，並在資訊不完整的情況下做出決定。

當問題改成這樣，AI 就不只需要簡報製作能力。它可能還需要資料分析、新聞寫作、資訊設計、風險評估，甚至反方查核的方法。

這裡的重點不是讓 AI 扮演很多角色，而是要求它採用這些專業真正使用的方法。不是「請你假裝是一位調查記者」，而是「請你查核資料來源、尋找矛盾，並區分事實、推論與尚未證實的假設」。

真正需要跨越的，是我們心中的成本上限

工程師過去養成的習慣，通常建立在一個合理前提上：時間有限、人力昂貴，所以必須先縮小範圍。

這個前提並沒有完全消失，但它正在改變。

許多以前不值得投入的嘗試，現在可能只需要讓 AI 多嘗試幾輪，就能看出是否值得繼續；以前需要湊齊不同專業的人才能開始的工作，現在可以先由 AI 建立原型，再交給真正的專業人士檢查。

我們需要保留工程師重視的拆解、測試與驗證，卻不必繼續用過去的執行成本限制目標。

下一次準備請 AI 完成一項工作時，或許可以先問：

如果時間與人力不再是最主要的限制，我真正想完成的是什麼？

接著再追問：

專業人士會使用哪些原始資料、工具與方法？
還有哪些領域能為這個問題帶來不同的解法？
除了我和 AI 之外，什麼證據能證明結果是對的？

AI 帶來的最大改變，或許不是讓我們更快抵達原本的目的地。

而是讓那些以前根本不會列入選項的目的地，第一次變得值得出發。

參考

💭 想把 AI 用得好，你得再瘋一點