你已經會使用 Claude，所以這一章不教你「AI 是什麼」。目標是讓你在 30–45 分鐘內，理解 ChatGPT 應該怎麼想、怎麼選模式，以及為什麼不能只把它當成另一個聊天機器人。
驗收門檻：80 / 100 分
遇到一個需求時，你能先判斷：要不要最新資料、要不要深度推理、要不要使用自己的資料、最後要回答還是完成工作。
版本註記：教材以 2026 年 9 月的 ChatGPT 產品概念編寫；實際功能可依方案、地區與工作區設定而不同。
Prompt 很重要，但「選錯工作方式」比「Prompt 少寫一句」更容易讓結果變差。
回答知識、查最新資料、研究多來源、分析檔案、建立成品、跨工具執行，其實是不同任務。
對話只是入口。真正的價值來自模型推理、搜尋、檔案、研究、外部工具與產出能力的組合。
| 層級 | 你要問自己的問題 | 例子 |
|---|---|---|
| 1. 對話層 | 這只是解釋、整理、腦力激盪嗎？ | 「解釋 PostgreSQL MVCC」 |
| 2. 推理層 | 需要規劃、比較、除錯、設計或複雜推理嗎？ | 「比較三種資料同步架構並說明 trade-off」 |
| 3. 資訊層 | 答案依賴現在的網路資料，或很多來源嗎？ | Search / Deep Research |
| 4. Context 層 | 需要我的 PDF、Excel、程式碼、過往脈絡或外部資料嗎？ | 規格書、系統文件、連接的服務 |
| 5. 行動／產出層 | 我要的只是答案，還是「把工作做完」？ | 建立試算表、產生文件、執行多步驟工作流 |
上面五層問的是「這個任務屬於哪一類」。動手前還要再問一次「我現在在哪個環境」。同一句 Prompt 在不同工作體驗與執行環境下，能拿到的檔案、工具與權限並不一樣；後面章節的「請你讀我的專案」能不能執行，取決於這一層。
| 層次 | 要問自己的問題 | 本教材的立場 |
|---|---|---|
| 工作體驗 | 我正在 Chat、ChatGPT Work，還是 Codex？ | 官方把它們描述為不同用途：對話探索、委派可審查成果、開發與技術工作。這是用途定位，不是互不重疊的能力牆。 |
| 模型與推理 | 這個帳戶提供哪些模型與推理選項？ | 從可用預設開始，用任務證據決定要不要提高推理。模型名稱與可用設定放在版本附錄，不寫進方法章。 |
| 工具與整合 | 這一步需要搜尋、讀檔、Plugin 還是 Browser？ | 需要時才加入。「功能存在」與「這個帳戶已授權」是兩件事，要分開確認。 |
| 上下文 | 資料在 Project、附件、repo 還是外部來源？ | 來源明確、版本可辨識、存取可確認。一般的 ChatGPT Project 集中的是聊天與上傳的檔案，不會自動讀到你電腦上的資料夾；要讓它讀本機資料夾，用的是另一種「local project」，而且必須明確把資料夾掛上去。先確認你現在用的是哪一種，再決定「請你讀我的專案」這句話成不成立。 |
| 執行環境 | 在本機、worktree 還是雲端執行？ | 官方已區分 Local／Worktree／Cloud。相同 Prompt 不保證相同檔案與依賴可用。 |
下面是「概念對照」，不是 1:1 功能翻譯。
| 你熟悉的 Claude 概念 | ChatGPT 中應建立的對應認知 | 注意 |
|---|---|---|
| 一般聊天 | ChatGPT 對話 + 適當的推理強度 | 不要每件事都開最重的推理。 |
| Extended Thinking | 更高 Thinking effort / reasoning | 適合複雜分析，不代表所有任務都更好。 |
| Projects / 長期 Context | 持續工作上下文 + Memory + 檔案 | 要分清「這次對話資料」與「跨對話持續脈絡」。 |
| Artifacts | 文件、試算表、簡報、圖片等成品能力 | 重點從「呈現答案」轉成「交付可用成果」。 |
| Web Search | Search | 適合快速取得最新資料。 |
| Research | Deep Research | 適合多來源、需要引用與完整報告的任務。 |
| Integrations / MCP 思維 | Plugins / Apps / 外部資料與動作 | 功能與可用性依方案、地區、權限而異。 |
| Claude Code | 不要強求 1:1 對應 | 依工作選 ChatGPT Work、Codex 或 IDE/CLI coding agent。 |
請完整告訴我什麼是 SDD， 並說明所有最佳實務。
問題：如果你問的是近期實務、工具生態或趨勢，只靠模型既有知識可能不夠。
先用既有知識幫我建立 SDD 核心概念。 再搜尋近期可靠來源，確認目前主流做法與差異。 最後整理成 .NET 團隊可以實踐的流程。
這時候才需要把 Search 納入工作流。
這是我的系統需求規格書。 請不要先摘要；先找： 1. 需求矛盾 2. 缺少驗收條件的需求 3. 非功能需求缺口 4. 可能影響 DB Schema 的需求 最後產生一份待確認清單。
判斷：這不是 Search 問題，而是「Files + reasoning」。外部網頁搜尋不是第一優先。
查目前 PostgreSQL 最新穩定版本。 只使用 PostgreSQL 官方文件與 release notes， 整理對我們現有 .NET Web API 最可能有影響的 5 項變化。
判斷：有「目前、最新版本」→ 必須把最新資訊層納入。
研究 PostgreSQL 高可用架構的主流方案。 比較 Patroni、雲端託管服務與其他常見方案， 評估政府資訊系統情境下的可維運性、RTO/RPO、 成本、供應商綁定與資安考量。 需要來源與可追溯結論。
判斷：來源多、研究問題複雜、需要證據 → Deep Research 比一般 Search 更合適。
根據分析結果，建立： - 系統架構說明 - PostgreSQL schema 初稿 - API 清單 - 測試案例表 - 實作優先順序
判斷：目標已經從「告訴我」變成「幫我產生成品」。這是使用 ChatGPT 時非常重要的升級。
背景：ASP.NET Core Web API + PostgreSQL。功能包括案件建立、承辦人、狀態、處理紀錄、附件、查詢。
不要馬上叫 ChatGPT 寫程式。依序做：
你可以直接從這句開始： 我要規劃一個 ASP.NET Core + PostgreSQL 的案件追蹤系統。 先不要寫程式。 請站在系統分析與實作者角度，先找出需求中會影響 資料模型、API、安全性與驗收測試的關鍵缺口。 一次只提出最重要的 5 個問題。
共 10 題，每題 10 分。先完成所有題目，再按「計分並顯示解析」。未選的題目視為答錯。
| 分數 | 辨識題表現 | 下一步 |
|---|---|---|
| 90–100 | 選項辨識穩定 | 進入 Part 2；同時完成下面的實作證據，才算真的會用。 |
| 80–89 | 辨識大致正確 | 複習錯題解析後進入 Part 2。 |
| 60–79 | 辨識仍不穩 | 重做五個實際案例與案件追蹤練習。 |
| 0–59 | 概念尚未成形 | 重讀五層心智模型與使用環境辨識。 |
以下是本課程的教學評量設計，不是經過測量研究校準的認證標準。
| 能力 | 你要交出什麼 |
|---|---|
| 概念解釋 | 不用選項，用自己的話解釋兩個容易混淆的概念，並各給一個反例。 |
| 證據查核 | 指出資料版本、哪句話被哪個來源支持、哪個來源其實不適用、哪些仍然未知。 |
| 完成實際成果 | 一份可開啟或可執行的成品，附驗收結果與已知限制。 |
| 陌生情境遷移 | 換一個沒看過示範的業務情境，重新建立工作流程與驗收條件。 |
| 失敗診斷與修正 | 找出一個真實錯誤，說明原因，並交出修正後的證據。 |
以下是本章涉及 ChatGPT 產品能力時所依據的官方頁面，並標示它支持本章哪一段說法。這些都是會持續更新的動態文件，查閱日期不等於發布日期；產品介面、方案與推出範圍仍以你當下看到的介面為準。查閱日期：2026-09-13。
| 項目 | 內容 |
|---|---|
| 查核日期／依據 | 2026-09-13；依 2026-09 現況查核報告（內部紀錄，未發布於網站） 的 F03、F05、F09 修訂。 |
| 適用介面 | 本章為方法章，不綁特定客戶端；涉及入口時請依實際介面確認。 |
| 已執行的步驟 | 已查閱官方文件並改寫正文；未對特定帳戶逐項操作測試。 |
| 待確認 | 各方案實際可見的模型選項、Codex 環境入口。 |