模型、上下文與錯誤答案

區分能力與可用資訊

語言模型運用學到的模式，以及任務期間提供的資訊。現代模型能做大量推理，也能完成有用的軟體工作，但仍可能基於錯誤假設，產生詳細答案。

「前沿模型」描述的是持續變動的能力水準。這個稱呼不代表模型讀過你的儲存庫，也不表示它知道相依項目版本或未成文的業務規則。任務環境必須提供這些事實。

有合適工具的代理程式可以取得資訊；沒有存取權的聊天介面，則無法檢查儲存庫。答案看似錯誤時，問兩個問題：模型取得正確資訊後，能解決問題嗎？模型實際收到這些資訊了嗎？

換模型可能幫助解決第一個問題。補上缺少的政策，或檢查相依項目，則可能解決第二個問題。

定義這項任務的上下文

上下文是產生目前回應時可用的資訊，包括指令、提供的檔案、相關對話和工具結果。各產品選取與保留資訊的方式不同，也可能摘要整理先前內容。

不要假設模型讀取了上傳資料夾中的每個檔案，也不要假設最初的指令會在漫長工作階段中一直保留。請工具指出實際使用的檔案和指令。

上下文更多，不一定讓答案更好。現行架構決策，可能比不相關的原始碼更有用。過時的移轉指南可能看似權威，反而導致錯誤答案。

以虛構帳號設定功能為例。提供路由、授權中介軟體、相關資料模型和既有測試，再加上具體限制：「成員可以修改自己的顯示名稱，但不能修改自己在組織中的角色。」模型現在有明確規則需要保留。

檢查解釋中的說法

答案可能聲稱端點安全，因為中介軟體會檢查資料歸屬。逐項驗證這個說法。

1. 檢查端點是否使用指定的中介軟體。
2. 檢查中介軟體是否驗證資料歸屬，而不只是身分驗證。
3. 確認使用者身分的來源。
4. 以另一名使用者執行拒絕存取測試。

儲存庫引用指出應去哪裡查看，但不能證明解釋與程式碼一致。

評估 API 建議時，也使用相同方法。生成的程式碼可能呼叫已安裝套件未匯出的方法。替換相依項目前，先檢查套件版本與官方文件。否則，沒有根據的假設可能造成不必要的移轉。

將不確定性轉成檢查

「務必正確」不是驗證計畫。應指出假設、所需證據，以及錯誤結果的後果。

例如：「尚未驗證這個端點的租用戶隔離。檢查請求處理函式，加入另一個租用戶的使用者請求同一筆紀錄的測試。」這項指令提供具體調查工作，以及可觀察的結果。

遇到實作問題，應檢查實際系統版本。文件可以描述預期行為，程式碼檢查和測試則有助於確認目前行為。兩者不一致時，記錄差異，直到負責人解決。不要默默選擇比較方便的答案。

管理者不必閱讀每項程式碼變更，也能運用這個方法。詢問團隊檢查過哪些假設，確認哪些仍未解決，以及各自的負責人。相較於模型名稱，這些資訊更能直接支持發布決策。