「已部署至 staging，單元測試通過，付款重試的整合測試尚未執行。」Agent 把它整理成「修正已完成驗證」，字變少了，讀者卻可能因此批准一個原本還不能批准的變更。
中文技術文件的改寫，我會先驗收這種資訊損失。句子順不順、長不長，可以留到第二輪；環境、條件、否定與證據狀態，第一輪就不能弄丟。
磊叔整理的〈Karpathy 的《ASD-STE100》中文版〉把 ASD-STE100 的技術寫作思路帶入中文，也提供給 Codex 使用的提示詞。頁名雖提到 Karpathy，中文整理與提示詞仍應歸於磊叔。本文沿著這個方向，提出一套中文工程文件的改寫檢查方法。它是借鑑 STE 原則的編輯實務，不是官方中文版標準，也不宣稱通過 ASD-STE100 符合性驗證。
站內〈Karpathy 談 AI 解說〉處理讀者能否理解，以及文字、圖解與影片怎麼分工。本篇把範圍縮到一份中文文件：同一個技術事實，改寫後還剩下多少？
英文標準提供方向，中文團隊仍要定義自己的規則
依 ASD 官方介紹，ASD-STE100 是面向技術文件的受控自然語言，包含寫作規則與受限制的詞彙，起源於航空維修文件。查核至 2026 年 10 月 4 日，官方列出的版本為 Issue 9，發布於 2025 年 1 月 15 日。
官方 FAQ說明，可以把一般寫作原則借用到其他文件，也容許專案所需的技術名詞與動詞。這給中文團隊一個可用的起點：固定同一概念的名稱、讓動作與條件可辨識、減少讀者需要猜的地方。
但英文的核准詞彙不能直接變成中文詞庫，英文的字數限制也不能換成中文字數後照搬。「快取失效」有四個中文字，cache invalidation 有兩個英文單字；計數相同或不同，都沒有回答讀者是否理解快取失效的時機。中文團隊應把自己的規則命名為「中文技術寫作指南」，並記錄哪些原則來自借鑑、哪些是專案自行制定。
模型也不能自行證明它符合標準。ASD 的下載頁提醒，AI 可能寫出看似符合 STE、實際誤用規則或詞彙的內容；工具說明頁則說明 ASD／STEMG 不替相關軟體或 AI 工具背書、認證。把提示詞命名為「STE 模式」，不會改變這個限制。
本文不重刊標準全文，也不整段搬用磊叔的提示詞。需要正式使用標準時，從官方下載頁取得相應版本，再依專案要求逐項核對；下面的例子與檢查流程都是本文自訂的示意，尚未做模型效果實驗。
術語表要鎖住概念，別把不同狀態磨成同一個詞
假設團隊的文件交替使用「重送」「重試」「補償」描述失敗處理。若 Agent 為了用詞一致，全改成「重試」，讀者可能再也分不出：這次是重新發出同一個請求、重新執行一個工作，還是執行反向業務操作。
一份有用的術語表，至少要寫出偏好的名稱、它指向的概念，以及不能拿來替代的詞。下面是虛構付款服務的專案詞彙，不是通用定義：
terms:
- preferred: 重送請求
meaning: 用戶端再次傳送同一個操作的請求
preserve_identifier: operation_id
do_not_replace_with: 補償
- preferred: 補償
meaning: 以另一個業務操作處理先前操作的效果
do_not_replace_with: 回滾資料庫交易
- preferred: staging
meaning: 本專案的預備環境
do_not_replace_with: 正式環境這份詞彙表的價值，是讓審查者看見名稱背後的界線。若原稿寫「失敗後會恢復」，Agent 無法只靠這三條定義判斷「恢復」到底是哪個動作。合適的輸出是保留原句、列出待確認問題，不能挑一個聽起來最像的詞補上。
API 欄位名、錯誤碼、命令與版本號也應保留原樣。把 operation_id 翻成「操作識別碼」可以幫助解釋，但首次出現時仍要保留原始識別字，讓讀者找得到程式與紀錄。
拆句的驗收單位，是一個可以核對的主張
「每句只寫一件事」可以當編輯方向，卻不能靠句號數量驗收。條件和結果若被拆開，後一句可能被單獨引用，變成沒有前提的保證。
以下原稿與改寫是本文編造的練習材料；測試數字、環境與效果都不是實際專案成果。
原稿
快取逾時的修正已在 staging 部署；這次單元測試 18/18 通過，但付款重試整合測試尚未執行。可能降低重複扣款風險，正式環境尚未驗證。
可接受的改寫
- 已完成：修正快取逾時，部署至 staging
- 已驗證：這次單元測試 18/18 通過
- 尚未執行：付款重試整合測試
- 尚未驗證：正式環境行為
- 預期效果：可能降低重複扣款風險，仍待驗證
改寫沒有增加成果。它只是把原稿的不同資訊拆到各自的位置。讀者能立刻分辨「程式改完」「某組測試通過」和「業務風險降低」之間還缺什麼。
應退回的改寫
已完成快取修正，所有測試通過，可避免重複扣款。
這句有三個可指出位置的錯誤：「所有」擴大了測試範圍，「可避免」把可能效果改成保證，staging 與正式環境的差別也消失了。審稿不需要爭論哪一版更流暢，直接回到原句就能退回。
停止規則：改寫若擴大驗證範圍、提升確定程度，或刪掉影響放行的條件，該段不得採用。
原稿本身也可能含糊。這個案例沒有說明誰負責整合測試、測試報告在哪裡、什麼結果才允許發布。這些應列為缺口，不能在改寫時捏造負責人、報告連結或驗收門檻。
否定與數量詞，值得單獨查一次
中文常省略主詞，也常把限制藏在句尾。自動潤稿若只追求肯定句與短句，很容易削弱禁止條件。
例如原稿寫：
只有操作 ID 相同，且去重紀錄尚未過期時，這個示例才允許重送；未出現錯誤不代表通過驗證。
可以把條件拆成清單，但必須保留「全部成立」的關係，以及後半段對驗證的否定。改成「操作 ID 相同或紀錄未過期即可重送」會把 AND 改成 OR；改成「沒有錯誤即通過驗證」則直接反轉意思。這裡只在示範文字邏輯，不代表上述條件足以保證真實付款系統的重送安全。
我會讓審查者在改寫前後各圈出一次：
- 條件：只有、除非、且、或、當……時
- 否定：不得、尚未、不代表、無法確認
- 範圍：全部、部分、這次、正式環境、指定版本
- 數量與程度：最多、至少、可能、預期、已驗證
圈出的詞不必逐字一樣，但邏輯關係必須相同。「尚未執行」不能變成「未通過」，「部分案例通過」不能變成「功能正常」。這份檢查特別適合發布紀錄、事故報告與操作手冊；純敘事文章則未必需要逐句如此處理。
讓 Agent 交回對照，而不是替自己蓋章
只要求「請用簡潔中文重寫」，審查者會收到一份完成度很高、卻很難追查改了什麼的文件。我會要求同時保留原稿與變更理由，優先處理可能改變決策的句子。
以下是本文原創的工作提示，可作為試用起點；它沒有經過模型間比較，也不保證 Agent 一定遵守。請把占位資料換成已授權使用的文件，不要加入不該提供給該工具的資料。
目的：協助工程師核對技術文件，保留原文的事實與限制。
輸入：原稿、專案術語表、來源版本或日期。
請逐段改寫成繁體中文。優先處理主詞不明、術語混用與多層條件。
保留識別字、版本、數字、環境、否定、條件關係與不確定程度。
不要把未執行改成未通過，也不要把部分測試通過改成全部驗證完成。
交付：
1. 改寫稿。
2. 有語意風險的原句與改寫對照，說明保留的限制。
3. 缺少來源、定義、負責人或驗收條件的待確認清單。
無法判斷原句時，保留原句並提問，不要補造事實。
不要宣稱符合 ASD-STE100，也不要自行宣布文件已獲批准。對照稿仍可能漏掉錯誤，所以不能只看 Agent 列出的「已保留」清單。審查者要抽查原稿，特別是原文含條件、數字與禁止事項的段落。若文件會影響安全或正式環境操作，就應由熟悉該系統的人逐項審查，不能把語言改寫工具當成領域驗證工具。
當文件缺少證據時，工作會退回資料提供者。把「待確認」留在交付裡，比讓模型自信地補成一句完整敘述更有用。
把改寫檢查放進文件的版本流程
團隊若想把這套方法變成日常工作，可以先拿一份變更說明做小範圍試用。保存原稿版本、術語表版本、改寫稿，以及人工指出的錯誤；不要只留下最後一份漂亮文件。
可機械檢查的部分很有限：識別字有沒有消失、數字是否改動、禁用同義詞是否出現。這些檢查適合提示風險，但不能直接判定語意相同。相同數字可能被放到不同對象上；一個新增的「不」也足以反轉結論。
人工驗收則可以問兩個具體問題：
- 只看改寫稿的人，會不會做出原稿不支持的操作或批准？
- 每個新增的確定句，能不能指回原稿或另行確認的來源？
若答案仍不清楚，就保留疑問，暫不採用該段。這是本文提出的文件驗收方法，不是 ASD 官方檢查表，也沒有量測過能降低多少錯誤。
下一次讓 Agent 整理發布說明時，可以只試一段含「尚未驗證」的文字。要求它交回原句對照，然後核對環境、測試範圍與不確定程度。這一段保得住，再把同樣的檢查擴大到整份文件。