Part 2
Prompt、Context 與 Thinking

01｜先建立一個正確模型

02｜Prompt：先定義成果，不要堆角色咒語

你不需要每次都寫「你是一位世界頂尖專家」。比角色更重要的是可操作的工作契約。

幫我設計一個案件系統的 API，
要專業、完整、符合最佳實務。

為案件追蹤系統提出 API 草案。
技術：ASP.NET Core + PostgreSQL。
角色：承辦人、主管、系統管理員。
先列出仍缺少的 5 個關鍵需求，不寫程式。
確認後輸出 endpoint 表格，包含：
method、path、角色、輸入、成功條件、主要錯誤。

03｜Context：不是越多越好，而是可辨識、可取捨

Context 是 ChatGPT 做判斷時能看到的資訊。大量貼入內容不等於有效上下文；過時、矛盾或沒有優先順序的內容，反而會降低品質。

遇到衝突 Context 時，定義優先順序

本次判斷優先順序：
1. 「需求規格_v3.pdf」是核准基準。
2. 「會議紀錄_0908.docx」只補充 v3 未涵蓋處。
3. 舊版 v2 只用來找變更，不得作為現行需求。
若資料互相衝突，不要自行決定；列入待確認清單。

04｜Thinking：把推理成本用在值得的地方

05｜真正穩定的方式：多輪協作

先不要稱讚這份草案。請依序檢查：
1. 哪些內容直接來自我的資料？
2. 哪些是你自行做的假設？
3. 是否違反任何明確限制？
4. 找出三個最可能失敗的情境。
5. 對照完成標準，列出尚未完成項目。
不要直接改寫；先回報檢查結果。

06｜實戰：案件狀態變更 API

先不要設計資料表或寫程式。
針對這項需求，找出會影響權限、狀態機、稽核、
並行控制與驗收測試的需求缺口。
依風險排序，一次問我最多 7 題。
每題說明：若不確認，可能造成什麼錯誤。

根據已確認回答，產生：
1. 狀態轉換表
2. API contract
3. PostgreSQL 資料表與 constraint 草案
4. 8 個驗收測試案例
每個決定標註：明確需求／合理假設／待確認。
先不產生完整實作碼。

以 hostile reviewer 角度檢查草案：
找出越權、跳過合法狀態、重複送出、並行更新、
稽核紀錄遭竄改與時區處理可能出錯的地方。
用「風險—觸發方式—預期防護—驗證方法」表格回答。

分幕是教學順序，不是執行時一定要停五次

上面把流程拆成五輪，是為了讓你看清楚每一步在檢查什麼。實際執行時，停不停下來應該由「還有多少未知」與「這個動作的風險」決定，而不是由固定回合數決定。目標、輸入與授權都清楚的低影響修改，可以讓它一路做到可審查的結果；會改變業務規則的歧義，就一定要先停。

可直接練習的工作契約

這是練習用的指令範例，不是固定公式；簡單任務只留下有用的部分就好。

目標：修復「取消尚未領取的設備申請後，設備仍被占用」。
輸入：已核准的 rules-v3.md、目前 repository、失敗案例。
限制：不得改變核准角色或其他狀態規則；不修改正式資料。
允許：讀取程式、在工作分支修正、執行本地與測試資料庫驗證。
完成：提供可重現案例、最小修正、相關測試結果與差異說明。
持續完成以上工作；如果規格互相矛盾，先列出精確衝突。
不能執行的檢查請標示原因，不得把預期結果寫成已通過。
正式部署不在本次範圍內。

07｜辨識題自我檢測（100 分）

共 10 題，每題 10 分。先作答，再按「計分並顯示解析」。未選視為答錯。

分數怎麼讀

08｜本章完成檢核

本章維護紀錄