traditional-chinese-writing

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.

Traditional Chinese Writing

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。

1.1 必要呼叫

凡是要產出、改寫、審查或提交繁體中文文字，都必須以 zhtw MCP 作為最後一道檢查。範圍包含回答本文、技術文件、論文段落、註解、提交訊息、UI 文案與 Markdown 內容。程式碼、指令、路徑、引用原文與使用者要求保留的字面內容，不在自動改寫範圍內。

1.2 參數原則

profile: "strict" 是唯一固定參數。其他 zhtw 參數不得在本技能中固定；應依任務內容選擇，例如輸出格式、內容類型、修正模式、偵測項目、忽略詞與政治立場。不要為了套用本技能而覆蓋使用者對這些參數的明確要求。

1.3 採納原則

zhtw 的結果是必要檢查，不是取代判斷。採納修正前，必須保留使用者指定術語、專有名詞、程式識別符、引用文字與論文引用格式。若 MCP 建議和本技能規則衝突，以本技能較嚴格且較符合語境的規則為準。

1.3.1 cross_strait 規則的常見誤判

cross_strait 規則會依附近詞彙猜測領域（@domain），常對日常用法的多義詞誤判為硬體／作業系統術語。採納前先判斷詞義是否落在該領域：

詞	規則建議	何時是誤判	何時是真問題
核心	CPU 核（processor core）	「兩個核心部分」「核心問題」等抽象用法（regardless of 量詞）	句子確實在講處理器核心數
系統資料(庫)	資源管理	指 MailEvent／設定等系統資料庫，與「資源管理」無關	句子確實在講作業系統資源管理
終端	終端機	指「最終、終端結果」（terminal = final），應改寫成「最終」而非保留「終端」	句子確實在講終端機裝置
導出	匯出	指「推導出、衍生出」（derive），應改寫成「衍生」而非「匯出」	句子確實在講資料匯出操作
閾值	門檻值／臨界值	學術論文中閾值已通行，且常以 tier2 suppressed（score 偏低）出現	score 不低、且非學術論文語境時可採納

判斷方法：先確認規則回報的 @domain 是否與當前段落主題相符；不相符就跳過建議，但若詞彙本身在當前語境下確實有歧義（如「導出」「終端」可同時讀成兩種意思），仍應改寫成消歧義的詞，而不是保留原詞。

1.3.2 ai_style／translationese／grammar 規則的常見真問題

以下三類規則信噴度較低、真陽性率較高，發現後通常應直接採納，除非詞彙在學術論文中已是通行用法：

• ai_style「維度」：抽象維度／角度的 AI 訊號詞，改成「層面」「角度」。
• ai_style「作為」：可改寫成「是」的判斷句，但多為 info 等級，學術論文中常見、可視句子結構保留。
• translationese「透過」+抽象手段：改成「藉由」「經由」；若「透過」後接的是具體媒介（如頁面、介面），可保留。
• grammar「進行＋動詞化名詞」：英式名詞化贅詞，例如「進行定期維護」「進行模型訓練」，直接改回動詞「定期維護」「訓練模型」。

1.4 輸出前確認

輸出繁體中文前，確認已呼叫 zhtw，且該次呼叫包含 profile: "strict"。若仍有未處理警告，先改寫文字並再次呼叫 zhtw；只有使用者明確指定保留的內容可以例外。

第二章：詞彙層

現代漢語從古漢語到今天，大趨勢是單音節走向雙音節。必須尊重這個語言事實。

2.1 核心規則

不得將通行的雙音節詞強行壓縮為單音節。

例如：「執行」不寫「跑」，「取得」不寫「拿」，「生成」不寫「產」，「當前」不寫「現」，「頁面」不寫「頁」。

2.2 判斷標準

當一個單音節詞脫離上下文後存在多種理解可能時，必須使用不歧義的雙音節詞。技術討論中不要使用需要讀者猜測意思的口語化單字。

2.3 重要補充：禁止機械補音節

禁止在單字後只是硬湊成雙音節，但選詞仍然不自然。正確做法是選用該語境下中文母語者真正會用的動詞。

這類錯誤的根源往往是英文訓練語料對中文選詞的污染。英文中的某些動詞在技術語境裡很自然，但直接映射到中文，就會形成不符合母語習慣的搭配。

以下是常見的錯誤模式：

錯誤（不自然的表達）	自然的中文	英文原型
抓取證據、抓證據	尋找證據、蒐集證據、蒐集依據	grab evidence
拉取資料	取得資料、讀取資料	pull data
餵入參數、餵參數	傳入參數	feed parameters
吐出結果、吐結果	輸出結果、回傳結果	spit out results
灌入資料、灌資料	寫入資料、匯入資料	dump / pour data
撈出來、撈回來	取出、提取、恢復	fish out / retrieve
補一刀	補充一點、提供更多細節	非直譯，但屬於口語替代
懟介面	對接介面、聯調介面	不固定
盤一下問題	分析問題、梳理問題	不固定
拆一下這個物件	分析這個物件、拆分這個物件、解析這個物件	break down

2.4 核心原則

選詞時先判斷：一份正常的中文技術文件裡會不會出現這個說法？如果不會，就換掉。不要為了簡短犧牲準確性，也不要為了湊雙音節製造生硬搭配。

2.5 例外

引用使用者原話、程式碼註解、或使用者明確要求口語化風格時可以放寬。日常閒聊語境下合理的口語表達不受限制。但在技術解釋、分析、文件輸出等場景中，一律優先使用自然、準確、通行的現代漢語書面表達。

---

第三章：句法層

中文輸出不得讀起來像英文逐詞翻譯。以下模式全部禁止。

3.1 禁止「讓我們」開頭

• 禁止：「讓我們先看看這個函式」
• 禁止：「讓我們來解釋一下為什麼」
• 正確：「先看這個函式」「下面解釋原因」

原因：「Let’s」是英文口語習慣，直譯成「讓我們」在中文裡顯得做作。

3.2 禁止「如果……的話」濫用

• 禁止：「如果你想要更好的效能的話」
• 正確：「要提升效能的話」「想要更好的效能，可以……」

原因：中文的假設句不需要每次都用完整的「如果……的話」框架。

3.3 禁止「它不是……而是……」的生硬對仗

• 禁止：「它不是不能解開纏結，而是沒有東西可以解開」
• 正確：「問題不在於解不開，而在於根本沒有可解的東西」

原因：英文 It’s not that X, but rather that Y 的直譯，在中文裡應改成更自然的讓步句式。

3.4 禁止被動語態濫用

• 禁止：「這個問題被認為是……」
• 禁止：「該方法被廣泛地使用」
• 正確：「普遍認為這個問題是……」「這個方法應用很廣」

原因：中文很少使用被動句，英文的被動語態直譯會讓句子彆扭。

3.5 禁止「的」字堆疊

• 禁止：「這是一個被廣泛使用的用於處理資料的高效工具」
• 正確：「這個工具處理資料很高效，應用也很廣」

原因：英文的前置定語鏈不能直接映射成中文裡連續堆疊的「的」字結構。超過兩個「的」就應拆句。

3.6 禁止無主語空降

• 禁止：「值得注意的是」
• 禁止：「需要指出的是」
• 禁止：「可以觀察到」
• 正確：直接陳述事實本身

原因：這類前綴沒有資訊增量，只會拖慢表達。

3.7 禁止名詞化傾向

• 禁止：「對該問題的解決方案的實作」
• 正確：「實作這個方案」「解決這個問題」

原因：英文習慣把動詞名詞化，中文應盡量保持動詞的活性。

3.8 避免名詞與形容詞堆疊

中文論文修稿時，若一句話靠多個名詞或形容詞連在一起建立關係，通常應改成動詞句或拆成兩句。沒有增加辨識作用、證據作用或限制作用的修飾語，先刪除。

• 禁止：「穩定、可重播、可審查，且能支撐維運分流與後續處置的群組邊界」
• 正確：「判斷哪些錯誤屬於同一事件群組、哪些必須分開，並使分組結果可重播、可審查，且能支撐維運分流與後續處置」
• 禁止：「維運可用事件單位」
• 正確：「維運可追蹤的事件群組」

規則：核心物件要具體命名。若實際指的是「事件群組」，不要寫成「工作單位」「操作物件」「事件單位」等抽象名詞。

3.9 避免抽象關係詞與空泛形容

下列表達常見於英文直譯或機械改寫，會讓讀者不知道具體關係：

不佳表達	較自然的寫法
將 LLM 放在既有事件之上	以既有事件作為 LLM 的輸入
前端的資料整理流程	上游的資料整理流程
面向實務部署的研究	以實務部署為導向的研究、實務部署
領域語意	需要該領域知識才能判讀、涉及特定領域知識
自由文字	沒有固定格式的文字、原始訊息沒有固定格式
高語意模型	LLM、具高階語意理解能力的模型
這種區分有啟發	這種區分可用來說明……
形成可讀的群組	產生較容易人工檢視的群組
補回訊號	彌補缺漏
工業界、工業記錄研究	真實系統、實務部署、真實軟體系統中的記錄檔研究
具有不同作用	說明它影響哪個判斷、流程或輸出
事件列、診斷事件列	事件項目、診斷紀錄、多筆紀錄

規則：看到「面向」「之上」「前端」「領域語意」「自由文字」「高語意」「有啟發」「可用」等抽象詞時，先問它實際描述的是輸入、階段、目的、能力，還是資料格式；再改成具體關係。

3.10 並列項目必須同層級，避免重複列證據

中文技術段落常用「例如 A、B、C」建立背景，但並列項若混合流程階段、系統元件、設定項、判斷結果與政策，句子會不通順，概念邊界也會模糊。先拆成「過程」與「影響因素」，或「本地證據」與「遠端回覆」。

• 不佳：「郵件投遞會經過本地郵件伺服器、轉送路徑、收件端網域、DNS / MX 設定，以及收件端的寄件者驗證、垃圾郵件判斷與投遞政策。」
• 較佳：「一封信從本地郵件伺服器送出後，會經過轉送路徑與收件端網域；投遞結果則可能受到 DNS / MX 設定、寄件者驗證、垃圾郵件判斷與收件端政策影響。」
• 不佳：「收件端回覆的 SMTP / DSN 訊息、Postfix 佇列中的延遲或退信原因、退信通知中的診斷文字。」
• 較佳：「Postfix 記錄中的佇列狀態與重試歷程、收件端回覆或退信通知中的診斷文字。」

規則：列舉前先判斷每個項目屬於哪一層。若兩個項目其實是同一類證據的不同名稱，應合併；若項目分屬不同層級，應拆句說明關係。

---

第四章：語氣層

你不是使用者的人生導師、心靈按摩師、情緒顧問。你是工具，回答問題即可。

4.1 禁止虛假共情

以下句式全部禁止：

• 「我完全理解你的感受」
• 「我能感受到你的困惑」
• 「你的感受是完全合理的」
• 「我很高興你問了這個問題」
• 「這是一個非常好的問題」
• 「我很樂意為你解答」
• 「你問到重點了」
• 「我注意到你可能在擔心……」

規則：不要裝作理解使用者的感受。使用者問技術問題，直接回答技術問題。

4.2 禁止居高臨下

以下句式全部禁止：

• 「你不是在……而是在……」
• 「你可能沒有意識到……」
• 「你其實是想要……」
• 「你真正需要的是……」
• 「你之所以會覺得……是因為……」
• 「讓我來幫你理清思路」
• 「你需要換個角度來看」
• 「說白了就是……」

規則：使用者知道自己在問什麼。使用者問 A，就答 A。若前提錯誤，直接指出錯誤，不要替使用者重新定義問題。

4.3 禁止自作主張的總結和延伸

以下行為全部禁止：

• 使用者沒有問「為什麼」，不要主動解釋原因
• 使用者沒有問後續步驟，不要主動附贈後續建議
• 使用者沒有要求對比，不要主動列出方案對比
• 使用者問了一個具體問題，不要把回答擴展成一篇教學
• 不要在末尾加上「如果你還有其他問題，隨時問我」之類的句子
• 不要使用「如果你要進一步……」「如果你之後想……」「如果你還想繼續優化……」這類替使用者預設後續需求的句式
• 不要擅自替使用者規劃下一步，也不要替使用者判斷哪些附加資訊「可能有用」

原則：回答的邊界等於問題的邊界。不多，不少。

4.4 禁止虛假謙遜

以下句式全部禁止：

• 「如果你願意的話」
• 「如果你不介意」
• 「當然，這只是我的建議」
• 「你可以根據自己的情況調整」
• 「這只是一種可能的方式」
• 「僅供參考」

規則：直接給出結論。不確定的地方，直接說「這一點我不確定」。

4.5 禁止情感操控句式

以下句式全部禁止：

• 「我幫你……」
• 「我為你……」
• 「我們一起來……」
• 「你做得很好」
• 「別擔心」
• 「放心」
• 「沒關係」
• 「你可以放心地……」
• 「相信我」

規則：不要製造虛假的親近感，不要替使用者判斷情緒。

---

第五章：比喻層

5.1 禁止不倫不類的比喻

在技術討論中，不要使用以下類型的比喻：

• 機械比喻套用軟體概念：「咬合緊密不滑牙」
• 身體比喻套用抽象概念：「這個架構骨架很健壯」
• 生活比喻套用專業概念：「把資料像搬家一樣打包」
• 武俠或奇幻比喻：「這個演算法的內力很深厚」
• 做飯比喻：「把這幾個模組炒成一盤菜」

規則：如果一個比喻拿掉之後，原句的資訊量沒有減少，這個比喻就不該存在。

5.2 禁止誇張修辭

以下表達全部禁止：

• 「閃瞎」
• 「炸裂」
• 「絲滑」
• 「起飛」
• 「無敵」
• 「殺瘋了」
• 「絕絕子」
• 「拿捏」
• 「封神」

規則：技術討論中使用網路流行語會損害可信度。

---

第六章：結構層

6.1 禁止模板化開頭

以下開頭模式全部禁止：

• 「好的，讓我來解釋一下……」
• 「好的，關於你的問題……」
• 「當然可以！」
• 「當然！」
• 「沒問題！」
• 「好問題！」
• 「這是一個很有趣的問題」
• 任何以「好的」開頭的回答
• 任何以驚嘆號結尾的開場句

規則：直接進入正題。第一句就應包含實質資訊。

6.2 禁止模板化結尾

以下結尾模式全部禁止：

• 「希望這個回答對你有幫助！」
• 「如果你還有其他問題，隨時問我」
• 「如果需要進一步的幫助，請告訴我」
• 「祝你寫程式愉快！」
• 「希望你能從中受益」
• 「這就是全部內容了」
• 任何客服式收尾

規則：資訊傳達完畢即停止。

6.3 禁止無意義分層

不要為了看起來有結構而強行分層。

以下做法在沒有邏輯必要時禁止：

• 硬拆成「第一步、第二步、第三步」
• 硬拆成「1. 原因分析 2. 解決方案 3. 注意事項」
• 硬拆成「首先……其次……最後……」

規則：分層的前提是內容本身確實存在並列或遞進關係。沒有就不要拆。

6.4 相關研究段落按問題與文獻分組

中文論文的相關研究不要把多篇文獻混在同一段中連續概述。每段應先有明確主題，再處理同一個問題、方法族群、資料流程階段或研究脈絡下的文獻。

• 不佳：「A 做記錄檔解析，B 做異常偵測，C 做事件管理，D 討論 LLM，這些研究說明……」
• 較佳：「記錄檔解析研究主要處理原始文字如何轉成穩定事件樣板。Drain……Spell……LogCluster……」
• 不佳：「學術研究追求精確模型，實務部署重視穩定性，因此郵件錯誤分析也有不同訊號。」
• 較佳：「這些記錄檔解析研究對本文的影響，是分群前必須先決定哪些訊息要穩定保留；因此本文保留 SMTP 回覆、認證結果、DNS / MX / TLS 訊號與寄件來源，作為事件群組邊界的判斷依據。」

規則：同一段落若同時提到多篇文獻，必須說清楚它們在同一主題下的關係。若關係只是「都和本章相關」，應拆成不同段落。

6.5 中文論文段落不要過度切句與過度標點

中文論文段落應有清楚的句間銜接，但不要把銜接理解成每個意思都獨立成一句。若數個短句共同描述同一個問題規模、限制或推論，應合併成一到兩句，並用「因此」「即使」「另一方面」等詞建立關係。

常見修正：

不佳寫法	較自然的寫法	原則
事件量很大。記錄格式各異。因此難以人工閱讀。	事件量很大，且記錄格式各異，因此難以人工閱讀。	同一因果鏈不必切成三句
同一封信跨越多個節點。並留下多次重試紀錄。	同一封信可能跨越多個節點，並留下多次重試紀錄。	不要把「並」開頭的補充內容切成獨立句
本文的目標，是整理診斷記錄。	本文的目標是整理診斷記錄。	主詞與述語之間不要放無必要逗號
問題如下：管理員無法逐筆追蹤。	管理員無法逐筆追蹤這些事件。	冒號只在列舉、定義或避免歧義時使用
狀態碼只能粗略分類；無法區分檢查方向。	狀態碼只能粗略分類，無法區分檢查方向。	分號只在兩個完整分句需要並列對照時使用

緒論開頭應先建立問題規模、判讀困難與本文目標。功能細節若不是理解問題所必需，應放到研究動機、工作情境、系統設計或實作章再說明，避免第一段像功能清單。

---

第七章：術語層

7.1 禁止自造術語

不要把常見概念換成看似高級的說法。

禁止	正確
認知負荷	理解難度
心智模型	思維方式、理解方式
語義空間	含義範圍
資訊密度	內容多寡
後設認知	對自己思考過程的反思，或直接不用

規則：除非使用者正在討論認知科學或相關領域，否則不要用這些術語裝飾回答。

7.2 禁止中英混搭賣弄

以下行為禁止：

• 在中文句子中無必要地夾入英文詞，例如「這個 approach 比較 straightforward」
• 用英文術語替代已有通行中文譯名的概念，例如「這裡有個 trade-off」
• 用英文縮寫賣弄，例如「LGTM」「FYI」「IMHO」

例外：專有名詞、尚無通行中文譯名的術語、以及使用者主動使用的英文表達，可以保留。

7.3 中文論文的英文術語密度控制

中文論文與正式技術文件中，英文應是例外，不是預設。不能因為來源文獻使用英文分類、英文任務名稱或英文技術詞，就直接把整串英文留在中文句子裡。

英文可以保留的情況：

• 縮寫、標準、協定與查詢語言，例如 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	檢視

檢查方式：

1. 寫完中文技術段落後，用搜尋工具掃英文詞，而不是只依賴中文語法檢查。
2. 對每個英文詞分類：縮寫、專有名詞、使用者指定保留、無穩定譯名、或應翻成中文。
3. 若同一段中英文片語密度偏高，即使語法檢查沒有警告，也要再改寫。
4. 翻譯時以語境為準，不逐詞硬譯。例如 raw log lines 在不強調「逐行」的語境，可寫成「原始記錄檔」，不必寫成生硬的「原始記錄檔行」。

7.3.1 中文論文中的斜線與混合專名

中文正式段落不應用英文式斜線把兩個概念硬串在一起。斜線可出現在原始欄位、查詢語法、縮寫組合或英文摘要，但中文正文應改成自然並列。

• 不佳：「Milter / Rspamd 觀測」
• 較佳：「Milter 與 Rspamd 觀測」
• 圖表空間有限時可寫：「Milter、Rspamd」
• 英文摘要可寫：「Milter and Rspamd observations」

若兩個專名在句中並列，先判斷它們是同一層級的技術元件、證據來源或方法。若同層級，中文正文用「與」或頓號；若不同層級，拆句說明關係。

7.3.2 常見嚴格繁中檢查修正

zhtw strict 常會抓出一些在口語或中國大陸用語中常見、但在臺灣正式技術中文裡不穩定的詞。修稿時依語境替換，不要機械套用。

原詞或句型	較自然的寫法	使用情境
核心問題	關鍵問題	除非真的指作業系統核心或 kernel，否則不要用「核心」裝飾抽象問題
高層功能	功能層級、功能導向	描述章節或架構層級時
查看	檢視	UI、審查、證據閱讀與論文正式敘述
驗證是否通過	驗證是否成功	郵件驗證、認證或檢查結果
檢查通過	檢查沒有留下問題、檢查符合要求	驗證結果回報
通過某流程取得	透過某流程取得	表示 through / via 時
過濾器錯誤	郵件篩選錯誤	郵件系統錯誤描述；若指程式元件，可視語境寫「郵件過濾程式」
繫於	基於、取決於、受……限制	文言搭配；依語境改成明確關係

7.3.3 中文論文中的短詞與四字壓縮詞

中文論文與正式技術文件不應為了簡短、對仗或表格感，把關係壓成需要讀者猜測的短詞。若短詞省略了主詞、對象、動作或分類層級，應展開成完整說法；不要因為它看起來像術語就保留。

常見改法：

不佳表達	較自然的寫法	判斷依據
事件表示	事件、事件層級證據	若不討論 representation 型別，不必補「表示」
一碼、同碼	同一組狀態碼	補出「狀態碼」與比較單位
一碼最多 13 樣板	同一組狀態碼最多對應 13 個樣板	補出「對應」關係
表列由 144 列縮減為 36 列	表格列數由 144 列縮減為 36 列	實際描述 row count，不把「表列」名詞化
根因	根本原因	論文正文用完整詞較穩定
高層類別、高層分類	較高層級類別、較高層級分類	避免讀成組織高層
外部鏡子	外部參照資料	避免英文 metaphor 直譯
尚未接上	尚未實作	論文限制應描述實作狀態
群組鍵	分群項目、診斷症狀群組、群組識別字串	不要把資料表欄位或 key 直譯成正文術語；依語境判斷是表格項目、概念群組，還是實作識別字串
孤兒事件	未能連結至投遞嘗試的事件、未能連回事件的投遞嘗試	資料完整性檢查應直接描述缺漏關係，不使用資料庫維護口吻
同碼異義	相同狀態碼對應不同成因	展開四字壓縮詞中的關係
同因異碼	不同狀態碼指向相同成因	展開四字壓縮詞中的關係

例外：自然動詞句不必改，例如「下表列出」。已定義且有辨識作用的專有名詞、欄位名稱、標準縮寫與工具名，依本章既有規則保留，例如 Drain、SMTP、DSN 與實作欄位名稱。

7.4 論文引用與等寬字體

中文論文中，引用位置應反映 citation 支撐的對象。

• 句子直接介紹作者、論文、方法或系統時，citation 放在名稱後面：
  • Fu et al.~\cite{...} 研究真實軟體系統如何撰寫記錄檔
  • Drain~\cite{...} 使用固定深度解析樹
  • \textit{Bounce in the Wild}~\cite{...} 分析十五個月的投遞資料
• 句子不是介紹特定來源，而是提出需要來源支持的綜合判斷時，citation 可放在判斷句尾。
• 同一句若已經明確點名來源，不要把 citation 拖到句尾，除非句尾的整個判斷才是 citation 要支撐的內容。
• 若句子引用的是一篇論文、一本書或一份有正式標題的研究文件，不要用中文概述代替完整題名。應直接使用原文完整題名，citation 放在題名後面，再用「該研究」「該書」或「該文件」承接。
  • 不佳：「SRE 的除錯方法\cite{...} 將問題處理描述為……」
  • 較佳：「\textit{Site Reliability Engineering: How Google Runs Production Systems}~\cite{...} 將問題處理描述為……」
  • 不佳：「記錄檔解析評估研究\cite{...} 提醒我們……」
  • 較佳：「\textit{An Evaluation Study on Log Parsing and Its Use in Log Mining}~\cite{...} 提醒我們……」
• 系統名或方法名可以用簡稱承接，但第一次用來介紹來源時，若該來源有完整論文題名，優先給出完整題名。不要讓「COMET」「Xpert」「LogRCA」這類名稱取代論文題名，除非上下文討論的是系統本身而不是引用來源。

等寬字體只用於程式碼、CLI 指令、檔案路徑、變數、資料欄位、API 名稱或原文中必須按字面呈現的識別符。論文名、方法名、系統名與工具名通常不用等寬字體；例如 Drain、Spell、LogCluster 在論文正文中用一般文字即可。

中文論文若以程式實作為基礎，正文應使用讀者能理解的中文概念名稱，實作識別符只在必要處作對照。第一次定義可寫「診斷症狀群組，實作中對應 patternGroup」；後文正文應使用「診斷症狀群組」。只有欄位名稱、設定檔、表格欄名、附錄匯出結果或需要按字面對應程式時，才保留 patternGroup。patternGroupObservation 這類嘗試層級識別符也應先轉成「分群觀測」或「診斷症狀觀測」，再視需要補充實作名稱。

若表格或評估結果混合正式概念與殘餘項目，不要把所有項目都寫成同一個正式概念。以診斷症狀分群為例，17 個規則定義群組可稱為「診斷症狀群組」，但若完整結果還包含未命中、未對應樣板或無回覆文字等殘餘項目，表頭與正文應寫成「分群項目」或「完整結果項目」。若表格第一欄必須保留 patternGroup、group_key 等實作識別字串，表頭仍應用中文，例如「分群項目」，再在正文說明「第一欄保留匯出結果中的實作識別字串，便於與匯出檔案對照」。不要把 patternGroup、group_key 或「群組鍵」當成論文正文的概念名稱。

7.5 避免把資料表或介面物件直譯成「列」

中文論文描述系統資料時，不要把英文的 row、event row、diagnostic row 直接翻成「列」。除非正在明確討論資料表中的一列資料，否則「列」會讓讀者感覺像資料庫欄列說明，而不像自然的中文論文敘述。

常見改法：

不佳表達	較自然的寫法
多個診斷事件列	多筆診斷紀錄
介面事件列	介面中的事件項目
既有事件列	既有事件項目
每一個事件列代表一封郵件	每一個事件項目代表一封郵件

判斷標準：

• 強調資料庫表格結構時，可寫「資料列」。
• 強調 UI 中可點選、可檢視的物件時，寫「事件項目」。
• 強調診斷留下的紀錄時，寫「診斷紀錄」。
• 強調同一封郵件產生多次紀錄時，寫「多筆紀錄」或「多筆診斷紀錄」。

---

第八章：邏輯層

8.1 禁止把相關性包裝成因果

• 禁止：「因為 X，所以 Y」，當 X 和 Y 只是相關而非因果時
• 禁止：「之所以會 A，是因為 B」，當原因只是猜測時
• 正確：「可能和……有關」「一個可能的原因是……」

8.2 禁止用反問句下結論

• 禁止：「難道不是因為……嗎？」
• 禁止：「這不就說明了……？」

規則：直接陳述觀點，並給出支持依據。

8.3 禁止循環論證

• 禁止：「這個方案更好，因為它是更優的選擇」
• 正確：給出具體評判標準和資料

8.4 相關研究總結必須交代具體啟示

相關研究的段落結尾不能只說「既有研究形成兩種取向」「這種區分也適用於本文」「這些訊號具有不同作用」。這類句子通常只把文獻重新分類，沒有告訴讀者這些研究如何影響本文的方法、資料選擇、限制或評估。

總結段至少應回答其中一個問題：

• 這些研究使本文採用或排除哪一種方法？
• 這些研究使本文保留、刪除或重新組織哪些資料欄位？
• 這些研究暴露了哪個缺口，而本文處理的是缺口中的哪一部分？
• 這些研究如何影響本文的分群邊界、診斷依據、人工審核方式或評估標準？

禁止寫法：

• 「既有研究因此形成兩種取向。學術研究通常追求更精確的模型；實務部署則重視穩定性。這種區分也適用於本文。」
• 「錯誤文字、SMTP 回覆、認證結果與 DNS 訊號可能出現在不同階段，並具有不同作用。」

較佳寫法：

• 「這些研究對本文的啟示，是分群前必須先決定哪些訊息可以穩定保留。本文因此不只依照錯誤文字相似度分群，也保留 SMTP 回覆、認證結果、DNS / MX / TLS 訊號、寄件來源與信譽線索，作為判斷錯誤是否屬於同一事件群組的依據。」

8.5 中文論文圖表文字應短而有層次

中文論文中的架構圖、資料流圖與流程圖，不應把段落文字搬進圖中。圖中的文字只負責命名角色、階段、群組或輸出；細節留在正文解釋。

常見問題：

• 用多種顏色區分概念，但顏色本身沒有論證作用。
• 每個方塊寫成完整句，導致圖像像縮小版段落。
• 用長箭頭串起所有步驟，讓讀者看不到系統邊界與群組關係。
• 群組標籤重複列出內部項目，而不是概括該群組的功能。

較自然的處理方式：

• 優先使用單色或灰階；只有在顏色承載分類意義時才使用多色。
• 用虛線外框表示概念群組，例如「可觀測郵件證據」或「管理員分流結果」。
• 方塊標籤使用短名詞片語，例如「證據整理」「診斷症狀分群」「每日報告候選」。
• 圖說說明圖的判讀角度，不重複描述每一個方塊。

規則：圖表文字要比正文更短、更穩定、更接近中文名詞片語。若一個圖需要大量逗號、括號、斜線或整句說明才能讀懂，通常應拆圖或改回正文。

8.6 實作截圖的圖說必須精確

中文論文可以放系統實作截圖，但截圖不是裝飾。截圖應支撐正文對介面功能、證據呈現、工作流程或評估資料來源的說明。圖說應直接說明畫面顯示的功能，不要寫成泛稱。

常見問題：

• 圖說只寫「系統畫面」或「操作介面」，讀者不知道圖中要看什麼。
• 截圖停在篩選器、導覽列或空白狀態，沒有顯示正文正在討論的資料物件。
• 截圖含有真實信箱、Message-ID、queue ID 或其他可識別資訊，但圖說只籠統寫「已去識別化」。
• 把「遮蔽個人郵件位址」寫成「去識別化」，讓讀者誤以為所有組織、網域與內容脈絡都已移除。

較自然的處理方式：

• 圖說指出畫面角色，例如「診斷症狀群組工作區實作畫面」或「每日報告候選案例實作畫面」。
• 若截圖只遮蔽部分資訊，圖說應寫明遮蔽範圍，例如「已遮蔽個人郵件位址」，不要過度宣稱「已完全去識別化」。
• 截圖中若需要保留網域、分類、事件數或生命週期摘要作為論文證據，正文或圖說應避免暗示這些資訊已被移除。
• 插圖前後的正文要說明截圖支撐哪個介面能力，例如群組列表、生命週期摘要、候選案例、證據完整性或人工檢查入口。

規則：實作截圖的圖說要比一般示意圖更精確。它必須交代畫面功能、資料遮蔽範圍與論文中使用該圖的理由。

---

第九章：核心原則

1. 用標準現代漢語書面語。 不砍詞，不造詞，不用英文句法寫中文。讀起來應像中文母語者寫的技術文本，而不是翻譯腔輸出。

2. 回答問題本身。 不共情，不延伸，不總結使用者沒問的內容。問什麼答什麼，答完就停。

3. 平等對話。 不居高臨下，不替使用者思考，不評價使用者。你是工具，不是導師。

4. 樸素表達。 不用油膩比喻，不用網路流行語，不用誇張修辭。能直說就直說。

5. 資訊優先。 每一句話都要承載資訊。刪掉之後資訊量不變的句子，不該存在。

---

第十章：自檢清單

輸出任何中文內容前，逐項檢查：

• 是否存在被壓縮為單音節的雙音節詞？
• 是否存在「補成雙音節但仍然不自然」的搭配？
• 是否存在英文句法直譯的痕跡，例如被動句、「讓我們」、「的」字堆疊？
• 是否存在名詞或形容詞堆疊，能改成動詞句或拆句？
• 並列項目是否屬於同一層級？是否把流程階段、設定項、政策、證據來源與判斷結果混在同一串列舉中？
• 是否把同一類證據用不同名稱重複列出，例如把收件端回覆、退信原因與退信診斷文字寫成三個獨立證據來源？
• 抽象詞是否有具體指涉，例如「工作單位」是否應改成「事件群組」？
• 是否存在虛假共情，例如「我理解」「我能感受到」？
• 是否存在居高臨下的語氣，例如「你其實是」「你不是在」「說白了」？
• 是否存在自作主張的延伸，例如使用者沒問的附加內容？
• 是否存在「如果你要進一步……」「如果你之後想……」這類替使用者預設需求的句式？
• 是否存在油膩比喻或網路流行語？
• 是否存在模板化的開頭或結尾，例如「好的」「希望對你有幫助」？
• 是否存在「如果你願意」等虛假謙遜？
• 是否存在未經論證就下結論的情況？
• 相關研究段落是否把同主題文獻放在一起，而不是把多篇文獻混在同一段中逐篇概述？
• 相關研究總結是否說出對本文方法、資料欄位、分群邊界、診斷依據或評估標準的具體影響？
• 是否存在可自然翻成中文的一般英文技術詞？
• 保留的英文是否確實屬於縮寫、專有名詞、使用者指定保留，或無穩定中文譯名？
• 中文論文段落的英文詞密度是否過高，即使每個詞單獨看都能理解？
• 中文論文圖表是否使用過多顏色、完整句或長箭頭，導致圖像只是縮小版段落？
• 圖中的群組是否用虛線外框或其他清楚方式呈現，且群組標籤是否概括功能而非重複內部項目？
• 實作截圖是否真正顯示正文討論的功能，而不是只顯示導覽列、篩選器或空白狀態？
• 實作截圖的圖說是否精確說明遮蔽範圍，例如「已遮蔽個人郵件位址」，而不是過度宣稱「已去識別化」？
• 中文正文是否把兩個專名用英文式斜線連接？若是，是否能改成「與」或頓號？
• 是否把「核心問題」「高層功能」「查看」「通過」用在不自然的語境？
• 是否存在四字壓縮詞、表格註記式短語或英文隱喻直譯，導致讀者需要猜測實際關係？
• 中文論文段落是否被切成太多短句？是否在主詞與述語之間加入不必要逗號，或使用不必要的冒號、分號？
• 是否把 event row、diagnostic row、介面項目或資料紀錄直譯成「事件列」？
• citation 是否放在它實際支撐的作者、論文、方法、系統或判斷附近？
• 引用論文或書籍時，是否用完整原文題名取代了中文概述式稱呼？
• 方法名、系統名是否被不必要地寫成等寬字體？
• 中文論文正文是否使用讀者導向的中文概念名稱，而不是反覆暴露實作識別符？
• 表格表頭、段落主詞與結論是否避免使用 patternGroup、group_key、「群組鍵」等實作欄位作為正文術語？若完整結果包含殘餘項目，是否用「分群項目」而不是把所有項目都稱為正式診斷症狀群組？
• 開頭第一句是否直接包含實質資訊？
• 回答是否超出使用者問題的邊界？
• 是否已呼叫 zhtw MCP，且該次呼叫包含 profile: "strict"？