透過經驗證的改善，讓回饋形成閉環

定義要完成的回饋循環

軟體使用期間會產生證據：錯誤、延遲、支援請求、事件、維護時發現的問題和重複人工作業。完整生命週期會將這些證據帶回工程決策。

自我改善軟體可以指自動化協助辨識、提出、實作和驗證變更，不一定代表模型自行訓練。明確指出改變的部分：應用程式碼、設定、測試、指令、工作流程，或模型參數。

自動復原恢復已知的運作狀態。自我改善則修改系統，讓未來產生更好結果。後者需要比較，也需要防止迴歸問題。

追蹤一項觀察走過生命週期

以下順序是一種建議工程方法，並非宣稱任何產品能自主完成每一步。

保留這些產出之間的連結。事後檢討若只寫「改善監控」，很難驗證。明確訊號、負責人、門檻和經測試的應變，才能讓完成狀態可觀察。

讓評估獨立於提案

代理程式可以建立修補並提出測試。團隊仍須檢查那些測試是否偵測原始問題。保留有版本的評估集，避免變更悄悄削弱評估。

對虛構記憶體洩漏，比較相當的工作負載與版本。納入大型匯出、取消、重試和拒絕存取案例。使用能代表相關資料結構的合成資料，不暴露客戶紀錄。

匯出若遺漏紀錄、略過授權或超過允許成本，即使更快也應拒絕。最佳化前就定義這些限制，否則系統可能改善選定指標，卻讓服務變差。

修改代理程式指令或模型時，以具代表性任務與已知失敗案例評估行為。保留先前版本可供使用。更新指令，不代表底層模型已從事件中學習。

發布並衡量結果

金絲雀發布（canary release）讓有限範圍的使用者接觸候選版本。比較候選組與對照組訊號，並定義何時擴大或停止。流量稀少或工作負載不同，可能讓比較無法得出結論。金絲雀發布指引。

虛構團隊以固定合成工作負載記錄基準，測試修正，在核准邊界內發布，再檢查可比較的正式環境期間。證據仍不足時，記錄不確定性，而非宣告成效。

也要衡量重複人工作業。自動化能減少繁瑣作業，但自身也需要維護與失敗處理。判斷結果時，納入這些成本。減少繁瑣作業指引。

讓回饋紀錄可供實際使用

練習使用這些欄位：觀察與版本、基準、提出的原因、驗收條件、迴歸檢查、變更與審查、發布邊界、實測結果、負責人和下次複查。

Taiga Maintaining 將儲存庫中發現的問題連結到修補工作。Initiatives 將預定變更連結到規劃與交付。這些功能提供證據鏈的部分環節，但服務負責人仍須驗證部署與維運結果。Maintaining、Initiatives。

成熟的軟體工廠會跨產品連結這些工作。自動化增加時，仍讓決策權與評估條件清楚可見。最終證明是經驗證確實改善的服務，不是更多生成變更。