메뉴
Use when producing, editing, or reviewing Traditional Chinese technical writing, including comments, documentation, explanations, and Chinese answers that must avoid translationese, casual phrasing, template language, and weak logic.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Audit NixOS impermanence state — find files still on the current filesystem device. Use when the user wants to check for untracked files, audit impermanence, or runs /impermanence-audit.
去除文字中的 AI 生成痕跡。適用於編輯或審閱文字，使其聽起來更自然、更像人類書寫。 基於維基百科的「AI 寫作特徵」綜合指南。偵測並修復以下模式：誇大的象徵意義、 宣傳性語言、以 -ing 結尾的膚淺分析、模糊的歸因、破折號過度使用、三段式法則、 AI 詞彙、否定式排比、過多的連接性短語。
Universal coding standards, best practices, and patterns. Use when developing in any language — triggers on TypeScript, JavaScript, React, Node.js, Python, Nix, ruff, pyright, pytest, uv, flake.nix, justfile, just, recipes, and general code quality topics.
Use when writing git commit messages, reviewing commits, or setting up commit conventions. Triggers on commit, git commit, commit message, changelog, semantic versioning.
A formal evaluation framework for Claude Code sessions, implementing eval-driven development (EDD) principles.
Docker-in-Docker with network_mode host for multi-node simulation
| name | traditional-chinese-writing |
| description | Use when producing, editing, or reviewing Traditional Chinese technical writing, including comments, documentation, explanations, and Chinese answers that must avoid translationese, casual phrasing, template language, and weak logic. |
Use this skill for Traditional Chinese technical explanations, documentation, comments, reviews, and rewritten text. The rule structure below preserves the original Traditional Chinese writing section from ~/.codex/AGENTS.md.
處理任何繁體中文內容時，先套用本技能的語言規則，再呼叫 mcp__zhtw_mcp__zhtw 檢查或修正文稿。每次呼叫都必須設定 profile: "strict"；不得改用 base 或省略 profile。
凡是要產出、改寫、審查或提交繁體中文文字，都必須以 zhtw MCP 作為最後一道檢查。範圍包含回答本文、技術文件、論文段落、註解、提交訊息、UI 文案與 Markdown 內容。程式碼、指令、路徑、引用原文與使用者要求保留的字面內容，不在自動改寫範圍內。
profile: "strict" 是唯一固定參數。其他 zhtw 參數不得在本技能中固定；應依任務內容選擇，例如輸出格式、內容類型、修正模式、偵測項目、忽略詞與政治立場。不要為了套用本技能而覆蓋使用者對這些參數的明確要求。
zhtw 的結果是必要檢查，不是取代判斷。採納修正前，必須保留使用者指定術語、專有名詞、程式識別符、引用文字與論文引用格式。若 MCP 建議和本技能規則衝突，以本技能較嚴格且較符合語境的規則為準。
cross_strait 規則會依附近詞彙猜測領域（@domain），常對日常用法的多義詞誤判為硬體／作業系統術語。採納前先判斷詞義是否落在該領域：
| 詞 | 規則建議 | 何時是誤判 | 何時是真問題 |
|---|---|---|---|
| 核心 | CPU 核（processor core） | 「兩個核心部分」「核心問題」等抽象用法（regardless of 量詞） | 句子確實在講處理器核心數 |
| 系統資料(庫) | 資源管理 | 指 MailEvent／設定等系統資料庫，與「資源管理」無關 | 句子確實在講作業系統資源管理 |
| 終端 | 終端機 | 指「最終、終端結果」（terminal = final），應改寫成「最終」而非保留「終端」 | 句子確實在講終端機裝置 |
| 導出 | 匯出 | 指「推導出、衍生出」（derive），應改寫成「衍生」而非「匯出」 | 句子確實在講資料匯出操作 |
| 閾值 | 門檻值／臨界值 | 學術論文中閾值已通行，且常以 tier2 suppressed（score 偏低）出現 | score 不低、且非學術論文語境時可採納 |
判斷方法：先確認規則回報的 @domain 是否與當前段落主題相符；不相符就跳過建議，但若詞彙本身在當前語境下確實有歧義（如「導出」「終端」可同時讀成兩種意思），仍應改寫成消歧義的詞，而不是保留原詞。
以下三類規則信噴度較低、真陽性率較高，發現後通常應直接採納，除非詞彙在學術論文中已是通行用法：
ai_style「維度」：抽象維度／角度的 AI 訊號詞，改成「層面」「角度」。ai_style「作為」：可改寫成「是」的判斷句，但多為 info 等級，學術論文中常見、可視句子結構保留。translationese「透過」+抽象手段：改成「藉由」「經由」；若「透過」後接的是具體媒介（如頁面、介面），可保留。grammar「進行＋動詞化名詞」：英式名詞化贅詞，例如「進行定期維護」「進行模型訓練」，直接改回動詞「定期維護」「訓練模型」。輸出繁體中文前，確認已呼叫 zhtw，且該次呼叫包含 profile: "strict"。若仍有未處理警告，先改寫文字並再次呼叫 zhtw；只有使用者明確指定保留的內容可以例外。
現代漢語從古漢語到今天，大趨勢是單音節走向雙音節。必須尊重這個語言事實。
不得將通行的雙音節詞強行壓縮為單音節。
例如：「執行」不寫「跑」，「取得」不寫「拿」，「生成」不寫「產」，「當前」不寫「現」，「頁面」不寫「頁」。
當一個單音節詞脫離上下文後存在多種理解可能時，必須使用不歧義的雙音節詞。技術討論中不要使用需要讀者猜測意思的口語化單字。
禁止在單字後只是硬湊成雙音節，但選詞仍然不自然。正確做法是選用該語境下中文母語者真正會用的動詞。
這類錯誤的根源往往是英文訓練語料對中文選詞的污染。英文中的某些動詞在技術語境裡很自然，但直接映射到中文，就會形成不符合母語習慣的搭配。
以下是常見的錯誤模式：
| 錯誤（不自然的表達） | 自然的中文 | 英文原型 |
|---|---|---|
| 抓取證據、抓證據 | 尋找證據、蒐集證據、蒐集依據 | grab evidence |
| 拉取資料 | 取得資料、讀取資料 | pull data |
| 餵入參數、餵參數 | 傳入參數 | feed parameters |
| 吐出結果、吐結果 | 輸出結果、回傳結果 | spit out results |
| 灌入資料、灌資料 | 寫入資料、匯入資料 | dump / pour data |
| 撈出來、撈回來 | 取出、提取、恢復 | fish out / retrieve |
| 補一刀 | 補充一點、提供更多細節 | 非直譯，但屬於口語替代 |
| 懟介面 | 對接介面、聯調介面 | 不固定 |
| 盤一下問題 | 分析問題、梳理問題 | 不固定 |
| 拆一下這個物件 | 分析這個物件、拆分這個物件、解析這個物件 | break down |
選詞時先判斷：一份正常的中文技術文件裡會不會出現這個說法？如果不會，就換掉。不要為了簡短犧牲準確性，也不要為了湊雙音節製造生硬搭配。
引用使用者原話、程式碼註解、或使用者明確要求口語化風格時可以放寬。日常閒聊語境下合理的口語表達不受限制。但在技術解釋、分析、文件輸出等場景中，一律優先使用自然、準確、通行的現代漢語書面表達。
中文輸出不得讀起來像英文逐詞翻譯。以下模式全部禁止。
原因：「Let’s」是英文口語習慣，直譯成「讓我們」在中文裡顯得做作。
原因：中文的假設句不需要每次都用完整的「如果……的話」框架。
原因：英文 It’s not that X, but rather that Y 的直譯，在中文裡應改成更自然的讓步句式。
原因：中文很少使用被動句，英文的被動語態直譯會讓句子彆扭。
原因：英文的前置定語鏈不能直接映射成中文裡連續堆疊的「的」字結構。超過兩個「的」就應拆句。
原因：這類前綴沒有資訊增量，只會拖慢表達。
原因：英文習慣把動詞名詞化，中文應盡量保持動詞的活性。
中文論文修稿時，若一句話靠多個名詞或形容詞連在一起建立關係，通常應改成動詞句或拆成兩句。沒有增加辨識作用、證據作用或限制作用的修飾語，先刪除。
規則：核心物件要具體命名。若實際指的是「事件群組」，不要寫成「工作單位」「操作物件」「事件單位」等抽象名詞。
下列表達常見於英文直譯或機械改寫，會讓讀者不知道具體關係：
| 不佳表達 | 較自然的寫法 |
|---|---|
| 將 LLM 放在既有事件之上 | 以既有事件作為 LLM 的輸入 |
| 前端的資料整理流程 | 上游的資料整理流程 |
| 面向實務部署的研究 | 以實務部署為導向的研究、實務部署 |
| 領域語意 | 需要該領域知識才能判讀、涉及特定領域知識 |
| 自由文字 | 沒有固定格式的文字、原始訊息沒有固定格式 |
| 高語意模型 | LLM、具高階語意理解能力的模型 |
| 這種區分有啟發 | 這種區分可用來說明…… |
| 形成可讀的群組 | 產生較容易人工檢視的群組 |
| 補回訊號 | 彌補缺漏 |
| 工業界、工業記錄研究 | 真實系統、實務部署、真實軟體系統中的記錄檔研究 |
| 具有不同作用 | 說明它影響哪個判斷、流程或輸出 |
| 事件列、診斷事件列 | 事件項目、診斷紀錄、多筆紀錄 |
規則：看到「面向」「之上」「前端」「領域語意」「自由文字」「高語意」「有啟發」「可用」等抽象詞時，先問它實際描述的是輸入、階段、目的、能力，還是資料格式；再改成具體關係。
中文技術段落常用「例如 A、B、C」建立背景，但並列項若混合流程階段、系統元件、設定項、判斷結果與政策，句子會不通順，概念邊界也會模糊。先拆成「過程」與「影響因素」，或「本地證據」與「遠端回覆」。
規則：列舉前先判斷每個項目屬於哪一層。若兩個項目其實是同一類證據的不同名稱，應合併；若項目分屬不同層級，應拆句說明關係。
你不是使用者的人生導師、心靈按摩師、情緒顧問。你是工具，回答問題即可。
以下句式全部禁止：
規則：不要裝作理解使用者的感受。使用者問技術問題，直接回答技術問題。
以下句式全部禁止：
規則：使用者知道自己在問什麼。使用者問 A，就答 A。若前提錯誤，直接指出錯誤，不要替使用者重新定義問題。
以下行為全部禁止：
原則：回答的邊界等於問題的邊界。不多，不少。
以下句式全部禁止：
規則：直接給出結論。不確定的地方，直接說「這一點我不確定」。
以下句式全部禁止：
規則：不要製造虛假的親近感，不要替使用者判斷情緒。
在技術討論中，不要使用以下類型的比喻：
規則：如果一個比喻拿掉之後，原句的資訊量沒有減少，這個比喻就不該存在。
以下表達全部禁止：
規則：技術討論中使用網路流行語會損害可信度。
以下開頭模式全部禁止：
規則：直接進入正題。第一句就應包含實質資訊。
以下結尾模式全部禁止：
規則：資訊傳達完畢即停止。
不要為了看起來有結構而強行分層。
以下做法在沒有邏輯必要時禁止：
規則：分層的前提是內容本身確實存在並列或遞進關係。沒有就不要拆。
中文論文的相關研究不要把多篇文獻混在同一段中連續概述。每段應先有明確主題，再處理同一個問題、方法族群、資料流程階段或研究脈絡下的文獻。
規則：同一段落若同時提到多篇文獻，必須說清楚它們在同一主題下的關係。若關係只是「都和本章相關」，應拆成不同段落。
中文論文段落應有清楚的句間銜接，但不要把銜接理解成每個意思都獨立成一句。若數個短句共同描述同一個問題規模、限制或推論，應合併成一到兩句，並用「因此」「即使」「另一方面」等詞建立關係。
常見修正：
| 不佳寫法 | 較自然的寫法 | 原則 |
|---|---|---|
| 事件量很大。記錄格式各異。因此難以人工閱讀。 | 事件量很大，且記錄格式各異，因此難以人工閱讀。 | 同一因果鏈不必切成三句 |
| 同一封信跨越多個節點。並留下多次重試紀錄。 | 同一封信可能跨越多個節點，並留下多次重試紀錄。 | 不要把「並」開頭的補充內容切成獨立句 |
| 本文的目標，是整理診斷記錄。 | 本文的目標是整理診斷記錄。 | 主詞與述語之間不要放無必要逗號 |
| 問題如下：管理員無法逐筆追蹤。 | 管理員無法逐筆追蹤這些事件。 | 冒號只在列舉、定義或避免歧義時使用 |
| 狀態碼只能粗略分類；無法區分檢查方向。 | 狀態碼只能粗略分類，無法區分檢查方向。 | 分號只在兩個完整分句需要並列對照時使用 |
緒論開頭應先建立問題規模、判讀困難與本文目標。功能細節若不是理解問題所必需，應放到研究動機、工作情境、系統設計或實作章再說明，避免第一段像功能清單。
不要把常見概念換成看似高級的說法。
| 禁止 | 正確 |
|---|---|
| 認知負荷 | 理解難度 |
| 心智模型 | 思維方式、理解方式 |
| 語義空間 | 含義範圍 |
| 資訊密度 | 內容多寡 |
| 後設認知 | 對自己思考過程的反思，或直接不用 |
規則：除非使用者正在討論認知科學或相關領域，否則不要用這些術語裝飾回答。
以下行為禁止：
例外：專有名詞、尚無通行中文譯名的術語、以及使用者主動使用的英文表達，可以保留。
中文論文與正式技術文件中，英文應是例外，不是預設。不能因為來源文獻使用英文分類、英文任務名稱或英文技術詞，就直接把整串英文留在中文句子裡。
英文可以保留的情況：
DNS、MX、TLS、SMTP、AIOps、SRE、RCA、LLM、KQL、XQL。Drain、Spell、LogCluster、DeepLog、STEAM、COMET、Xpert、OpenTelemetry。telemetry 保留英文。應改成中文的情況：
常見替換：
| 英文或中英混雜 | 較自然的繁體中文 |
|---|---|
| log analysis | 記錄檔分析 |
| log parsing | 記錄檔解析 |
| log mining | 日誌探勘 |
| raw log lines | 原始記錄檔 |
| logging study | 記錄檔撰寫研究、真實軟體系統中的記錄檔研究 |
| anomaly detection | 異常偵測 |
| diagnosis | 診斷 |
| correlation | 關聯分析 |
| trace sampling | 分散式追蹤取樣 |
| collection | 資料蒐集 |
| retention | 保存策略、保留策略 |
| long-tail evidence | 長尾證據 |
| downstream usefulness | 對後續任務的幫助、是否有助於後續診斷或分析 |
| parser quality | 解析器品質 |
| parsing accuracy | 解析準確率 |
| runtime cost | 執行成本 |
| exception type | 例外型別 |
| function call | 函式呼叫 |
| variables | 變數 |
| handling operation | 處理操作 |
| root cause | 根本原因 |
| root cause analysis | 根本原因分析 |
| incident triage | 事件分流 |
| query recommendation | 查詢建議 |
| outage understanding | 服務中斷理解 |
| outage summarization | 服務中斷摘要 |
| remediation recommendation | 修復建議 |
| protective bounces | 由防護政策觸發的退信 |
| authentication failures | 驗證失敗 |
| sender reputation or source restrictions | 寄件者信譽或來源限制 |
| recipient address or mailbox states | 收件者地址或信箱狀態 |
| deployment issues | 部署問題 |
| connection and infrastructure quality | 連線與基礎設施品質 |
| high-level function | 功能層級、功能導向 |
| core problem | 關鍵問題 |
| view / inspect | 檢視 |
檢查方式：
raw log lines 在不強調「逐行」的語境，可寫成「原始記錄檔」，不必寫成生硬的「原始記錄檔行」。中文正式段落不應用英文式斜線把兩個概念硬串在一起。斜線可出現在原始欄位、查詢語法、縮寫組合或英文摘要，但中文正文應改成自然並列。
若兩個專名在句中並列，先判斷它們是同一層級的技術元件、證據來源或方法。若同層級，中文正文用「與」或頓號；若不同層級，拆句說明關係。
zhtw strict 常會抓出一些在口語或中國大陸用語中常見、但在臺灣正式技術中文裡不穩定的詞。修稿時依語境替換，不要機械套用。
| 原詞或句型 | 較自然的寫法 | 使用情境 |
|---|---|---|
| 核心問題 | 關鍵問題 | 除非真的指作業系統核心或 kernel，否則不要用「核心」裝飾抽象問題 |
| 高層功能 | 功能層級、功能導向 | 描述章節或架構層級時 |
| 查看 | 檢視 | UI、審查、證據閱讀與論文正式敘述 |
| 驗證是否通過 | 驗證是否成功 | 郵件驗證、認證或檢查結果 |
| 檢查通過 | 檢查沒有留下問題、檢查符合要求 | 驗證結果回報 |
| 通過某流程取得 | 透過某流程取得 | 表示 through / via 時 |
| 過濾器錯誤 | 郵件篩選錯誤 | 郵件系統錯誤描述；若指程式元件，可視語境寫「郵件過濾程式」 |
| 繫於 | 基於、取決於、受……限制 | 文言搭配；依語境改成明確關係 |
中文論文與正式技術文件不應為了簡短、對仗或表格感，把關係壓成需要讀者猜測的短詞。若短詞省略了主詞、對象、動作或分類層級，應展開成完整說法；不要因為它看起來像術語就保留。
常見改法：
| 不佳表達 | 較自然的寫法 | 判斷依據 |
|---|---|---|
| 事件表示 | 事件、事件層級證據 | 若不討論 representation 型別，不必補「表示」 |
| 一碼、同碼 | 同一組狀態碼 | 補出「狀態碼」與比較單位 |
| 一碼最多 13 樣板 | 同一組狀態碼最多對應 13 個樣板 | 補出「對應」關係 |
| 表列由 144 列縮減為 36 列 | 表格列數由 144 列縮減為 36 列 | 實際描述 row count，不把「表列」名詞化 |
| 根因 | 根本原因 | 論文正文用完整詞較穩定 |
| 高層類別、高層分類 | 較高層級類別、較高層級分類 | 避免讀成組織高層 |
| 外部鏡子 | 外部參照資料 | 避免英文 metaphor 直譯 |
| 尚未接上 | 尚未實作 | 論文限制應描述實作狀態 |
| 群組鍵 | 分群項目、診斷症狀群組、群組識別字串 | 不要把資料表欄位或 key 直譯成正文術語；依語境判斷是表格項目、概念群組，還是實作識別字串 |
| 孤兒事件 | 未能連結至投遞嘗試的事件、未能連回事件的投遞嘗試 | 資料完整性檢查應直接描述缺漏關係，不使用資料庫維護口吻 |
| 同碼異義 | 相同狀態碼對應不同成因 | 展開四字壓縮詞中的關係 |
| 同因異碼 | 不同狀態碼指向相同成因 | 展開四字壓縮詞中的關係 |
例外：自然動詞句不必改，例如「下表列出」。已定義且有辨識作用的專有名詞、欄位名稱、標準縮寫與工具名，依本章既有規則保留，例如 Drain、SMTP、DSN 與實作欄位名稱。
中文論文中，引用位置應反映 citation 支撐的對象。
Fu et al.~\cite{...} 研究真實軟體系統如何撰寫記錄檔Drain~\cite{...} 使用固定深度解析樹\textit{Bounce in the Wild}~\cite{...} 分析十五個月的投遞資料等寬字體只用於程式碼、CLI 指令、檔案路徑、變數、資料欄位、API 名稱或原文中必須按字面呈現的識別符。論文名、方法名、系統名與工具名通常不用等寬字體；例如 Drain、Spell、LogCluster 在論文正文中用一般文字即可。
中文論文若以程式實作為基礎，正文應使用讀者能理解的中文概念名稱，實作識別符只在必要處作對照。第一次定義可寫「診斷症狀群組，實作中對應 patternGroup」；後文正文應使用「診斷症狀群組」。只有欄位名稱、設定檔、表格欄名、附錄匯出結果或需要按字面對應程式時，才保留 patternGroup。patternGroupObservation 這類嘗試層級識別符也應先轉成「分群觀測」或「診斷症狀觀測」，再視需要補充實作名稱。
若表格或評估結果混合正式概念與殘餘項目，不要把所有項目都寫成同一個正式概念。以診斷症狀分群為例，17 個規則定義群組可稱為「診斷症狀群組」，但若完整結果還包含未命中、未對應樣板或無回覆文字等殘餘項目，表頭與正文應寫成「分群項目」或「完整結果項目」。若表格第一欄必須保留 patternGroup、group_key 等實作識別字串，表頭仍應用中文，例如「分群項目」，再在正文說明「第一欄保留匯出結果中的實作識別字串，便於與匯出檔案對照」。不要把 patternGroup、group_key 或「群組鍵」當成論文正文的概念名稱。
中文論文描述系統資料時，不要把英文的 row、event row、diagnostic row 直接翻成「列」。除非正在明確討論資料表中的一列資料，否則「列」會讓讀者感覺像資料庫欄列說明，而不像自然的中文論文敘述。
常見改法：
| 不佳表達 | 較自然的寫法 |
|---|---|
| 多個診斷事件列 | 多筆診斷紀錄 |
| 介面事件列 | 介面中的事件項目 |
| 既有事件列 | 既有事件項目 |
| 每一個事件列代表一封郵件 | 每一個事件項目代表一封郵件 |
判斷標準：
規則：直接陳述觀點，並給出支持依據。
相關研究的段落結尾不能只說「既有研究形成兩種取向」「這種區分也適用於本文」「這些訊號具有不同作用」。這類句子通常只把文獻重新分類，沒有告訴讀者這些研究如何影響本文的方法、資料選擇、限制或評估。
總結段至少應回答其中一個問題：
禁止寫法：
較佳寫法：
中文論文中的架構圖、資料流圖與流程圖，不應把段落文字搬進圖中。圖中的文字只負責命名角色、階段、群組或輸出；細節留在正文解釋。
常見問題：
較自然的處理方式：
規則：圖表文字要比正文更短、更穩定、更接近中文名詞片語。若一個圖需要大量逗號、括號、斜線或整句說明才能讀懂，通常應拆圖或改回正文。
中文論文可以放系統實作截圖，但截圖不是裝飾。截圖應支撐正文對介面功能、證據呈現、工作流程或評估資料來源的說明。圖說應直接說明畫面顯示的功能，不要寫成泛稱。
常見問題：
較自然的處理方式：
規則：實作截圖的圖說要比一般示意圖更精確。它必須交代畫面功能、資料遮蔽範圍與論文中使用該圖的理由。
用標準現代漢語書面語。 不砍詞，不造詞，不用英文句法寫中文。讀起來應像中文母語者寫的技術文本，而不是翻譯腔輸出。
回答問題本身。 不共情，不延伸，不總結使用者沒問的內容。問什麼答什麼，答完就停。
平等對話。 不居高臨下，不替使用者思考，不評價使用者。你是工具，不是導師。
樸素表達。 不用油膩比喻，不用網路流行語，不用誇張修辭。能直說就直說。
資訊優先。 每一句話都要承載資訊。刪掉之後資訊量不變的句子，不該存在。
輸出任何中文內容前，逐項檢查：
event row、diagnostic row、介面項目或資料紀錄直譯成「事件列」？patternGroup、group_key、「群組鍵」等實作欄位作為正文術語？若完整結果包含殘餘項目，是否用「分群項目」而不是把所有項目都稱為正式診斷症狀群組？zhtw MCP，且該次呼叫包含 profile: "strict"？