Chinese ai writing polish

中文 AI 語句避雷 Writing Skill

這是一個 portable writing skill：可獨立使用，也可由 openpress-create-pages 載入。當輸出語言為繁體中文的專業內容時，本 skill 提供句型、用詞、表格文字、被動句、反向句的判斷規則。

與其他 Skill 的關係

• 在 open-press page-based 文件中，由 openpress-create-pages 在繁體中文內容時載入。
• 若同時載入其他 project-specific portable writing skill，衝突解決依 openpress-create-pages 內的優先順序。
• 本 skill 不規範 open-press 的 source 路徑、CLI、驗證、輸出、部署或 starter 套用流程；系統操作一律回到 openpress 分流，再由它決定是否交給其他 openpress-* skill。

目標

產出專業、可用、可交付的中文內容。優先保留事實、判斷、對象、行動與結果；避免用看似漂亮但資訊量低的 AI 腔句型填補內容。

核心原則

• 直接說明主張，不用戲劇化轉折包裝薄弱論點。
• 用具體名詞、動詞、情境與結果取代抽象口號。
• 每段只承擔一個重點：對象、問題、做法、效果要清楚。
• 能量化就量化；不能量化就說清楚觀察依據。
• 避免過度承諾。沒有證據時，不寫「最佳」「顛覆」「重新定義」「革命性」。
• 寫給讀者要做的決策，不寫給文字本身好看。
• 反向說法只作為少量 hook 使用；一般段落應直接說產品做了什麼，讓讀者第一秒掌握重點。
• 表格文字要像表格，不要像段落。欄位名稱已經交代語意時，儲存格避免重複「驗證」「支援」「已完成」「用於」等附帶動詞，優先保留名詞、數據、狀態與結果。
• 避免同一小節反覆提及相同主詞。段落開頭已建立產品、公司或創辦人時，後續句子可用「產品」「平台」「團隊」「這項規劃」承接，或在語意清楚時省略主詞。

高風險 AI 腔句型

避免句型	問題	改寫方向
這不是 A，而是 B	用對比製造深度，但常沒有新增資訊；若太常使用，讀者第一秒抓不到重點	直接說 B 的具體功能、價值或差異；只有在需要與差異很大的系統做對比時，才可作為 hook 使用
不只是 A，更是 B	結構老套，容易把兩個空泛名詞堆在一起	拆成「目前能做什麼」與「因此帶來什麼結果」
把每一次的 A 都變成 B	過度願景化，缺少執行機制	說明每次 A 發生時，系統或流程實際記錄、判斷、提醒、產出什麼
讓 X 不再只是 Y	轉折感強但資訊密度低	直接描述 X 現在新增的能力或使用情境
從 A 到 B，全面升級	範圍過大，缺少可驗證細節	列出升級的項目、使用者感受到的變化、限制條件
重新定義 A	宣稱過大，通常無法證明	改成「改善 A 中的某個具體環節」
打造一個有溫度的 A	抽象且常見，難以落地	寫出哪個互動、回饋或服務讓使用者感受到差異
賦能、賦予、開啟新篇章	商業套話，容易顯得空泛	改成「支援」「協助」「提供」「降低」「縮短」「提升」
在這個快速變動的時代	開場空泛，與主題連結弱	直接進入讀者面臨的具體問題
真正的 A，不是 B，而是 C	像演講稿金句，不像專業說明	改成可被檢驗的判斷或標準
每一個 A，都值得被 B	情緒化且泛用	指出哪些 A 需要 B，以及原因
透過 A，讓 B 更 C	過度依賴「透過」「讓」串句	改成主詞明確的動作句：「A 會整理 B，並標示 C」
讓 X 可以被／能被 Y	被動句包裝，主詞與責任不清，容易寫成「讓資料能被使用」「讓問題可以被看見」這類空泛句	改成主詞明確的主動句：「系統整理 X，供 Y 使用」「教師可用 X 判斷 Y」
X 可以被／能被 Y	過度使用被動語態，讀者難以判斷誰執行動作、產出什麼結果	改成「誰使用 X 做什麼」或「系統如何處理 X」

改寫方法

1. 找出句子的實際意思：這句話到底要說功能、差異、願景、成果，還是情緒？
2. 刪掉套語骨架：移除「不是...而是...」「不只是...更是...」「把每一次...都變成...」。
3. 補上具體資訊：誰在什麼情境下，做了什麼，得到什麼結果。
4. 檢查證據強度：若沒有資料支持，就降低語氣，改成「有助於」「可協助」「目標是」。
5. 用短句收斂：一句話只放一個主要判斷，避免連續堆疊抽象名詞。

主詞延續規則

中文商業文件不需要每一句都重複產品名或公司名。當小節標題、段落第一句或前一句已經建立主詞，後續句子應自然承接。

避免寫法	問題	建議寫法
QJudge 目前是一人公司……因此 QJudge 現階段雖然以一人公司形態推進……	同一資訊重複兩次，讀者會覺得段落在原地打轉	第一段交代現況，後段改寫為「現階段雖然團隊規模小，但產品不是孤立開發。」
QJudge 的組織化不會……QJudge 會……QJudge 需要……	產品名過度重複，語氣僵硬	組織化不會……後續會……下一階段需要……
本產品支援……本產品提供……本產品能夠……	每句都重啟主詞，段落節奏笨重	第一處保留產品名，後續用「系統」「平台」「功能」或直接接動作

判斷標準：

• 同一段出現同一產品名超過 2 次，先檢查是否可省略或替換。
• 若前一句已明確說明主詞，下一句不要再用相同名詞開頭。
• 主詞替換應服務清楚度，不要為了變化而使用模糊代稱；讀者會誤解時才保留完整主詞。
• 結論句可回到產品名，但不應重複前文已講過的狀態或背景。

表格文字規則

表格的欄位名稱已經提供上下文，儲存格應減少完整句與重複動詞，讓讀者快速掃描。

避免寫法	問題	建議寫法
規模：60 人受測	欄位已寫「規模」，受測 多餘	60 人
已驗證能力：驗證程式上機等特殊題型也能在線上完成作答與監考	欄位已寫「已驗證能力」，開頭再寫「驗證」重複	程式上機等特殊題型可在線上完成作答與監考
平台開發狀態：已支援正式課程建立考試	狀態欄已有「已上線」，備註再寫「已支援」冗餘	正式課程考試建立；多題型作答介面
備註：可用於考前到場簽到、身分確認與考生狀態整理	可用於 不增加資訊	考前到場簽到、身分確認與考生狀態整理

判斷標準：

• 欄位叫「規模」時，儲存格只放數字與單位。
• 欄位叫「狀態」時，儲存格只放狀態，不再補「目前」「已經」。
• 欄位叫「能力」「功能」「備註」時，儲存格用名詞片語或短句，不用完整說明段。
• 同一列若需要補充因果或限制，移到表格前後段落，不塞進儲存格。

反向說法使用邊界

「不是 A，而是 B」「不只是 A，更是 B」這類反向句，不應作為常規說明段落的開頭。它會先要求讀者理解一個被否定的對象，再等待真正主張出現，容易讓評審或讀者第一秒抓不到重點。

可使用的情境：

• 對比差異很大的系統：例如需要說明 QJudge 與 LMS、Google Forms、一般題庫或 OJ 平台的根本差異。
• 段落 hook：用一句話打開對比，但下一句必須立刻接具體差異，例如功能、流程、資料、責任邊界或使用者行為。
• 避免連續使用：同一章節若已用過一次反向句，後續段落應改用正向敘述。

不建議的情境：

• 說明產品功能時：直接寫系統要求使用者做什麼、系統記錄什麼、產出什麼結果。
• 說明願景時：直接寫未來要支援的題型、資料流或評量方式，不要用金句包裝。
• 說明價值時：直接寫降低多少人力、縮短哪個流程、保留哪些紀錄。

判斷標準：如果刪掉「不是 A」後，句子仍然能直接說清楚 B 的功能或價值，就應該刪掉反向開頭。

改寫範例

例 1：產品定位

避免：

這不是一個解題平台，而是一個陪伴學生持續成長的學習夥伴。

建議：

QJudge 會記錄學生的提交紀錄、錯誤類型與修正歷程，讓學生回看自己的卡點，也讓教師掌握班級常見問題。

例 2：學習歷程

避免：

把每一次練習都變成成長的契機。

建議：

每次練習後，系統會保留題目、提交結果、錯誤訊息與修改紀錄，方便學生比較前後版本並整理弱點。

例 3：商業提案

避免：

我們不只是提供工具，更是協助教育現場重新定義程式學習。

建議：

我們提供自動批改、作業派發、學習紀錄與班級分析，協助教師減少批改時間，並更早發現學生的共同錯誤。

例 4：網站文案

避免：

在 AI 快速發展的時代，打造更智慧、更有溫度的學習體驗。

建議：

學生提交程式後，系統會即時回傳測資結果與錯誤提示；教師可在後台查看完成率、錯誤分布與個別進度。

可用句型

• X 是給 [使用者] 在 [情境] 中完成 [任務] 的 [產品類型]。
• [功能] 會在 [觸發時機] 自動 [動作]，供 [使用者] [具體行動]。
• 相較於 [既有做法]，[方案] 減少了 [成本或阻力]，並保留 [必要能力]。
• 這項設計解決的是 [具體問題]，不是泛稱的 [抽象願景]。
• 目前版本支援 [能力 A]、[能力 B]、[能力 C]；尚未涵蓋 [限制]。
• 若目標是 [決策或成果]，建議優先呈現 [證據或指標]。

用字偏好

• 優先使用：支援、協助、提供、記錄、整理、比對、標示、提醒、降低、縮短、提升、追蹤、檢視。
• 謹慎使用：打造、賦能、顛覆、革新、重新定義、全方位、沉浸式、無縫、前所未有、有溫度。
• 避免連續使用抽象名詞：體驗、價值、願景、場景、生態系、解決方案、影響力。
• 專業內容應使用繁體中文與台灣常用語感；避免不必要的簡體詞與翻譯腔。

英文技術術語處理

不要為了「全中文」而強硬翻譯英文技術術語。判斷標準：

情境	處理方式
業界已普及、讀者一看就懂的英文詞	直接保留英文，例如 edge case、spec、rubric、pipeline、SOP、KPI、API、OAuth
存在更精準、不引起誤會的中文說法	用中文，例如「鑑別度」「採購週期」「監考流程」
直譯結果晦澀或失準	用英文，或改寫情境描述（例：edge case 不要硬翻成「邊角案例」，可寫「教學現場的例外事件」或「平常想不到的特殊情境」）
同一份文件中已先出現英文原詞	後續沿用英文，不要混用兩種譯名

判斷時優先看「讀者第一秒抓到意思」與「精準度」，而不是「中英文比例」。專業讀者（評審、業界）對常見英文術語的辨識度通常高於彆扭的直譯。

交付前檢查

• 是否出現「這不是...而是...」「不只是...更是...」「把每一次...都變成...」或其變體？
• 是否出現「讓 X 可以被／能被 Y」「X 可以被／能被 Y」「資料被使用」這類被動包裝句？
• 若使用反向說法，是否是為了和差異很大的系統做對比？下一句是否立刻接具體差異？
• 每段是否至少有一個明確主詞與一個具體動作？
• 形容詞是否能被證據支持？不能支持就刪掉或降級。
• 是否用功能、流程、數據、限制取代口號？
• 讀者看完是否知道下一步可以判斷、操作或相信什麼？

使用規則

當輸出中文內容時，先以本 Skill 掃描草稿。若草稿含有高風險 AI 腔句型，必須改寫為具體、可驗證、可交付的版本；除非使用者明確要求保留宣傳式、演講式或高度修辭化的語氣。