OceanCT 的 Humanize Skill

自己用 AI 写文章时，我总觉得生成的文字有股很浓的 AI 味。试过一些现成的 Humanize Skill，读起来有所改善，但还是不太属于自己的风格。于是就有了这份 OceanCT 的 Humanize Skill：拿自己会怎么说、怎么写作参照，把几次改稿中反复在意的地方整理成规则。

每个人喜欢的表达都不一样。你可以参考这份 skill，也可以拿自己的文章和 AI 的初稿对照，写一份符合自己习惯的 Humanize Skill。

下载 OceanCT 的 Humanize Skill

附件是完整的独立版本，指令用英文编写，适用于中文学习笔记和技术博客。下载后保存为 oceanct-humanize/SKILL.md，放进所用工具支持的 skill 目录；也可以直接把文件内容和原稿一起交给 AI，让它按这些要求改写。有自己的写作样稿时，一并附上会更方便表达偏好。

讲解逻辑：让读者跟得上

改 Agent 学习笔记时，有一句话让我停了下来：

全文沿用一个技术调研助手的例子。

这句话交代了文章的安排，但我读到这里，还不知道这个助手到底要做什么。如果前面的问题是 Agent 怎样完成任务，就可以用调研压缩技术的过程，说明怎样查资料、比较结果。这样引入例子，是为了回答已经提出的问题。

选什么例子也有讲究。我们当时讨论过，介绍 Agent 的开头不适合用“调研 Agent 的记忆方案”来举例。读者还没有理解 Agent，又要先弄明白它的记忆方案，就很难借这个例子理解前面的概念。这也是“用已知解释未知”的来由：先选读者熟悉的事情，理解它不需要提前学会我们正在讲的新知识。

有了熟悉的例子，还需要明确接到新问题上。比如讲过现有的调研流程之后，再问：“假设现在想设计一个 Agent 来完成同样的任务，参照这套流程，我们应该怎么做？”这样就能从需求、查证、工作记录和审阅中，逐步找到新系统需要考虑的问题。

这里对应另一条规则：“说明新增能力的来由”。旧系统可以是人工流程，也可以是已有的软件或组织协作。我们借鉴它完成任务的经验，同时看看条件变了以后，哪些机制需要重新设计。比如原先的工作记录启发我们保存 Agent 的任务进度，但程序中断后怎样恢复、会不会重复写入文件，还需要继续分析。

不过，例子熟悉、前后都在讲同一件事，也不一定说明逻辑连贯。后来介绍 Agent 框架时，开头问“已有模型 SDK，为什么还需要框架”，下一段却直接摆出了调研助手的任务，没有说明这个任务怎样回答前面的疑问。这里缺的是 SDK 的能力边界：它完成模型调用以后，工具执行、消息记录和循环还要自己写；明确这些工作，再介绍框架提供了什么，才有比较的依据。

所以复读时，我会先看上一段留下了什么问题，这一段补了什么，为什么接下来会引出下一段。先修正段落推进，再调整语气和措辞，不能只把孤立的句子改顺。

表达风格：保留讲述的节奏

另一些地方涉及句子怎么组织。比如我在描述自己想要的开头时，会说：

这是我系统学习 Agent 的第一篇笔记，我们先从这几个问题谈起。从宏观上看，设计一个 Agent 会涉及执行编排、记忆管理和工具调用，也会遇到多个 Agent 之间如何协作的问题。

“从宏观上看”在这里说明了讨论的层次，后一句也顺势把几个相关的问题连了起来。我喜欢这种展开的节奏，所以在规则里保留了“有用的过渡”和“允许句子舒展”。删掉多余的话之后，仍然要让一句话能够接住上一句。

正文的组织也一样。最初的笔记把不少内容拆成表格和要求清单，查找起来方便，连续读却更像一份提纲。后来我们把其中需要解释因果和来龙去脉的部分写回段落，比较概念的地方继续用表格。这就成了“正文优先讲解”：选择形式时，要看这段内容是在解释一个问题，还是在并列比较几件事情。

查阅资料的过程也不用每次写进正文。“这些资料是在某年某月某日查阅的”通常没有帮助解释技术问题，文章已有日期可以交代写作时间。若某个版本改了接口，或者项目进入维护模式，就在相关位置说清楚变化和来源。

至于口述里的“嗯”、重复起头和转写错误，可以整理掉。想留下的是思路展开的方式，不需要特意加入口头禅。同样，改写也不能补造经历，或者为了读起来顺畅，删掉技术结论的适用条件。

这些偏好在《Agent学习笔记（一）Agent设计中的几个问题》里做了一次尝试。以后用到自己的文章上，也可以从一两段开始：把读着不舒服的地方圈出来，写下自己会怎么讲，再看看差别究竟在讲解逻辑，还是表达习惯。