[Github] sepia – 面向 Agent Skills 的结构化去 AI 味写作技能

如果你把 AI 生成的稿件交给“改得像人一点”的工具，最容易漏掉的不是某个形容词，而是整篇文章的组织方式：小说一路按单线因果收束，技术文章每段都像同一个模板压出来。sepia 处理的正是这一层——它把文本先按体裁分流，再决定改结构、改语篇，还是只做表面修订。本文会说明它怎么安装、四个操作入口分别做什么，以及为什么“结构化编辑”不等于“保证通过检测”。

它解决的不是错别字

sepia 是 Nanako0129 发布的 Agent Skill，项目源码位于 Nanako0129/sepia。仓库把一份 canonical skills/sepia/SKILL.md 作为规则中心，再用四个轻量 wrapper 暴露 write、review、refactor、recreate 四种操作。它的目标不是把所有文字改成同一种“人味”，而是根据文本类型选择不同的约束。

这个定位和常见的词汇级 humanizer 不同。后者通常先处理套话、句式或标点；sepia 的 README 则把小说的叙事架构、语篇节奏和表面风格拆成不同层，并把 release notes、PR/Issue 回复、postmortem、ticket、技术文章等专业文本交给各自的 venue 规则。WarpNav 已有一篇中文去 AI 味工具与检测 Skill 怎么选，适合做横向分类；本文只聚焦 sepia 这一个仓库的工作契约。

四个入口对应四种改动深度

不要把四个命令当作四个同义词。它们对“是否编辑原文”的承诺不同：

在 Codex 中，README 给出的入口是 $sepia-write、$sepia-review、$sepia-refactor 和 $sepia-recreate；一般路由器是 $sepia。其他平台有对应的 slash command。这里的命令名称来自仓库文档，是否可用仍取决于你安装到哪个 Agent 环境。

小说为什么先修架构

sepia 把小说分成三遍处理。第一遍看叙事架构：主题是否被旁白讲得太白、因果链是否过于整齐、揭示是否全部提前、情绪是否只靠身体感受表达；第二遍看语篇流动：段落问题序列、节奏和中段塌陷；第三遍才处理陈词、句法和词汇。这个顺序来自仓库对 StoryScope 等研究的整理，不应理解为“论文已经证明 sepia 的干预有效”。

StoryScope 的原论文在 61,608 个故事上报告：仅使用叙事特征的人类/AI 分类达到 93.2% macro-F1，表面风格编辑后仍能保持较高区分度。这个数字说明“只改措辞”可能漏掉结构信号，但它不是 sepia 的通过率，也没有证明使用 sepia 就能让文本被判成人类。文章、小说和检测器的目标必须分开。

专业文本按场景换规则

当输入不是小说，sepia 不会硬套叙事配方。它把专业文本按场景路由：

• Release notes / announcement：先写用户影响，每条变化要能对应产物或版本，不用营销膨胀替代事实。
• PR / Issue 回复：先回答问题，必要时给出 file:line 证据，避免条件反射式夸赞。
• Postmortem：对人保持无责备，对机制保持严格；写时间线、走过的死路和有负责人的行动项。
• Ticket / work order：标题写结果，验收条件要可测试，链接已有信息而不是重复粘贴。
• Technical article：从真实问题开场，保留一个可核查的失败或死路，给出有条件的判断。

这部分的价值在于“场景匹配”，而不在于生成更口语的句子。换句话说，同一份事实写成 release note、Issue 回复或技术文章，应该改变信息排序和证据粒度，而不是只换几个词。

安装路径要分清范围

仓库 README 目前把 Skills CLI 作为通用入口，命令按用户级安装编写：

npx skills add Nanako0129/sepia -g
npx skills update sepia -g
npx skills remove sepia -g

-g 表示用户范围；README 也提醒，Skills CLI 的 agent 支持范围与作者实际做过运行验证的范围不是一回事。仓库列出的四个平台原生安装路径是 Claude Code、Codex、Grok Build 和 Antigravity；以 Codex 为例：

codex plugin marketplace add Nanako0129/sepia
codex plugin add sepia@sepia

安装后先做最小验证，不要马上把整套写作流程换掉：

1. 确认 skills/sepia/SKILL.md 与四个 wrapper 都被安装，入口名称没有被截断。
2. 用 300～500 字、事实边界清楚的文本运行 review，先观察它是否只诊断、不改稿。
3. 再对同一文本选择 refactor 或 recreate，对照数字、人名、引用、链接和责任主体。
4. 把最终稿放回目标 venue 的人工审核流程；Skill 的规则不能替代事实核对或编辑签字。

v0.4.0 的 voice skill 仍是实验项

截至 2026 年 9 月 1 日，仓库最新 release 是 v0.4.0。这版新增了可选的 voice-skill 组合接口：你可以声明一个品牌声音、极简方法或 persona guide，让 sepia 先做结构判断，再选择少量（README 写作 3～5 个）声音动作。专业文本仍由 venue 决定语域，voice 不能绕过场景规则。

这里需要留出证据边界：release notes 说明该功能的依据是一次严格极简样本的盲审工作例，不是大规模效果评测。升级时应把它当作实验性组合方式，先检查规则冲突和输出差异，不要把“叠加 voice”理解成效果保证。

它不能替你证明“像人”

sepia 的研究叙事建立在 StoryScope 等论文摘要和仓库整理上，但仓库没有把自己包装成科学检测器。实际使用有四个边界：

• 不是检测器：它不会给文本一个可信的“AI 概率”，也不应作为处罚或删稿依据。
• 不是事实核验器：日期、数字、引用、许可证和责任主体仍需要人或专门工具核对。
• 不是万能重写器：轻度人工编辑过的文字可能不需要整套三遍流程，过度改写会损失原作者声音。
• 不是所有 Agent 都等价：README 提到 Skills CLI 支持 77+ agents，但作者明确说明四个平台做过安装验证，其他环境的运行时行为未全面测试。

我的建议是先用 review，再决定 refactor 还是 recreate；只有在确定写作场景、事实责任和验收标准后，才让 write 参与新稿。目标应是信息更可靠、结构更贴合读者，而不是追逐某个检测分数。

项目状态与许可

核验日 GitHub 页面显示 sepia 约有 1,336 stars、78 forks，默认分支为 main，仓库未归档，最近提交在 2026-09-01；最新 release 为 v0.4.0（2026-08-31）。仓库 LICENSE 是 MIT，允许使用、复制、修改和分发，但分发时仍应保留版权与许可声明。

如果你在 Claude Code、Codex、Grok Build 或 Antigravity 中持续写小说、技术文章、Issue 回复或复盘文档，sepia 值得作为“先诊断、再改动”的规则层试用。它真正的门槛不是安装命令，而是愿意为每种文本承认不同的证据、语域和结构；如果你的需求只是把几句产品文案改得顺口，使用完整的结构化流程反而过重。

相关链接

• GitHub 仓库：https://github.com/Nanako0129/sepia
• 官方 Agent Skills 规范：https://agentskills.io/specification
• StoryScope 论文：https://arxiv.org/abs/2604.03136
• 最新 Release：https://github.com/Nanako0129/sepia/releases/tag/v0.4.0
• WarpNav 相关专题：中文去 AI 味工具与检测 Skill 怎么选：https://warpnav.com/ai-writing-humanizer-skills

本文依据 sepia 官方仓库 README、SKILL.md、插件清单、LICENSE、v0.4.0 release notes 与 StoryScope 论文摘要核对整理；示意图不代表 sepia 的真实运行界面或效果评测。