判斷轉折 · 13 則
原本怎麼想、發現什麼問題、為什麼改變、後來怎麼做。每一則都附上原文。
原本收到需求，第一個問題是：怎麼做？
後來先問為什麼要做，再把需求往回拆到業務問題。
01我原本怎麼想
最早聽到的需求都很正常：讓客戶可以篩選健檢項目、要有健檢推薦、要能線上預約、要讓選擇方案更方便，甚至要 AI 線上解決客戶問題。
02發現什麼問題
真正去看客戶怎麼選，才發現一個很基本的問題：客戶根本不知道自己該選什麼。
03為什麼改變判斷
如果是這樣，還做一個更好用的篩選器就有點奇怪，因為我們只是讓一個不知道怎麼選的人，更方便地自己選。
04後來怎麼做
現在收到需求，我會先問：為什麼要做？使用者到底卡在哪裡？這一步真的需要他自己判斷嗎？資料和規則能不能先幫他排除一些選項？
原本好的 AI 提案，是把技術與成果呈現得更完整。
後來讓經營者看清楚：哪些價值已經被證明，哪些還沒有。
01我原本怎麼想
以前我會覺得，投獎就是要把亮點放大。好的 AI 提案，就是把技術和成果講得越完整越好。
02發現什麼問題
簡報改到第 9 版，突然發現一件有點尷尬的事：我們一直努力證明 AI 做了多少事情，卻差點忘記證明，這些事情究竟創造了什麼價值。
03為什麼改變判斷
效率變好、用的人變多，有多少真的是 AI 帶來的？哪些已經驗證，哪些只是剛好同時發生，哪些只是我們的期待？自己沒先想清楚，很難說服別人。
04後來怎麼做
改到後來，我反而一直在刪：聽起來很厲害、但證據還不夠的說法，都拿掉。
原本先討論、釐清需求、確認規格，再開始開發。
後來先做一版給大家挑毛病，更早看見彼此理解的差異。
01我原本怎麼想
我們習慣從需求開始：先討論方向、釐清需求、畫流程、確認規格，再安排開發。
02發現什麼問題
自己動手做完才發現，連提出需求的人，都不一定能在一開始就清楚描述自己真正想要什麼，包含我自己。很多想法講了半天還是很抽象，直到看到畫面才知道。
03為什麼改變判斷
當做出第一版越來越便宜，最浪費的反而可能是一直停留在想像裡。
04後來怎麼做
現在更常問：「我們能不能先做一版，讓大家看看哪裡不對？」讓 PM、設計、工程師和業務早點看到同一個東西。
原本PM、工程、QA 都完成了，專案就算順利。
後來開發前先定義成功的樣子，驗收時看問題有沒有改善。
01我原本怎麼想
PM 說需求完成了，工程師說開發完成了，QA 也確認測試通過了。從專案管理的角度看，似乎一切順利。
02發現什麼問題
我心裡忍不住想：這個功能，真的解決了我們原本想解決的問題嗎？答案是，可能沒有。
03為什麼改變判斷
「需求沒有這樣寫」「這是前面交接的」「系統本來就有限制」，這些可能都是真的。但每個環節都照流程運作，最後卻沒解決問題，反映的就不是單一環節的失誤，而是整個團隊的工作方式。
04後來怎麼做
開發前先定義成功的樣子：不是「新增匯出報表功能」，而是「讓原本兩小時的資料整理，目標縮短到十分鐘」。
原本主管直接給答案，事情比較快。
後來給 Context，讓同事自己判斷、做決定、承擔結果。
01我原本怎麼想
我習慣快速分析問題、辨識風險，再找出解決方案。主管直接說「照我說的做」「這個我來決定」，事情通常會變快。
02發現什麼問題
事情會變快，但人不一定會變強。
03為什麼改變判斷
幫團隊把事情做完很容易；把一個人帶到可以自己做判斷，難很多。
04後來怎麼做
現在常問：你覺得真正的問題是什麼？你有哪幾個方案？每個方案的風險是什麼？如果是你，你選哪一個？為什麼？很多時候我心裡已經有答案，但會忍住。
原本第一個直覺：這個流程，哪一步可以放 AI？
後來先問這一步需不需要存在，再讓 AI 接手剩下的工作。
01我原本怎麼想
面對一條「需求提出 → 多層確認 → 人工整理 → 開發 → 測試 → PR → 再確認」的流程，大家第一個直覺通常是：哪一步可以放 AI？
02發現什麼問題
這幾年在企業內推 AI，我越來越覺得：很多公司不是 AI 做得不夠快，而是太快把 AI 加到一個本來就不該存在的流程上。
03為什麼改變判斷
馬斯克的五步驟提醒了順序：先質疑需求、刪除流程、簡化，然後才加速，最後才自動化。
04後來怎麼做
現在會先問：這一步真的需要存在嗎？哪些工作根本不需要人做？哪些決策應該保留在人？
原本每個需求單看都有道理，就做成平台上的功能。
後來先標準化流程，把人的判斷留給真正值得判斷的地方。
01我原本怎麼想
BU 說：「我要這個功能，這個功能很簡單。」單看每一個需求，其實都有道理。
02發現什麼問題
產品往下拆，才慢慢冒出「這個情況不一樣」「這類客戶要另外處理」「這裡還是要人工判斷」，一個看起來很簡單的功能越拆越大。
03為什麼改變判斷
人工作業的世界，模糊地帶可以靠經驗撐住，平台不行。
04後來怎麼做
碰到功能需求，先往前問：哪些流程應該先標準化？哪些規則可以透明化？哪些特殊情境可以被消掉？哪些判斷真的值得留給人？
原本有 API、資料傳得過去，工程師接起來就好。
後來有人站在整條業務流程驗收，連異常情境一起測。
01我原本怎麼想
一開始討論通常很順：「有 API 嗎？」有。「訂單可以傳過去嗎？」可以。「物流狀態可以回傳嗎？」沒問題。聽起來好像工程師把 API 接起來就好了。
02發現什麼問題
真的開始整合，才發現串接成功只是問題的開始：訂單取消但物流已接單、分批出貨怎麼回寫、Timeout 但對方其實成功了要不要重送、兩邊資料不一致以誰為準？
03為什麼改變判斷
這些都不是測試 API 回傳 200 OK 就能解決的。真正容易出問題的，往往是取消、重送、超時、部分成功，以及人工介入後的資料同步。
04後來怎麼做
現在特別在意 End-to-End Testing：不能各廠商測完自己的就算，要有人站在整條業務流程確認，而且不能只測 Happy Path。
原本從技術開始：模型準不準、能不能預測、能不能做 Agent。
後來從健檢異常到行為改變，整條鏈走通，AI 才不會只停在 Demo。
01我原本怎麼想
以前很容易從技術開始：模型準不準？能不能預測？能不能生成報告？能不能做 Agent？
02發現什麼問題
一個健檢異常出來之後，誰看到？誰決定下一步？決定有沒有變成行動？有沒有持續追蹤？健康結果有沒有改變？這條路沒走通，再好的 AI 都可能只停在 Demo。
03為什麼改變判斷
進入醫療場景，還多了一個常被忽略的問題：誰負責？哪些事情可以交給 AI、哪些一定要 Human in the Loop、出錯時責任落在哪裡。
04後來怎麼做
用這條路徑看 AI：Data → Prediction → Decision → Action → Behavior → Outcome。
原本先問用了哪個模型、Prompt 怎麼調。
後來先問這個 AI 懂不懂我們怎麼做事。
01我原本怎麼想
看企業的 AI 服務，很容易把注意力放在模型：哪個模型更強、回答更準、推理更快；也花很多力氣在調 Prompt。
02發現什麼問題
真的要上線服務客戶，問題很快變成：AI 現在應該知道哪些資料？哪些情況可以回答、哪些要停？什麼時候轉真人？回答完，下一步接什麼服務？
03為什麼改變判斷
沒有模型外面那一層 Harness，AI 回答了問題，但健康管理並沒有真的發生。
04後來怎麼做
看一個 AI 專案，我已經不太先問「你們用哪個 Model？」，而是問「這個 AI 到底懂不懂你們公司怎麼做事？」
原本快速分析、找出最可能的原因，就往下處理。
後來記錄證據與未確認的事，保留被新證據推翻的可能。
01我原本怎麼想
我很習慣快速分析問題、辨識風險，再找出最可能的原因與解決方案。
02發現什麼問題
問題發生的當下，我們通常沒有事後看起來那麼完整的資訊。客戶反映資料有問題但查詢對不上、Log 看起來沒有明顯錯誤、各系統檢查都正常。
03為什麼改變判斷
「目前沒有發現異常」與「已經確認沒有異常」是兩件不同的事。不一定要等所有答案都出來，才開始管理風險。
04後來怎麼做
把目前的判斷和已確認的事實分開記錄：有哪些證據？哪些還沒確認？什麼新資訊會讓我們改變判斷？
原本看 AI Agent，先看它做不做得到。
後來先問誰授權、代表誰、可以做到哪一步、能不能隨時停下。
01我原本怎麼想
原本只是想用 AI Agent 做一次 User Testing。
02發現什麼問題
它一路完成註冊登入、取得 Email OTP、填寫資料、選方案、完成預約、再取消預約，最後還整理了缺陷與測試紀錄。
03為什麼改變判斷
同一時間，Amazon 擋下了代替使用者購物的 Agent，理由是沒有取得平台授權、也沒有清楚表明身分。問題已經不是 AI 做不做得到，而是誰授權它做、平台允不允許、它到底代表誰。
04後來怎麼做
把 Agent 的問題從 Login 往下拆成 Delegation：Identity → Permission → Action → Audit → Human Control。
原本AI 理解需求後直接推薦商品，是最短的轉換路徑。
後來AI 先給有依據的資訊與限制，選擇留給消費者。
01我原本怎麼想
既然 AI 已經能理解消費者需求，為什麼不直接推薦商品，甚至完成購買？從商業角度看，這似乎是最短的轉換路徑。
02發現什麼問題
轉換成消費者身分，我反而希望 AI 不要直接推薦特定品牌。
03為什麼改變判斷
醫療 AI 平台 OpenEvidence 也有廣告，但把廣告和 AI 回答分開，讓使用者知道答案背後有哪些可追溯的證據。
04後來怎麼做
我希望 AI 負責理解需求、給有依據的資訊、講清楚適用情境和限制；真的有需要，再帶到電商，讓消費者自己比較、自己選。