如何把完整需求拆成自己能理解、實作與驗證的問題？

昨天談到自動恢復的效益與成本。決定要做之後，接下來就是把需求轉成實際的程式修改。

「完成自動恢復」是一個目標，但開發時需要知道的更具體：要讀哪些資料、依什麼條件判斷、接到哪段既有流程，以及怎麼確認結果正確。

AI可以協助分析與實作，工程師則需要掌握這些部分如何組成完整功能。看懂每個檔案的修改，還要能說清楚它們之間的關係。

沿著流程，把要處理的事情拆開

回到訂單自動恢復，可以先整理成三個部分：

1. 取得資料：找出待確認的訂單，取得原本的庫存操作識別。
2. 判斷下一步：根據庫存查詢結果與目前訂單狀態，決定接續處理、等待或補送。
3. 執行後續行為：沿用原操作識別進行符合條件的補送，並將已完成的結果接回既有訂單流程。

接著對照現有程式，找出每一部分的實作位置。哪些能力已經有了、哪些需要調整、哪些需要新增，修改範圍就會逐漸清楚。

這也能幫助我們發現遺漏。只想到「查詢庫存後更新訂單」，容易漏看原本成功處理時會觸發的出貨與通知。把後續行為列出來，才會記得追查恢復流程應該接到哪裡。

拆解問題，是把一個目標轉成能逐一確認的處理內容。

看懂依賴，才能安排實作順序

拆開之後，還要知道各部分需要什麼，才能正確執行。

查詢庫存結果需要原操作識別；決定是否補送，需要查詢結果與目前訂單狀態；接續訂單處理，則需要知道既有流程的使用條件與副作用。

這些依賴會影響實作順序。先確認資料從哪裡取得、既有流程從哪裡接入，後面的判斷與執行才有依據。

開發時，我會優先釐清會影響後續做法的地方。尤其是共用流程的行為，一旦理解錯誤，後面寫得越多，需要回頭調整的範圍也越大。

這份整理可以很簡單。幾個修改點，加上它們之間的關係，就能幫助我們掌握接下來要做的事。

拆到能理解、能檢查就好

拆解的尺度，可以用三個問題判斷：

• 這一段負責什麼？
• 它需要哪些資料與前提？
• 要看什麼結果，才能確認它做對了？

能回答這些問題，就有了可以實作與討論的範圍。仍然只能用「把異常處理好」帶過的地方，就需要繼續釐清包含哪些行為。

拆得過細也有成本。每個欄位、方法與判斷分支都列成工作，容易讓人埋在細節裡，反而看不見整段流程。拆分應該幫助理解，粒度以自己能掌握、團隊能討論為準。

AI提出的拆法，也需要工程師判斷

把規格、程式碼與背景提供給AI，可以請它整理修改範圍、依賴關係與驗證方式，再接著實作。

審查方案時，我會沿著前面的流程核對：取得的資料是否足以判斷？處理條件是否符合規格？後續行為是否接回正確位置？

尤其要看清楚它打算沿用哪些既有程式。方法名稱相近，不代表使用條件相同；另外寫了一套處理邏輯，也要確認是否有必要，以及有沒有漏掉原本的規則。

掌握這些關係，才能針對具體範圍和AI討論。發現判斷條件有問題，就回到那段邏輯與依據；調整共用流程，就檢查受影響的呼叫端。每次修改的原因和影響都能追得回來。

即使AI完成了大部分程式，工程師仍要能解釋整個方案如何運作。這份理解，會直接影響我們能不能發現遺漏，以及判斷修改是否合理。

最後，把拆開的部分接回需求

驗證時，可以沿著相同的拆分，分別檢查資料篩選、條件判斷與後續處理，再確認完整流程。

以「庫存已扣減，但回應遺失」這筆訂單為例，恢復流程應該找到正確資料、查明原操作的結果，並接續訂單處理。庫存不能再次扣減，應有的下游作業也不能遺漏。

這個完整情境，能檢查各部分是否接得起來。發生問題時，也能沿著資料取得、判斷與執行逐段追查，縮小需要檢查的範圍。

AI可以協助產生測試與分析結果，工程師則要核對測試是否涵蓋了這些關係，以及預期結果是否符合需求。每一段各自正確，還要確認它們使用相同的資料、狀態與處理規則。

**在AI時代，拆解問題的基本功，讓工程師能掌握方案的組成與依賴，知道該檢查哪裡，也能判斷整合後是否真正完成需求。

從序言提出「AI時代，工程師還需要懂什麼」，到這幾天沿著一顆「重新處理」按鈕，追問使用者的困難、核對系統限制、找出隱藏的假設，再比較做法、拆解問題，其實都圍繞著同一件事：我們要知道自己正在解決什麼，以及為什麼這樣做。

AI 能協助分析與實作，但工程師仍要理解需求、衡量取捨，並確認結果是否解決了使用者的困難。這些基本功，讓我們在和AI協作時有依據做出判斷。否則忙了一輪，最後可能只換來使用者一臉嫌棄。