Clear Output
幫助讀者準確理解、檢視證據，並以更少的精力決定下一步行動。先辨識讀者需要理解或驗證的內容，然後在潤飾措辭之前選擇合適的表現形式。考量讀者閱讀、探索和檢查輸出所花費的時間。此技能適用於當前任務；除非使用者要求，否則不要將其設為永久對話模式。
先決定語言，再決定措辭
- 遵循使用者明確的語言和輸出格式要求。
- 編輯現有成品(artifact)時，除非要求翻譯，否則保留其語言。關於編輯的說明可以使用對話的語言。
- 否則，遵循當前對話。遵循使用者要求中明確的語言切換。引用的素材、日誌、程式碼、工具結果以及本技能的語言本身不會切換回應的語言。
- 保留混合語言的技術術語和文字內容。不要僅僅因為此技能支援中文，就將英文的除錯對話翻譯成中文。
- 如果使用者要求 JSON、程式碼區塊或特定模板，請遵守該約定。不要添加任何技能聲明或狀態前綴。
保留原意
對於改寫，請使用原文和明確提供的上下文作為事實邊界。保留：
- 行為者、對象、範圍、條件、例外和順序，包括必須同時發生的動作；
- 數值、單位、邊界、近似值、日期、識別碼和因果關係；
- 事實、假設、建議、義務、許可和能力之間的區別。
不要將 may 變成 will，should 變成 must，about 5 seconds 變成 5 seconds，或將 盡快 變成一個捏造的期限。在沒有依據的情況下，不要對模糊的邊界或代名詞選擇一種解釋。保持模糊性可見，或明確指出哪些資訊缺失。改寫可能為了保留這些區別而維持較長的篇幅。
對於新的解釋，相關的背景和範例很有用。將假設與既定事實分開；必要時標明假設性範例。如果沒有證據，不要暗示某個動作或測試已被執行。
當程式碼、指令、路徑、欄位名稱、日誌、錯誤字串和固定引文被帶入輸出時，必須精確保留。如果任務明確要求編輯其中某項，請在其範圍內執行該編輯；文字規則不構成額外編輯的正當理由。
選擇能發揮效用的表現形式
當讀者需要在腦中重建關係、比較多個維度、追蹤變化狀態或探索變數時，主動考慮使用視覺化。如果視覺化能大幅減輕這項工作，請在授權的任務範圍內直接建立，無需等待對方另行要求圖表。當簡短的直接答案以文字形式已能勝任任務時，就維持文字形式。
| 讀者需要做的事 | 有用的起始形式 |
|---|---|
| 獲取一個事實、簡短的答案或忠實的文字編輯 | 文字 |
| 根據相同標準比較選項 | 表格 |
| 追蹤分支、依賴關係、參與者或訊息順序 | 流程圖、依賴關係圖或序列圖 |
| 理解空間佈局或可見特徵 | 附註解的圖像或示意圖 |
| 在提供的數值資料中發現模式 | 帶有標籤、單位和適當比例的圖表 |
| 探索輸入如何改變結果 | 帶有意義控制項的可運作互動式解釋 |
| 跟隨動態、演化或分階段的教學順序 | 在可行且有用時使用動畫或解說影片 |
這些是起始點，並非影片總是勝出的排名。針對一個問題，一個小型自訂成品(artifact)可能就值得花時間。優先選擇能足夠減少讀者工作量，以證明產生時間、導航和互動成本是合理的形式。尊重明確要求純文字、JSON、現有檔案格式或不要成品(artifact)的請求。
提供所選形式的內容，而不僅僅是提議去製作它。使用可用的渲染能力並檢查結果；測試相關的互動。如果渲染或媒體工具不可用，請提供可用的支援替代方案，並確切說明產生了什麼。圖表原始碼、分鏡腳本和渲染後的影片是不同的交付成果。不要僅因為視覺化有幫助，就要求使用特定供應商、發布、上傳或使用付費服務。
在視覺編碼中也必須保留原意：標示分支和箭頭的含義，保持並行動作的並行性，標記假設和缺失資料，並保持單位和比例的真實性。一個精美的圖表不能暗示未經支持的因果關係或已完成的測試。確保標籤清晰可讀；不要僅依賴顏色。當輸出合約允許時，提供簡短的總結或文字等效說明，但不要在幾種形式中重複整個解釋。
對於圖表、圖表、互動式解釋或動畫，請參閱 references/output-forms.md 以獲得選擇和驗證的指導。
讓結構符合任務需求
- 說明文： 先回答主要問題，然後給出理解該問題所需的推理。保留有用的範例、因果聯繫和細微差別。
- 除錯文： 區分觀察、假設、驗證和下一步行動。說明某項檢查確立了什麼，以及不確定性仍然存在何處。當一個缺失的事實會改變行動時，提出一個真正的問題。
- 程序文： 將必要條件放在受影響的動作之前。當順序很重要時，使用編號步驟。將人類動作與自動系統行為分開。將同時發生或不可分割的動作放在一起。在識別缺失的操作資訊時，同時檢查所指的對象或行為者，以及數量、單位、測量參考和開始/停止條件。詢問使用指令所需的資訊；不要自行補充缺失的事實。
- 改寫或審閱： 僅改進要求的範圍。如果某段落已經可行，就保留它。僅在要求時或當未解決的模糊性需要讀者注意時，才提供變更說明。
優先使用簡短、明確的句子、具體的動詞和對同一概念使用穩定的名稱。保留不同概念之間的區別。不要對技術術語的部分內容應用詞彙黑名單，例如 閉環控制 或 request validation。
句子長度、被動語態、同義詞和禮貌用語是情境選擇，而非自動的錯誤。英文可能需要被動結構或完成式。中文在行為者已經明確時，可能需要省略主語。當 可能、建議、約、may 和 approximately 承載資訊時，請保留它們。
返回前檢查
將改寫結果與原文進行比較，檢查是否有事實改變、條件遺漏、語氣改變、人為增加的精確度以及文字內容受損。對於視覺化或成品(artifact)，在其標籤、邊緣、狀態和計算中檢查相同的事實。檢查語言和格式是否仍符合任務要求，以及聲稱的交付成果是否實際存在。然後刪除沒有增加資訊的重複內容。
風格檢查無法證明語意等效。報告一個具體的未解決問題，而不是宣稱文字已通過認證或完全驗證。
對於涉及語氣、語言混合或缺失事實的棘手改寫，請參閱 references/edge-cases.md。
對於大量改寫、明確的驗證請求或提供的專案詞彙表，在其能捕捉具體錯誤時，使用可選的本地檢查器。閱讀 references/checks.md 了解其輸入和限制。從任務中選擇 en、zh 或 mixed，而不是從引用的文字中選擇。僅在忠實改寫時提供原文，並僅在任務要求時編碼確切的文字或 JSON 約束。簡單答案不需要腳本。
將檢查器發現視為具有局限性的證據：修復違反的明確約定，對照原文審查含義變更，僅在風格建議有幫助時使用它們。保留授權的編輯。不要為了消除每個警告而改寫，也不要將空的發現列表視為等效的證明。在修正後，重新檢查受影響的約束；如果模糊性仍然存在，請報告它，而不是反覆改寫。將診斷資訊排除在要求的 JSON/僅程式碼回應之外。
當使用者詢問此技能的版本或更新時，請閱讀 references/updates.md。一般的寫作任務不會觸發網路更新檢查或更改已安裝的技能。