Install
$ agentstack add skill-aeopress-writing-skills-tw-good-writing-tw ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
中文好寫作
> 注意: 本 Skill 專注於句型結構精簡與節奏琢磨。若需處理 AI 生成痕跡、翻譯腔與中國用語,請搭配 humanizer-tw。建議順序:先 humanizer-tw(去機器味)→ 再 good-writing-tw(琢磨節奏)。
節奏規則
氣口
兩個標點符號(,。;:!?)之間,連續字數不超過 15–20 字。超過就該斷句或加逗號。
錯落
相鄰兩句長度差異應 > 5 字。避免連續 3 句以上長度相近(±3 字)。
句尾
- 名詞收尾 → 穩
- 動詞收尾 → 勁
- 助詞收尾(的、了、呢)→ 軟
避免連續句尾都落在同類型。
改寫技法
一、刪贅字(連續「的」)
連續三個「的」→ 想法沒整理好,至少刪一個。
原句:這是公司的新的產品的宣傳方案。
改寫:這是公司新產品的宣傳方案。
(理由:三連「的」刪為一個,語意不變)
原句:他提出的關於市場的未來的發展報告。
改寫:他提出的市場未來發展報告。
(理由:「關於」多餘,「的」可精簡為一個)
二、刪贅字(進行/實施/加以)
「進行」「實施」「加以」通常可直接刪除。
原句:我們對此問題進行了深入的討論。
改寫:我們深入討論了這個問題。
(理由:刪「進行」,動詞前移)
原句:相關部門已對該方案加以審核。
改寫:相關部門已審核該方案。
(理由:刪「加以」,直接用動詞)
三、拆長句
原則上不超過 30 字。例外:緊密條件句、排比句、專業術語連綴可放寬,但需以標點確保內部停頓。
原句:由於天氣不好加上交通阻塞的關係,所以他沒有辦法準時抵達會場參加會議。
改寫:天氣差,路又塞。他遲到了。
(理由:一句塞了兩個因果,拆開各自獨立)
原句:為了能夠更好地滿足客戶在不同場景下對於產品功能的多樣化需求,我們決定重新設計整個系統架構。
改寫:客戶需求多樣,現有架構撐不住。我們決定重新設計。
(理由:40+ 字壓縮為兩句,因果更清晰)
拆句 ≠ 連發造勢(cross-guard):拆長句的目的是因果清晰與節奏,不是製造戲劇感。連續三個以上短促斷句堆疊語勢(「沒有人停下。沒有人回頭。一切都變了。」)是新一代 AI 文的 tell(humanizer-tw 類別十三「短句連發戲劇腔」)。拆完的句子要長短相間:一兩個短句收束可以,整段拆成等短斷句即失敗——那不是節奏,是把一種 AI 味換成另一種。
四、砍開頭
直接刪掉填充開頭,從重點開始。
原句:關於這個問題,我認為我們應該重新思考策略。
改寫:我們應該重新思考策略。
(理由:「關於這個問題」是廢話)
原句:基本上來說,這個方案的可行性是比較高的。
改寫:這個方案可行性高。
(理由:砍開頭 + 刪「是...的」句式)
五、還原強動詞
「弱動詞 + 抽象名詞」→ 還原為單一強動詞。被動語態 → 主動語態。
常見模式:
- 「進行 X」→「X」
- 「做出 X」→「X」(做出決定 → 決定)
- 「給予 X」→「X」(給予協助 → 協助)
- 「加以 X」→「X」(加以改善 → 改善)
- 「達到 X 的目的」→「為了 X」
- 「被...所...」→ 主動語態
原句:我們需要對現有流程做出改善。
改寫:我們需要改善現有流程。
(理由:「做出改善」→ 直接用「改善」)
原句:這個問題被許多研究者所關注。
改寫:許多研究者關注這個問題。
(理由:「被...所...」→ 主動句,更有力)
原句:本計畫旨在達到提升效率的目的。
改寫:本計畫旨在提升效率。
(理由:「達到...的目的」是多餘包裝)
防過度矯正(完整模式也適用)
節奏規則的數字(氣口 15–20 字、句長差 > 5 字、單句 30 字)是預設值,不是鐵律。硬套數字上限的失敗模式是把作者的風格也剷平——比漏改更糟:
- 作者刻意的風格不算違規:有內部停頓、念得出口的長句(余光中式綿長句)、刻意的排比、刻意的重複——能看出作者「為什麼這樣寫」的地方保留,不硬拆。判準同 humanizer-tw 的防誤殺:寧可漏改,不可錯改。
- 別把全文改成同一種節奏:每句都卡在 15–20 字、每句句長都精準差 5 字,改出來是節拍器不是文章——均質化本身就是新的 AI tell。規則用來抓「明顯單調」,不是把每句校準到公差內。
- 風格樣本優先於預設數字:使用者提供過自己的書寫樣本、或前一步 humanizer-tw 已做個人風格校準時,氣口/錯落/句尾的目標對齊樣本,不套本檔預設值。樣本作者愛寫長句,就別把成品全改成短句——串接的目的是保住使用者的聲音,不是覆蓋它。
檢查清單
改寫完成後逐項檢查:
- 原則上沒有超過 30 字的句子(緊密條件句、排比句、術語連綴除外,但需有標點停頓)
- 沒有連續三個「的」
- 相鄰句長差異 > 5 字,無 3 句以上等長(±3 字)
- 開頭沒有填充廢話
- 句尾沒有連續相同類型(連續「的」「了」「呢」)
- 「進行」「實施」「加以」能刪的都刪了
- 「弱動詞+抽象名詞」已還原為強動詞,被動語態已轉主動
- 改過頭? 拆句後沒有連續短促斷句造勢;作者刻意的長句/排比/重複沒被剷平;全文不是同一種節奏(見「防過度矯正」)
工作流程
模式一:改寫既有文章
依序輸出三個區塊:
`` — 逐句掃描原文,列出所有違規:
- 哪些句子超過 30 字
- 哪裡有連續「的」
- 哪些開頭是廢話
- 哪些「弱動詞+名詞」可還原
- 節奏是否單調(連續等長句)
`` — 對每個違規擬定修改策略:
- 在哪裡斷句、刪哪個贅字、怎麼還原動詞
- 確保拆句後邏輯仍連貫(必要時補銜接詞)
`` — 輸出改寫版本,以粗體標註主要修改處。
輸出前回掃(兩頭都查):改過頭?——對照「防過度矯正」三條,把誤拆的風格句還原;改不夠?——對照檢查清單 1–7,補漏。
> ` 和 ` 是改寫流程的必要輸出,確保修改全面且一致。
模式二:寫作時自動套用
寫中文內容時,自動遵循上述節奏規則、改寫技法與檢查清單,不需額外提示。
模式三:技術文件保守模式(conservative)
觸發時機:處理技術 README、API 文件、CLI 說明、錯誤訊息、技術 blog,或使用者明確要求「只改標點/氣口,不動結構」。
這個模式之所以存在,是因為技術文件有大量不該被「潤飾」的內容:程式碼範例、命令列片段、錯誤訊息字串、API 名稱、參數列表。完整模式的「錯落」「打破公式化」規則若強行套用,會把結構化列舉(例如表格說明、指令解釋)改得面目全非,反而傷害資訊傳達。
只執行(四類):
- 刪連續三「的」—— 語意無損時
- 刪「進行/加以/實施」—— 能直接用動詞時
- 拆超過 30 字的單句 —— 但見下方術語連綴例外
- 修氣口 —— 標點間連續 15–20 字加逗號斷開
停用:
- 「錯落」規則(相鄰句長差異 > 5 字)—— 技術列舉同結構是刻意的
- 「打破公式化段落」—— 首先/其次/最後在操作步驟中反而清楚
- 重組段落順序、重寫語義
- 動用「句尾類型輪換」
絕對不碰:
- 程式碼區塊(``
…`、inline`) - CLI 指令、檔案路徑、URL、Markdown 連結語法
- 表格結構與欄位
- 英文技術術語(保留原樣,即使夾在中文句中)
- YAML front matter、語言選單、版本標註
- 使用者明確標示「不改」的區塊
術語連綴例外(即使超過 30 字也不強拆):
以下情境的長片段視為已有「內部停頓」,不需要加逗號:
- 頓號列表:「
.py .ts .js .go .rs .java .c .cpp .rb .cs .kt .scala .php」—— 每個副檔名都是一個停頓點 - 破折號引介:「完全多模態 —— graphify 會用 Claude vision 從這些內容中提取概念」—— 破折號已分段
- 括號補充:「對程式碼檔案做結構分析(類、函式、匯入、呼叫圖、docstring)」—— 括號本身是停頓
- 連字符連綴:「程式碼-論文之間的邊會比程式碼-程式碼邊權重更高」——
-提供視覺停頓
判斷原則:一個片段若去掉中英文/數字/標點後剩不到 15 個中文字,即使字元計數長也不算違規。
理論背景見 [references/guide.md](references/guide.md)。整合自 Paul Graham〈Good Writing〉、余光中、王鼎鈞。
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: aeopress
- Source: aeopress/writing-skills.TW
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.