Humanizer (English + zh-TW)去除 AI 味(中英雙語)

Catches the tells that make English and Traditional Chinese read as machine-written, then rewrites them into human prose揪出讓中英文讀起來像機器寫的破綻,改回像人講話的樣子

EN繁中中英Model-invoked模型叫用
Read SKILL.md on GitHub在 GitHub 看 SKILL.md

This skill strips AI writing tells out of a draft. It runs two separate checks, and one of them switches itself off depending on what kind of document you hand it — that's the part most people get wrong, and the reason this page exists.

Install

npx skills add https://github.com/leoluyi/skills -g -a humanizer-zh -y

Keep it current:

npx skills update humanizer-zh

Source

What it does

It hunts two different defects, and they're independent judgments:

Something that shouldn't be there. A phrase standing in for a fact.

This platform doesn't just offer a rich, diverse range of courses — it lays a solid foundation for every employee's career growth.

"Doesn't just... it..." props up a contrast with no content behind it, "rich, diverse" never says how many courses, "lays a solid foundation" delivers nothing concrete. 45 rules chase this (of the 47 rules across 8 classes, minus the two — hidden author and stance vacuum — that flex by document type), and every document type gets checked.

Someone missing. Every sentence is individually fine, but nobody sounds like they wrote the whole thing.

Self-hosting and managed hosting each have trade-offs, depending on team needs. Monthly versus annual billing is the same — it depends.

Not one sentence carries the author's own choice, a concrete time/amount/scenario, or a spoken-register break from the pattern. This is hidden author (作者隱身) — a whole-document judgment, visible only when you step back, and it only runs on signed-voice writing.

There are three finished-prose modes (rewrite, detect-only, edit-in-place), and a protected list locked before any edit — prices, dates, commitment clauses, named quotes, code — these stay exactly as written even if they technically match a rule; a hit there gets marked "protected," not rewritten. It doesn't write for you: when stripping the AI-voice leaves nothing behind, it flags the gap in place rather than inventing an experience to fill it; hidden author in particular only reports, never rewrites. It also doesn't inject a voice — giving a piece opinion, metaphor, and rhythm is addition, that's blog-writing-zh's job; this skill only subtracts.

If no draft exists yet, but you manually invoke it to prepare writing context for a downstream planning or writing skill, read writing preflight. This pre-draft handoff produces a writing contract, style guardrails, and gaps; it does not write the document or replace the skill that owns composition.

When you manually invoke it with no mode, exact file path, or draft content, it defaults to preflight. When you provide an exact file path without a mode, it stops and asks whether you want detect or modify instead of guessing.

When to use

Reach for it as a final de-AI pass before shipping a README, ADR, blog post, or any English/Chinese draft that reads machine-generated.

When not to

Use blog-writing-zh when you need to compose a piece or give it a human voice from scratch; this skill's preflight only prepares a writing handoff for the downstream writer and does not compose the document.

How it works

The whole skill's logic in one sentence: classify the genre first, lock down what can't be touched, then run two independent questions down two separate tracks, and finally check whether any fact got lost along the way.

Your document's genre decides whether check #2 runs

The skill first classifies what kind of document you gave it:

Examples hidden author check
Signed voice blog posts, newsletters, opinion pieces, deep-dive essays, personal writing Runs
Functional docs, README, reference, spec, RFP, SOP, official memos, 簽呈, project plans, proposals, investor letters Skipped

When it can't tell, it defaults to functional and says so.

Why functional documents skip it. Not laziness — that check is guaranteed to misfire on these. It's asking whether the author's judgment, experience, metaphor, tone, and rhythm are present, and a well-written 簽呈 shouldn't have any of those five. This gate sits in front of everything else.

That doesn't mean your memo is clean: turning off hidden author still leaves the other rules running. The 簽呈 example above gets:

Hidden author: not applicable (functional document)

5 hits:
・"Amid the wave of digital transformation..."        parachuted opening claim
・"doesn't just... it lays a solid foundation"          contrast + universal closer
・"rich, diverse"                                       empty-word filler
・"it's worth noting that"                              explainer-voice hedge
・"expected to significantly improve overall outcomes"  abstract claim, no deliverable

Seeing "not applicable" is not a clean bill of health — it only turns off one check, not the whole report.

Proposal-type documents: judgment required, personality not

Project plans, proposals, and investor letters count as functional, but one rule is unusually strict with them:

stance vacuum — a proposal that spends the whole document saying "each option has trade-offs" without recommending anything gets flagged. The entire point of a proposal is to recommend something.

This rule leaves docs, README, spec, RFP, and SOP alone (those exist purely to state information), and leaves official memos alone too (the 擬辦 line is already their form of taking a position) — but it does not leave proposals alone.

The dividing line: proposals need the author's judgment, not their personality. So stance vacuum catches them, but the hidden author group (spoken-register breaks, invented metaphor, rhythm variation) doesn't — a formal proposal correctly has none of those; that's genre, not a defect.

--expect-author: when you need it

Normally you don't. Blog posts get the hidden author check automatically, no flag required.

You need it when: your document got classified as functional, but you believe it should read like someone wrote it.

Check this client-facing project plan with --expect-author

Passing this flag is your declaration that "this draft should show an author" — the skill runs the check on that basis, and anything missing counts as a real finding. The report notes that this classification came from your declaration, not its own judgment, so you can retract it if you called it wrong.

It only works in one direction — the flag can push a document toward "check it," never turn a check off.

The judgment pipeline: from draft to output

Step 1's genre classification isn't a warm-up — it's the fork the whole report branches on. Step 4's two tracks are the core of the skill and the most commonly misunderstood part — they ask two independent questions, and only one of them ever gets switched off by genre.

                         draft comes in
                               │
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 1. Context detection                                          │
│ Set the frame. Two calls, both ripple to the end              │
├──────────────────────────────────────────────────────────────┤
│ Language ─┬─ Chinese ──── zh rule layer                       │
│           ├─ English ──── en rule layer                       │
│           ╰─ mixed ────── each passage runs its own layer,    │
│                            terms of art stay in English       │
│                                                                │
│ Genre ─┬─ signed voice ── blog, newsletter, opinion, essay    │
│        ╰─ functional ──── docs, memos, 簽呈, project plans…   │
│                            defaults here when unclear, and    │
│                            says so                             │
╰──────────────────────────────────────────────────────────────╯
                               │
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 2. Lock the protected list                                     │
│ Ring-fence what can't be touched before any edit               │
├──────────────────────────────────────────────────────────────┤
│ Prices, dates, commitment clauses, named quotes, code,          │
│ and any deliberate register breaks you left in                 │
│ Once ringed, a rule hit there gets marked "protected," untouched│
╰──────────────────────────────────────────────────────────────╯
                               │
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 3. Scope decision                                              │
│ How wide a change this pass makes                              │
├──────────────────────────────────────────────────────────────┤
│ spot patch (default) / paragraph rewrite / full rewrite         │
╰──────────────────────────────────────────────────────────────╯
                               │
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 4. Rewrite by class                                             │
│ Two independent tracks, two different questions                 │
╰──────────────────────────────────────────────────────────────╯
                               │
               ╭───────────────┴────────────────╮
               ▼                                ▼
╭─────────────────────────────╮  ╭─────────────────────────────╮
│ A: something that shouldn't  │  │ B: is the author missing?  │
│    be there?                 │  │                             │
├─────────────────────────────┤  ├─────────────────────────────┤
│ 47 rules, 8 classes          │  │ hidden author, 1 rule       │
│ every genre runs it          │  │ 5 sub-signals, ≥2 to report │
│ functional genre is no pass  │  │ only signed-voice genres run│
│ unit: sentence, phrase       │  │ unit: whole document        │
│                              │  │ reports absence only, never │
│                              │  │ writes it in                │
╰─────────────────────────────╯  ╰─────────────────────────────╯
               ╰───────────────┬────────────────╯
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 5. Fidelity check                                              │
│ Did any fact get lost in the rewrite?                          │
├──────────────────────────────────────────────────────────────┤
│ Numbers, dates, names, commitments must match exactly          │
│ Re-audits what step 4 let through                              │
│ Fails → back to step 4 to re-judge                             │
╰──────────────────────────────────────────────────────────────╯
                               │
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 6. Pre-ship self-read                                           │
│ Read its own freshly rewritten draft cold                      │
├──────────────────────────────────────────────────────────────┤
│ Catches defects the rewrite itself introduced                  │
│ e.g. flattening tone that used to have variation                │
│ Reruns at most once; a third pass is just a full rewrite        │
╰──────────────────────────────────────────────────────────────╯
                               │
                               ▼
              output: genre call → per-class hits → fidelity check

The line between A and B is the thing this whole page keeps repeating: when genre switches off B, A doesn't lose a single rule.

Three finished-prose modes decide how you get the result back. There is also a manual pre-draft handoff for a blank page. When manually invoked without a mode, exact file path, or draft content, preflight is the default. An exact file path without a mode opens a choice between detect and modify. For supplied prose or a draft, an unspecified rewrite request still defaults to detect.

How you asked Mode What you get
Invoke it directly with no mode, exact file path, or draft content preflight Reads the current context and returns a writing contract, positive style guidance, an evidence boundary, and gaps; does not write prose
"Get the AI-isms out of this," "make it sound human," or "rewrite this" rewrite Every hit (rule name + quote), the full rewritten text, a list of what changed
"Just flag it, don't change anything" detect Hits grouped P0/P1/P2, each marked hard-defect or judgment-call; original text untouched
With prose or a draft supplied, "take a look at this," "scan this document," or no explicit rewrite request detect Hits grouped P0/P1/P2, each marked hard-defect or judgment-call; original text untouched
Provide an exact path such as draft.md without a mode choice prompt Asks whether to detect or modify; does not audit or edit until the user chooses
Choose modify, or say "Edit draft.md directly" edit-in-place Reads the file, changes only the hit spans, re-reads once after editing, reports before/after per change; clean passages stay byte-identical
No draft exists and the user manually asks for a pre-draft writing handoff preflight Reads the brief, plan, sources, genre, and author preferences, then returns a writing contract and gap list; does not write prose. See writing preflight

The checklist: 8 classes, 47 rules

The rules aren't a flat list — they split into 8 classes, each catching a different failure mode:

Class Catches Rules Example
Content words spent, no fact delivered 7 meaning inflation, empty-word filler, universal closer
Sentence patterns the shape of the sentence doing the work instead of content 13 false-contrast structure, translationese, register drift
Style & layout formatting substituting for actual structure 6 em-dash overuse, bullet-point bloat, table misuse
Interface residue chat-interface and tool artifacts leaking into the document 4 sycophantic tone, stray AI-tool markers
Fact & citation borrowing authority instead of earning it 3 vague attribution, hallucinated or unverified citation
Stance & opening a call that should be made gets deferred, dodged, or dropped 7 parachuted opening claim, stance vacuum, hidden author
Manufactured drama a reaction invented out of nowhere, with no consequence attached 3 canned-reaction shot, declared emotion
Breaking the fourth wall the draft describing its own generation 4 self-referential document, self-endorsement, leaked reasoning process, seam between merged drafts

Every hit comes with its rule name and the quote it matched, so anything the report shows you traces back to this table — "which class is this" is usually easier to remember than "what's this rule called."

Two mechanisms cut across every class rather than belonging to one: the protected list (decides what stays verbatim) and scope (decides how wide the edit goes).

Cross-reference: genre decides which rules run

Putting "which document" and "which rule" side by side is clearest — inside "functional," stance vacuum and hidden author don't behave the same way:

docs / README / spec / RFP / SOP official memos / 簽呈 project plans / proposals / investor letters blog / newsletter / opinion / personal essay
The other 45 rules run run run run
stance vacuum off (neutral statement is the genre) off (the 擬辦 line already is the stance) on (a proposal that recommends nothing is exactly what this catches) on
hidden author off off off on

This table is why proposals and investor letters get flagged more often than memos — they match memos on "doesn't need personality," but not on "doesn't need judgment." --expect-author only moves the hidden author row from off to on; it leaves the other three rows alone.

Common misreadings

You might assume What's actually true
Memos and SOPs skip the AI-ism check entirely 45 rules still run; only hidden author is skipped
"Hidden author: not applicable" in the report means it's clean That's the conclusion of one check — keep reading for the rest
You have to ask specially for it to check "does this feel soulless" Blog posts get it automatically, no request needed
--expect-author turns the checks up in general It only declares the genre, which activates hidden author for this document
A proposal that recommends nothing isn't a defect stance vacuum flags it — that's exactly what the rule exists for
It'll make my writing sound more human It only removes what shouldn't be there; what it can't add is left to you

Related skills

  • blog-writing-zh — use it for composing from scratch or giving a draft a personal voice; it handles addition (opinion, metaphor, rhythm), while this skill handles subtraction and the optional pre-draft handoff.
  • avoid-china-writing — catches mainland-China wording and stray Simplified characters, an orthogonal axis to de-AI cleanup; a document may need a pass from both.

這個 skill 幫你把稿子裡的 AI 味拿掉。它做兩種檢查,而其中一種會依你給的文件類型自動關閉——這是最容易誤會的地方,也是這份文件主要要講清楚的事。

安裝

npx skills add https://github.com/leoluyi/skills -g -a humanizer-zh -y

之後更新:

npx skills update humanizer-zh

原始碼

它做什麼

它在找兩種毛病,兩種是獨立的判斷:

多了不該有的東西。 一個片語頂替了一個事實。

本平台不僅提供豐富多元的課程內容,更能為同仁的職涯發展奠定堅實的基礎。

「不僅…更…」撐起一個沒有內容的對比,「豐富多元」沒說幾門課,「奠定堅實基礎」沒交付任何東西。這類共 45 條規則(8 大類 47 條裡,扣掉 作者隱身立場真空 這兩條會依文件類型調整的),任何文件都查

少了作者。 每一句都挑不出毛病,整篇讀完卻感覺不到有人在。

自架和託管各有優缺點,要看團隊需求。月繳和年繳也是,見仁見智。

沒有一句作者的選擇、沒有一個具體時間金額場景、沒有一處口語破格。這叫 作者隱身,是整篇尺度的判斷,退開來看才浮得出來,只在署名文體上查。

它有三種成稿模式(改寫、只標記、直接改檔),以及一份動筆前先鎖定的保護清單——價格、日期、承諾條款、具名引言、程式碼,這些原樣保留,就算命中規則也只標「受保護」不動。它不代筆:剝掉語氣後那段什麼都不剩時,它會就地標出來,不會替你編一段經驗填進去;作者隱身 更是只報不改。它也不注入聲音——把文章寫得有觀點、有比喻、有節奏是加法,那是 blog-writing-zh 的事,這個 skill 只做減法。

如果尚未有草稿,但你手動啟動它來替下游 plan 或 writer skill 準備寫作 context,請讀 writing preflight。這條前置 handoff 只產出寫作契約、風格護欄與資料缺口,不寫正文,也不取代真正負責寫作的 skill。

直接手動啟動、沒有提供模式、確切檔案位置或草稿內容時,預設走 preflight。若提供確切檔案位置但沒有指定模式,先停下來提示你選「偵測」或「修改」,不替你猜測意圖。

何時使用

在 README、ADR、部落格或任何中英文草稿出稿前,當作去 AI 味的最後一關。

何時不要

若要從零寫文章或替它注入個人聲音,改用 blog-writing-zh;本 skill 的 preflight 只準備交給下游 writer 的寫作 handoff,不會代替它寫正文。

運作方式

整個 skill 的判斷邏輯是一句話:先定調,再鎖住不能碰的,然後分兩條線各問各的問題,最後回頭驗事實有沒有掉。

你的文件是哪一類,決定第二種查不查

skill 會先判斷你的文件屬於哪一類:

例子 作者隱身
署名文體 部落格、電子報、觀點文、深度解讀、個人 essay
事務文體 docs、README、reference、spec、RFP、SOP、公文、簽呈、規劃書、建議書、計劃書、投資人信 不查

判不出來的時候一律當事務文體,並且會告訴你它這樣判了。

為什麼事務文體不查。 不是省事——是那個檢查在這些文件上必然答錯。它問的是「作者的判斷、經驗、比喻、口氣、節奏在不在」,而一份寫得好的簽呈這五樣本來就都不該在。這道關卡擋在最前面。

但這不代表你的公文沒事:作者隱身 被關掉,其餘規則照跑。一份簽呈範例會拿到:

作者隱身:不適用(事務文體)

命中五處:
・「在數位轉型的浪潮下…」        空降斷言開場
・「不僅…更…奠定堅實的基礎」    對比句式 + 萬用收尾
・「豐富多元」                    空話填充
・「值得注意的是」                解說導引腔
・「預期將顯著提升整體學習成效」  抽象claim缺交付

看到「不適用」四個字不要收工——它只關掉一項檢查,不是整份報告的結論。

提案類文體:需要判斷,不需要個性

規劃書、建議書、計劃書、投資人信歸在事務文體,但有一條規則對它們特別嚴:

立場真空——一份通篇「各有優缺點」、不推薦任何方案的建議書,會被標。它存在的目的就是給一個建議。

這條規則對 docs、README、spec、RFP、SOP 放行(那些文件本來就只是陳述資訊),對公文簽呈也放行(「擬辦」那一行就是它的表態形式),但對提案類不放行

分界線是:提案類需要作者的判斷,不需要作者的個性。所以 立場真空 會抓它,但 作者隱身 那組(口語破格、自創比喻、節奏起伏)不會——正式提案沒有這些是體裁正確。

--expect-author:什麼時候你需要它

平常你不需要。部落格自動就會查 作者隱身,不必特別要求。

會用到它的情境是:你的文件被歸成事務文體,但你認為它應該看得見作者。

用 --expect-author 檢查這份給客戶的規劃書

傳了這個旗標等於你宣告「這份稿子該有作者現身」,skill 就照這個判定跑,找到的缺席算真發現。報告會註明這個判定來自你的宣告而不是它自己的判讀,所以你發現下錯了可以直接撤回。

它不會反過來用——旗標只能把文件推向「要查」,不能關掉任何檢查。

判定流程:從讀稿到出稿

第 1 步的體裁判定不是暖身,它是整份報告的分歧點;第 4 步的兩條線是這個 skill 的核心,也是最容易被誤解的地方——它們問的是兩個獨立的問題,只有其中一條被體裁關掉。

                            稿子進來
                               │
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 1. 情境辨識                                                  │
│ 定調。判兩件事,兩件都一路影響到最後                         │
├──────────────────────────────────────────────────────────────┤
│ 語言 ─┬─ 中文 ────── zh 規則層                               │
│       ├─ 英文 ────── en 規則層                               │
│       ╰─ 中英混雜 ── 各段跑各自的層,術語留英文              │
│                                                              │
│ 體裁 ─┬─ 署名文體 ── 部落格、電子報、觀點文、essay           │
│       ╰─ 事務文體 ── docs、公文、簽呈、規劃書…               │
│                      判不出來時歸這類,並告訴你              │
╰──────────────────────────────────────────────────────────────╯
                               │
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 2. 保護清單鎖定                                              │
│ 動筆前先圈出不能碰的範圍                                     │
├──────────────────────────────────────────────────────────────┤
│ 價格・日期・承諾條款・具名引言・程式碼,                     │
│ 以及你刻意留下的口語破格                                     │
│ 圈起來之後,命中規則也只標「受保護」,不動                   │
╰──────────────────────────────────────────────────────────────╯
                               │
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 3. scope 判斷                                                │
│ 決定這次要改多大範圍                                         │
├──────────────────────────────────────────────────────────────┤
│ 片段修補(預設) / 段落改寫 / 整段重寫                     │
╰──────────────────────────────────────────────────────────────╯
                               │
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 4. 逐類改寫                                                  │
│ 兩條各自獨立的線,問兩個不同的問題                           │
╰──────────────────────────────────────────────────────────────╯
                               │
               ╭───────────────┴────────────────╮
               ▼                                ▼
╭─────────────────────────────╮  ╭─────────────────────────────╮
│ A:多了不該有的東西?       │  │ B:這篇看不見作者?         │
├─────────────────────────────┤  ├─────────────────────────────┤
│ 47 條規則,8 大類           │  │ 作者隱身 1 條               │
│ 任何體裁都跑                │  │ 5 個子訊號,滿 2 個才報     │
│ 事務文體不是免死金牌        │  │ 只有署名文體跑              │
│ 判斷單位:句子、片語        │  │ 判斷單位:整篇              │
│                             │  │ 只報缺席,永不代筆          │
╰─────────────────────────────╯  ╰─────────────────────────────╯
               ╰───────────────┬────────────────╯
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 5. 保真驗證                                                  │
│ 事實有沒有在改寫途中掉東西                                   │
├──────────────────────────────────────────────────────────────┤
│ 數字、日期、人名、承諾一字不差                               │
│ 回頭審第 4 步放行的判斷                                       │
│ 站不住 → 退回第 4 步改判                                     │
╰──────────────────────────────────────────────────────────────╯
                               │
                               ▼
╭──────────────────────────────────────────────────────────────╮
│ 6. 出貨前自評                                                │
│ 冷讀一次自己剛生出來的稿子                                   │
├──────────────────────────────────────────────────────────────┤
│ 抓改寫過程自己引入的新毛病                                   │
│ 例如把原本有起伏的語氣改平了                                 │
│ 最多重跑一次;第三次只是整份重寫一遍                         │
╰──────────────────────────────────────────────────────────────╯
                               │
                               ▼
              出稿:體裁判定 → 各類命中 → 保真核對

A 跟 B 的分野就是整份文件反覆在講的那件事:B 被體裁關掉的時候,A 一條都沒少。

三種成稿模式,另有一條手動前置 handoff。 直接手動啟動且沒有提供模式、確切檔案位置或草稿內容時,預設使用 preflight。 若只給確切檔案位置,先提示選「偵測」或「修改」;「把 AI 味拿掉」「改成人話」這類明確說法,才會直接進入 rewrite。 對已提供的草稿或貼上文字,未明確表達改寫意圖時,預設使用 detect

你怎麼問 模式 你拿到什麼
直接啟動,沒有提供模式、確切檔案位置或草稿內容 preflight 讀取目前 context,產出寫作契約、正向風格指引、證據邊界與資料缺口;不寫正文
「幫我把 AI 味拿掉」「改成人話」「幫我改寫」 rewrite 每個命中處(規則名+引文)、改寫後的全文、一份改了什麼的清單
「先標出來就好,不用改」 detect 命中處依 P0/P1/P2 分組列出,每條註明是硬傷還是判斷題;原文一字不動
已提供草稿時說「看一下這段」「掃描這份文件」或沒有明確要求改寫 detect 命中處依 P0/P1/P2 分組列出,每條註明是硬傷還是判斷題;原文一字不動
draft.md 這類確切檔案位置,但沒有指定模式 先提示選擇 顯示「偵測」或「修改」兩個選項;收到選擇前不稽核、不改檔
選擇修改,或明確說「直接編輯 draft.md」 edit-in-place 讀檔、只改命中的範圍、改完重讀一次、逐處回報改前改後;沒問題的段落原封不動
尚未有草稿,手動要求寫作前置 handoff preflight 讀取 brief、plan、來源、體裁與作者偏好,產出寫作契約與資料缺口;不寫正文。詳見 writing preflight

檢查清單:8 大類、47 條規則

規則不是一份平的清單,而是分成 8 類,每類抓一種不同的毛病:

類別 抓什麼 規則數 例子
內容類 字數花了,事實沒到 7 意義膨脹、空話填充、萬用收尾
語言句式 句型的形狀在代替內容做工 13 對比句式、翻譯腔、語體漂移
風格版面 用排版取代論述結構 6 破折號濫用、條列膨脹、表格誤用
溝通殘留 對話介面與工具痕跡留進文件 4 諂媚語氣、AI 工具殘留標記
事實與引用 借權威而非自己撐出來 3 模糊歸屬、幻覺引用與未查證主張
立場與開場 判斷該表態卻延後、迴避或缺席 7 空降斷言開場、立場真空、作者隱身
人工戲劇 憑空製造一個沒有後果的反應 3 罐頭式反應鏡頭、情緒宣告
打破第四面牆 稿子在講自己怎麼被生出來的 4 文件自述、自我背書、思考過程外洩、併稿接縫

每條規則命中時都會附規則名跟引文,所以報告裡看到的名字都能對回這張表——「這是哪一類的問題」通常比「這條規則叫什麼」更好記。

還有兩個跨類別的機制,不屬於任何一類,但影響全部:保護清單(鎖定什麼原樣保留)和 scope(判斷改多大範圍)。

對照表:體裁決定哪些規則查不查

把「哪種文件」跟「哪條規則」合在一張表看最清楚——同樣是「事務文體」,立場真空作者隱身 的態度並不一樣:

docs/README/spec/RFP/SOP 公文/簽呈 規劃書/建議書/計劃書/投資人信 部落格/電子報/觀點文/個人 essay
其他 45 條規則
立場真空 不查(本來就該中立陳述) 不查(「擬辦」一行就是表態) (提案不推薦方案,正是這條要抓的)
作者隱身 不查 不查 不查

看這張表就懂為什麼規劃書、建議書比公文更容易被標——它們在「不需要作者的個性」這件事上跟公文一樣,但在「需要作者的判斷」這件事上不一樣。--expect-author 只會把 作者隱身 那一列從「不查」推成「查」,不動其他三列。

常見誤解

你可能以為 實際上
公文/SOP 不用查 AI 味 45 條照查,只有 作者隱身 不查
報告寫「作者隱身不適用」= 這份沒問題 那只是一項檢查的結論,往下看還有沒有命中
要 skill 查「有沒有靈魂」得特別要求 部落格自動查,不用講
--expect-author 是把檢查開得更嚴 它只是宣告文體,讓 作者隱身 對這份文件生效
建議書沒推薦方案不算毛病 立場真空 會標——它就是為這件事存在的
它會幫我把文章改得比較有人味 它只拿掉不該有的,加不進來的東西留給你

相關技能

  • blog-writing-zh——從零寫文章或替稿子注入個人聲音時改用它;它負責加法(觀點、比喻、節奏),這個 skill 只負責減法。
  • avoid-china-writing——查陸用語與簡體殘留,跟去 AI 味是不同軸線;一份文件可能同時需要兩個 skill 各跑一輪。