案例 1|需求書衝突
內部 PDF + 會議紀錄
核准規格 v3 與昨天會議紀錄衝突。不要叫 AI 自行選「較新」的內容。
① Files:辨識衝突位置
② Context:定義 v3 為核准基準
③ 輸出:待確認表,不擅自合併
列出衝突內容、影響範圍、需決策人與截止時間。 未經確認,不修改核准需求。
100 分不一定等於能應用。這一章刻意拿掉明顯錯誤選項,改用「每個選項看似都有道理」的真實情境,檢驗你是否能把概念轉成工作判斷。
看到明顯正確選項,是辨識能力;沒有選項時能自己提出做法,才是回想與應用。
知道 Search 適合最新資料,不代表遇到「最新資料 + 內部 PDF + 選型報告」時會正確組合工具。
可能靠關鍵字猜中。這次請先說出理由,再選答案。
真正吸收要留下成果:澄清問題、來源策略、風險表、驗收條件或可用成品。
核准規格 v3 與昨天會議紀錄衝突。不要叫 AI 自行選「較新」的內容。
列出衝突內容、影響範圍、需決策人與截止時間。 未經確認,不修改核准需求。
既需要官方最新資訊,也要結合內部相容性清單。
外部事實逐項附官方來源;內部限制標明文件位置; 推論與事實分欄,不把建議寫成已證實結論。
不要先要求「給我最佳修正碼」。先建立假設與證據計畫。
先產生「假設—支持證據—反證—下一個安全檢查」表。 資訊不足時停止,不直接改 production 設定。
高風險且會變動,不能只靠模型,也不能只看一篇網路文章。
AI 負責找來源、比對與列問題;最終法律判斷及核准 保留給具權責的人員。
回答一張 Markdown 表格不等於完成可維護的追蹤矩陣。
完成標準:無重複需求 ID、每項需求至少一個驗收案例、 未對應項目自動標示。
最成熟的第一步通常不是完整架構,也不是立即寫 code。
一次只問最重要的問題;每題說明若不確認會造成什麼 設計或驗收風險。
情境:你有一份內部系統規格 PDF,要評估升級到目前最新 .NET 與 PostgreSQL 的影響。自行寫出完整工作流程。
必須包含:資料來源分類、工具順序、Prompt 第一輪、哪些結論需來源、哪些需測試、停止條件與最終成品。
幫我看需求書,查最新最佳實務,直接設計完整系統, 把不合理需求修好並產生程式碼。
把它拆成至少三輪。每輪都要有輸入、成果、限制和驗證;不得允許 AI 自行修改核准需求。
設計案件狀態更新功能,但先不寫完整 code。交付:7 個澄清問題、狀態轉換表、API contract、稽核資料模型、並行更新策略、8 個測試案例與 3 個待人工決策事項。
題目涵蓋四個面向,每題 5 分。選項刻意設計得相近;請選「當下最合理的第一步或做法」,不是選任何可能有幫助的做法。
| 條件 | 代表意義 |
|---|---|
| 總分 ≥ 85 | 多數混合情境能選出合理工作方式。 |
| 每個能力軸 ≥ 70% | 不是靠某一類題目拉高總分。 |
| 完成至少一個實作 | 能在沒有選項提示時自行產出流程。 |
| 能解釋錯題 | 知道其他選項不是永遠錯,而是此時順序或風險不合理。 |
| 項目 | 內容 |
|---|---|
| 查核日期/依據 | 2026-09-13;依 2026-09 現況查核報告(內部紀錄,未發布於網站) 的 F03 修訂。 |
| 本次變更 | 重新分配 20 題正解的選項位置;補上分數解讀說明。題目內容與解析未變。 |
| 已執行的步驟 | 已重跑「全選同一字母」的計分模擬,確認不再出現高分。 |