AI PoC

Can You Build an AI PoC Without Writing Much Code? How Technical Does an AI Product Manager Need to Be?

內容目錄

不需要一開始就會寫完整程式，也不用把自己逼成工程師。

但在推動 AI PoC 時，還是會遇到 Python、API、JSON、RESTful API、No-code 等名詞。這些詞聽起來很技術，但對 PM 而言，重點不是立刻學會開發，而是理解它們各自能幫你完成什麼事。

你不需要會所有工具。

你需要知道：當你想驗證一個 AI 想法時，該找什麼工具、該問工程師什麼問題，以及哪些事情可以自己先測試。

Python：讓你能自己做小型測試的工具

Python 是一種常用的程式語言，在 AI、資料分析與自動化領域非常普遍。

對許多 AI 產品表面上有不同的介面和功能，但其實背後的運作邏輯相似，主要依賴大型語言模型（LLM）、檢索增強生成（RAG）、向量資料庫、API 等底層技術。工具的價值在於是否解決實際工作中的問題，並降低使用者的工作摩擦。來說，Python 不一定是必備能力，但如果會一些基礎操作，會非常有幫助。因為你可以不必等待工程師排時間，就先自行測試一批資料，例如把 100 則客服留言交給 AI 分類、比較不同提示詞的結果，或將 AI 的分析結果整理成 Excel。

你不需要一開始就會寫複雜程式，目標是做到…..

能讀取 Excel、CSV 或文字檔
能把資料交給 AI 工具或模型處理
能看懂 AI 回傳的結果
能把結果整理成表格
能修改簡單的參數或提示詞
能判斷錯誤大概出在資料、格式或連線

Python 的價值，不是讓 PM 取代工程師，而是讓 PM 有能力快速驗證想法。

API…讓不同系統可以互相溝通的接口

API 可以理解成不同軟體之間的溝通管道。

AI 客服想回答使用者「我的訂單到哪裡了？」時，AI 本身不會知道訂單資訊。它必須透過 API 向公司的訂單系統查詢，取得正確資料後，才能組織成回覆內容。

你可以把 API 想成餐廳服務生….

使用者提出需求，就像顧客點餐。
AI 或系統發出 API 請求，就像服務生把訂單送到廚房。
後端系統查詢資料，就像廚房準備餐點。
系統回傳結果，就像服務生把餐送回桌上。

AI PM 不一定要自己串 API，但應該知道幾件事….

AI 需要哪些資料才能完成任務？
這些資料目前在哪一個系統？
AI 是否有權限取得資料？
取得的資料是否包含個資或機密？
AI 是只能「查詢」，還是可以「修改」資料？
如果系統查不到資料，AI 要怎麼回答？

JSON：讓系統看得懂資料的格式

JSON 是系統之間傳遞資料時常用的格式。

它不需要當成一門複雜技術來學。對 PM 而言，可以把 JSON 理解為一份「有固定欄位名稱的資料表」。一筆客服案件可能會包含….

客戶編號
產品型號
問題類型
問題摘要
優先程度
是否需要人工處理

系統用 JSON 傳遞資料時，就是把這些欄位和對應內容整理成一個標準格式，讓另一個系統知道每一項資訊代表什麼。

理解 JSON 的目的，不是要求你手寫資料格式。而是當工程師問你「AI 回傳時需要哪些欄位」時，可以回答….

AI 除了回答文字，是否還要標記問題類型？
是否需要判斷案件優先級？
是否需要提供參考資料來源？
AI 不確定時，是否要標記為「需要人工覆核」？
哪些資料必須由企業系統提供，不能讓 AI 自己猜？

這些欄位的設計，會直接影響 AI 能不能安全地進入後續流程。

RESTful API：讓資料與操作更有規則的設計方式

RESTful API 是許多系統用來設計 API 的常見方法。

對非工程背景的 PM，不需要深入理解它的技術規範。只要知道它的核心概念是：不同動作要有清楚的規則與邊界….

查詢訂單資料，是一種動作。
建立客服案件，是另一種動作。
修改客戶資料，是另一種動作。
執行退款，又是更高風險的動作。

這些動作不應該全部混在一起，也不應該讓 AI 想做什麼就做什麼。AI PM 要關心的是權限與風險….

AI 可以讀取哪些資料？
AI 可以新增哪些紀錄？
AI 是否能直接修改客戶資訊？
AI 是否能發送訊息、建立訂單或執行退款？
哪些動作一定要人類確認？
如果 AI 做錯了，是否能追查、撤銷或修正？

AI 可以協助提出建議，但涉及客戶權益、金流、合約、醫療或安全的操作，通常不應讓 AI 在沒有人工確認的情況下直接執行。

No-code：不寫程式，也能快速做出 AI 工作流程

No-code 指的是不用自己撰寫大量程式碼，也能建立自動化流程或簡易應用的工具。

對 AI PoC 而言，No-code 是很好的起點。因為你可以先測試流程與使用者需求，而不是一開始就花大量時間開發正式系統，可以先做出這樣的流程…

客服收到客戶留言 → AI 自動摘要問題 → AI 判斷問題類型 → 將案件分派給對應團隊 → 客服人員確認後回覆客戶。

這種流程在 PoC 階段，可以先透過表單、試算表、Email、Slack、Teams 或 Notion 等工具驗證。

No-code 特別適合：

會議紀錄自動整理
客服留言初步分類
客戶回饋摘要
Email 分流
表單內容自動分析
知識庫問答測試
AI 回覆草稿生成
專案任務初步建立

但 No-code 通常比較適合驗證概念，不一定適合作為正式產品的長期架構。當系統開始涉及大量使用者、企業機密、個資、複雜權限或核心系統串接時，仍需要工程團隊協助建立更穩定、安全的系統。

簡單示範…AI 客服 PoC 不需要先寫程式

假設公司想導入 AI 客服，但目前還不確定是否值得投資正式系統。

這時候，AI PM 不需要先找工程師開發完整聊天機器人，也不必先學會寫 API。

可以先做一個小型 PoC。

第一步，先整理 30 到 50 個最常見的客戶問題，例如：

如何查詢保固期限？
產品無法開機怎麼辦？
配件遺失是否可以補購？
維修需要多久？
訂單什麼時候出貨？

第二步，準備官方產品手冊、保固規範、常見問題與維修流程，並確認內容是否為最新版本。

第三步，將這些資料提供給 AI 工具，測試 AI 是否能根據官方內容回答問題，而不是自行編造答案。

第四步，設計評估表，請客服人員針對每一題回答進行評分：

回答是否正確？
回答是否容易理解？
是否引用正確資料？
是否有不該承諾的內容？
遇到不確定的問題時，是否有建議轉人工？
這個回答是否真的能減少客服處理時間？

第五步，根據結果決定下一步。

如果 AI 在產品操作與 FAQ 類問題表現良好，但在保固例外、退款與訂單修改問題上風險較高，那就不需要硬做「全自動 AI 客服」。

更合理的做法可能是…..

先讓 AI 協助客服人員產生回覆草稿；涉及保固、退款、個資與訂單異動時，一律轉由人工確認。

這就是 AI PoC 的核心：不是證明 AI 很厲害，而是找出 AI 在哪裡真的有價值、哪裡不能取代人，以及後續是否值得投入工程資源。

懂名詞與流程，比急著會寫程式更重要

技術能力，不是以會多少程式碼來衡量。

更重要的是，你是否理解……

Python 能幫你快速做哪些測試。
API 如何讓 AI 取得或傳送資料。
JSON 如何讓系統使用 AI 的結果。
RESTful API 為什麼和權限、風險及責任有關。
No-code 如何讓你低成本驗證 AI 工作流程。
哪些事情可以自己先做 PoC，哪些事情需要工程師協作。

對 AI PM 來說，最有價值的不是成為全端工程師。

而是能將商業問題轉化成可驗證的 AI 情境，並帶著團隊從小範圍測試中，找出真正能上線、能被使用、也能被安全管理的 AI 解法。

下面這段是很常見的「Python 呼叫 AI API」範例，能一次對照 Python、API、JSON、RESTful API、Request、Response、API Key 等名詞。

它不是正式產品程式，而是一個適合 AI PoC 理解流程的最小範例。

python

import os
import requests

#1. API Endpoint：要呼叫的 AI 服務網址
url = “https://api.openai.com/v1/responses“
#2. API Key：身分驗證用的金鑰
建議將金鑰存在電腦環境變數，不要直接寫在程式碼裡
api_key = os.getenv(“OPENAI_API_KEY”)
#3. Headers：告訴 API「我是誰」以及「我傳送的資料格式」
headers = {

“Authorization”: f”Bearer {api_key}”,
“Content-Type”: “application/json”
}
#4. JSON Payload：要送給 AI 的資料
payload = {
“model”: “gpt-4.1-mini”,
“input”: “請將這段客服訊息分類為：產品、保固、物流或其他。\n\n客戶訊息：我的產品無法開機，而且還在保固期內。”
}
#5. POST Request：將資料送到 AI API
response = requests.post(
url,
headers=headers,
json=payload
)
#6. Response：接收 API 回傳的結果
result = response.json()
#7. 印出 AI 回覆
print(result[“output”][0][“content”][0][“text”])

程式碼對照名詞

名詞	程式中的位置	白話意思
Python	整段程式	用來讓電腦執行指令的程式語言。
API	`https://api.openai.com/...`	讓你的程式可以向 AI 服務提出要求的管道。
Endpoint	`url = "..."`	API 的特定服務地址；像是要把需求送到哪個窗口。
API Key	`OPENAI_API_KEY`	身分憑證，證明你有權使用該服務。
Headers	`headers = {...}`	附在請求上的基本資訊，例如身分與資料格式。
JSON	`payload = {...}`	系統交換資料常用的結構化格式；看起來像 Python 的字典。
Payload	`payload`	你真正想傳給 AI 的內容，例如模型名稱與問題。
POST	`requests.post(...)`	將資料送出去的一種 API 操作。
Request	`requests.post(...)` 整段	你的程式向 AI 發出的請求。
Response	`response`、`result`	AI API 回傳給你的結果。
RESTful API	`POST` 加上 `url`	一種常見 API 設計方式；透過網址與操作方法進行系統溝通。

用餐廳來理解整個流程

這段程式其實就是：

Python：你派出的服務生。
API Endpoint：AI 餐廳的地址。
API Key：你的會員卡或付款資格。
JSON Payload：你寫好的點餐內容。
POST Request：服務生把菜單送進廚房。
AI 模型：廚房根據點單處理。
Response：服務生把完成的餐點，也就是 AI 回答送回來。

AI PM 看這段程式時，真正要檢查什麼？

不需要急著理解每個 Python 語法。比較重要的是用產品角度檢查以下幾件事…

1. `input` 裡的問題是否夠清楚？

請將這段客服訊息分類為：產品、保固、物流或其他。

可以思考….

分類只有這四種嗎？
如果一則訊息同時涉及產品與保固怎麼辦？
AI 不確定時能否回答「需要人工判斷」？
分類結果是否能直接用在後續客服分流？

2. AI 回傳的是一句文字，還是可用於流程的結果？

目前程式只要求 AI 回傳文字，例如：保固
但如果未來要接進客服流程，可能還需要 AI 一起提供…..

問題分類
優先程度
是否需要人工覆核
建議處理部門
回覆草稿
判斷依據或資料來源

這時才需要和工程師討論更完整的輸出格式。

3. 哪些事情不能讓 AI 自己決定？

這個範例只做「問題分類」，風險較低。

但若 AI 要查詢訂單、修改客戶資料、執行退款或承諾保固條件，就不能只靠模型回答。它必須取得正確系統資料，並加入權限、人工覆核與紀錄機制。

如果程式執行失敗，最常見的原因

現象	常見原因
`401 Unauthorized`	API Key 沒設定、錯誤或失效。
`429 Too Many Requests`	呼叫太頻繁，或帳號額度不足。
`404 Not Found`	API 網址或服務路徑寫錯。
`500` 系列錯誤	AI 服務端暫時異常，或請求內容有問題。
`KeyError`	程式預期的回傳欄位不存在，可能是 API 格式或錯誤訊息不同。
沒有回覆或回覆很奇怪	提示詞不夠清楚、資料不足，或模型本身不適合該任務。