AI 產品要怎麼開始？為什麼不該直接從 Prompt 開始寫？（2026 需求定義懶人包）

想做一個 AI 產品，打開聊天視窗就開始寫 Prompt？先等一下！這篇帶你在動手前問完三個問題：誰用、哪種錯最不能接受、怎麼驗收。

有人問我：「我想做一個 AI 客服，接上 CRM，客人可以直接在對話裡預約，要怎麼開發？」

我沒有先回答該用哪個模型。我先追問三件事：誰每天要用它？哪一種錯最不能接受？做到什麼程度算完成？

這個問題在 2026 年會越來越常見。LINE 台灣在 10 月宣布，官方帳號後台會內建 AI 代理平台，預計 2027 年第一季推出，第一批就有預約、銷售、客服三種角色，店家用自然語言對話就能做出自己的 AI 代理，預約資料同步到行事曆，進階版還能查 CRM 的會員資料。不想等平台的人，打開 Claude Code 說一句「幫我做一個接 LINE 和 CRM 的預約客服」，一個下午就有能跑的東西。

做出來已經不難了。所以這篇想講的只有一句：先決定要解決什麼，再決定讓 AI 做什麼。

快速回答 做出來的成本接近零，所以「錯了誰承擔」成了要不要先寫定義的唯一判準。做 AI 產品不要從挑模型或調 Prompt 開始，而要先寫一頁「問題定義」：定義誰在什麼場景付費或使用、容錯率多高、失敗路徑怎麼退回。把不確定性留在 Prompt 裡，系統架構與業務邊界先用程式碼和規格釘死。

為什麼不能直接從 Prompt 開始：沒寫清楚的業務規則，AI 會自己亂猜預設值

以前做一套預約系統要幾個月，光是估價就逼著大家開會：誰用、要處理哪些情況、做錯了誰負責。這些問題很煩，但開發成本高到讓人不敢不問。

現在順序倒過來了。可以運作的畫面比任何定義都先出現，而且看起來很完整：會回話、會查空檔、會寫進行事曆。問題在於，每一個沒人決定的地方，AI 都替你填了一個說得通的預設值。改期要不要收費、客人說「不對，改週三」時以哪個為準、客訴要不要轉真人，它都有答案，只是那些答案沒人同意過。

Anthropic 給 Claude Code 使用者的建議寫得很直接：讓 AI 直接跳進寫程式，可能寫出一套解決錯問題的程式。我認為 2026 年最常見的錯，就是把「做整個系統」當成第一個指令。定義沒寫，不會消失，它會在上線後變成兩種錯。

先算錯誤代價矩陣：找出「漏轉客訴」與「誤約時段」，用設計把錯推向便宜那格

還不算。這類系統每處理一則訊息，至少在做兩個決策，每個決策都有兩種錯法。下面這張圖是我看這類系統的方式，先看兩格陶土色的：那是最貴的錯。

矩陣圖：兩個決策乘以兩種錯誤。決策一「這則要不要轉真人」，該轉沒轉是漏轉，屬於偽陰性，代價是客訴升級；不必轉卻轉了是多轉，屬於偽陽性，代價是客服多看一則。決策二「這個時段要不要直接成立」，不該成立卻成立是誤約，屬於偽陽性，代價是兩個人同時到店；可以成立卻先擋是多確認一次，屬於偽陰性，代價是客人多等一下。兩條箭頭把設計從貴的錯推向便宜的錯。 — 客服預約系統的兩個決策各有兩種錯；先找出代價最貴的「漏轉」與「誤約」，再用產品設計把錯誤推向代價較低的那一格（依據 Google PAIR 與 Microsoft Research 人機互動準則整理）。

第一個決策是「這則要不要轉給真人」。把「要轉」當成正例，漏轉就是偽陰性：客人在抱怨、在要求退費，系統卻自己回了一段客氣話，客人覺得被機器打發。反過來，不必轉卻轉了，是偽陽性，代價是客服多看一則訊息。

第二個決策是「這個時段要不要直接成立」。這次把「成立」當成正例，誤約就是偽陽性：一個沒確認過的時段被寫進行事曆，或寫錯了客戶，兩個人同時出現在門口。反過來，可以成立卻先擋下來確認，是偽陰性，代價是客人多等一下。

Google 的 People + AI Guidebook 用火災警報說明這件事：誤報和漏報都是錯，其中一種危險得多。客服預約也一樣，四格的代價差很多，只用一句「回答準確」驗收，等於把它們混在一起算。

找出貴的那一格，設計就跟著變。漏轉很貴，就把轉真人的門檻調低，寧可多轉，也讓客人隨時能喊人，系統再整理一份「待真人處理」清單。誤約很貴，就把預約改成「AI 先保留、真人或規則確認後才成立」，再送出通知。Microsoft Research 2019 年整理的十八條人機互動準則裡，「沒把握時縮小服務範圍」和「讓人容易修正」各占一條，說的就是這種設計。

調 Prompt 可以改善回覆品質，但替代不了這些產品決策。

動手前先看現有對話與流程：別把產品類別當成使用者需求

「AI 客服＋CRM＋預約」說的是三個產品類別，還沒說明誰有什麼困難。同一套系統，老闆可能想少請一個人，客服人員可能想從重複問答裡脫身，客人可能只想在半夜也約得到時段。若一開始就要求模型「回答得像真人」，這些需求很容易被壓成一個什麼都會講、卻沒人敢放手讓它處理的聊天視窗。

先選一個使用者和一個工作。假設我們要協助一間預約制工作室的客服人員，處理每天在 LINE 上重複出現的「還有沒有空檔」與改期，問題就具體了一些。接著還要問：現在怎麼排？空檔記在哪裡？客人改期時誰更新 CRM？預約出錯，是因為回覆慢、行事曆不同步，還是改期規則根本沒寫下來？原因不同，產品要處理的環節也不同。

這些問題最好用現有流程回答，不要在會議室裡直接猜。看一段有使用權、去識別化的對話紀錄，對照預約最後如何進到行事曆和客戶資料，再請實際排班的人指出他每次要手動補的資訊。若問題出在改期和取消的規則沒人定過，AI 回得再快，也不會替店家訂出規則。平台的預約範本也一樣：它幫你接好行事曆，但「改期前一天要不要收費」這種事，範本不會知道。

開工前必寫的一頁四欄表：誰用、做哪個工作、錯誤代價、驗收條件

我會先填四欄。拿這個客服預約需求當例子：

欄位AI 客服預約的填法還要確認的事

誰（User）

AI 客服預約的填法: 預約制工作室的客服人員
還要確認的事: 一天多少則詢問，誰有權看客戶資料

哪個工作（Job）

AI 客服預約的填法: 回覆空檔詢問、建立與改期預約並寫回 CRM
還要確認的事: 現在由誰排，卡在哪一步

錯誤代價

AI 客服預約的填法: 漏轉與誤約最貴；多轉、多確認可以接受
還要確認的事: 哪種錯最不能接受，出錯後怎麼補救

驗收（Acceptance）

AI 客服預約的填法: 每筆預約連回來源對話；不明資訊先回問；爭議訊息轉真人
還要確認的事: 由誰抽查，多久檢查一次

這頁最重要的空格，是「還要確認的事」。如果沒看過原本的對話紀錄、沒找實際排班的人核對流程，上面的填法就只是待驗證的假設。

錯誤代價那一欄，就是前面那張圖的結論：四格裡哪一格最貴。這一欄寫不出來，通常代表還沒問過店家，因為答案取決於店的生意。客人多半是熟客的工作室，誤約一次賠個笑臉就過了；一天只排得進三位客人的店，誤約一次就是少一筆收入。

一頁問題定義不用一次寫對。測試後發現客服人員最需要的是處理改期，就把工作欄位改掉；若客戶資料受保存限制，就調整寫進 CRM 的欄位，或先不接 CRM。問題定義應該隨證據修正，不能只在提案當天填完就收進資料夾。

把驗收條件變成可重跑的 Eval 測試集：分開計算「漏轉」與「誤約」比總分更重要

驗收欄寫好之後，下一步是讓它能被重複檢查。做 AI 應用的人把這種東西叫 eval：一組有標準答案的測試案例，每改一次 Prompt、換一次模型，就重跑一次，看分數怎麼變。Anthropic 的開發文件把順序講得很清楚：先定義成功的標準，再設計 eval 去量它。文件也提醒，測試案例要貼近真實的分布，別忘了邊界案例，包括連人都很難判斷的那種。

客服預約的測試集，就是一張表：一則客人訊息，配上正確的處理方式。重點是別只挑問得清楚的客人。一句話問三件事、說「下週二下午，不對，週三」、改期時同時提到新舊兩個日期，才會暴露真正的邊界。

下面是一個可以直接跑的最小版本，只用 Python 標準函式庫。十則訊息是我寫的示意案例，naive_bot 是一個只看關鍵字的假系統，代表「做得出來、看起來也會動」的第一版。實際使用時，把案例換成有使用權、去識別化的真實對話，把 naive_bot 換成呼叫你的系統。

import re

# Each case: customer message, the correct action, the correct day (bookings only)
CASES = [
    ("這週六下午還有空檔嗎？", "回覆空檔", None),
    ("我要約下週二下午三點剪髮", "建立預約", "週二"),
    ("下週二下午，不對，週三下午三點", "建立預約", "週三"),
    ("週五可以嗎？什麼時間都行", "回問", None),
    ("週日下午兩點，一位", "建立預約", "週日"),
    ("幫我把週四的預約改到週六上午十點", "建立預約", "週六"),
    ("我想退費，上次的課沒上完", "轉真人", None),
    ("你們的客訴專線是幾號？", "轉真人", None),
    ("上次剪完兩邊不一樣長，我很不開心", "轉真人", None),
    ("請問你們營業到幾點？", "一般回覆", None),
]


def naive_bot(msg: str) -> tuple[str, str | None]:
    """A keyword bot standing in for your system. Swap in a call to the real one."""
    if "退費" in msg or "客訴" in msg:
        return "轉真人", None
    if "空檔" in msg:
        return "回覆空檔", None
    day = re.search(r"週[一二三四五六日]", msg)
    time = re.search(r"[0-9一二兩三四五六七八九十]+點", msg)
    if day and time:
        return "建立預約", day.group()
    if day:
        return "回問", None
    return "一般回覆", None

接著逐筆比對，算三個數字：整體正確率、漏轉（該轉真人的訊息裡，有幾則沒轉）、誤約（系統成立的預約裡，有幾筆不該成立或日期錯了）。最後把出錯的對話列出來，這份清單比分數更重要。

results = [(msg, want, day, *naive_bot(msg)) for msg, want, day in CASES]
correct = sum(want == got and day == got_day for _, want, day, got, got_day in results)
should_transfer = [r for r in results if r[1] == "轉真人"]
missed = [r for r in should_transfer if r[3] != "轉真人"]
booked = [r for r in results if r[3] == "建立預約"]
wrong_booking = [r for r in booked if r[1] != "建立預約" or r[2] != r[4]]

print(f"整體正確率：{correct}/{len(results)}")
print(f"漏轉（該轉真人卻沒轉）：{len(missed)}/{len(should_transfer)}")
print(f"誤約（成立了不該成立的預約）：{len(wrong_booking)}/{len(booked)}")
for msg, *_ in missed + wrong_booking:
    print("  需要看的對話：", msg)

跑出來是這樣：

整體正確率：7/10
漏轉（該轉真人卻沒轉）：1/3
誤約（成立了不該成立的預約）：2/4
  需要看的對話： 上次剪完兩邊不一樣長，我很不開心
  需要看的對話： 下週二下午，不對，週三下午三點
  需要看的對話： 幫我把週四的預約改到週六上午十點

七成正確率聽起來還可以，但拆開看，系統成立的四筆預約裡有兩筆是錯的，三則該轉真人的訊息漏了一則，漏掉的正好是沒說出「客訴」兩個字的那位客人。只看一個總分，你會以為它差一點就能上線。

這個測試集也會跟著四欄表長大。每次上線後發現新的錯，就把那則對話加進去，下次改 Prompt 或換模型之前先跑一次。題目越貼近真實客人，分數才越有意義；它還有一個附帶好處，換模型的時候，你有一個客觀的理由。

破除三個常見誤解：調好 Prompt、看整體準確率或套用平台範本，都不能取代問題定義

「Prompt 調好就好。」 Prompt 決定 AI 怎麼回答，四欄表決定它該不該回答、錯了怎麼辦。改期規則、轉真人的門檻、預約要不要人確認，這些在 Prompt 之外。

「準確率夠高就能上線。」 上面的例子就是反證。不同的錯代價不同，要分開量，而且要先決定哪一格最不能錯。

「平台都幫我做好了，不必定義。」 平台給的是功能：會回話、會寫行事曆、會查會員。哪種錯最不能接受、誰來抽查，只有店家知道。範本越好用，越容易讓人以為這些問題已經有人處理。

什麼時候可以直接從 Prompt 開始：只給自己用、錯了自己承擔的探索型原型

只給自己用的探索型原型，可以。你想知道 AI 能不能讀懂自己的行事曆、想看一個點子做出來長什麼樣子，直接開口叫 AI 做就對了。GitHub 介紹 spec-driven development 時也承認，vibe coding 很適合快速原型；Anthropic 的建議裡也有一句：還在探索、錯了改得回來的時候，模糊的指令反而有用。

我的判斷標準只有一個：錯了誰承擔。只有你自己用、錯了自己收拾、做完可能就丟掉，從 Prompt 開始沒問題，原型甚至是幫你想清楚定義的好工具，做出來看一眼，常常就知道自己真正要的是什麼。一旦它會碰到別人的資料、別人的錢、別人的時間，例如真的客人、真的預約，就回到那四欄。

另一個邊界是，四欄表擋得住的只有你想到的錯。上線後一定會冒出沒預料到的對話，這是為什麼測試集要一直加題目，四欄表也要跟著改。

結論：做出來的成本接近零，做錯的成本沒有，模型晚點選、錯誤代價要先算

回到一開始那個問題：「我想做一個 AI 客服，接上 CRM，客人可以直接在對話裡預約，要怎麼開發？」

我的回答是，先別急著開發。先找出那位每天要用它的客服人員，看一個禮拜的對話紀錄，和店家一起決定漏轉和誤約哪個比較貴，寫下十則最難處理的訊息當成第一份測試集。這些都做完了，選哪個模型、用哪個平台，反而是最容易的決定。

做出來的成本已經接近零，做錯的成本沒有。模型可以晚點選，錯誤代價要先算。

當你已能寫出使用者、工作、錯誤代價與驗收，下一步可以讀〈AI Coding 還需要寫 PRD 嗎？需求越模糊，Agent 替你決定的越多（2026 完整指南）〉，把這一頁展開成交給 Coding Agent 也不會走樣的規格。

常見問題

為什麼 AI 產品不能直接從調 Prompt 起步？

Prompt 是所有環節中最容易變動、也是可替換性最高的組件。如果沒有先想清楚使用者是誰、資料從哪來、出錯時由誰承擔責任，花幾週微調出來的提示詞，往往在模型升級或使用者輸入格式稍微改變時就全數失效。

一頁「產品定義」至少要包含哪五個要素？

一、目標使用者在什麼痛點場景使用；二、這項任務的真實容錯率（90% 正確能否被接受）；三、當模型給出錯誤或幻覺時的退回機制；四、哪些邊界條件必須用傳統程式碼硬性約束；五、成功完成的客觀標準是什麼。

什麼時候可以跳過詳細定義、直接動手做？

當你在探索技術可行性、或是做給自己驗證個人想法時，可以跳過定義直接開工。只要這套工具還沒要對外收費、不涉及真實使用者的敏感資料，用最快的方式碰壁就是最好的定義過程。

商業成敗與模型能力的關聯性到底有多大？

歷史經驗顯示關聯性有限。底層模型的能力每隔幾個月就會被新版追平或超越；真正決定產品能否存活的，是產品對工作流程的滲透度、專屬數據的積累、以及在異常狀況下依然能交付確定性結果的工程體系。

參考資料

產品與工具現況

iThome,〈LINE官方帳號將內建AI代理平台，先提供3款店家AI代理角色，也將支援MCP協定〉（李建興，2026-10-13） https://www.ithome.com.tw/news/179642
Anthropic, Best practices for Claude Code（2026-10-16 檢視） https://code.claude.com/docs/en/best-practices
GitHub, Spec-driven development with AI: Get started with a new open source toolkit（Den Delimarsky，2025-09-02） https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/

錯誤代價與人機互動設計

Google PAIR, People + AI Guidebook: User Needs + Defining Success（2019 首版，2021 改版；"Weigh false positives & negatives" 一節） https://pair.withgoogle.com/chapter/user-needs/
Amershi, S., Weld, D., Vorvoreanu, M., et al., Guidelines for Human-AI Interaction（CHI 2019；G9 Support efficient correction、G10 Scope services when in doubt） https://www.microsoft.com/en-us/research/wp-content/uploads/2019/01/Guidelines-for-Human-AI-Interaction-camera-ready.pdf

Eval

Anthropic, Define success criteria and build evaluations（Claude 開發者文件，2026-10-16 檢視） https://platform.claude.com/docs/en/test-and-evaluate/develop-tests