當我們需要 LLM 執行複雜任務時，通常需要餵給它大量的情境。為新功能設計方案，需要描述我們希望該功能呈現給使用者的樣子、實作時應遵循的指引、需參考的外部系統等資訊。這些內容可能長達數頁 Markdown。顯而易見的方式是由人類撰寫這些情境，但另一種做法是讓 LLM 在訪談人類後，產出這些情境。

我的做法是提示 LLM 對我進行提問。它應該詢問所有必要的問題，以便建立合適的情境。我可以提供它所需的大部分資訊，並告訴它若無法自行判斷，應查閱哪些其他來源。完成後，它便能為另一個工作階段（可能使用另一個模型）產生情境報告，以執行下一步。

我第一次看到對這種方法的完整描述，出自 Harper Reed 的部落格。他方法中特別值得注意的一點是堅持 LLM 每次只問一個問題。（我自己嘗試時發現，需要經常提醒它這一點。）

另一種使用提問式 LLM 的方式，是給它一份文件，例如軟體規格，裡面已包含領域知識，然後要求 LLM 訪談人類專家，以判斷該文件是否正確。這是讓人類專家閱讀文件進行審查的替代方案。人們通常覺得審閱很辛苦，因此與 LLM 的對話可能更有效率，特別是當文件撰寫不佳時。

當然，我們可以同時使用這兩種方式：先用一個提問式 LLM 建立文件，再用其他提問式 LLM 與其他專家一起審查。

以上所述，是讓 LLM 為特定 LLM 使用情境建立或評估情境。但這種技術適用範圍更廣。我已經成為一個自然寫作者，認為寫作是思考過程中不可或缺的一部分。要真正理解某件事，我需要寫下來。但每個人都不一樣。許多人覺得寫作很困難，而且常常非常困難。當我們需要把某人的想法轉化成其他人能理解的形式時，這會成為真正的問題。也許這些人會覺得讓 LLM 訪談他們，比自己撰寫文件更容易。當然，結果會帶有那種讓像我這樣的人感到不寒而慄的 AI 寫作風格——但這總比完全沒有資訊（因為草率撰寫或根本沒寫）要好。