「幫我看 Python session 的錯誤，順便提出怎麼改。」這句話交給 IDE 裡的 agent，如果它把「看」理解成「執行修復」，回覆寫得再像資深工程師也沒用。背後多跑了一段程式、改了檔，任務就已經走偏。
我會把 skill 當作團隊維護的任務契約。提示詞可以描述語氣和步驟；契約得讓人查得出：它為什麼被叫起來、實際碰了什麼、憑什麼說完成，以及做不到時停在哪裡。
以資料框轉換出錯為例。使用者想知道目前 session 跑到哪裡，並取得一個最小修改建議。團隊可以把這件事拆成兩個自訂 skill：
ryanvale
inspect-runtime：只在使用者要診斷目前執行狀態、且已選定工作區與 session 時觸發。允許查詢 session 與必要的錯誤線索；輸出觀察、來源位置及不確定之處。不執行新的程式碼。propose-change：接收診斷證據與相關檔案內容，產生待審的修改建議。它不能自行改檔、提交、推送或部署。要落地修改，另外取得明確授權並走另一條工作流程。這些名稱與欄位是本文的團隊設計示例，不是某個 IDE 的官方 skill 格式。刻意分開的原因很實際：只問「這段轉換為什麼報錯」的人，並沒有同意讓 agent 在含有真實資料的 Console 試跑修正。
IDE 現在確實有更貼近現場的工具介面。Positron 的十月更新介紹了供外部 coding agent 存取正在運行的 Python／R session 的實驗性 MCP server；agent 執行的程式會在 Console 標出名稱。這提供了觀察執行行為的線索，卻不能把「看得見執行紀錄」當成「權限已被妥善限制」。這項 MCP 能力需要啟用 ai.mcp.enabled；另一個 Posit Assistant IDE 預覽功能則是不同功能，也不能混作一般已開放的預設能力。本文沒有替讀者在 Positron 實測這套 skill。
因此，團隊若要實作上面的唯讀路徑，必須在自己的工具配置裡限縮可呼叫的操作；若只能透過執行 Console 程式來取得資料，就不要把那條路徑假裝成唯讀查詢。先停下來請人決定，比偷偷升權更可靠。
我會在每個 skill 旁邊放一份團隊自己的契約，至少填完這些欄位，再討論 prompt 怎麼寫：
| 欄位 | inspect-runtime 的約定 |
|---|---|
| 觸發與排除 | 問目前 session 的狀態可觸發；要求直接改檔或執行修復不在範圍內 |
| 必要輸入 | 工作區、使用者指定或確認的 session、要排查的錯誤或操作 |
| 可用工具 | 經團隊確認的 session 唯讀查詢；不准執行程式、修改檔案或把物件內容整包帶走 |
| 交付證據 | session 識別線索、觀察到的錯誤位置、查詢時間與未能確認的部分；敏感資料只記必要資訊 |
| 停止與接手 | 找不到 session、工具遭拒或兩個 skill 同時符合時標記 blocked，說明缺口並交由使用者選擇 |
這不是要替每個問題建一份複雜規格。它只要求 agent 的動作範圍能被檢查。若團隊選用的工具沒有可用的唯讀查詢能力，表格裡就得改寫成「此情境無法執行」，不能靠 prompt 裡一句「請小心」補洞。
輸出也應有固定的最低要求：status、observations、evidence、missing、next_owner。其中 done 只表示約定的查詢確實完成、證據足以支持結論；找到可能的修法，不等於已執行，更不等於已驗證。propose-change 的完成狀態只能是「建議已交付待審」，不能借用修復成功的語意。
路由衝突最容易被忽略。當使用者說「看一下錯誤，能改就改」，兩個 skill 可能都命中。這時讓模型自由挑一個，等於讓它替使用者決定能不能動手。我會先處理觀察需求，再把改動列成需要確認的下一步；如果任務仍有歧義，就回問，不觸發有副作用的工具。
session 不存在或工具拒絕存取，則回報 blocked，保留原始任務、缺少的證據與人工接手者。可以請使用者提供去識別化錯誤訊息或檔案片段做離線分析，但要清楚標示那不是現場 session 的診斷結果。也別因為 MCP 查不到，就改用有更大權限的 Console 執行來「補資料」。
最後一種更難抓：agent 確實找到了相關檔案，也寫出一個合理修正，卻沒有當前 session 的錯誤資訊，或根本沒有跑過驗證。這時可以交付假設與建議，狀態仍不能寫成「已修好」。把「缺哪項證據」寫在回覆裡，審查者才知道下一步該補什麼。
最小的回歸測試不必很華麗。我會用兩個正常請求檢查能否選對觀察與建議流程，再放進幾個刻意刁鑽的案例：只要求查錯卻可能誤觸執行、兩個 skill 同時符合、session 已結束、唯讀工具遭拒，以及有修正提案卻沒有實際執行結果。
每個案例都核對同一組事情：最後啟動了哪個 skill、實際呼叫哪些工具、輸出證據是否足夠、blocked 時誰接手。尤其要檢查「零次寫入」是否真的由工具層限制，而不是只靠模型在文字裡保證。這裡是建議的測試清單，不是宣稱任何產品或本篇範例已通過測試。
一份跨地區開發者調查裡，多數受訪者感覺 AI 讓交付更快，回報日常流程摩擦明顯減少的人卻少得多。這不表示上述契約已證明能改善效率；它提醒我，能快速產生答案與能讓團隊安心接手，是兩道不同的門檻。
能維護的 skill，遇到叫錯、查不到或不能動手時，也會明確停下來，讓接手的人知道下一步該查什麼。
iThome鐵人賽
看影片追技術