選擇有用的第一項 AI 任務

選擇能驗證的任務

第一項有用任務，應讓你了解工具如何在自己的環境中運作，也要產生能檢查的結果。小幅修正已知缺陷，通常能同時滿足這兩個條件。

不要只因展示效果亮眼就選某項任務。大規模重新設計，可能產生許多可見變更，卻掩蓋錯誤假設。小任務可以看出代理程式是否讀取指令、遵守範圍，以及如實回報失敗檢查。

不必選最簡單的任務，而要選團隊能辨識正確結果、也能解釋為何正確的任務。

以報表應用程式中的三項虛構請求為例。

解釋任務有助於檢查推理與證據；迴歸測試則增加一項受控操作。架構任務之後可能很有價值，但需要更完整的任務說明和審查流程。

第一次練習選擇迴歸測試，使用虛構日期和本機分支。明確說明正式環境存取、相依項目升級及不相關重構，都不在範圍內。

「改善日期處理」留下太多解釋空間。改用具體條件：「輸入包含無效日曆日期時，回傳驗證錯誤。有效日期則保留文件記載的輸出。」

加入有效與無效輸入範例，指出現有測試命令。要求代理程式先檢查目前行為，再修改檔案。變更後，須簡短說明缺陷與證據。

區分任務結果和活動。「代理程式寫了測試」描述活動；「測試能拒絕已知缺陷」描述證據。如果測試對正確和錯誤程式碼都通過，就不能證明具備預期保護。

練習時，記錄代理程式在哪裡需要更多上下文。檢查它是否讀取相關儲存庫指令，留意是否修改範圍外的檔案，或沒有新證據卻反覆嘗試失敗的方法。

不必立即糾正每個小選擇。讓代理程式完成已授權、可復原的工作，才能評估結果。當下一項操作跨越邊界，或後續工作依賴尚未解決的需求時，再介入。

完成後，審查 diff 並執行相關檢查。同時記錄代理程式花費的時間，以及自己的準備和審查時間。這些觀察有助於選擇下一項任務，並改善工作指令。

練習成功後，增加一個面向的複雜度。例如，從一個函式擴大到兩個相關模組，或加入已有文件的整合。權限與驗證要求仍須明確。

練習失敗時，先找出原因，再擴大範圍。缺少上下文、需求不清、測試環境不可用，以及模型能力限制，需要不同修正。增加自主程度，不能解決全部四個問題。

如果原型持續使用，應指定維護負責人。即使程式碼未變，新的弱點資訊也可能需要處理。請參閱持續弱點管理。