本系列取材自真實經歷，人物、場景、對話與時間順序經過合成與小說化處理。文中假設案例與示意數字用於說明觀念。

管理室後面的包裹架快滿了。師父把剛登記好的箱子移到合適的位置，讓待領件不會擋住走道。我站在櫃台外，看他把一件大箱子的標籤朝外擺，等整理完才問產品第一版的事情。

前幾次聊到 AI 客服草稿工具，我一直想知道，功能要完整到什麼程度才敢拿給人用。師父說，可以先從一個很小的流程開始，甚至有些部分先由人協助。

我問他：「如果後面還要工程師幫忙處理，前面就一個上傳按鈕，這也算產品？」

第一版先回答一個具體問題

師父說，先看這一版想知道什麼。他把 AI 客服草稿工具當作假設案例：假如團隊還不知道客服會不會使用建議回覆，那第一版就可以只處理一類常見詢問，讓客服看草稿、修改，再自行送出。

這一版要觀察的，是草稿能不能幫助完成工作、需要修改多少，以及哪些錯誤會讓人放棄使用。多語系、完整管理後台、精細統計，可以等這些問題有答案之後再安排。

我說：「那就是 MVP？」

師父回答，MVP 是 Minimum Viable Product，通常譯為最小可行產品。對我們這個例子來說，重點是用足以完成約定流程的版本，取得真正使用後的回饋。小到只剩畫面、使用者根本做不了工作，就無法驗證剛才的問題。

YC 在談早期產品時，鼓勵先推出能讓初期使用者互動、回饋的版本，再持續調整；這個做法的前提是找到確實需要解決的問題。Y Combinator：The Real Product Market Fit

我追問：「那漂亮的畫面是不是都可以不管？」

師父說，影響操作理解的部分得處理。使用者找不到按鈕、不知道草稿還沒送出，這些都會影響結果。可以先沒有華麗的轉場，但不能讓人連自己正在做什麼都搞不清楚。

可以先人工協助，但要知道人工改變了什麼

師父進一步說明，假設資料匯入方式還沒做齊，初期可以在雙方同意的範圍內，協助整理一份資料，再讓對方試用。這樣可能比較快知道產品是否值得繼續開發。

我問：「可是你把資料整理得乾乾淨淨，客戶以後自己操作就壞了，這次試用不是有點假？」

師父說，所以要記錄人工做過哪些處理。格式轉換花多久、有哪些例外、需要問客戶幾次，這些也是驗證得到的資訊。如果只報告草稿很受歡迎，卻把背後兩天的資料整理藏起來，團隊就會錯估正式導入的成本。

他接著區分兩件事：使用者喜不喜歡結果，和團隊能不能穩定、合理地提供結果。早期可以先確認其中一段，但要說清楚另外一段還沒驗證。

Paul Graham 討論過早期團隊親自協助使用者、用人工推動服務的價值。這類投入能讓團隊更直接理解需求，並不等於日後可以永遠不處理交付成本。這就是他最經典一句創業名言：Do Things that Don't Scale.

我問師父：「那什麼時候該把人工步驟做掉？」

師父回答，要看它是不是已經反覆發生、是否形成等待，以及規則是否足夠清楚。還不知道怎麼整理的資料，先做一個自動整理按鈕，也可能只是把錯誤處理得更快。真正重複、每次都耗掉很多時間的部分，才值得優先考慮。

功能可以少，必要的品質要留著

我說：「照這樣講，第一版只要能回答問題，就可以先上？」

師父提醒，還要看失敗的代價。客服草稿如果內容錯了，應該讓人能辨認、修改，不能悄悄自動送給客戶。資料應該讓誰看、如何刪除、出了問題怎麼停止使用，也要和當次用途一起安排。

他把這個假設版本的界線說得更清楚：限定資料來源和詢問類型、由客服確認後送出、遇到無法處理的情況退回原流程。這些限制讓試用範圍可以理解，也讓團隊知道觀察結果適用在哪裡。

我問：「如果大家用完都說不錯，但沒有再用呢？」

師父說，就要回去看，當初想驗證的是一次展示還是日常使用。可以安排下一個實際工作週期再看一次，而不是把第一次操作成功當作所有問題都解決了。若根本沒有人願意把它放進工作，繼續補後台功能之前，應該先了解原因。

我看著他剛整理好的包裹架，說自己原本對第一版的想像比較像功能打折：正式版十項，先做三項。師父說，功能數量沒有固定比例，得從想取得的答案倒推。

先定義要驗證的事情，再決定簡化哪些功能、保留哪些品質。 這樣第一版拿出去以後，才知道該看什麼，也知道什麼結果會讓團隊改方向。