與 Coding Agent 合作時，上下文的品質經常比長度更有影響。不是把整個專案貼進對話，而是提供目前任務需要的資訊。
穩定資訊與任務資訊分開
穩定的專案資訊可以放在儲存庫文件中，例如啟動方式、目錄結構、測試指令與程式風格。隨任務變動的內容，則寫在當次要求裡：背景、修改範圍與驗收條件。
這樣做可以避免文件不斷堆疊過期的需求，也讓新任務更容易開始。
最值得提供的三種資訊
專案中的既有做法
指出一個最接近的元件、資料流程或文章格式，往往比口頭描述十條規則更有效。要求沿用現有慣例，並說明哪些差異是刻意的。
明確的修改邊界
例如「只調整文章列表，不更換內容儲存方式」或「可以新增依賴，但要說明必要性」。邊界讓實作更容易審查。
可觀察的驗收結果
避免只寫「要好用」。改成「手機上能操作分類」、「搜尋沒有結果時可以重設」或「重新開啟分享網址後仍保留篩選」。
給上下文，也保留查證空間
文件不可能永遠完整。好的指示應允許 Agent 先讀取現況、指出矛盾，再依證據實作。當文件和程式不同時，讓差異浮上檯面，比繼續累積猜測更有價值。
一次只改善一個地方
下一個任務可以試著補上一個相關檔案位置，或一句具體的驗收條件。觀察它是否減少重做，再逐步形成適合自己專案的合作方式。