提示詞工程需要回到需求工程

好的提示詞來自清楚需求

提示詞工程（Prompt Engineering）常被理解為撰寫精準的指令，讓 AI 產生符合需求的內容。在軟體開發中，提示詞品質取決於需求是否已經整理清楚。

例如開發者要求 AI「幫我寫一個會員折扣功能」時，AI 除了需要功能名稱，也需要知道會員等級如何判斷、折扣何時生效、能否與優惠券併用、異常資料如何處理，以及哪些情境需要拒絕。

這些資訊若沒有放進提示詞，AI 只能依照訓練資料中的常見模式補足空白。

需求工程（Requirements Engineering）的價值，在於協助團隊將模糊想法整理成具體的行為、規則、限制與驗收條件。這些內容整理完成後，提示詞才有足夠的上下文資訊可以使用。

好的提示詞來自完整的需求整理。團隊先釐清業務規則、使用情境、限制條件與具體範例，再將這些內容轉換成 AI 能理解的輸入格式。

開發者也比較容易檢查 AI 產出的內容是否符合原本討論，不必在生成結果裡猜測它採用了哪些假設。

模糊指令會導致 AI 自行補完

AI 很擅長把不完整的資訊補成看起來合理的內容。這項能力用在草稿生成、文件整理與方案發想時很有幫助，放到程式開發情境中，卻會帶來額外風險。

AI 自行補充的內容看起來完整，命名也很自然，卻不一定符合業務既有流程、金流服務限制或客服處理方式。

模糊提示詞等於把部分決策交給 AI。團隊沒有明確定義的規則，AI 會自己填入判斷。團隊沒有交代的系統邊界，AI 會依照通用模式補上細節。生成內容看起來越完整，開發者越容易忽略其中包含的假設。

在 AI 輔助開發中，提示詞應該說清楚哪些內容已經確認、哪些內容仍待釐清，以及哪些內容不能自行假設。

當需求還沒有整理完成時，應請 AI 協助整理問題、找出資訊缺口或產生討論草稿，不要直接要求它生成正式程式碼。等需求、規則與限制確認後，再把已確認的內容帶入生成上下文。

需求工程能降低幻覺風險

幻覺（Hallucination）在 AI 輔助開發中，不一定會表現成明顯的錯誤。

它常以「看起來合理，但沒有根據」的形式出現，例如自行新增欄位、補上不存在的 API、假設某個狀態流程，或套用團隊沒有採用的設計慣例。

需求工程可以降低這類風險，因為它要求團隊先把重要資訊整理清楚。

使用者角色、前置條件、業務規則、例外情境、資料限制與驗收條件，都會影響 AI 的生成結果。這些資訊若能在撰寫提示詞前完成整理，AI 就不需要依靠推論補足需求缺口。

行為驅動開發（Behavior-Driven Development, BDD）正好提供了需求工程與提示詞工程之間的銜接方式。

團隊可以先用範例描述系統在特定情境下應該如何反應，再把這些行為規則整理成結構化提示詞。AI 接收到的是一組具體的行為約束，推論空間也會縮小。

當提示詞建立在需求工程的成果上，團隊就能回到同一份規格檢查生成結果，確認 AI 是否遵循原本的行為規則。

這會讓提示詞從一次性的對話，變成後續審查、測試與修改時可以追溯的依據。

從實例映射萃取 AI 需要的上下文

用規則整理業務邏輯

實例映射（Example Mapping）是一種將需求討論整理成規則、範例與問題的協作方法。它適合放在 AI 輔助開發之前，因為團隊在討論中整理出的業務規則，正是AI 生成時最需要的內容。

業務規則描述的是系統必須遵守的判斷邏輯。例如「金卡會員滿 1200 元可享 9 折」、「折扣不得與活動優惠併用」、「已取消訂單不可重新付款」。這些規則看似簡單，卻會直接影響程式分支、資料驗證、錯誤處理與測試案例。

如果團隊只把需求寫成「實作會員折扣功能」，AI 就缺少足夠的業務領域資訊判斷。它可能自行設計會員等級、折扣計算方式、例外處理與錯誤訊息。團隊若先透過實例映射整理規則，再把這些內容放進提示詞，AI 就能理解哪些條件需要判斷、哪些限制不能忽略，以及哪些流程必須遵循。

規則整理的目的，是讓 AI 理解系統行為背後的約束。這些約束可以包含資格條件、計算方式、例外限制、狀態轉換與權限邊界。規則寫得越清楚，生成時被自由補完的地方就越少。

用範例補足抽象描述

需求討論中常會出現抽象描述，例如「符合資格」、「金額不足」、「不得重複申請」或「依會員狀態判斷」。這些詞對團隊成員來說或許能形成初步共識，對 AI 而言仍保留很大的推論空間。範例可以把抽象描述轉成具體情境，讓 AI 理解規則應該如何套用。

例如「金卡會員滿 1200 元可享 9 折」這條規則，可以補上幾個範例：金卡會員消費 1300 元，折扣後為 1170 元。金卡會員消費 1199 元，不適用折扣。銀卡會員消費 1300 元，也不適用金卡折扣。這些範例能讓規則的適用範圍與邊界更清楚。

範例的價值，在於把容易被忽略的細節提早攤開討論。當團隊寫出具體的輸入與預期結果時，原本模糊的地方就會浮現。例如滿 1000 元是以折扣前金額判斷，還是折扣後金額。優惠券與會員折扣的套用順序為何。金額的小數如何計算與進位。這些問題若等到開發階段才發現，就會增加修改與驗證成本。

對 AI 而言，範例也是最直接的開發上下文。它可以根據範例推導程式邏輯、建立測試資料、產生單元測試，甚至找出尚未覆蓋的邊界條件。範例越貼近真實業務情境，生成結果裡的假設就越少。

用問題清單標示不確定內容

實例映射中的問題清單，對 AI 輔助開發特別重要。它提醒團隊，需求中仍有一些內容尚未確認，這些地方不應交由 AI 代替團隊判斷。

需求討論時，團隊經常會遇到尚未釐清的問題。例如「退貨後會員折扣是否需要回補」、「跨國幣別是否使用同一套折扣規則」、「人工客服調整訂單時是否套用相同限制」。這些問題若沒有被明確記錄，容易在提供規則時遺漏，最後由 AI 依照通用模式自行補上。

問題清單也可以直接轉成提示詞的限制條件。團隊可以明確告訴 AI 以下問題尚未確認，請不要自行假設。若完成程式需要這些資訊，請先列出待確認項目。產生程式時，只能處理已確認規則涵蓋的情境。這樣可以降低 AI 將未知內容當成既定設計的風險。

對開發流程而言，問題清單也能協助團隊判斷需求是否已經具備實作條件。

若問題集中在文案、顯示順序或其他非關鍵細節，主要流程仍可繼續開發。若問題涉及金額計算、權限、狀態轉換或外部系統整合，就應先完成確認，再讓 AI 生成程式。

透過規則、範例與問題清單，實例映射可以把需求討論整理成結構清楚的開發輸入。提示詞接著承接這些內容，帶入業務規則、行為邊界、限制條件與待確認事項。

將 Gherkin 轉成生成約束

用 Given 說清楚 AI 需要的執行背景

Gherkin（Given-When-Then）是行為驅動開發（Behavior-Driven Development, BDD）常用的情境描述方式。它能把需求整理成具體的行為規格，也能進一步轉換成 AI 生成程式時的約束條件。

Given 描述的是系統執行前的背景。對 AI 而言，這些背景會影響資料結構、判斷條件與程式分支的設計。例如「Given 使用者是金卡會員」、「Given 訂單金額為 1200 元」、「Given 此訂單尚未使用優惠券」，這些資訊代表目前情境中哪些資料狀態已經成立。

如果提示詞只寫著「請建立會員折扣功能」，AI 就需要自己推測會員資料從哪裡取得、訂單有哪些狀態、優惠券是否存在，以及折扣是否可以併用。

當 Given 先整理完成後，這些背景會限制推論範圍，避免 AI 補上未被確認的設計。

Given 也可以補充系統邊界。例如會員資料來自會員服務、訂單資料來自訂單服務。目前只處理單一幣別。

這些背景資訊都會直接影響生成結果。背景描述越完整，AI 就越能依照既有系統與業務規則產生符合需求的程式。

用 When 定義觸發行為與事件條件

When 描述的是觸發行為的動作或事件。它告訴 AI 在什麼時候需要執行這段邏輯，也能避免 AI 把規則放錯位置，或將原本屬於特定流程的邏輯分散到其他地方。

例如「When 使用者送出結帳請求」、「When 系統重新計算訂單總額」、「When 客服人員手動調整訂單金額」，這些描述能讓 AI 理解行為發生的節點。相同的折扣規則，若套用在購物車預覽、結帳確認或付款完成後重新計算，程式設計與系統行為都會有所不同。

When 也需要交代事件的觸發條件。例如使用者點擊按鈕、API 收到請求、排程工作開始執行，或外部金流服務回傳付款結果，都是不同的觸發來源。不同來源會影響錯誤處理、交易控制、重試機制與紀錄方式。

在提示詞中加入 When，可以讓 AI 判斷這段邏輯應該出現在哪個流程節點。團隊也能用它檢查 AI 是否正確理解規則的適用時機。若 AI 沒有依照 When 描述的業務事件處理規則適用時機，團隊就能回到行為規格，要求它補上正確的業務條件與判斷邊界。

用 Then 建立可驗證的輸出結果

Then 描述的是系統應該產生的結果。對 AI 生成程式而言，Then 的作用，是把「需求完成」轉成可以驗證的輸出。

例如「Then 系統應將訂單金額計算為 1170 元」、「Then 系統應拒絕套用會員折扣」、「Then 系統應回傳折扣不可與優惠券併用的錯誤訊息」。這些結果比「正確套用折扣」更具體，也較容易轉換成程式邏輯、測試案例與驗收條件。

Then 應盡量描述可觀察的結果。可觀察的結果可以是畫面訊息、API 回應、資料狀態、事件紀錄、通知內容或錯誤代碼。只要結果能被觀察，團隊就能在 AI 完成生成後，依照規格確認輸出是否符合預期。

這樣的規格也能支援 AI 同時生成測試。當 Given 提供前置狀態，When 定義觸發事件，Then 說明預期結果，AI 就具備產生單元測試、整合測試或驗收測試草稿的依據。團隊再依照系統現況補充測試資料與驗證細節。

把 Gherkin 轉成提示詞時，重點是讓 AI 清楚知道哪些條件已經成立、哪個事件會觸發行為，以及結果應該如何驗證。提示詞同時帶入行為規則、流程節點與驗收標準，生成結果才有明確的檢查依據。

讓規格成為 AI 產出的驗證準則

生成後回到規格檢查

AI 生成程式後，團隊仍需要回到原本的行為規格檢查結果。這個步驟可以避免審查只停留在語法是否正確、程式是否能執行，或命名是否一致。

AI 產出的內容即使看起來完整，仍需要確認是否符合需求討論時定義的業務行為。

規格在這裡就是檢查基準。團隊可以依照實例映射（Example Mapping）整理出的規則、範例與問題清單，逐一對照 AI 產出的程式。

規則用來確認判斷邏輯，範例用來驗證輸入與輸出，問題清單則用來檢查 AI 是否自行補上尚未確認的內容。

例如規格寫明「已取消訂單不可重新付款」，AI 生成的程式就必須明確處理已取消的訂單狀態。如果程式只檢查付款金額，沒有驗證訂單狀態，即使測試案例暫時通過，也代表需求規格沒有被完整實作。

這種檢查方式能讓程式碼審查更聚焦。審查者不必只憑經驗閱讀大量生成的程式碼，可以先回到行為規格確認幾個關鍵問題：這段程式是否符合 Given 的前置條件、When 的觸發事件與 Then 的預期結果。是否新增了規格沒有定義的判斷。是否遺漏已經確認的例外情境。

讓 AI 同時生成測試案例

當行為規格已經整理完成，AI 不只可以生成程式，也可以協助產生測試案例。這些測試案例應該建立在同一份規格上，讓程式與測試回到相同的需求來源。

Given-When-Then 一開始就是依照測試結構設計出來的。Given 可以對應測試資料與前置狀態，When 可以對應執行動作，Then 可以對應驗證結果。

若規格中已經包含具體範例，AI 也能依照這些範例建立測試資料，並補上接近邊界條件的測試草稿。

例如折扣規格包含三個情境：金卡會員滿額可享折扣、金卡會員未滿額不適用折扣、銀卡會員滿額也不適用金卡折扣。AI 可以根據這三個情境生成對應的單元測試。團隊再檢查測試是否符合既有測試框架、資料建置方式與命名慣例。

AI 生成測試時，團隊仍需要保留人工判斷。測試是否真正驗證關鍵行為、是否把錯誤假設寫進測試，以及是否只驗證表面輸出，都需要開發者與測試人員確認。若錯誤的測試被保留下來，後續程式即使符合測試，也不代表符合需求規格。

較好的做法，是先讓 AI 根據規格產生測試草稿，再由團隊審查測試是否完整涵蓋主要規則、例外情境與邊界條件。確認測試內容後，再用這些測試驗證 AI 生成的程式是否符合預期行為。

把提示詞視為可重用的開發規格

當提示詞承接 BDD 規格、實例映射（Example Mapping）與 Gherkin（Given-When-Then），它就會成為可重用的開發規格，記錄團隊要求 AI 依照哪些背景、規則與限制生成內容。

這樣的提示詞應該被保存下來。團隊可以把它放進文件、工單、拉取請求描述或版本管理系統，讓後續成員知道這段程式是依照哪些需求規格產生。當需求變更時，團隊也能回頭調整提示詞，再重新生成程式或測試草稿。

可重用的提示詞也能降低團隊成員之間的差異。若每位開發者都用自己的方式要求 AI，產出的程式風格、行為規則與測試品質就容易不一致。

當團隊建立共同的提示詞範本，開發者可以把規則、範例、待確認事項、技術限制與輸出要求整理在固定位置，審查者也較容易理解生成依據。

提示詞進入開發流程後，也需要定期檢查與調整。團隊可以觀察哪些提示詞會讓 AI 遺漏例外情境、哪些提示詞會讓 AI 自行補上尚未確認的設計，以及哪些提示詞能穩定產生符合規格的程式與測試。

這些經驗可以整理成團隊的共同做法，下一次遇到相似需求時就能直接沿用。

會員折扣功能的實例映射範例

以下以「會員折扣」為例，示範如何將需求整理成實例映射（Example Mapping）。

需求描述

金卡會員在結帳時，若訂單折扣前金額達到 1200 元，可享 9 折優惠。此折扣不可與優惠券併用。

這個需求看起來是「結帳時打折」，實際討論時會牽涉會員資格、訂單金額、優惠券併用、訂單狀態與金額計算方式。

實例映射可以先把這些內容拆成規則、範例與待確認問題，讓團隊在請 AI 生成程式前，先把判斷依據放在同一個地方。

規則、範例與問題清單

透過實例映射，團隊可以先把會員折扣功能拆成幾組明確資訊。規則描述必須遵守的業務邏輯，範例描述不同條件下的輸入與輸出，問題清單則標示目前尚未確認的內容。

這個實例映射的重點，是把 AI 需要遵守的判斷依據拆清楚。當規則、範例與問題清單都整理出來後，提示詞就能帶入業務規則、行為邊界與風險提醒。

會員折扣功能的 Gherkin 範例

接續「會員折扣」的例子，示範如何將整理好的實例映射範例展開成 Gherkin，再進一步轉換成 AI 可以使用的結構化提示詞。

情境一：金卡會員滿額且未使用優惠券，成功套用折扣

 Scenario: 金卡會員訂單滿額且未使用優惠券時，套用 9 折優惠
  Given 使用者是金卡會員
   And 訂單狀態為「待付款」
   And 訂單折扣前金額為 1300 元
   And 訂單尚未使用優惠券
  When 使用者送出結帳請求
  Then 系統應套用會員 9 折優惠
   And 訂單應付金額應為 1170 元
   And 系統應記錄折扣類型為「金卡會員折扣」

這個情境描述的是成功路徑。Given 說明會員等級、訂單狀態、金額與優惠券狀態。When 說明觸發點是送出結帳請求。Then 說明系統應產生的結果。

情境二：金卡會員未滿額，不套用折扣

 Scenario: 金卡會員訂單未滿額時，不套用會員折扣
  Given 使用者是金卡會員
   And 訂單狀態為「待付款」
   And 訂單折扣前金額為 1199 元
   And 訂單尚未使用優惠券
  When 使用者送出結帳請求
  Then 系統不應套用會員折扣
   And 訂單應付金額應為 1199 元

這個情境用來補足金額門檻的邊界。AI 若只看到「金卡會員有 9 折」，高機率會忽略滿額條件。透過這個例子，可以讓 AI 知道金卡會員資格不足以套用折扣。

情境三：銀卡會員滿額，不套用金卡折扣

 Scenario: 銀卡會員訂單滿額時，不套用金卡會員折扣
  Given 使用者是銀卡會員
   And 訂單狀態為「待付款」
   And 訂單折扣前金額為 1300 元
   And 訂單尚未使用優惠券
  When 使用者送出結帳請求
  Then 系統不應套用金卡會員折扣
   And 訂單應付金額應為 1300 元

這個情境用來確認會員等級規則。金額達標仍然不能套用折扣，因為會員等級不符合資格。

情境四：金卡會員滿額但已使用優惠券，不套用會員折扣

 Scenario: 金卡會員訂單滿額但已使用優惠券時，不套用會員折扣
  Given 使用者是金卡會員
   And 訂單狀態為「待付款」
   And 訂單折扣前金額為 1200 元
   And 訂單已使用優惠券
  When 使用者送出結帳請求
  Then 系統不應套用會員折扣
   And 系統應保留原本的優惠券折扣

這個情境處理互斥規則。它告訴 AI，優惠券與會員折扣之間需要有優先判斷，不能把兩種折扣直接疊加。

轉成結構化提示詞的範例

上面的 Gherkin 可以轉成給 AI 使用的提示詞。寫法上要把行為規則、限制與驗收情境一起放進去，避免只留下「請幫我寫折扣功能」這種寬泛指令。

請根據以下行為規格，使用 TypeScript 產生會員折扣計算函式。

功能目標：
建立一個 calculateMemberDiscount(order, user) 函式，用來計算訂單是否可套用金卡會員折扣。

業務規則：
1. 只有金卡會員可以使用會員折扣。
2. 訂單折扣前金額必須大於或等於 1200 元。
3. 金卡會員折扣為 9 折。
4. 若訂單已使用優惠券，不可再套用會員折扣。
5. 折扣後金額若有小數，請四捨五入為整數。

請依照以下 Gherkin 情境實作：

Scenario 1:
Given 使用者是金卡會員
And 訂單狀態為「待付款」
And 訂單折扣前金額為 1300 元
And 訂單尚未使用優惠券
When 使用者送出結帳請求
Then 系統應套用會員 9 折優惠
And 訂單應付金額應為 1170 元
And 系統應記錄折扣類型為「金卡會員折扣」

Scenario 2:
Given 使用者是金卡會員
And 訂單狀態為「待付款」
And 訂單折扣前金額為 1199 元
And 訂單尚未使用優惠券
When 使用者送出結帳請求
Then 系統不應套用會員折扣
And 訂單應付金額應為 1199 元
And 系統應回傳「訂單金額未達會員折扣門檻」

Scenario 3:
Given 使用者是銀卡會員
And 訂單狀態為「待付款」
And 訂單折扣前金額為 1300 元
And 訂單尚未使用優惠券
When 使用者送出結帳請求
Then 系統不應套用金卡會員折扣
And 訂單應付金額應為 1300 元
And 系統應回傳「會員等級不符合折扣資格」

Scenario 4:
Given 使用者是金卡會員
And 訂單狀態為「待付款」
And 訂單折扣前金額為 1200 元
And 訂單已使用優惠券
When 使用者送出結帳請求
Then 系統不應套用會員折扣
And 系統應保留原本的優惠券折扣
And 系統應回傳「會員折扣不可與優惠券併用」

輸出要求：
- 請產生 TypeScript 程式碼。
- 請包含型別定義。
- 請不要自行新增未列出的會員等級規則。
- 請不要自行設計其他折扣類型。
- 請同時產生對應的單元測試。

重點摘要

• 提示詞工程（Prompt Engineering）要承接需求工程（Requirements Engineering）。AI 生成程式前，團隊需要先釐清業務規則、使用情境、限制條件與驗收條件，提示詞才有可檢查的依據。
• 模糊指令會放大 AI 的自由補完。需求缺少業務領域資訊時，AI 會用通用模式填補空白，生成內容看起來完整卻可能偏離既有流程。
• 實例映射（Example Mapping）能把討論拆成規則、範例與問題清單。規則說明判斷邏輯，範例補足邊界情境，問題清單標示尚未確認的內容。
• Gherkin（Given-When-Then）可以轉成生成約束。Given 提供前置背景，When 定義觸發事件，Then 描述可驗證結果，AI 才能依照行為規則生成程式與測試。
• 規格也是生成後的檢查基準。團隊可以用同一份行為規格檢查程式、測試與提示詞，找出 AI 是否新增未定義判斷或遺漏例外情境。
• 提示詞可以保存為開發規格。當需求變更或後續維護時，團隊能回到原本的提示詞調整規則、範例與輸出要求。