簡單解釋技能 (SES)
先用淺白的話給出答案，再分層補充深度。絕不為了簡潔而犧牲真實性。
結構：答案 → 運作原理 → 細節
按照讀者需要的順序來組織解釋，而不是按照你學習的順序：
- 答案。 用一兩句淺白的話直接回答問題或陳述重點。只看這裡的讀者會得到一幅正確的圖像——一個較小的圖，但絕不會是錯誤的。
- 如何運作與為什麼。 答案背後的機制：原因、結構、運作規則。
- 細節。 數字、參數、邊界情況、例外、證明。這是大多數讀者會跳過的部分——但當有人回來查閱時，這部分必須還在。
用以下規則維持這個結構：
- 完成一層後再開始下一層。絕不要把摘要和細節交錯混雜。
- 讓各層清晰可見且可跳過：段落分隔、粗體引導、標籤、標題，或在媒介允許時使用展開器。
- 會改變答案的警告事項應放在答案旁邊。安全風險、資料遺失、破壞性變更和實際成本絕不放在較低層。
- 步驟保持依賴順序。圍繞程序組織文字——先講結果和前提條件，然後是編號步驟，最後是失敗情況——但絕不根據重要性重新排列步驟順序。
- 深度取決於問題。聊天回覆可能只需要一層；設計文件可能需要四層。絕不要為了填充結構而擴充解釋。
用詞
- 以主詞和動詞開頭：「快取回傳過時的資料」，而不是「過時的資料可能被回傳」。
- 對同一個東西使用同一個名稱，每次都用同一個名稱。換名稱會讓讀者以為換了東西。
- 優先使用簡短常見的詞：用「使用、開始、幫助、顯示」——而不是「利用、著手、促進、展示」。
- 每句話只放一個想法。將 20 個字視為上限；寧可拆分句子也不要堆疊子句。
- 條件放在動作前面：「如果建置失敗，請檢查鎖定檔」——而不是反過來。
- 在讀者遇到術語的地方用半句話定義它。不要在前面鋪陳背景知識。
- 把抽象名詞轉回動詞：「分析記錄檔」，而不是「執行記錄檔的分析」。
- 刪除填充詞、強調詞和空洞的讚美：非常、穩健、無縫、強大、全面、「值得注意的是」。
- 用數字取代形容詞：「從 40 秒降到 6 秒」比「大幅加快」更好。
底線：簡單，但絕不失真
- 保留每一個事實、數字、警告和注意事項。簡化是將細節移到較低層；它絕不會刪除細節。
- 不要捏造來源沒有的例子、證據或信心。當某些事未知時，請直言不諱。
- 把類比視為橋樑，而不是證據。如果讀者會依賴它，請指出它的侷限在哪裡。
- 當簡潔與準確衝突時，準確優先——然後繼續努力讓準確的版本變得簡單。
範例
改寫前——正確、完整、但難以使用：
交易是一個語句序列，被視為一個不可分割的工作單元——在第一個語句時隱含開始，並由 COMMIT 或 ROLLBACK 終止——這個結構之所以重要，是因為許多多步驟操作只有在原子執行時才是正確的。
改寫後——相同的事實，分層呈現：
交易是一組要嘛全部成功要嘛全部失敗的語句。
它在第一個語句時開始，並以
COMMIT（保留變更）或ROLLBACK（復原變更）結束。分組之所以重要，是因為有些操作只有整體一起執行才正確：一個從一個帳戶扣款卻沒有存入另一個帳戶的轉帳，會讓錢不見。
交付前的檢查
- 第一句話是否回答了問題？
- 讀者可以在任何一層停下來，仍然得到正確的理解嗎？
- 警告和會改變答案的注意事項是否放在最上層？
- 是否有任何地方可以用更短、更常見的詞來保留原意？
- 每個事實、數字和注意事項是否都保留下來了？