sepia 把去 AI 味拉到敘事結構層：一份給小說與專業文稿的 Agent Skill
De-AI writing skill for any Agent Skills-compatible agent (77+ via the Skills CLI), with native plugins for Claude Code, Codex, Grok Build, and Antigravity. Narrative-architecture repair for fiction, venue-matched rules for professional prose. Based on StoryScope (arXiv:2604.03136).
秒懂
- 它是什麼？
- 多數 humanizer 只改詞彙與句法，sepia 依 StoryScope 的敘事結構特徵，先修架構再談用字，並為不同文體套上各自的規則檔。它適合已經在用 Agent Skills 的寫作者，不適合期待一鍵完稿的人。
- 適合誰用？
- 如果你已經在用 Claude Code、Codex、Grok Build 或 Antigravity，而且手上有具體的小說稿或專業文稿要修，sepia 值得裝來試：它的三層協定與 30 項診斷評分表，比單純的詞彙替換更能處理「一看就是 AI 寫的」那種結構感。如果你要的是零設定的自動潤稿，或你的 agent 不支援 Agent Skills 標準，那它幫不上忙；wrapper 也必須連同完整 plugin package 一起裝，單獨安裝不支援。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
問題不在用詞，在故事的骨架
市面上多數 humanizer 做的是同一件事：換掉陳腔濫調、打散句法模板、調整語域。sepia 的作者認為這一層改不到痛點。README 引用 StoryScope（Russell et al., 2026，樣本為 61,608 篇故事，人類加上五個前沿 LLM）的結果：只靠敘事結構特徵的分類器，偵測 AI 小說的 macro-F1 達 93.2%；而在 LAMP-edited 條件下，人類編輯已經改寫過表面風格，偵測率只從 95.5% 降到 93.9%。也就是說，真正出賣 AI 的線索是架構性的：由敘述者直接解釋主題、單線且因果過於整齊的情節、情緒只寫成身體感受、沒有真實世界的指涉、沒有讀者、時間軸筆直、結局靠主角成長與接受來收束。
這個觀察決定了 sepia 的適用對象。它不是給「想讓貼文讀起來不那麼像 ChatGPT」的人用的，而是給寫小說、或寫 release notes、PR 回覆、postmortem、ticket、技術文章這類有明確場合的專業文稿的人用的。前者修的是架構，後者修的是場合錯配。兩條路線共用一份 checklist，但規則檔不同。
三層協定與 30 項診斷評分表
sepia 把寫作與修訂拆成三層。第一層是敘事架構，只針對小說：停止解釋主題、放鬆因果鏈、把揭露往後挪、混用情緒模式、讓角色網絡稀疏、指名真實事物。第二層是語篇流動：拆掉段落與問題的模板順序、處理中段塌陷、變化節奏與位置。第三層才是表面風格，也就是其他 humanizer 唯一在做的那一層：陳腔濫調、句法模板、詞彙、語域。
診斷端是一份 30 項特徵的評分表，加上兩層 per-model 指紋。敘事層的指紋來自 StoryScope 對 Claude、GPT、Gemini、DeepSeek、Kimi 的測量；句法層的指紋取自各家自己的 prompting guide（Claude Fable 5.1 與 Mythos 5.1、Fable 5 與 Mythos 5、Opus 5、Opus 4.8；GPT-5.6、GPT-6 Astra；Gemini 3 系列）。README 明確寫了一條邊界：沒有公布這類指引的廠商，只記為「已查閱」，不做推測。這個處理方式比硬湊指紋誠實。
整體原則寫得很直接：calibrate to the human distribution, don't invert the AI one。人類的數值落在中間，一篇把每條規則都用上的小說，本身就是一組新指紋。所以 sepia 每篇只挑 3 到 5 個動作，刻意留白。這是整個設計裡最容易被忽略、也最關鍵的約束。
四種操作與五個入口：write、review、refactor、recreate
sepia 定義四種操作。write 是從零寫；review 只診斷、不動稿；refactor 做最小幅度的就地修改；recreate 從來源事實與意圖重寫。這個切分對實務有意義：當你只想知道自己稿子哪裡有問題，review 不會擅自改掉你的句子，這比一個「幫我潤稿」的黑箱好用。
完整 plugin package 另外給 Claude Code、Codex、Grok Build、Antigravity 一個通用 router 加五個直接入口。Claude Code、Grok Build、Antigravity 用斜線形式：/sepia-write、/sepia-review、/sepia-refactor、/sepia-recreate、/sepia-hemingway，通用入口是 /sepia。Codex 用錢號形式：$sepia-write 等，通用入口是 $sepia。hemingway 這個入口是以內建的 Hemingway 聲音寫或改小說。
這裡有個安裝上的硬限制：operation wrapper 依賴同一包的 canonical skill，README 寫明 standalone wrapper installation is unsupported，必須安裝完整 plugin package。如果你只想挑一個指令裝，會裝不起來。
專業文稿走另一條路：場合決定規則
小說與專業文稿的失敗方式不同，sepia 沒有用同一套規則硬套。專業路線在共用 checklist 之上，每一種文件型別疊一份薄規則檔。
release notes 與公告：先講使用者影響，每個宣稱都要有對應產出物，不准行銷式膨脹。PR 與 issue 回覆：先回答，引用 file:line，不要反射式稱讚，長度與利害相稱。postmortem：對人不責難，對機制不留情；要有時間戳、走過的死路、有歸屬的 action item。ticket 與工單：標題即結果，驗收條件可測試，用連結而不是重述。技術文章：從問題開場，寫一個真實的死路，給一個有立場的意見，數字要附條件。
這些規則的共通點是場合敏感。同一句話放在 PR 回覆裡是精簡，放在技術文章裡是敷衍。把「去 AI 味」簡化成一份通用黑名單，正好會踩到這種錯配。
安裝與執行：Skills CLI 一行，plugin 另計
README 給的安裝路徑有兩條。通用路徑是透過 Skills CLI，一行指令安裝，該 CLI 支援 77 個以上的 agent；任何實作 Agent Skills 標準的 agent 都能載入同一份 canonical SKILL.md，沒有 per-platform fork。原生路徑是 Claude Code、Codex、Grok Build、Antigravity 四個平台的 plugin 打包，這一條才提供上面那五個直接入口。
要注意 README 在 Install 一節的措辭：各平台「實際驗證過什麼」寫在該節，而不是一句「全部支援」帶過。這種寫法在 agent 生態裡是必要的，因為同一個 skill 在不同 host 上的載入行為並不一樣。
另外有一個實驗性介面，從 v0.4.0 起提供：把 voice 或 style skill 疊在 sepia 之上，例如極簡主義方法、品牌聲音、persona 指南。它是 opt-in 的，你不說，它不會載入任何外部 voice。合約的內容是：sepia 的架構決策優先；voice 的動作選擇性套用，每篇 3 到 5 個招牌動作，公式化結尾有時刻意打破；review 會報告 voice 的已知代價而不是把它修掉，但一致性問題的強度不減，因為有 voice 並不構成節拍器的藉口；專業路線仍由場合決定語域；直接衝突會回報給你。內建一個 profile 放在 references/voices/ 底下（Hemingway：小說用冰山省略，專業文稿用 Kansas City Star 規則，每個動作都標註來源）。README 對這個介面的證據等級說得很清楚：根據一次嚴格極簡樣本的盲測審查，是 worked example，不是測量證據。
限制：它不幫你決定該不該改
最實在的限制來自它自己的設計原則。calibrate to the human distribution 意味著 sepia 會刻意不套用某些它偵測到的問題，每篇只挑 3 到 5 個動作。如果你要的是「把所有 AI 痕跡清乾淨」，這個工具的節制會讓你覺得它沒做完。反過來說，把 30 項特徵全部套上去，得到的是一篇符合所有規則、卻誰都不像的文字，那只是換了一組指紋。
第二個限制是依賴關係。operation wrapper 不能單獨安裝，必須連 canonical skill 一起。這在 CI 或自動化流程裡會影響你怎麼打包。
第三個是覆蓋範圍的邊界。per-model 指紋只在寫作或執行模型已知時才套用；廠商沒公布 prompting guide 的，sepia 記為已查閱而不猜。這代表某些模型組合下，句法層的指紋是空的，實際作用會退回敘事層與通用 checklist。
最後，這是一個 Agent Skill，不是獨立程式。你的 agent 不講 Agent Skills 標準，或不在 Skills CLI 的支援範圍內，它就沒有載入的途徑。首頁欄位是空的，README 也沒有列出獨立 CLI 的用法。
替代方案：通用 humanizer 與它差在哪
最直接的替代品是通用 humanizer，也就是 README 開頭點名的那一類：改詞彙、改句法、改語域。兩者的差別不是效果好壞，而是作用層不同。通用 humanizer 假設 AI 味是表面現象，因此它的輸入輸出都是句子；sepia 引用 StoryScope 的測量結果主張，表面風格被人工改寫後，偵測率幾乎不動（95.5% 到 93.9%），所以它把第一層放在敘事架構。對小說來說，這個差別是實質的：通用工具不會叫你放鬆因果鏈或把揭露往後挪，因為那不是句子層的操作。
代價是 sepia 需要更多輸入才能運作。你得告訴它這是小說還是哪一種專業文稿，走哪條規則檔；如果要用 voice 疊加，你得主動說 voice skill 在場。通用 humanizer 通常貼上文字就能跑。
如果你的需求是「把一段文字改得不那麼像 AI」，而且你不在意它是不是小說，通用工具更省事。如果你的稿子會被拿去做結構性判斷，例如投稿、審稿、或讀者會記得情節走向，那麼架構層的修復才是你真正要買的東西。
授權、維護與升級成本
授權是 MIT，寬鬆，商業使用與修改的空間都大。這對要把它包進內部工具鏈的團隊是好消息。MIT 不提供任何擔保，實際使用前該看的是 LICENSE 全文而不是這篇評測，本文不構成法律意見。
維護節奏可以從版本號讀出來：v0.7.0 在 2026-09-04，v0.8.0 在 09-05，v0.9.0 在 09-08，四天內三個 minor 版本，主分支最後推送時間與 v0.9.0 同為 2026-09-08。這代表專案還在快速變動期，也代表你如果鎖定某個版本，升級時要預期介面或規則檔會動。
升級成本主要落在兩處。一是 per-model 指紋：新模型出來、廠商更新 prompting guide，指紋層就得跟著改，這是持續的維護負擔，也是它相對通用 humanizer 的額外成本。二是 voice 介面，README 自己標為實驗性，v0.4.0 引入，合約細節仍有調整空間。如果你的流程依賴 /sepia-hemingway 的輸出一致性，這點要先納入評估。
CI 方面，repo 帶了 behavioral eval 與 version consistency 兩條 workflow，README 開頭有對應的 badge。這說明作者把行為評測與版本一致性當成發佈前的檢查項目，但 badge 只代表流程存在，不代表你的使用情境已被涵蓋。
編輯結論
如果你已經在用 Claude Code、Codex、Grok Build 或 Antigravity，而且手上有具體的小說稿或專業文稿要修，sepia 值得裝來試：它的三層協定與 30 項診斷評分表，比單純的詞彙替換更能處理「一看就是 AI 寫的」那種結構感。如果你要的是零設定的自動潤稿，或你的 agent 不支援 Agent Skills 標準，那它幫不上忙；wrapper 也必須連同完整 plugin package 一起裝，單獨安裝不支援。動手前先確認三件事：你的 agent 是否在 Skills CLI 支援清單內、你要處理的是小說還是專業文稿（兩者走不同規則檔）、以及你的模型是否在它記錄的 per-model fingerprint 名單中，因為指紋只在寫作或執行模型已知時才會套用。
社群筆記