任務邊界
到底要做什麼、不做什麼。
確認目標、範圍、一次性原型或長期工具、是否需要保存資料、是否需要可重複使用。
AI 很認真亂做,通常不是因為模型太弱,而是需求還沒被問清楚。Grill Me 的價值,是讓 代理 在動手前先把受眾、限制、輸出、技術選擇與不能做的事全部釐清。
Grill Me 不是魔法 提示詞,也不是自動化工具。它是一種「先訪談再執行」的工作法:當需求還只是方向,代理 必須先追問你,直到任務能被清楚執行。
例如:做一個側邊欄小遊戲、做一份教學檔、整理一個客戶問題。
代理 先問使用情境、限制、成功標準與不能做的事。
把回答整理成 任務摘要、產品需求文件 或任務規格。
用 TDD 或驗收清單定義紅燈與綠燈。
交給 Codex、Claude Code、PM 工作流程 代理 或內容輸出 代理。
到底要做什麼、不做什麼。
確認目標、範圍、一次性原型或長期工具、是否需要保存資料、是否需要可重複使用。
誰在什麼環境使用。
釐清是側邊欄、桌面、網頁、手機、團隊工具或客戶場景;不同入口會影響操作設計。
怎麼操作、哪些不能碰。
確認鍵盤、滑鼠、觸控、通知、權限、資料保存、清除紀錄,以及安全與隱私限制。
什麼叫做完成。
用驗收條件描述成果:能否正常操作、資料是否正確、畫面是否符合使用者情境。
怎麼知道沒有壞。
把需求轉成紅燈/綠燈測試、手動驗收或 Playwright 檢查,避免只看 示範 感覺。
做完之後誰接手。
確認檔案位置、文件、使用說明、錯誤處理、重設方式,以及是否需要寫成 技能。
| 面向 | 直接叫 代理 做 | 先用 Grill Me 訪談 | 實務判斷 |
|---|---|---|---|
| 需求品質 | 代理 會自行猜測未定義細節。 | 未定義處會被先問出來。 | 客戶/內部專案應先訪談。 |
| 功能完整度 | 可能能跑,但缺模式、紀錄、通知、重設等情境細節。 | 功能來自明確使用情境,而不是隨機腦補。 | 正式工具要有情境設計。 |
| 返工風險 | 後面才發現方向錯,常要重構。 | 早期先對齊,降低後續大改。 | 越高風險越要先問。 |
| 測試方式 | 多半只看 示範 能不能跑。 | 可轉成 產品需求文件 與 TDD 驗收。 | Codex 實作前要有測試標準。 |
| 適用任務 | 小型一次性草稿。 | 專案、報告、工具、代理 工作流程。 | Hermes 穩定流程都該採用。 |
先問讀者是誰、看完要會什麼、需要哪些圖解、哪些字眼不能出現、是否要手機預覽與分享格式。
先問異常定義、影響範圍、負責人、期限、證據、下一步,以及哪些資料不能外流。
先問檔案範圍、預期行為、不可改動區域、測試方法、回復 條件,避免一改就散。
先問研究問題、可信來源、時間範圍、信心等級、是否需要進 raw/inbox,而不是直接寫成正式知識。
在開始執行前,請先反過來訪談我。 請一次問一個最關鍵問題,直到你能整理出: - 目標 - 使用者與場景 - 輸出形式 - 限制與不能做的事 - 成功標準 - 測試/驗收方式 在我回答完之前,不要開始實作。
請把剛剛的訪談整理成 PRD。 格式包含: 1. 背景與目標 2. 使用情境 3. 功能需求 4. 非功能需求 5. 不做的範圍 6. 驗收條件 7. 風險與待確認問題
請根據這份 PRD 產生 TDD 計畫。 請列出: - 紅燈測試 - 綠燈標準 - 邊界條件 - 手動驗收步驟 - 需要截圖或瀏覽器檢查的地方
請在製作 Michael 教學筆記 HTML 前先訪談我。 你要問清楚: - 讀者是誰 - 看完要會什麼 - 哪些內容要圖解 - 哪些字眼不能出現 - 是否要手機預覽 - 是否要寄信 問完後先輸出 brief,不要直接做 HTML。
以下來源用於核對 Codex 技能、Matt Pocock 技能 倉庫與 Grill Me / Grill with Docs 相關工作法。第三方 技能 導入前仍需依 來源、權限與適用範圍審查。