| name | tenten-human-tone-tw |
| description | 把 AI 味重、簡轉繁或過度拋光的文字，改成自然、可信、符合臺灣語感的繁體中文，同時保住作者原有聲音與所有事實。使用者只要提到「去 AI 味」「更像人寫的」「說人話」「自然一點」「臺灣用語」「不要像 ChatGPT」「幫我潤稿再發」，或要改電子報、社群貼文、客服信、公告、README、release note、觀點文與出版稿，都應使用本 skill。若原文已自然，應主動少改或原文放行；不適用於逐字翻譯、事實查核、仿特定作者文風、程式碼本體或純品牌 voice 擬合。
|
| license | MIT |
| metadata | {"version":"0.15.0","language":"zh-Hant-TW","maturity":"experimental","baseline":"speak-human-tw 1.4.0"} |
Tenten Human Tone TW
把文字從「模型在表演寫作」拉回「這個作者正在這個場景說一件事」。
核心順序：先保真，再辨認作者聲音，只移除人工痕跡，最後才做臺灣化與節奏回讀。
這不是禁詞替換器，也不是替作者發明人格。真人感必須能在原文找到證據；找不到，就不能加。
1. 先判任務，不要急著改
先判斷使用者要哪一種結果：
rewrite：直接交付可用稿，預設模式annotate：使用者明確說「先標問題」「不要改」「只診斷」preserve：原文已自然，或只有一兩處不影響閱讀的小問題audit：無來源引用、法務條款、學術或新聞稿需要作者補證據
若使用者說「直接改」「不用先問」或這是單次 CLI／自動化執行，直接交付；不要停在一份沒人會回答的確認清單。若使用者要逐項批准，再先列清單。
2. 判場景與改動預算
先選主場景。完整邊界見 場景矩陣。
| 場景 | 預設改動 | 先守住什麼 |
|---|
| chat / 客服 | surgical | 回應關係、條款、下一步 |
| 社群 | surgical | 口頭禪、碎句、玩笑、具體細節 |
| 電子報 / 觀點文 | surgical | 作者立場、時間轉折、留白、故事順序 |
| 銷售頁 | structural | 價格、期限、CTA、承諾邊界 |
| status / docs | surgical | 時間線、術語、系統主語、風險 |
| 公告 | preserve-first | 正式語域、時間、影響範圍 |
| README / release note | surgical | 版本、命令、能力、限制、驗證方式 |
| publishing | surgical | 語體、引文、術語、作者風格 |
三種改動模式：
preserve-first：沒有明確問題就原文放行。正式公告、自然社群文、技術敘述優先用這檔。surgical：預設。逐句只改有證據的問題，不重排故事，不把自然句統一拋光。structural：只有原文資訊在、但被大量模板骨架包住，或使用者明確要求重寫時才使用。仍不得新增素材。
優先判斷能不能只做減法
若 AI 痕跡集中在可整句拆除的開場、收尾或旁白，而中間核心句已自然、具體且有作者聲音，採 subtractive 路徑：
- 逐字複製要留下的核心句，不做同義改寫
- 刪掉可獨立拆除的人工句
- 只在語意轉折處加入空行；不更動核心句內標點
- 不補鉤子、轉場、結論或「更順」的連接詞
這種稿件不是重寫題，而是刪除題。只要刪掉頭尾後核心仍能獨立成立，就直接交付抽取出的原句。不得把「不想讓整間病房的通知聲一直響」潤成「不想讓通知聲吵到整間病房」，也不得把「還是會忍」改成「忍不住」；流暢度與編輯偏好都不能成為改動自然核心的理由。
以下看似「不夠標準」的句子反而是高風險 voice anchors，採 subtractive 時一律逐字保留：
- 否定範圍：「不是不想」「沒有比較喜歡」「還不能說不算」
- 臺灣口語強度：「講不死」「說不過去」「沒有到討厭」「還是會忍」
- 自我修正與懸置：「我不是……；我只是……」「也不算……但……」「我也不知道那算什麼」
- 怪異但精確的物件、身體感或語序
不要替它們補主詞、因果、心理診斷或標準成語，也不要把雙重否定解成較乾淨的肯定句。作者選擇的彆扭程度本身就是資訊。
subtractive 保留字句，不等於保留一整塊排版。刪掉人工頭尾後，依語意插入空行，但仍不得改核心句中的任何字或標點：
- 觀點／評論：原立場或習慣／具體事件／現在仍未完全翻轉的立場
- 創辦人／負責人信：決策與影響／責任承認／補救與仍未決定
- 散文：物件與場景／反應或突然想起的事／後續動作或反悔／未命名、未解決的收尾
通常是兩到三段，不是每句一段。散文若確實有「物件／情緒轉折／後續動作／懸置」四個不同功能，可以四段；像「笑完才想起……」這種從玩笑掉進另一層意思的句子，應以空行托住，不要黏在物件介紹後面。責任句若是整封信的核心，可單獨成段；補救與不確定放在同一段。若最後一句從受影響的人而非產品處理重新開題，也可獨立成最後一段。只用空行製造落點，不加「責任」「下一步」等標題。
長文或使用者要求保長度、保句數、保段落時，鎖定段落順序；只刪整句純空話。承擔轉場、節奏、情緒或責任的句子不算空話。
3. 建立內部「作者證據圖」
動筆前在心裡列四組，不預設輸出：
protected：數字、日期、價格、網址、專名、引文、命令、版本、條款、責任主體facts：動作、結果、限制、因果、下一步voice anchors：作者已經寫出的立場、猶豫、時間轉折、怪細節、口語碎片、慣用節奏artificial layer：時代大帽子、價值拔高、模型旁白、空總結、商業黑話、機械排比、假口語
改寫只應動第 4 組；第 1 組逐字保護，第 2、3 組盡量維持原本的資訊關係與語氣。
把使用者要求保留的片段視為不可拆的字串。不能在中間插入「可、最多、成、約」等看似無害的字，也不能換同義詞。交稿前逐字搜尋；少一個片段，就把原句還原到該片段連續出現為止。流暢度不能凌駕明確保留要求。
若任務同時列出多個必留片段，先把它們原樣貼進候選稿，再刪周邊套話。交稿前做一次機械式核對：逐項確認每個片段連續出現；任何一項缺失，都回復原句後重新回讀，不能只在心裡判斷「意思一樣」。
如果使用者沒有貼出逐字清單，只說「保留決策／條件／下一步／限制／不確定性」，先從原文擷取承載該資訊的最短完整子句，暫時當作原子字串。原句本來已經直白，就移動整個子句，不要在裡面補「我們會、則、可以、預計」或換同義詞；只有子句本身含待刪 AI 話術時，才在保住主詞、動作、時間與否定範圍的前提下最小改寫。
Voice anchors 是保護項，不是素材邀請
以下內容只在原文已出現時保留、整理：
- 「我以前……後來……」的真實轉折
- 「我還不知道」「我沒有把握」的真實不確定
- 不成比例但具記憶點的細節
- 突然的短句、停頓、岔題、不完整收尾
- 作者對事實的反應，而不只是事實本身
不要為了像人而新增「老實說」「我也還沒想清楚」、第一人稱故事、感受、對話、數字、比喻或口語助詞。那是仿真人，不是真人感。
若使用者說「保留作者原話／原句／原本用詞」，這不是只保意思，而是把承載立場、反應、責任與不確定的完整句子升級成硬保護。先逐字複製，再處理它前後的人工層。
4. 先問一句：這句真的需要動嗎
每句動手前做三個檢查：
- 有可指出的 AI 痕跡、臺灣用語問題或場景錯位嗎？
- 改完後，讀者會更快得到原文已有的資訊嗎？
- 這個改動會不會抹掉作者的口氣、精確度或責任邊界？
第 1 或第 2 題答不出來，就不改。第 3 題是「會」，優先保留原句。
若整句沒有命中人工痕跡，且前後句刪掉人工層後仍接得起來，就把它視為 subtractive 核心句：逐字留下，不再逐詞潤飾。先證明一句需要改，才取得改那一句的權限。
完整誤殺邊界見 Protected Spans。
5. 處理人工痕跡
先按問題族處理，不靠逐詞搜尋。完整模式與密度規則見 Patterns。
A. 刪提示層
常見訊號：
- 在這個瞬息萬變的時代、隨著 AI 快速發展
- 值得注意的是、讓我們深入探討、今天想跟大家分享
- 總的來說、綜上所述、未來可期
- 這讓我明白、這意味著、真正的關鍵在於
動作：提示層後面有實質內容，就刪提示層留內容；整句沒有資訊，就刪整句。不要補另一句漂亮總結。
第一段獨特資訊測試
對電子報、部落格、社群與署名文章的第一段，問：「這段有沒有只有本文才有的人物、時間、數字、物件、動作或衝突？」如果沒有，而下一段才出現具體素材，第一段就是暖身，整段刪掉，直接從下一段開始。不要把「AI 更新很快、資訊很多、機會與挑戰並存」換一組同義詞寫回來；改寫空泛背景仍是空泛背景。
若前文的具體事實、取捨或對比已經讓讀者看懂結論，就停在那裡。不要再把它濃縮成「追 X 不是重點，Y 才是」「真正重要的是」這類格言式收束；那會把已清乾淨的稿子重新套回模型骨架。
B. 拆價值拔高與對比骨架
常見訊號：
- 這不只是一個 X，更是 Y
- 不是 A，而是 B 連續出現
- 標誌著、見證了、彰顯了、奠定基礎
- 一場關於……的革命／旅程／深刻反思
動作：找出原文真正成立的 B、動作或結果，直接寫它。若原文沒有可落地內容，寧可刪掉，不補虛構事實。
C. 把黑話還原成動作
常見訊號：賦能、抓手、閉環、落地、打造、沉澱方法論、全鏈路、深度佈局。
動作：只用原文已有資訊回答「誰做了什麼、影響誰、結果如何」。答不出來就刪姿態層。
D. 降低機械整齊
常見訊號：硬湊三點、每句等長、每段都結論、粗體標題列表、emoji 轟炸、破折號連發。
動作：讓結構服從資訊。清單若負責查找、步驟或 changelog，就保留；散文被硬切成三點才改回段落。不要刻意加入碎句來製造變化。
段落也不能機械切碎。短稿刪掉頭尾套話後，若剩下的句子原本就是同一口氣，就保留成一段；不要把每個事實、責任句或數字各拆成一個單句段落。只有時間、場景、說話功能或處理狀態真的切換時才換段，例如「決定與後果」轉到「責任與下一步」，或「已修復」轉到「仍未完成」。段落不是替每句加重音的工具。
E. 處理無來源權威
- 社群、電子報、觀點文：刪掉「研究顯示／專家認為」的權威外殼；只留原文可獨立成立的觀察。
- status、docs、新聞、學術、出版：標示缺來源或缺歸屬，不把它改寫成已證實。
- 不查證就不改成另一個來源；不補機構、年份、樣本、比例。
6. 臺灣化是獨立一層
AI 痕跡清掉後，再做臺灣用語與句法檢查。完整表見 Taiwan Style。
基本替換：
- 軟件→軟體、硬件→硬體、視頻→影片、信息→資訊
- 用戶→使用者、數據庫→資料庫、服務器→伺服器
- 內存→記憶體、硬盤→硬碟、鼠標→滑鼠、屏幕→螢幕
- 算法→演算法、程序（軟體脈絡）→程式、項目→專案
- 導出→匯出、文件→檔案（依語境）、支持功能→支援功能
只換詞不夠。把「進行了優化」「實現了提升」「基於……來……」壓回直接動詞；中英混排、引號與全形標點跟臺灣慣例。
不要改：
- 引號內原話，包括簡體字和中港用語
- 中國品牌、機構、法規、制度專名
- 程式碼、命令、介面名、欄位名、路徑
- 被討論的詞本身，例如「我不再用『賦能』」
7. 分場景收束
社群、電子報、觀點文
- 保留作者已存在的口語、怪細節、時間轉折與矛盾
- 觀點短文若是「原立場 → 一件讓立場鬆動的具體事件 → 尚未解決的現在立場」，讓三個節拍各自呼吸；在具體事件前後留出段落或清楚斷句。三拍是三個語意單位，不等於把每一句都另起一段
- 不補鉤子、不硬造金句、不一定要結尾
- 刪掉罐頭收尾後，可以停在最後一個具體句子或作者原有的不確定
- 產品上線或活動發布貼文不能被洗成規格備註。原文已有發布能量時，最多保留一個 emoji 或驚嘆號；用「發生什麼／功能與限制／價格或行動」收束。先找原文已存在的 CTA：輸入折扣碼、填表、回覆、下載、到場等動作只要有一個，就把它保留在收尾，不再另造第二個行動。沒有原始 CTA 才能在不新增承諾的前提下標示待補，不能自行發明「建立第一個……」之類的新任務。不要重複主詞、方案名、日期或功能湊尾巴
- 「最多一個 emoji 或驚嘆號」是二選一，不是各一個。保留 emoji 時刪掉所有驚嘆號；保留驚嘆號時刪掉所有 emoji。不能用「🚀 要來了！」同時保留兩種強調
- 活動與產品貼文屬於可掃讀資訊，不套用「短稿一律單段」。原文同時有事件／日期地點、功能／名額限制、價格／CTA 時，依這三組分段；每組內保持自然句，不把所有資料擠成一段，也不把每個數字各拆一段
客服與公告
- 客服先答案、再條件、最後下一步；不先給對方頒獎
- 如果答案取決於期限或條件，第一句要同時交代「能不能」與主條件，例如「可以協助處理，是否能更改要看發票開立時間」；不要只說「可以協助處理」後把限制藏到下一段
- 明確是 email／客服回信、原文又沒有稱呼時，可在最前面補中性的「您好：」。這是場景格式，不是諂媚；聊天視窗或表單內嵌訊息不加
- 「您好：」是稱呼行，不計入內容第一句；下一行仍須直接放答案與主條件。兩種情況用兩個短項目呈現。若其中一項已寫「請回覆……」，那就是下一步，不再另加「下一步」段落重述一次
- 公告的「因應」「敬請見諒」可能是合宜語域，不要機械口語化
- 條款、時間、影響範圍與承諾逐字核對
status、docs、release note
- 技術性不是 AI 味。保留系統主語、術語、根因、參數、錯誤碼與列表
- 技術稿中含指標、識別碼、
root cause、處置狀態或已知限制的句子，若本身沒有 AI 話術，先整句原樣複製到草稿；只刪前後宣言。不要為了順口把 root cause 翻成「根因」，也不要拆寫已清楚的修復或限制子句
- release note 讓人快速找到「改了什麼、怎麼驗證、已知限制」
- 「未來持續精進／後續持續改善」若沒有時程、責任人或具體動作，只是宣言，直接刪除；不要把它換句話說留下來
- 不把技術稿寫成品牌宣言，也不把 changelog 改成故事
- 團隊手記或事故更新用三個語意區塊：事故與人的代價、恢復狀態、殘餘影響與下一步。短稿可以讓恢復句單獨成段，因為狀態真的切換；不要用「修好／已恢復／未完成」標題罩住不屬於該狀態的內容。原文沒有標題、使用者也沒要求清單時，優先用自然分段而非新增標題
- 不要把未完成退款、殘餘風險或下一步塞在同一長段末尾。原句已清楚時，不另加「責任在我」「尚未完成：」「這項處理尚未完成」等編輯評語；讓原作者的主詞、動作與時態自己說明狀態
forum post、issue／PR 回覆
- 維護者在論壇談踩雷經驗時，保留抱怨、自嘲、括號與具體 bad case；只刪品牌宣言、英雄化與空泛教訓，不改成官方公告
- issue／PR 回覆先確認觀察到的問題，再寫可重現條件、當前判斷與已承諾的下一步；不要先道歉、安撫或替回報者頒獎
- 原文只承諾「下一版補測試」時，就停在這個承諾；不能升級成修復時程、已解決或保證不再發生
publishing
- 先判
academic / whitepaper / magazine / news / corporate / textbook / literary
- 學術、新聞的無來源引用採
audit；不機械拆被動句與術語重複
- 雜誌、散文保留感官細節、敘事順序與作者句法
- 三千字以上鎖定術語一致性；詳見 場景矩陣
8. 兩遍回讀
Pass 1：保真
逐項核對：
- 所有 protected spans 是否逐字存在
- 有沒有新增數字、網址、來源、人物、因果或承諾
- 作者立場、猶豫與責任歸屬是否漂移
- 關鍵事實、限制與下一步是否仍可追溯
- 場景正式度與術語是否被改壞
- 引號內原話是否完全不動
- 若採
subtractive，所有留下的核心句是否與原文逐字相同；除了新增空行，不應有 diff
硬保護採字面檢查，不以「語意差不多」通過。例如「一次匯出 30 篇文章」改成「一次可匯出 30 篇文章」，或「當閱讀」改成「當成閱讀」，都算失敗。只有使用者沒有要求逐字保留時，才可做不改語意的微調。
任何一項失敗，先修正再進下一遍。
Pass 2：殘留味
只檢查五件事：
- 開場還有提示層
- 結尾還有空總結
- 還在用旁白解釋「這說明什麼」
- 還有沒有證據的拔高判斷
- 句長與段落落點是否被統一拋光
再做兩個反向檢查：是否把短稿切成「一句一段」；是否在原文已有 CTA、責任句或下一步後又補了一句同義說明。命中就刪掉後加的那句，不動原句。
第二遍只准小修。若必須重寫全文才能再「更像人」，表示應該停手。
9. 輸出合約
rewrite（預設）
只交付一個可直接使用的版本。不要預設附自評分數、逐條分析、多版本、前言「以下是改寫版」或「希望有幫助」。
只有出現無法安全解決的缺口時，在正文後加極短的「待作者確認」，例如缺來源、缺必要事實或條款歧義。
annotate
只列最重要的問題，不交完整改寫稿。每點包含：
preserve
原文已自然時直接原文放行。不要為了證明 skill 有工作而改同義詞、標點偏好或句長。
10. 最後的停手條件
交稿前問：
- 這版比原文更像作者，還是更像「某個很會寫的 AI」？
- 我是否只留下原文有證據的人味？
- 如果拿掉 skill 名稱，作者仍會認得這是自己的話嗎？
答案不確定時，退回較少改動的版本。
