菜单
中文好寫作指南：提升中文寫作品質與改寫既有文章。基於 Paul Graham、余光中、王鼎鈞的寫作智慧。 使用時機： - 用戶說「潤稿」「改寫」「rewrite」「讓文字更順」 - 用戶要求「改善文筆」「寫好一點」「高品質中文」 - 用戶提供文章並要求修改或潤飾 - 需要產出高品質中文內容時 技術文件（README、API 文件、CLI 說明）請使用保守模式（見下方模式三），避免改動結構化列舉與術語連綴。 觸發詞：/good-writing、/潤稿、good writing、潤稿、改寫、rewrite、文筆、讓文字更順、技術文件潤飾、conservative 模式
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/yelban/orz99-skills --skill good-writing-zh命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Fable-based concept explorer — learn any field through parables. Picks a graduate-level concept from a user-specified domain, writes a literary fable that indirectly conveys it (the reveal comes only near the end), then follows with a clear explanation. Supports difficulty levels (-e easy, -h hard), batch mode (-3), interactive guess-first mode (-i), multiple-choice quiz (-g), cross-domain structural comparison (-x), and story styles (-s 莊子/sci-fi/aesop/detective). Use whenever the user wants to explore a field through stories, learn concepts via narrative, or says /fable-explore, /寓言, /探索, 寓言探索, 用故事學, fable explore, "tell me a fable about", "用寓言教我". Also trigger when user says "再一個" or "another" after a previous fable to continue exploring the same field.
Amanda Askell's original economics fable prompt (March 2025). Picks a niche economics principle that early undergrads wouldn't know but late grad students would, writes a strict 3-paragraph illustrative story without naming the principle, then reveals and explains it in a single closing paragraph. Faithful to the original structured format. Use when user says /fable-econ, /經濟寓言, "economics fable", "經濟學寓言", or wants to explore economics concepts through Amanda Askell's original 3+1 story format. For general-purpose fable exploration across any field, use fable-explore instead.
去除中文文字中的 AI 生成痕跡。針對中文 AI 寫作的獨特問題設計： 時代開場白、連接詞濫用、互聯網黑話、翻譯腔、書面語過重、公式化結構、結尾套話、中國用語滲入。 使文字更自然、更有人味、更像台灣人寫的。 觸發詞：/humanizer、humanize、去除 AI 痕跡、人性化、去機器味
正在显示 SKILL.md
基于 SOC 职业分类
| name | good-writing-zh |
| version | 1.1.0 |
| description | 中文好寫作指南：提升中文寫作品質與改寫既有文章。基於 Paul Graham、余光中、王鼎鈞的寫作智慧。 使用時機： - 用戶說「潤稿」「改寫」「rewrite」「讓文字更順」 - 用戶要求「改善文筆」「寫好一點」「高品質中文」 - 用戶提供文章並要求修改或潤飾 - 需要產出高品質中文內容時 技術文件（README、API 文件、CLI 說明）請使用保守模式（見下方模式三），避免改動結構化列舉與術語連綴。 觸發詞：/good-writing、/潤稿、good writing、潤稿、改寫、rewrite、文筆、讓文字更順、技術文件潤飾、conservative 模式 |
| user_invocable | true |
| argument_hint | <article text or file path to rewrite> |
注意： 本 Skill 專注於句型結構精簡與節奏打磨。若需處理 AI 生成痕跡、翻譯腔與中國用語，請搭配 humanizer-tw。建議順序：先 humanizer-tw（去機器味）→ 再 good-writing-zh（打磨節奏）。
兩個標點符號（，。；：！？）之間，連續字數不超過 15–20 字。超過就該斷句或加逗號。
相鄰兩句長度差異應 > 5 字。避免連續 3 句以上長度相近（±3 字）。
避免連續句尾都落在同類型。
連續三個「的」→ 想法沒整理好，至少刪一個。
原句：這是公司的新的產品的宣傳方案。
改寫：這是公司新產品的宣傳方案。
（理由：三連「的」刪為一個，語意不變）
原句：他提出的關於市場的未來的發展報告。
改寫：他提出的市場未來發展報告。
（理由：「關於」多餘，「的」可精簡為一個）
「進行」「實施」「加以」通常可直接刪除。
原句：我們對此問題進行了深入的討論。
改寫：我們深入討論了這個問題。
（理由：刪「進行」，動詞前移）
原句：相關部門已對該方案加以審核。
改寫：相關部門已審核該方案。
（理由：刪「加以」，直接用動詞）
原則上不超過 30 字。例外：緊密條件句、排比句、專業術語連綴可放寬，但需以標點確保內部停頓。
原句：由於天氣不好加上交通阻塞的關係，所以他沒有辦法準時抵達會場參加會議。
改寫：天氣差，路又塞。他遲到了。
（理由：一句塞了兩個因果，拆開各自獨立）
原句：為了能夠更好地滿足客戶在不同場景下對於產品功能的多樣化需求，我們決定重新設計整個系統架構。
改寫：客戶需求多樣，現有架構撐不住。我們決定重新設計。
（理由：40+ 字壓縮為兩句，因果更清晰）
直接刪掉填充開頭，從重點開始。
原句：關於這個問題，我認為我們應該重新思考策略。
改寫：我們應該重新思考策略。
（理由：「關於這個問題」是廢話）
原句：基本上來說，這個方案的可行性是比較高的。
改寫：這個方案可行性高。
（理由：砍開頭 + 刪「是...的」句式）
「弱動詞 ＋ 抽象名詞」→ 還原為單一強動詞。被動語態 → 主動語態。
常見模式：
原句：我們需要對現有流程做出改善。
改寫：我們需要改善現有流程。
（理由：「做出改善」→ 直接用「改善」）
原句：這個問題被許多研究者所關注。
改寫：許多研究者關注這個問題。
（理由：「被...所...」→ 主動句，更有力）
原句：本計畫旨在達到提升效率的目的。
改寫：本計畫旨在提升效率。
（理由：「達到...的目的」是多餘包裝）
改寫完成後逐項檢查：
依序輸出三個區塊：
<diagnosis> — 逐句掃描原文，列出所有違規：
<planning> — 對每個違規擬定修改策略：
<rewrite> — 輸出改寫版本，以粗體標註主要修改處。
<diagnosis>和<planning>是改寫流程的必要輸出，確保修改全面且一致。
寫中文內容時，自動遵循上述節奏規則、改寫技法與檢查清單，不需額外提示。
觸發時機：處理技術 README、API 文件、CLI 說明、錯誤訊息、技術 blog，或使用者明確要求「只改標點/氣口，不動結構」。
這個模式之所以存在，是因為技術文件有大量不該被「潤飾」的內容：程式碼範例、命令列片段、錯誤訊息字串、API 名稱、參數列表。完整模式的「錯落」「打破公式化」規則若強行套用，會把結構化列舉（例如表格說明、指令解釋）改得面目全非，反而傷害資訊傳達。
只執行（四類）：
停用：
絕對不碰：
…、inline）術語連綴例外（即使超過 30 字也不強拆）：
以下情境的長片段視為已有「內部停頓」，不需要加逗號：
.py .ts .js .go .rs .java .c .cpp .rb .cs .kt .scala .php」—— 每個副檔名都是一個停頓點- 提供視覺停頓判斷原則：一個片段若去掉中英文/數字/標點後剩不到 15 個中文字，即使字元計數長也不算違規。
理論背景見 references/guide.md。整合自 Paul Graham〈Good Writing〉、余光中、王鼎鈞。