報表匯出服務有個設定：所有工作節點合計，最多同時執行兩份大型報表。尖峰時段有人反映等待太久，團隊準備評估能不能調高上限。

程式看得出數字是 2，文件也寫「並行上限為 2」，卻沒有留下原因。這是早期環境的限制、曾經量測後的選擇，還是先設定一個保守值？

原因要說清楚保護了什麼、接受了什麼

假設當時的量測發現，匯出服務與訂單查詢共用資料庫。提高大型報表並行數後，訂單查詢超出回應時間目標，因此團隊在當時的資料量與環境下，將上限設為兩份，接受尖峰時報表需要排隊。

文件若只寫「為了效能」，就省略了這個取捨：保護的是一般訂單查詢，代價是報表較晚完成。日後想縮短報表等待時間，就需要同時考慮對線上查詢的影響。

數字的作用範圍也要留下來。「全部工作節點合計兩份」與「每台兩份」代表不同的負載。後來增加節點時，如果只保留數字、遺失範圍，就可能改變原本決策想達到的結果。

記錄當時的選擇，也留下重新選擇的條件

這類內容可以整理成簡短的決策紀錄；涉及架構選擇時，也常稱為 ADR。以下用這個案例示意：

只記錄實際比較過的方案，並區分已量測的結果與尚待確認的風險，不必為了填滿表格補寫。當年的量測支持上限為兩份，也不表示這個值永遠適用；留下重新評估的條件，才能讓文件成為調整的依據。

合理的解釋，不能取代真實的決策依據

AI可以從程式流程與設定推導出限制並行數的合理原因，但「這樣設計有什麼好處」，不等於「團隊當時為什麼這樣選」。若原始討論或量測紀錄已不可考，就將原因標為待確認，並分開記錄目前的推測與查證結果，避免把推論當成歷史事實。

日後改採新方案時，保留舊紀錄並標示取代它的新決策，同時更新相關設定與操作文件。讓過去的選擇有跡可循，也讓目前有效的做法清楚可辨。

有用的決策文件，留下選擇的依據、接受的代價與適用條件。後來的人才能判斷哪些理由仍然成立，哪些限制已經值得重新考慮。

「這個限制是誰訂的？」
「三個月前的你。」
「有寫原因嗎？」
「你寫：這個很重要，不要改。」