humanizer
作者 softaworkshumanizer skill 可協助把帶有 AI 味的文字改寫成更自然的表達,同時盡量保留原意、語氣與作者聲音。它特別適合用於潤飾草稿、辨識常見 AI 寫作模式,以及在 Claude Code 中強化 Rewriting 工作流程的 humanizer 編修品質。
這個 skill 的評分為 78/100,對技能目錄使用者來說是相當值得收錄的項目:它為代理定義了清楚的編修任務,提供細緻的判斷準則,也附有足夠範例,整體上明顯比泛用提示更實用;不過實際採用時,仍可能因 repo/安裝來源不夠明確,以及缺少可直接執行的支援資產而增加上手阻力。
- 用途與觸發情境非常明確:專注於辨識並改寫常見 AI 寫作痕跡,讓文字更自然,同時盡量保留原意與語氣。
- `SKILL.md` 提供了相當完整的操作指引,包含多種已命名的寫作模式與編修原則,對代理而言比單純的「讓這段更像人寫的」提示更具體可執行。
- README 提供了實際使用範例與安裝路徑,讓使用者在安裝前就能先理解這個 skill 的用途與適用方式。
- README 的安裝說明指向原始 `blader/humanizer` repo,對於在 `softaworks/agent-toolkit` 中評估這份副本的使用者來說,可能會造成來源與安裝位置上的混淆。
- 這個 skill 僅提供文件說明,沒有附帶腳本或測試樣例,因此實際執行效果很大程度取決於代理是否能正確理解並落實較長篇的文字指引。
humanizer skill 概覽
humanizer skill 是一種編修型技能,專門把「AI 味太重」的文字改寫得更自然、更像真人寫的內容。它的做法不是亂修,而是辨識常見的 AI 寫作模式,再在不改變核心意思的前提下替換掉。對於已經有初稿、但希望成稿更成熟的人特別實用:像是部落格作者、文件團隊、行銷人員、創辦人、研究者,以及任何會用 AI 打草稿、但最終仍需要更可信輸出的人。
humanizer 實際上會做什麼
這個 humanizer skill 不是那種籠統的「幫我寫好一點」提示詞。它的職責更聚焦,也更實用:找出一眼就看得出是 AI 的寫作習慣,例如誇大重要性、空泛的宣傳語氣、重複的句型、模糊的歸因、破折號濫用、固定的「三段式」節奏、常見 AI 詞彙,以及沒有實質內容的轉承語,再把這些部分改寫成更清楚、更像真人寫的 prose。
最適合的使用情境
當你需要以下結果時,就適合用 humanizer:
- 在發佈前把 AI 輔助產出的草稿整理乾淨
- 把文字改得不那麼模板化、機器感沒那麼重
- 在不改動主要事實的情況下,讓文案更自然
- 改善文章、個人簡介、landing page、email、文件與評論類內容的輸出品質
它特別適合用在 humanizer for Rewriting 類型的任務:內容在技術上沒有錯,但文風死板、浮誇,或明顯看得出是模型產出的草稿。
哪些人適合安裝 humanizer
如果你經常要審 AI 寫出的文字,並且想建立可重複使用的流程,而不是每次都重新拼一段編修 prompt,就值得安裝這個 skill。對高頻率編輯者來說,它的價值會明顯高於偶爾用一次的輕量使用者。
相比一般 prompt,主要差異在哪裡
它的關鍵差異在於「具體」。這個 skill 不是靠模糊建議,例如「讓這段聽起來更像人寫的」,而是建立在一份明確的 AI 寫作訊號清單上。這會帶來更穩定的編輯一致性,也讓你更容易判斷問題到底出在哪裡:是語氣太 hype、抽象空泛、節奏不自然,還是缺乏真正的作者聲音。
安裝前多數使用者最在意什麼
多數在評估 humanizer 的人,通常會先想快速確認四件事:
- 它會不會保留原意?
- 它能不能貼近我想要的語氣?
- 它是只適合行銷文案,還是也能處理技術寫作?
- 它除了刪掉破折號和明顯 buzzword 之外,還有沒有更深一層的處理能力?
從 skill 本身的設計來看,整體答案大致是肯定的:它的目標是保留原意、維持指定 voice,而且不只是移除陳腔濫調,還會試著補回一些人格感。
重要邊界
humanizer 是編輯工具,不是事實查核器、研究系統,也不是 style guide 的替代品。如果原文本身在內容層面就有錯、很淺,或想法本身很空泛,humanizer 可以改善表達方式,但無法憑空補出真正的專業性。另一方面,若內容涉及法律、科學或合規等必須一字不動的正式措辭,也不應直接使用它來重寫。
如何使用 humanizer skill
humanizer 的安裝方式
repository 的 README 記錄了很簡單的 Claude Code 風格安裝方式。建議路線如下:
mkdir -p ~/.claude/skills
git clone https://github.com/blader/humanizer.git ~/.claude/skills/humanizer
如果你只想拿 skill 檔案本身:
mkdir -p ~/.claude/skills/humanizer
cp SKILL.md ~/.claude/skills/humanizer/
如果你看的是 softaworks/agent-toolkit 版本,實際生效的 skill 內容位於 skills/humanizer/SKILL.md。請先讀那個檔案,因為真正的運作規則與改寫判準都寫在裡面。
第一次使用前應先讀哪些檔案
如果你的目標是快速判斷值不值得安裝,建議依這個順序讀:
skills/humanizer/SKILL.md或SKILL.mdREADME.md
SKILL.md 會告訴你這個 skill 是怎麼思考的;README.md 則告訴你怎麼呼叫它。對大多數使用者來說,這兩份就夠了,因為這個 skill 不依賴額外 script 或 resource folder。
humanizer 的基本用法
安裝完成後,你可以直接把文字交給這個 skill,或請你的 agent 直接 humanize 某一段內容。實務上最有效的模式很簡單:
- 提供原始文字
- 說明目標語氣
- 指出哪些內容不能改
- 視需要補充受眾與格式
一個偏弱的請求會像這樣:
「Humanize this.」
一個更強的請求會像這樣:
「Use the humanizer skill on this product announcement. Keep all factual claims, shorten inflated language, remove obvious AI phrasing, and make it sound like a confident but not salesy founder update for existing customers.」
humanizer 需要什麼輸入
若你提供以下資訊,這個 skill 會表現得最好:
- 要改寫的完整文字
- 預期 voice:正式、白話、專家感、對話感、技術向
- 目標受眾:客戶、招募主管、開發者、高階主管、一般讀者
- 限制條件:保留事實、維持篇幅、避免俚語、保留 CTA、保留特定術語
如果沒有這些約束,模型雖然可能把文字修得更自然,卻也更容易在語氣或重點上跑掉。
把模糊目標變成可執行的 prompt
如果你真正想要的是「讓這段不要那麼像 AI 寫的」,最好把這句話翻成 humanizer skill 能執行的編輯指令:
Use the humanizer skill for rewriting.
Text type: About page intro
Audience: B2B buyers
Tone: credible, direct, restrained
Keep: all company facts and product names
Fix: hype, generic abstractions, repetitive rhythm, obvious AI transitions
Avoid: em dashes, empty superlatives, fake warmth
這樣效果更好,因為它同時明確指出「哪些要保留」與「哪些要移除」。
humanizer for Rewriting 的最佳工作流程
一個穩定可靠的流程通常是:
- 先正常寫初稿
- 找出最有機器感的段落
- 先只對那一段跑
humanizer - 檢查有沒有偏離原意
- 如果需要,再用更嚴格的指示處理剩下段落
- 最後再做一次通篇一致性檢查
一次整份文件一起跑並不是不行,但分段編修通常更容易控制,也比較乾淨。
這個 skill 背後到底在抓什麼
從 repository 的內容來看,humanizer 會掃描一些特定模式,包括:
- 被誇張放大的象徵意義或重要性
- 偽裝成中性描述的宣傳性語言
- 流於表面的
-ing式分析 - 模糊不清的歸因
- 過度使用破折號
- 公式化的三連句
- 常見 AI 詞彙
- 否定式平行結構
- 太多連接型轉承語
知道這一點很重要,因為你可以先在 prompt 裡標記可能有問題的地方,讓改寫更有針對性。
如何保留 voice,而不是把文字修扁
任何 humanizer 類工具都有一個常見陷阱:最後產出變成一種很無聊、很「乾淨」的標準文。這個 skill 有明確在避開這件事——它希望補進個性與靈魂,而不是只刪掉 AI 痕跡。想幫它做得更好,你可以直接指定聲音來源:
- 「sound like a practical staff engineer」
- 「sound like an editor, not a marketer」
- 「sound like a thoughtful founder memo」
- 「keep some wit, but no sarcasm」
比起泛泛要求「自然一點」,這種 voice 指令通常有用得多。
什麼時候該用段落級,什麼時候該用句子級編修
如果整段都瀰漫著假裝有推進感的語氣,或整體 framing 很空,就用段落級重寫。若事實本身沒有問題,只是幾個句子或片語不自然,那就做句子級處理。若你想把風險壓到最低,可以先請 humanizer skill 標出可疑句,再只改那些地方。
第一輪輸出後,該怎麼做有效 review
第一輪改完後,不要只問「有沒有比較好?」更應該問:
- 有沒有任何事實被改掉?
- 語氣是不是變得太隨便,或太精緻?
- 文字有沒有失去原本有用的具體性?
- 句型是否仍然重複?
- 讀起來像不像一個真的有觀點的人寫的?
這個 review loop,才是讓 humanizer 從一次性重寫工具,變成真正有價值的編輯流程的關鍵。
humanizer skill 常見問題
如果我本來就會下「sound more human」這種 prompt,humanizer 還值得安裝嗎?
通常值得,尤其當這是你反覆遇到的問題時。一般 prompt 確實能去掉一些明顯痕跡,但 humanizer 提供的是一套更可重複的編修視角,建立在已命名的失敗模式上。這通常能減少隨機改寫,也更能保住原本想表達的意圖。
humanizer 對新手友善嗎?
友善。這個 skill 很容易呼叫,因為核心任務相當直接:給它文字,再給目標 voice。但新手最好還是至少補上兩個限制條件——哪些內容不能變、想要什麼語氣——不然輸出很容易失焦。
humanizer 可以用在技術寫作嗎?
可以,但要小心使用。它很適合修 docs、說明文、release notes、內部更新這類內容,尤其當它們讀起來太膨脹或太像機器時。對技術內容而言,務必要明講保留術語、精確性與結構,否則它可能把本來該精準的文字修得過度平滑。
什麼情況不該用 humanizer?
以下情況應避免直接用 humanizer:
- 法務或政策文字必須逐字精確
- 你需要的是事實查核,而不是改寫
- 草稿問題在於想法太弱,不是文風太 AI
- 原文其實已經有明顯的人味,只需要一般 copyediting
這些情況下,用範圍更窄、更保守的編修方式會更安全。
humanizer 只是修破折號這類表層問題嗎?
不是。humanizer skill 的價值不只是在清理標點。它也會處理被誇大的 framing、空泛的轉場、人工感過重的結構、模糊主張,以及缺乏 voice 這些更深層的問題。也因此,它有機會實質改善那種「很乾淨但毫無靈魂」的草稿。
這個 skill 只適合行銷文案嗎?
不是。行銷文案確實是常見使用場景,但它同樣適合 essay、個人簡介、documentation、評論、newsletter 與 outreach 類寫作。關鍵前提是:你手上已經有一份要精修的文字。
humanizer 跟人工編輯相比如何?
當細膩度很重要,而且真正的編輯很懂受眾時,人工編輯仍然更好。humanizer 最適合扮演快速第一輪整理:先把那些明顯的機器痕跡清掉,再交給人工 review。它能縮短清稿時間,但不能取代編輯判斷。
如何改進 humanizer skill 的使用效果
給 humanizer 一個清楚的編輯目標
想提升 humanizer 成果,最快的方法就是不要再只說「更像人寫的」,而是直接說清楚「像哪種人」。把角色、語氣與受眾講明白。像「Plainspoken technical lead」這種指示,幾乎一定會比「natural and engaging」更有效。
用明確護欄保住原意
如果事實準確性很重要,就直接寫清楚:
- 「Do not add claims」
- 「Keep all dates, figures, and product names」
- 「Do not change the recommendation」
- 「Preserve paragraph order」
這些指令能降低最常見的採用阻力:擔心改寫會扭曲內容本身。
先點出你已經看見的問題模式
如果你已經看得出問題在哪,就直接告訴這個 skill。例如:
Use the humanizer skill. The current draft sounds AI-written because it overstates importance, uses empty transition phrases, and repeats the same sentence rhythm. Rewrite for a skeptical professional audience. Keep the meaning and shorten by 15%.
這比把問題完全交給模型猜,要有效得多。
品質要求高時,先要求診斷再改寫
如果是敏感文案,建議用兩步驟流程:
- 先辨識文本中的 AI 式寫作模式
- 再依照這些問題進行改寫
這樣的輸出更容易信任,因為你能對照「診斷結果」與「改動內容」,而不是收到一份黑箱式重寫。
要注意的常見失敗模式
使用 humanizer skill 時,最常見的失敗模式包括:
- 把文字修成一種過度通用的「標準好文」
- 把原本應該保留的強烈主張修弱了
- 把正式內容改得太口語
- 在刪掉壞轉場的同時,也把有用的轉場一起刪掉
- 改掉了強調重點,而不只是改掉風格
這些問題通常不是 skill 不行,而是限制條件還不夠明確。
在跑 humanizer 前,先補強太弱的草稿
如果原始草稿通篇都是抽象說法、沒有具體細節,那 humanizer 的發揮空間本來就有限。先補進更具體的材料:事實、例子、名稱、結果、利害關係。比起一堆空泛填充語,真實素材本來就更容易長出像人寫的文字。
用並排比較,不要直接整段覆蓋
不要自動把原文整段貼掉。請把原文和改寫版一起看,確認:
- 哪些內容被刪掉了
- 哪些地方變得更具體
- 情緒語氣是否仍然合適
- 現在的文字是否真的像你的刊物或團隊會寫的東西
這種對照,是你下次更會用 prompt 駕馭 humanizer 的最快方法。
用更窄的後續指令迭代
如果第一輪已經接近想要的結果,不要整份從頭再 humanize 一次。改用更窄、更有方向性的 follow-up,例如:
- 「Keep this version, but make it less polished」
- 「Preserve the new clarity, but restore some authority」
- 「Cut the remaining marketing tone」
- 「Make the second paragraph sound more like an experienced operator」
這種小幅度導向,通常比整份重新跑一次更有效。
在 humanizer 之上建立自己的 house style
長期來看,humanizer 最好的用法,是把它當成可重複使用的編輯層。把它和你自己的 style notes 配在一起:禁用詞、偏好的語氣、閱讀難度、對受眾的預設。這會讓它從一個泛用的清稿工具,變成你寫作流程中可穩定複製的一部分。
搞清楚真正的成功指標
好的 humanizer 輸出,不只是「看起來比較不像 AI 寫的」。它應該讀起來像是一個有判斷的人,帶著明確意圖寫出來的。如果結果只是更乾淨,卻更沒生命力,那就代表你該把 voice 指令收得更緊,再跑一次。這正是單純去 AI 味,和真正把文字寫得更好之間的差別。
