AI 写作去套路,这个开源工具有点不一样

你有没有发现一个很奇怪的现象？

现在的 AI，写文章越来越快了。给它一个主题，几秒钟就能生成一篇结构完整、语句通顺、标题清晰的文章。写总结、写方案、写技术文档，效率确实提高了不少。

但有时候，你读着读着就会产生一种感觉：这篇文章没什么明显错误，可怎么看都像是 AI 写的。

比如：

更麻烦的是，即使你让 AI「写得自然一点」「去掉 AI 味」，它也可能只是换一批词、调整一下句式。文章看起来变了，写作套路却没有真正改变。

最近发现一个 GitHub 开源项目，专门针对这个问题设计了一套写作与修订工作流。它叫sepia。

它的思路很有意思：如果 AI 味不只是出现在词语和句子里，那么为什么不从故事结构、行文节奏和表达方式三个层次一起处理？

先说一个很多人容易忽略的问题。我们通常说的 AI 文本润色，主要做什么？替换重复词汇、调整句式、删掉套话、让语气更自然。这些操作当然有用，但它们解决的主要是文字表面的问题。

以小说为例。假设 AI 写了这样一个故事：主角遭遇困难，认识一位导师，获得启发，克服内心障碍，最终完成成长。整条故事线非常完整，逻辑也很清楚。

但问题是，故事可能太规整了。人物的每次行动都恰好推动剧情，所有事件都指向同一个主题，最后再用一段总结把人物成长解释清楚。即使把里面的词汇全部换掉，这个故事的整体结构仍然没有变化。

sepia 的设计理念，就是把问题看得更深一些。它根据项目整理的研究资料，将小说创作与修改拆成三个层次：

换句话说，它不满足于把一句话改得更顺口，而是尝试判断：这篇文章为什么会形成现在这种写法？有没有必要从更深的层次重新组织？

很多 AI 写作工具有一个共同的问题：你让它修改文章，它就直接开始重写。至于原文哪里有问题、哪些地方值得保留、修改后为什么更好，往往说不清楚。

sepia 把写作、审查、轻量修改和整体重写设计成了不同操作。

1. Write：从一开始就按照目标场景写

如果你还没有文章，可以使用写作模式。它会根据不同场景采用相应的写作规则，而不是对所有内容都使用同一种所谓的「人类风格」。

例如，写小说与写技术文档，本来就应该有不同的表达方式。小说可以通过人物行动、情节安排和信息揭示推进故事；技术文档则应该重视准确性、可验证性和清晰度。

sepia 的目标是根据内容类型选择相应的规则，让写作从一开始就更贴合使用场景。

2. Review：只检查，不擅自修改

这是我比较喜欢的一项设计。如果你已经写好了一篇文章，但不确定哪里需要调整，可以先让它进行审查。

Review 模式的重点是诊断，而不是直接修改原文。你可以先了解哪些地方存在模板化表达、行文节奏问题或者场景不匹配，再决定是否进行修改。

这种方式尤其适合已经有自己写作风格的人。毕竟，文章不需要被改得面目全非才叫优化。有时候，找到两三个真正影响阅读体验的问题，就已经足够了。

3. Refactor：尽量少改，保留原文

如果你的文章整体不错，只是有些段落显得生硬，可以使用轻量修改模式。它的设计目标是尽可能减少不必要的改动，针对已经发现的问题进行调整。

例如：

这种模式适合已经有明确内容和观点，只希望提高表达质量的场景。

4. Recreate：保留事实与意图，重新组织表达

有些文章的问题不是修修补补就能解决的。比如，原文结构混乱，论证顺序不合理，或者写了很多内容，却始终没有把核心观点说清楚。这时候，可以考虑整体重写模式。

sepia 的 Recreate 操作，目标是依据原文的事实和意图重新组织内容，而不是简单地逐句换词。

四种操作各有用途，不必每次都直接选择全文重写。

从项目介绍来看，sepia 特别重视小说的叙事结构，但它的适用范围并不局限于小说。项目还针对多种专业写作场景提供了不同规则。

技术文章：技术文章不应该只追求结构工整。真正有价值的技术分享，往往需要解释问题从何而来、尝试过哪些方法、哪些方案失败了，以及最终为什么选择现在的方案。sepia 的技术文章规则强调从真实问题切入，呈现具体过程和有依据的判断，而不是把所有内容都写成标准化的知识总结。

软件发布说明：发布说明应该优先解释用户会受到什么影响，而不是堆砌一串看似专业的功能描述。例如，与其只写「优化了系统性能」，不如说明具体改善了什么，以及改善在哪些条件下成立。

PR 和 Issue 回复：在开发过程中，很多回复容易出现无意义的客套话，或者绕了半天仍然没有回答问题。sepia 针对这类场景强调先回答核心问题、提供可核实的代码位置，并根据问题的重要程度控制回复长度。

故障复盘：复盘的重点应该是机制、时间线、失败原因和后续行动，而不是把内容写得很漂亮。项目为这类文档设计了相应的规则，强调明确记录过程、失败环节和责任行动项。

工单与任务说明：好的任务描述应该让执行者知道要实现什么，以及怎样判断任务已经完成。因此，项目强调可验证的验收标准，避免重复描述和含糊不清的目标。

这意味着，sepia 并不是试图让所有文章都变成同一种风格。相反，它希望根据写作场景，采用不同的表达规范。

sepia 的另一个特点，是它没有把所有规则都包装成个人经验，而是整理了相关研究资料，并尝试把研究发现转化为具体的写作和修改规则。

项目 README 引用了 StoryScope 等研究。根据 README 对 StoryScope 研究的介绍，该研究使用叙事结构特征来区分人类创作与 AI 生成的小说，报告了93.2% 的宏平均 F1 分数。

这个结果值得关注，因为它提示我们：判断文本是否具有 AI 写作特征，可能不只是看词汇和句式，还可以观察整个故事如何组织。

但这里有一个非常重要的边界：研究中的分类指标，不等于 sepia 能把任意文章改到某个检测分数，也不意味着所有 AI 文本都能被可靠识别。

不同数据集、不同语言、不同模型和不同写作任务，都会影响结果。

sepia 的价值在于尝试把研究发现转化成可以使用的工作流，而不是承诺让文章通过所有 AI 检测器。对于真正想提升写作质量的人来说，这个方向比单纯追求一个检测分数更值得研究。

sepia 采用 Agent Skill 的形式，可以接入符合相应标准的 AI Agent。项目 README 介绍了 Skills CLI 的安装方式，并为 Claude Code、Codex、Grok Build、Antigravity 和 QwenPaw 等环境提供了相应的集成方案。

如果你想先尝试通用安装方式，可以打开终端执行：

这里的 -g 表示安装到用户级范围，具体使用方式仍需根据你的客户端和项目需求确认。

如果你使用 Codex，项目还提供了原生插件安装方式：

如果你使用 Claude Code，也可以按照项目 README 中的插件安装说明进行配置。

安装完成后，可以根据客户端支持的调用方式使用相应操作。例如，在支持相关命令的环境中，你可以尝试：

Codex 的对应调用形式使用 $ 前缀，例如 $sepia-review 和 $sepia-refactor。

具体命令、可用操作和安装方式可能随版本变化，建议以仓库中的最新 README 为准。

如果你只是偶尔让 AI 帮忙写一条简单消息，可能不需要专门安装一个 Skill。但如果你经常使用 AI 写作，sepia 就有几个值得尝试的场景。

1. 经常用 AI 写小说的人：如果你发现人物、剧情和章节节奏越来越套路化，可以尝试让它从叙事结构入手审查，而不只是润色句子。

2. 运营公众号、自媒体的人：如果你经常使用 AI 生成文章，可以先检查文章是不是存在重复论述、过度总结和模板化段落，再决定哪些地方需要修改。

3. 技术人员和开发者：如果你经常写 README、技术博客、发布说明、PR 回复和故障复盘，可以利用针对不同文档类型的规则，改善内容的准确性和可读性。

4. 喜欢研究 AI Agent 的人：sepia 不只是一个提示词集合，还包含统一的 Skill、场景规则、诊断标准和相关研究资料。如果你想了解如何把写作方法组织成可以重复使用的 Agent 工作流，这个仓库也值得研究。

我觉得，sepia 最值得关注的地方，并不是它声称能让文章变得多么像人写的。而是它提出了一个值得思考的问题：

当 AI 已经能够生成语法正确、结构完整的文字之后，写作质量的差异究竟还来自哪里？

对于小说来说，答案可能藏在人物关系、叙事节奏和信息揭示方式中。对于技术文章来说，答案可能来自真实的问题、具体的尝试和有依据的判断。对于软件文档来说，答案可能就是准确、清楚，不浪费读者的时间。

当然，任何工具都无法自动保证文章优秀。sepia 的修改建议同样需要结合作者的目的进行判断，不能为了追求所谓的「人类风格」，牺牲事实准确性、个人表达或者必要的规范。

如果你已经在使用 Claude Code、Codex 等 AI 工具，不妨看看这个项目。它免费开放使用，采用 MIT 许可证，相关研究资料也可以在仓库中查看。

项目传送门

感兴趣的话，可以进入仓库阅读 README，了解安装方式、各项操作和研究依据。如果觉得有价值，也欢迎给项目点一个 Star，支持开源项目继续完善。

说明：本文根据 sepia 项目的公开 README 整理改写，用于开源项目介绍。相关研究结果仅代表其特定研究条件，不构成对文本检测结果或写作效果的保证。

既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。

THANKS FOR READING