搞清楚問題，比解決問題更難
剛開始工作的時候，我以為工程師最大的挑戰是技術。怎麼讓 agent 跑得更準、怎麼處理各種 edge case、怎麼優化 latency 和 cost — 我把大部分心力花在這些事情上，覺得只要技術到位，產品自然會好。
做了幾個月之後，我發現自己錯了。真正卡住我的，從來不是技術，而是「到底要做什麼」。
那段時間我負責開發一個文件審閱的 AI agent，讓使用者能透過 AI 自動檢查文件裡的問題和風險。我是主要的開發者，從需求釐清、架構設計到實作都是我在處理。
這個功能的起點來自使用者的直接回饋 — 有人跟我們說「如果能先幫我把整份文件 review 一遍，給一個初步的風險偵測就好了」。聽起來很明確，對吧？我當時也這樣覺得，所以基於這個需求設計了一個整份文件審閱的架構，假設使用者會按照固定流程審閱文件，花了大概一兩週做出了一個 MVP。東西能動了，也交給 domain expert review 了，我當時覺得方向應該是對的。
結果拿給不同的 domain expert 看之後，他們對「風險識別」的結果評價差很多。同一份文件、同一個分析結果，有人覺得抓到了重點，有人覺得完全不是他在意的東西。這時候我才意識到一件事 — 很多時候 user 自己也不清楚他們需求背後真正的問題點。他們會覺得 AI 什麼都能做到，所以提出來的需求聽起來合理，但其實不夠精準。我跟同事是在 MVP 給 user 看了之後，才一起發現這件事情的。
更現實的問題是，要幫每種文件類型預先建立審閱規則根本不切實際 — 種類太多了，每個都需要 domain expert 投入大量時間去定義檢查項目。這意味著我花了近兩週開發的架構，在產品層面走不通。
接下來的一個禮拜非常曲折。週一團隊討論後決定改成對話式互動 — 讓使用者透過聊天的方式要求 AI 做事，搭配檔案庫讓 agent 存取相關文件。但到了週五，經過更多討論之後，又繞回整份文件自動審閱的方向。
一個禮拜轉了兩次方向，老實說我蠻挫折的。我跟同事深入分析了反覆的原因，才找到根本問題：我們的 target user profile 是模糊的。我們同時想滿足資深使用者（需要精細的內容比對）和初階使用者（需要基礎的風險提示），這些需求其實分散在不同的角色上，導致功能設計不斷搖擺。
認清這件事之後，我做了幾個調整。
第一，收斂使用者角色。不再試圖做一個「所有人都能用」的功能，而是先聚焦在最明確的場景 — 文件基礎品質檢查。這是所有使用者都需要、而且行為模式相對一致的任務。
第二，定義驗收標準。在開發的過程中，我意識到一個關鍵的盲點 — agent 的驗收標準不夠清晰，導致根本沒辦法客觀評估做出來的東西好不好。而這個問題的根源，是我們對要解決的問題本身理解不夠深入。
第三，用評估驅動開發。我開始要求自己在寫 prompt 和 tool 之前，先定義「什麼算成功」，用具體的測試案例來驅動開發，不再靠感覺迭代。
後來品質檢查的功能順利完成了初版，但在長文件上遇到了 performance 瓶頸 — 檢查項目一多，成本和準確度完全不成比例。這讓我進一步建立了一個功能開發前的評估框架：先問自己三件事 — 必要性（這真的需要 AI 嗎？能不能先用 rule-based 的方式預篩？）、成本效益、performance 與使用體驗。如果這三個問題都回答不清楚，那大概還不是動手寫 code 的時候。
最後團隊收斂到一個方向 — 讓使用者透過自然語言與 AI 互動做文件審閱。這個方向在之後順利交付了 end-to-end 的可用版本。繞了一大圈，但回頭看，每一次的轉向都不是白費的，是這些嘗試和碰壁讓我們最終找到了對的方向。
回頭看這段經歷，最大的收穫不是完成了什麼功能，而是三個認知上的轉變。
第一，使用者說的需求不能照單全收。User 會覺得 AI 什麼都能做到，所以他們提出的需求聽起來合理，但不一定精準。真正要做的是透過訪談去理解他們的工作流程，找到需求背後的問題。而且問題不能過度發散，要聚焦在使用者的具體行為模式上。
第二，先定義問題，再設計解法。從需求直接跳到實作，只會浪費大量時間。我後來養成的習慣是：先釐清 target user → 定義具體場景 → 設定驗收標準 → 再開始動手。
第三，agent 開發需要工程紀律。Agent 的行為有 non-determinism，不能靠感覺開發，必須建立明確的驗收標準和評估機制，才能客觀衡量品質。
這段經歷讓我從一個「拿到需求就開始寫 code」的工程師，變成會先問自己「我們到底在解決誰的什麼問題」的開發者。雖然聽起來像廢話，但真的是自己踩過幾次坑懷疑人生之後，才體會到這句話的重藥性。