| name | shuorenhua |
| description | 檢查和清理中英文文本裡的 AI 套路，並把稿件對齊臺灣用語與出版慣例。適用於「去 AI 味」「說人話」「自然一點」「別像模板」「別像 ChatGPT」「先標問題」「臺灣用語檢查」「清掉中國用語」「繁體潤稿」「改成能直接發的稿子」這類改寫和審稿需求；按場景控制力度，同時保留事實、術語、語域和責任主體。 |
說人話
把文本從「像模型在表演寫作」拉回「像具體的人在當前場景下表達」，並讓繁體中文稿件讀起來像臺灣人寫的。
這份 skill 不是敏感詞替換器，也不是反技術、反抽象、反專業。它的目標是減少模板感、表演感和語域漂移，清掉混入繁中稿件的中港用語，同時保住事實、術語和責任主體。
When to use
在下面這些需求裡使用：
- 使用者明確說「去 AI 味」「說人話」「自然一點」「別像模板」「別太像 ChatGPT」
- 需要改寫中文或英文的
chat、status、docs、public-writing、publishing
- 需要檢查繁中稿件的臺灣用語（中港用語混入、簡轉繁錯字、標點不合出版慣例）
- 需要先判斷文本該輕改、中改還是重改
在下面這些需求裡不要硬套：
- 使用者要逐字翻譯、保留原文風格、仿官方模板或仿特定品牌 voice
- 文本主要是程式碼、日誌、命令、設定、介面名、錯誤訊息
- 使用者要的是事實查核，不是風格改寫
- 稿件明確要以簡體中文或中國大陸用語發布（此時只做去 AI 味，跳過臺灣化）
Core stance
- 去 AI 味，主要處理的是模板感、收束腔、虛假主語、語域混搭和表演性技術腔。
- 臺灣化是獨立的一層：一篇文本可以沒有 AI 味但滿是中港用語，也可以用語道地但整段套話。兩層都要看，互不取代。
- 保留技術性。專業詞、系統主語、事後檢討（postmortem）用語、PRD／release note 中的術語預設可保留。
- 優先保資訊，再談風格。任何改寫都不能新增事實、刪核心事實或改變責任主體。
- 不用機械同義詞替換表。預設可以刪句、併句、降調、換主語、去總結式收尾；如果進入
in-place scope，就只做句內改寫。
- 短語表預設只列代表項，不追求窮舉所有變體。遇到新口癖，先按現有模式歸類，再決定要不要補詞。
Execution order
按固定順序做，不要跳步：
- 判場景：
chat / status / docs / public-writing / publishing
- 查禁改項：先劃
protected spans，看有沒有必須保留的術語、系統主語、引用原文、命令或正式語體
- 臺灣化檢查：比對中港用語與簡轉繁易錯字；輸入是簡體時預設轉為繁體（臺灣用語），引用原文與程式碼維持原字形。完整對照表見 臺灣在地化
- 判 Tier：
Tier 1 / Tier 2 / Tier 3，按問題命中強度判斷，不要把 Tier 當作改寫力度
- 再判檔位：
minimal / standard / aggressive
- 判 scope：
structural / bounded / in-place，判斷這次能刪到什麼程度——自由刪併重排、只把整句空話列進刪除清單、還是一句都不刪
- 先執行本檔案裡的最小規則；只要環境裡能讀
references/，預設繼續按問題類型補看 Protected Spans、Positive Style Contract、微操作手冊、結構反模式 和相關短語表；如果目標是「改完能直接發」，或文本明顯屬於 README、release note、論壇文、issue 回覆，再補看 Scene Packs 和 改寫示例；如果是出版稿件，補看 出版語體 和 標點排版規範
- 回讀拆成兩步：先做保真回讀（含臺灣化回讀），再按需做殘留味回讀
- 輸出：預設只給單一推薦版本；使用者明確要求「先標問題，不改寫」時切到
annotation mode；publishing 場景另附品質評分
執行第 7 步時，先按「模式」處理，再按「詞條」補漏：
- 同一類調試腔、暴力動作腔、主動出擊腔、總結提示腔，預設按同一模式處理，不要求逐詞命中
- 只有當新說法改變了誤殺邊界，或明顯不屬於現有模式時，才把它當作新增詞條處理
1. Scene detection
先判主場景，再處理局部問題。混合文本只保留一個主語域，其他語域只在必要資訊層面留下。
chat
訊號：
- 短回覆、日常對話、協作溝通、留言、即時回饋
- 允許口語，但不該端著說話
預設檔位：minimal
status
訊號：
- 站立會議更新、進度同步、檢討摘要、報告式狀態說明
- 重點是時間線、動作、結果、風險
預設檔位：minimal 或 standard
docs
訊號：
- 操作文件、技術說明、API 說明、FAQ、事後檢討（postmortem）
- 重點是可檢索、可重現、術語穩定
預設檔位：minimal
public-writing
訊號：
- 粉專貼文、IG、Threads、Dcard、部落格、方格子、Medium、對外文章、觀點寫作
- 重點是語域一致，不要裝「有洞見」
預設檔位：standard
publishing
訊號：
- 書稿、期刊論文、白皮書、雜誌專欄、新聞評論、企業內刊、教科書、文學散文
- 重點是送印水準：語體正確、臺灣用語、標點合規、術語全篇一致
預設檔位：standard；長稿（約 1000 字以上）預設 bounded scope
進入 publishing 後，先判七種語體之一（academic / whitepaper / magazine / news / corporate / textbook / literary），使用者沒指定時先詢問，無法詢問時以文本特徵推斷。各語體的門檻、60 分品質評分和術語一致性鎖定見 出版語體；標點與排版套用 標點排版規範。
更細的下限限制見 場景禁改表。
Scene Packs
如果文本本身命中下面任一子場景，不依賴使用者是否明說，也不受主場景初判限制，都要補看 Scene Packs：
README：出現專案介紹、快速開始、安裝方式、功能列表、README intro 等訊號時，第一屏要說清「這是什麼、給誰用、解決什麼問題」release-note：出現版本標題、Release Highlights、Added / Changed / Fixed / Tested、changelog 列表等訊號時，列清本版變更、驗證和限制，不寫發布宣言forum-post：出現 PTT / Dcard / Hacker News / 社群發文 / 發文檢討等訊號時，保留維護者的真實觀察和社群語氣，不改成公告issue-reply：出現 issue / PR 回覆、bad case、重現、下一版補 benchmark 等訊號時，先確認問題和下一步，不做客服式安撫
子場景只負責發布目的和語氣收束，不覆蓋 protected spans、Tier、檔位和回讀規則。完整策略見 Scene Packs。
2. Single-file fallback rules
只載入 SKILL.md 時，也必須能完成基礎改寫。下面這些規則預設直接生效：
- 刪開場套話、諂媚和後設評論：例如「值得注意的是」「讓我來為你解釋」「希望這對你有幫助」「Great question!」
- 刪空總結和收尾腔：例如「綜上所述」「歸根結底」「本質上」「At the end of the day」
- 處理二元對比骨架：「不是 X，而是 Y」「與其 X，不如 Y」多數刪前半句，直接說 Y
- 處理無來源引用：「研究表明」「數據顯示」「studies show」「experts say」預設按場景選擇
rewrite-safe 或 audit-only；只有使用者明確要保留原論證骨架時才用 rewrite-with-placeholder；不要補虛構來源
- 把商業黑話和表演性技術腔改回普通動作：例如「賦能」「抓手」「閉環」「收窄」「兜住」「落盤」「leverage」——這批詞在臺灣稿件裡同時是中國職場用語混入，屬於雙重信號，清得更徹底
- 遇到過度接住、替使用者做心理判斷或身分認證式誇獎：例如「你不是敏感」「你只是太久沒被穩穩接住了」「你問到了問題的核心」「頂尖研究者的素養」，預設刪姿態層，改回低承諾回應或具體判斷；不要硬演「我懂了」
- 發現翻譯腔時，優先縮短主語和動作，少用長定語鏈、被動堆砌、「基於……」「透過……來……」
- 臺灣化基礎替換（完整表見
references/taiwan-localization.md）：軟件→軟體、視頻→影片、信息→資訊、質量→品質、數據庫→資料庫、網絡→網路、用戶→使用者、服務器→伺服器、屏幕→螢幕、鼠標→滑鼠、內存→記憶體、硬盤→硬碟、算法→演算法、項目→專案、程序（軟體脈絡）→程式
- 標點基礎規則：引號用「」（巢狀用『』），書名用《》、篇名用〈〉；破折號「——」與刪節號「……」各佔兩個全形字位；中英之間空一格
- 誤殺防護優先：引用原文、命令、介面名、欄位名、日誌、錯誤訊息、系統主語、技術報告術語預設保留
- 中英混排句中的英文詞按當前句子的實際語義判斷，不機械套英文詞表
單檔模式只是後備，不是完整模式。只要環境裡能讀 references/，預設就繼續補看對應檔案；只有在 system prompt 真的只給了 SKILL.md 時，才退化為只按本檔案做基礎清理。
Unsourced citation modes
處理無來源引用時，固定只在這 3 種模式裡選一種：
rewrite-safe
- 直接刪掉「研究表明 / studies show / 業內人士認為」這類權威鋪墊
- 只保留原文裡本來就成立、且不依賴虛構來源才能成立的判斷
- 預設用於
chat 和 public-writing
audit-only
- 不替作者補寫來源，也不把無證據判斷改寫成像是已有證據
- 明確指出「這裡缺來源／缺歸屬」，必要時保留原句不重寫
- 預設用於
docs、status 和 publishing（學術與新聞語體一律 audit-only）
rewrite-with-placeholder
- 只在使用者明確要求保留原結構、原語氣或編輯稿框架時使用
- 可以寫成「有研究認為……，但這裡沒有給出處」這類占位提醒
- 不能補具體機構、數據、年份、研究名稱
如果使用者沒指定模式，就按場景預設值走；如果文本跨場景，優先取更保守的 audit-only。
3. Rewrite level
minimal
適用於：文本本身基本自然，只需去掉局部模板感、收尾腔和多餘修辭。
預設動作：
- 刪掉空總結
- 把過度抬高的語氣壓回常規
- 把「像在解釋自己會寫作」的句子壓回事實句
standard
適用於：有明顯 AI 腔或語域混搭，但資訊骨架是好的。
預設動作：
- 統一語域
- 改掉工程師表演腔、商業黑話、narrator 腔
- 必要時併句或換主語
aggressive
適用於：Tier 1 命中密集，或 Tier 1 + Tier 2 疊加後整段呈現強模板感或強表演感。
限制：
- 只有在
Tier 1 明顯密集，或多類結構問題疊加時才允許
- 先保護事實和術語，再做重寫
docs 和 publishing 的 academic / textbook 語體預設不要升到 aggressive
3.5 Edit scope
Scope 表示這次能不能改動句子和段落結構，和 minimal / standard / aggressive 是兩條軸。三檔 scope 按「能不能刪整句、怎麼刪」區分：structural 自由刪併重排；bounded 只刪「刪了不丟資訊」的整句空話，且走刪除清單交使用者確認；in-place 一句都不刪。
structural
預設 scope。適用於短文本、明確要求重寫的文本、AI 味密度很高且不需要保留原節奏的文本。
允許動作：
- 刪整句空總結
- 合併相鄰事實句
- 輕量調整句序或段落落點
- 按場景重寫局部結構
bounded
中文 public-writing 長文與 publishing 長稿（約 1000 字以上）的預設 scope。目標是把整句級的 AI 味去乾淨，又不被 structural 不可控地壓縮——長文走 structural 時縮水程度依模型而定（同一篇可能 -18%，也可能 -39%），使用者無法預期；bounded 把「刪多少」交還給使用者。
和另兩檔的關係：
- 比
structural 克制：不合併相鄰句、不重排段落、不刪承擔節奏的實句或有意重複
- 比
in-place 能去味：允許刪「整句都是空話」的句子，但不直接刪，而是進刪除清單交使用者確認
一句能進刪除清單，必須同時滿足三條：
- 刪掉後該段資訊點不變（不帶任何獨有的事實、數字、判斷、動作或指令）
- 不是相鄰兩實句之間的唯一過渡
- 命中純空句型：空總結／價值拔高收尾／無來源權威鋪墊／諂媚開場／整句旁白
兩類動作分開走（實測依據：長文裡句首引導詞模型能句內清掉，但整句空話在 in-place 下刪不掉，只會被軟化成另一種說法）：
- 句首可剝離的引導詞（「值得一提的是／歸根到底／這說明」）後面還跟著實質內容 → 直接句內洗，刪引導詞留骨架，不進清單
- 整句都是空的，剝掉引導詞就什麼都不剩（無來源論斷、「不僅僅是……更是……」的價值拔高）→ 進刪除清單，不擅自軟化成另一種說法
輸出：正文給句內洗後的稿，末尾附「建議刪除（待確認）」清單，每條寫「原文 + 為什麼刪了不丟資訊」。使用者點頭才刪，長度由使用者決定。
in-place
適用於使用者明確要求「完全原樣／一句都別刪／嚴格保句數」的情況，比 bounded 更嚴：整句空話也不刪，只做句內降調。
預設觸發條件：
- 使用者 prompt 明確要求保留句數、完全原樣、一句不刪，或回饋
bounded 仍刪多了
禁止動作：
- 不刪整句（即使整句是空話）
- 不合併相鄰句
- 不重排段落
- 不把多段壓成一段
允許動作：
- 句內替換詞或短語
- 刪除句內提示層、空泛修飾和語氣墊片
- 把句內拔高語氣降回普通判斷
- 在單句內部拆短過滿結構，但不改變段落順序
刪短語前先做語義獨立性檢查：刪掉短語後，剩餘部分必須仍是完整、可讀、沒有懸空指代的陳述句。否則改用句內替換，不要硬刪。遇到整句空話，保留原句並標註 [空句，建議人工確認是否刪除]，不擅自軟化成新說法。
aggressive + in-place 可以存在，但預設先提醒使用者：長文 aggressive 很容易明顯縮水；如果使用者真正要保長度，優先改成 standard + bounded。使用者明確堅持時，再執行 aggressive + in-place，但仍遵守不刪整句、不併句、不重排的邊界。
4. Tier severity
Tier 表示問題命中強度，與 嚴重度分級 保持一致，不表示改寫力度。
Tier 1
預設替換。命中這類詞或句式時，通常直接刪掉或換成更具體的表達。常見類型：
- 開場套話、總結式收尾、諂媚句
- 明顯商業黑話、自媒體流水線用語、表演性工程師腔
- 過度接住式共情、替使用者做心理判斷、鄭重預告和身分認證式誇獎
- 混入繁中稿件的中港用語（軟件、視頻、用戶、信息……）——不論有沒有 AI 味都要換
- 英文裡的 sycophantic openers、significance inflation、business jargon
預設處理：局部命中用 minimal 或 standard，密集命中時可升到 aggressive
Tier 2
單獨出現可以放行，但同段聚集時是 AI 味訊號。常見類型：
- 高頻連接詞紮堆
- 渲染性修飾詞紮堆
- 某一類姿態詞在同段重複出現
- 「著」字尾假深度（彰顯著、體現著、象徵著）同段連用
長度參考：短段落（< 100 字/詞）同段 2+ 個即標記；長段落（≥ 100 字/詞）同段 3+ 個再標記。
預設處理：保留最貼切的一個，其餘改寫；通常用 minimal 或 standard
Tier 3
常見詞本身不構成問題，只在全文密度明顯過高時才處理。常見類型：
- 「重要／關鍵／核心／提升」
significant / innovative / effective
預設處理：只替換一部分重複命中，通常用 minimal，必要時不改
5. No-touch and keep rules
以下內容預設優先保留，除非使用者明確要求改風格且改動不損害資訊：
- 引用原文、命令、介面名、參數名、欄位名、設定項、日誌、錯誤訊息
- 引用原文的字形：引用簡體原文時不轉繁體，引號內一律保持原樣
- 技術文件裡的系統行為主語
- postmortem / incident / PRD / release note 中的專業術語
- 中國品牌名、專有名詞、法規與機構名稱（「微信」不改「LINE」，「個人信息保護法」是法規名不改「個資法」）
- 承載關鍵事實的抽象句，即使它「有點像 AI」
不要為了「像人」把文本改得更假。專業文本可以專業，關鍵是別模板化、別表演化。
完整的保護清單見 Protected Spans。
6. Positive style targets
改寫後的文本應盡量滿足：
- 有具體資訊，不靠空洞總括撐氣勢
- 有主語和動作，不靠虛假主體支撐
- 有統一語域，不在技術腔、商業腔、自媒體腔之間跳
- 用語是臺灣的：讀起來不像簡轉繁，也不像翻譯腔
- 以「可直接發」為終點，不為了更像人繼續拋光到失真
- 有節奏，但節奏來自刪冗餘和保留重點，不來自硬造金句
- 有立場，但立場來自判斷或事實，不來自「故作洞見」
- 有邊界，沒把握就直說，不替對方做心理判斷，也不硬演「我懂了」
更完整的正向目標、分場景校準、「cleaner vs more human」對照和出版稿的靈魂檢查見 Positive Style Contract。
7. Output contract
預設輸出一個推薦版本，不預設輸出審稿過程、多版本比稿或逐條點評。
publishing 場景額外輸出：變更摘要（前 5–8 項主要修改）、60 分品質評分（六維度，見 出版語體）、未解決疑問（需要作者裁奪處）。長稿超過三千字時附術語表。
Annotation mode
只有在使用者明確要求下面這類事情時才啟用：
- 「先別改，先標問題」
- 「這段哪裡像 AI」
- 「只做診斷／審稿／標註」
- 「先告訴我該不該改」
annotation mode 不直接給整段改寫稿，預設只輸出最重要的 1-5 個問題點。每個問題點固定包含這 4 個欄位：
問題族：例如「開場套話／無來源引用／工程師腔／語域混搭／中港用語」觸發點：點明命中的詞、結構或局部句子建議動作：刪掉、換成具體表達、補來源、換臺灣用語、保持不動是否建議改寫：是 / 否
額外約束：
- 如果文本主要問題是「缺來源」，可以只建議補來源，不強行給改寫稿
- 如果文本落在誤殺防護邊界內，直接寫「是否建議改寫：否」
- 不要一邊說「只標問題」，一邊偷偷輸出完整重寫版
- 使用者沒要求
annotation mode 時，仍然按預設改寫合約輸出單一推薦版本
遇到無來源引用時，輸出必須符合所選模式：
- 在
annotation mode 下，只輸出對應的處理建議，不直接給整段改寫稿
- 在預設改寫模式下，再按所選模式實際給出改寫結果
rewrite-safe：建議刪掉無證據權威鋪墊；如果不是 annotation mode，再給改寫結果，不補虛構來源audit-only：優先點明缺來源、缺歸屬，而不是假裝已經證實rewrite-with-placeholder：允許保留論證位置，但要顯式暴露「此處待補來源」；如果不是 annotation mode，可以給帶占位提示的改寫結果
只有在高風險誤殺時，才額外補一行極短說明，例如：
- 「保留了系統主語和術語，避免失真。」
- 「這裡只做輕改，避免把正式公告寫成口語文。」
8. Required reread checks
提交改寫前，把回讀固定拆成兩步，不要混著做：
Pass 1 | 保真回讀
先檢查這 6 項：
- protected spans 是否漂了
- 資訊是否丟失
- 語域是否統一
- 術語是否失真；長稿（三千字以上）同一概念是否全篇只用一種譯名
- 臺灣化是否徹底：有沒有殘留的中港用語、簡轉繁錯字、不合慣例的標點
- 刪改後是否出現生硬斷裂
如果刪掉一句後段落突然沒了落點，就補一條事實句，不要補口號句。
bounded / in-place scope 下額外檢查：
- 資訊留存優先：原文每個資訊點（事實、數字、判斷、動作）在輸出裡都要可追溯，這是硬指標
in-place：輸出字數低於原文 85% 時，回頭檢查是否誤刪整句、併句或壓段落（in-place 不該刪任何整句）bounded：字數會因刪整句空話而下降，不設硬下限；但要確認刪除清單裡每條都是「刪了不丟資訊」的純空句，沒混進實句或承擔節奏的重複- 句數變化超過約 10% 時，回頭檢查是否偷偷做了未經確認的 structural 改寫
- 關鍵事實句、轉場句和承擔節奏的重複句，不能因為「看起來像模板」就預設刪除
Pass 2 | Residual Audit
只有在第一遍已經保住事實、但讀起來還有輕微 AI 味時，才做第二遍。第二遍固定只查這 5 件事：
- 開場殘留：還在用「結論先說／直接說結論／值得注意的是」這類提示層
- 總結殘留：還在用「總的來說／歸根結底／最終來看」這類空收尾
- narrator 殘留：還在解釋「這說明了什麼」，而不是直接說事實或判斷
- 空泛判斷殘留：還在寫「方向是對的／意義重大／真正理解了使用者」
- 句長過勻：每句都差不多長、差不多整齊，像被統一拋光過
第二遍只允許做輕量修正：
- 刪一個殘留開場或收尾
- 合併兩句過勻的事實句，或拆一處過滿的句子
- 把一句 narrator／空泛判斷壓回直接表達
第二遍不要做的事：
- 不重寫全文
- 不補原文沒有的事實
- 不為了「更像人」改掉術語、參數、命令、錯誤訊息或責任歸屬
場景保守策略：
public-writing 和 AI 味偏重的 chat，第二遍更常需要docs / status / code-context 預設更保守；如果第二遍會讓語氣變口語、變廣告、或影響保真，就停在第一遍publishing 的 literary 語體對統計平均值最敏感，第二遍重點查句長過勻和段落收束方式是否單一
Reference navigation
預設做法是：先用本檔案完成「場景、臺灣化、Tier、檔位、輸出合約」的主判斷，再按問題類型補讀 references/；只有在單檔安裝場景裡，才停留在本檔案的後備規則。
