Agent 改完重試機制，測試通過，附上一大段說明。接手的人卻答不出來：如果伺服器已經完成寫入，只是回應在途中遺失，再送一次會發生什麼？這份交付有程式、有測試，也有摘要，人的判斷仍停在「看起來合理」。

Andrej Karpathy 在 2026 年 10 月 2 日的貼文談到類似的理解負擔。他建議試用受控技術英文，再依需要改成圖解、可互動 HTML 或客製解說影片。他尤其看好影片，也預期 Agent 承擔更多工作後，人會花更多心力監督與理解結果。這些是他的使用經驗與預測，原文沒有提供不同格式的學習成效比較。

本文把這個建議延伸成一個工程判斷：交給人批准的工作，應附上足以做決定的解說與證據。驗收時要確認接手的人能說明適用條件，並預測一個失敗案例。格式選擇服務這個目的，不預設每件事都值得做成影片。

簡化句子時，要留下會改變決定的條件

Karpathy 提到 ASD-STE100，也說嚴格套用時可能太受限，因此有時只要求接近其風格。這不是一個標準符合性聲明。

ASD 官方介紹將 Simplified Technical English 定義為受控自然語言，結合寫作規則與受限制的詞彙；它起源於航空維修文件。官方下載頁的 AI 說明還特別警告：模型可能產出看似符合 STE、實際卻誤用規則或詞彙的文字。若工作要求正式符合標準，仍須逐項檢查，不能讓模型自己宣告通過。

繁體中文團隊可以借用「固定術語、明確主詞、拆開條件」的編輯思路，不把中文文件標示成 ASD-STE100 合規。以開頭的重試機制為例，下面兩段都是本文編寫的示意文字：

系統會自動處理暫時性錯誤，提升可靠性，並確保請求安全完成。

這段沒有交代誰重試、重試哪個動作，也無法判斷「安全」指什麼。可改成：

用戶端在讀取回應逾時後，最多重送兩次。重送沿用同一個操作 ID。伺服器必須把去重紀錄與業務寫入放在同一個交易內，並以操作 ID 的唯一約束或等價的併發控制阻擋重複執行。若無法確認上述條件，這份變更不開啟自動重送。

後一段更長，但審查者知道要找哪段程式，也知道什麼情況必須停下來。這裡的交易設計只是示例前提；跨服務操作、外部副作用與去重紀錄過期，還需要另外處理，不能由這段說明推得端到端恰好執行一次。

停止規則：改寫若刪掉會改變放行決定的前提，就退回重寫。 「更好懂」不能靠隱藏限制達成。

用讀者要回答的問題選格式

同一份重試機制，可能需要四種不同的閱讀工作。以下是本文的選擇方法，不是 Karpathy 已驗證的效果排名。

要找責任與前提，先用短文字

審查者要知道誰發送、誰保存操作 ID、去重資料留多久，以及哪些測試尚未執行。這些資訊適合可搜尋、可引用的文字。每個結論旁邊放檔案位置或測試結果，讀者能立刻回到證據。

若一句話已能回答問題，就不增加另一份圖像產物。少一個需要同步維護的版本，也少一次文字與畫面互相矛盾的機會。

要追跨系統關係，用靜態圖

當爭議落在「寫入完成」與「回應送達」之間，圖解可以把兩件事放在不同節點，標出回應遺失與重送的路徑。箭頭應指向真實事件，並保留未知區段，不能為了畫面整齊把失敗分支省掉。

圖上若寫「去重成功」，應能追到處理相同操作 ID 的程式或測試。畫出一個方框只證明模型能畫圖，不能證明系統有這項保證。

要改條件看結果，用互動 HTML

如果讀者要比較不同回應延遲、去重保存時間與重試間隔，可用互動頁面調整參數。介面要區分「實際量測」與「假設值」，並顯示目前使用哪組條件。

一個展示每次都成功的動畫，對設計審查幫助很小。我會要求它至少能呈現「寫入成功但回應遺失」和「去重紀錄已過期」兩種案例，而且能重設、重播。這是解說模型的驗收要求；它仍然需要和正式程式的測試對照。

要引導第一次閱讀，才投入影片

影片可以依序介紹角色、事件與失敗路徑，但觀眾很難像查文字一樣快速定位細節。解說片應保留章節、文字稿與對應來源，讓第二次閱讀的人能跳到問題所在。

3Blue1Brown 的官方 FAQ也提醒創作者避免沒有目的的動作，讓旁白與視覺共同說明同一件事。用動畫模仿外觀容易；決定哪個瞬間該停下來，才會影響這個案例是否講清楚。

本文沒有製作或比較這四種格式的教學成效。若決定製作影片，站內〈Claude 寫出影片程式後，先驗收每一幀的時間契約〉處理的是逐幀渲染與聲畫對齊；本篇處理的是觀眾看完後能做什麼判斷。

同一個 Agent 的解說，不能替自己的結論背書

Agent 可能把錯誤理解寫進程式，再用同一個理解畫圖、配音。四個產物彼此一致，仍可能一起錯。多一種媒介，沒有自動增加獨立證據。

我會要求解說旁邊保留一份精簡的證據清單。它不需要重印所有 log，但必須能區分三種材料：

  • 已觀察到的行為：來源版本、程式位置、實際執行過的測試，以及結果檔案。
  • 為了說明而設定的假設：例如回應在寫入後遺失、操作 ID 保存一天；這些不能冒充現場量測。
  • 尚未確定的部分：例如外部服務是否共享同一去重規則，以及尚未測過的錯誤路徑。

在重試案例中，解說若主張「不會重複寫入」，審查者至少要能找到覆蓋重送的測試。若證據只測了成功回應，動畫裡的逾時分支就只能標示為設計假設。

下面的提示可用於準備這份交付。它是本文的工作流提案，沒有宣稱某個模型一定會遵守，也沒有執行模型間的效果比較。

這次交付要協助審查者決定：是否開啟自動重送。

先列出你實際讀過的來源版本、程式位置與已執行測試。
把未執行的測試、設計假設和未確認項目分開標示。

用繁體中文說明：
- 哪個元件在什麼條件下重送？何時停止？
- 哪個條件成立時可以避免重複寫入？證據在哪裡？
- 如果寫入完成但回應遺失，接下來會發生什麼？
- 哪一個反例會讓目前的建議失效？

先交付短文字；只有文字無法清楚表達關係時才補圖。
如果需要互動頁面，標明假設值，並提供重設與失敗案例。
不要把解說中的模擬結果寫成正式系統的測試結果。

這份提示的用途，是把缺資料的地方顯露出來。若 Agent 找不到來源，增加影片長度只會延後審查者發現缺口的時間。

可丟棄的解說，仍需要可追溯的版本

Karpathy 看好為單次理解需求生成大型客製產物的可能性。對工程團隊而言，我會把這個方向限定在解說層：可以為今天的決策做一個互動頁面，用完後刪除；支撐決策的來源版本與驗證紀錄仍要保留。

這能減少把每個教學原型養成長期產品的負擔，但需要一道清楚的隔離。一次性解說頁只讀取經挑選的示例資料，不攜帶正式環境憑證，不提供修改正式系統的按鈕。頁面也應標示依據的 commit 或文件日期，避免半年後被轉傳時，看起來仍代表現況。

解說需要更新時，從同一組已確認的來源重建，然後再查一次主張與畫面的對應。只修旁白卻沒改畫面、只換程式卻留下舊圖，都會製造新的誤解。

這和〈用原型與型別草圖取代抽象 Plan〉的分工不同：原型用來回答尚未確定的設計問題；解說產物用來讓人掌握已知結果與剩餘疑問。兩者都可以短命，證據與用途卻要說清楚。

最後五分鐘，用反例驗收理解

閱讀完成後，可以請接手的人不看解說，用自己的話回答：這次改了什麼、在哪個條件下可以放行，以及遇到一個新案例時會怎麼判斷。

對重試機制，這個新案例可以是：「同一個操作 ID 隔天才再次送達，而去重紀錄已被清掉。」能答出「目前的去重前提可能已失效，需要查保存期限與業務約束」，比重複影片中的「系統能安全重試」更接近可用的理解。

這個方法也有範圍：人的正確重述無法替代程式測試；一句答錯的話也未必代表設計錯了，可能是解說省略條件，或讀者缺少必要背景。因此要分別記錄實作缺陷、證據缺口與解說問題，再決定退回哪一步。

若要比較文字與影片，先固定同一個決策題、同一組來源與相近背景的讀者，記錄閱讀時間、找出錯誤前提的情況，以及需要多少次追問。小規模觀察只用來改善自己的流程，不包裝成通用 benchmark。

下一次讓 Agent 交付變更時，在既有測試之外加上一個反例問題。要求它附上證據，讓接手的人先預測結果，再打開測試核對。這比多生成一支精緻影片，更容易知道目前還缺哪一段理解。

若問題是人根本沒注意到輸出中的關鍵資訊，可接著讀Claude Code 的 You should know 提醒驗收；該文處理漏報與介入時機，再把需要理解的問題交回解說流程。

若要把受控語言的思路用在中文文件，〈中文技術寫作借用 STE〉進一步示範術語表、原句對照與條件保留檢查，避免 Agent 在潤稿時擴大驗證範圍。

我把過去用 show me 生成本地暫存 HTML 的習慣整理成 AnswerMe。〈我為什麼做 AnswerMe〉記錄理解債如何促成這個 skill，以及來源核對、格式選擇與交付檢查的取捨。