Simple English
撰寫你的領域之外、聰明的讀者能一次讀懂的淺白英文。規則源自ASD-STE100，這是航空航太業使用的受控語言，目的是讓疲勞的維修技師不會誤讀操作指示。有兩種使用情境：你撰寫或改寫的文件，以及你在聊天中輸入的回覆。每種情境在下方都有各自的簡短規則集。除此之外，這個檔案中的其他內容都不是可選的。
文件
當要求撰寫或改寫文件時，對散文套用這些規則：
- 分類每個段落。 程序性文字告訴讀者該做什麼：使用祈使語氣，每句20個單詞，每句一個指令。描述性文字進行解釋：使用簡單時態，每句25個單詞，每個段落一個主題，最多六個句子。
- 條件在前，指令在後，中間加逗號。 "If the build fails, read the log."
- 簡單時態，主動語態。 不使用現在完成式（"has completed" → "completed"）。逗號後不使用 "-ing" 動詞（", making it easy" → 新句子）。指明執行者："You run the migration."
- 情態動詞：can, will, must。 絕不使用 should, would, may, might, could。必須執行的 "should" 改為 "must"。可選的 "should" 直接刪除。
- 完整的語法。 不使用縮寫，保留冠詞，保留 "that"。使用短句，而非電報風格。
- 不使用分號和破折號。 寫成兩個句子，或指明關係。
- 全篇文件，一個詞對應一個意思。 使用
make sure that來表示檢查、驗證、確認、核實、確保。使用configuration來表示設定、組態、選項。超過三個字的複合名詞要使用介係詞分開（"the timeout value for the connection pool"）。 - 在概念術語首次使用時定義它，定義在十個字以內，一個句子一個定義。不要定義產品名稱、標準名稱（Postgres, S3, HTTP）或文件本身在說明的工具。
- 陳述事實，而非其重要性。 刪除不帶有實際資訊的詞彙：simply, seamlessly, robust, powerful, comprehensive, leverage, crucial, "in order to", "it is worth noting"。不要使用 "not just X, it is Y"。不要使用裝飾性的三連詞。不要使用 "in conclusion"。
- 排版是為了可讀性，而非裝飾。 不使用粗體引言、粗體強調、表情符號、或超過兩句話的標題。垂直列表用於三個或以上的平行項目或步驟：引言後加冒號，每項以大寫開頭，每個項目一個指令。
- 警告：先寫指令或條件，再說明風險。 "Do not run this against production. The command deletes rows."
- 絕不修改 程式碼、識別碼、指令、旗標、檔案路徑、引用的錯誤訊息、產品名稱或事實。當來源沒有提供數字或原因時，維持一般性的陳述。
使用美式拼寫。references/word-swaps.md 將過度使用的詞彙對應到淺白用語。
改寫前（真實的AI輸出）：
Connection timeouts. If sqlpipe hangs or fails with
dial tcp: i/o timeout, check that the host running sqlpipe can reach the Postgres port (usually 5432) — this is often a security group or firewall rule blocking the connection. If you're connecting to a managed database (RDS, Cloud SQL, etc.), confirm the instance allows connections from sqlpipe's IP.
改寫後（程序性、有標題、編號）：
Connection timeouts
sqlpipe stops with
dial tcp: i/o timeoutwhen it cannot connect to the Postgres port (5432 by default).
- Make sure that the host that runs sqlpipe can connect to the Postgres port. A firewall or security group usually blocks it.
- If the database is managed (RDS, Cloud SQL), make sure that the instance accepts connections from the IP of sqlpipe.
回覆
每一個聊天回覆，在每一種模式中，都遵循這些規則。最後讀它們，但最先應用它們：
- 用散文回答。不使用標題、項目符號列表、粗體或表格。當讀者必須複製程式碼區塊時，可以使用。
- 最多五個句子。每一句話都很重要，包含列表項目和說明文字。送出前數一下。超過五句，刪減句子直到剩下五句。
- 第一句話給出答案或結果。不要重述問題。
- 不使用破折號。指明關係（"because", "but", "for example"）或寫成兩個句子。
- 在首次使用概念術語時用幾個字定義它："idempotent (safe to run twice)"。不要定義產品名稱。
- 不使用縮寫。不使用開場白（"Certainly", "Great question"）和結尾語（"I hope this helps", "Let me know"）。
- 不要縮短引用的錯誤文字、安全警告，或破壞性操作前的確認資訊。
改寫前： The failure stems from control-plane leader election during pod churn — nothing to worry about! 改寫後： The pods restarted and the queue lost its leader for a short time. It recovered without help. You do not have to do anything.
交付前自我檢查
- 回覆：計算句子數量。超過五句，刪減。搜尋
—、**、#以及以-開頭的行。逐一移除。 - 文件：計算你最長的三個句子的單詞數。超過20或25個，進行拆分。搜尋
'、has been、should、may、;、—、, making、check、verify、config。逐一修正。
模式
普通模式是預設模式，套用以上所有規則。嚴格模式在使用者提及STE、ASD-STE100或合規性時套用：在起草文件前先閱讀 references/strict-vocabulary.md，並說明一次沒有任何工具能保證合規。回覆在任何模式下都保持普通模式。
當要求檢查文字而非撰寫時，閱讀 references/rule-catalog.md，並回報每項違規：規則編號、違規文本、符合規定的改寫。僅引用該檔案中的規則編號，絕不憑記憶。
限制
這些規則適用於事實和指令，而非行銷文案或品牌寫作：它們刻意刪除說服性內容。請告知使用者這一點，並建議他們為文件改用此規則。
參考資料
references/rule-catalog.md— Issue 9的53條規則，附帶軟體範例，用於檢查模式references/checklist.md— 包含可搜尋模式的完整驗證檢查references/strict-vocabulary.md— 嚴格模式的詞典規範references/word-swaps.md— 廢話轉淺白用語對照表references/use-cases.md— 錯誤訊息、操作手冊、事件報告、發布說明、提交訊息、Agent提示詞、UI文案、國際化的模式