这期视频想分享一个我最近觉得很好用的 Claude 使用方式：**当你没有脑力读 README 或长篇文档时，可以让 Claude 把一个项目做成一套可交互的 mini course。** （录着玩的，大家随便看看，没带耳机，收音有点闷闷的）

今天我在网上看到 Peter Yang 分享了一个开源 Skill，主要用于识别和修改写作中的“AI 味”。http://t.cn/AX96Uken

我对这个项目有点兴趣，但当天已经消耗了很多脑力，完全不想继续读一大篇 README。

一开始，我只是把项目链接发给 Claude，让它告诉我这个 Skill 是做什么的。它确实给了我一份文字介绍，但我看到密密麻麻的字还是觉得头大。

于是我换了一种要求：不要再给我写摘要，而是帮我设计一套 mini course。形式可以是 Slides 或 HTML，像一个产品经理给客户做一对一 demo 一样，向我解释四件事：

1. 这个项目是做什么的；
2. 它具体怎么使用；
3. 它在设计上是怎么实现的；
4. 有哪些思路值得我借鉴到自己的产品或 Skill 中。

注意我懒到就连这个要求的描述都是语音告诉他的！！！！连字都懒得打了。。

Claude 很快生成了一套可以直接浏览和交互的 HTML Slides。整个过程中，我几乎没有提供任何视觉设计 Prompt，但成品已经比以前好看很多。这也是我最想分享这期视频的原因之一：**最近几个月，Claude 的视觉设计审美确实有明显提升。**

过去让模型做 Slides，结果往往只是把很多字放进几个方框里。现在它开始更懂得怎么用布局、层级、交互和动态效果来帮助人理解内容。Codex 最近在这方面也进步很多，但这一次 Claude 做出来的结果尤其让我惊讶。

## 这个去 AI 味的 Skill 在做什么

这个 Skill 的核心目标，是识别 AI 写作中经常出现的固定模式，并只修改这些具有明显“AI 味”的部分。

这点对我来说很重要。

很多所谓 AI Humanizer 的问题是，你把一段自己写的文字交给它，它会把整篇文章重新写一遍。最后虽然可能“更像人”，但你原本喜欢的句子、语气和表达方式也一起被改掉了。

Peter 的这个 Skill 采用的是更克制的逻辑：

* 先识别哪些句子触发了常见的 AI 写作特征；
* 只修改这些有问题的部分；
* 尽量保留作者原本的 voice 和其他表达；
* 清楚展示每一处修改及其原因。

它主要有两个功能。

第一个功能是修改文本，减少文章中的 AI 味。

第二个功能是检测一篇文章是否具有明显的 AI 写作特征，相当于一个 AI Slop Detector。

## 为什么修改过程的可视化很重要

我特意让 Claude 在课程中展示这个 Skill 实际运行起来是什么样子，因为我不想为了了解一个工具，先把它安装一遍。

Claude 在 Slides 里做了一个完整 demo：左边是修改前的文本，右边是修改后的结果。被删除的词句会以删除线呈现，鼠标悬停在修改处，还可以看到这句话触发了哪一种 AI 写作问题。

Peter 在这个项目中一共定义了 22 种常见的 AI 写作特征。Skill 会先判断每句话出现了哪些问题，再决定是否修改。

这种设计比“直接输出一篇改好的文章”更适合对文字控制要求较高的人。

因为用户不只是获得一个结果，还能看到：

* 哪句话被模型认为有 AI 味；
* 它为什么做出这个判断；
* 它具体修改了什么；
* 自己是否同意这次修改。

用户可以保留最终决定权，而不是把整篇文章完全交给模型。

最近一段时间，一些做 AI 写作的工具也开始采用类似设计。它们不再只提供一个黑盒式的重写结果，而是更强调 diff、理由解释和逐项接受修改。

我觉得这是一个很好的产品方向：**AI 不应该只是替用户完成工作，也应该让用户理解它做了什么。**

## 这个 Skill 是怎么设计的

除了知道它有什么功能，我更想了解它背后的设计方式。

我经常会通过研究别人的项目，寻找可以借鉴到自己产品和 Skill 中的思路。因此我在 Prompt 里特意强调：不要只教我怎么使用，也要解释它是怎么设计的。

Claude 总结出的一个关键点是：**Skill 的描述本身就是触发器。**

也就是说，Skill 文件不只是描述产品功能，还会明确告诉模型：

* 什么情况下应该调用这个 Skill；
* 它要解决什么问题；
* 具体应该按照什么步骤执行；
* 哪些内容应该修改；
* 哪些内容不应该碰；
* 最终结果应该满足什么标准。

这种写法很像同时定义产品需求、工作流程和行为边界。

另一个值得注意的设计，是它为每一种 AI 写作 pattern 都提供了正例和反例。

仅仅告诉模型“不要写得像 AI”是非常抽象的。通过提供具体例子，模型才能更准确地理解：

* 哪些表达属于问题；
* 哪些相似表达其实可以接受；
* 修改应该做到什么程度；
* 如何避免误杀正常或有个性的语言。

## Worker + Evaluator 的双层结构

我觉得这个项目里最值得借鉴的部分，是它使用了一个 Worker + Evaluator 的结构。

可以把它理解成两个角色：

* 一个角色负责修改文章；
* 另一个角色负责检查修改结果。

Worker 完成初稿之后，Evaluator 会根据预先定义的 rubric 进行评估。如果结果还没有达到标准，就会继续修改和重新检查，直到两边都认为结果足够好。

它很像一个人负责干活，另一个人负责监工。

这个逻辑现在越来越常见于 Skill 和 AI 产品设计中。过去大家更关注的是：

* 我要让模型做什么；
* 我应该给模型哪些步骤；
* 我应该写怎样的 Prompt。

但现在更重要的一个问题是：

**你如何定义“做得好”？**

如果没有 evaluator，模型通常只会生成一次结果，然后任务就结束了。加入 evaluator 和 rubric 后，系统就可以对自己的结果进行检查、打分和迭代。

这也是一种非常基础的自我改进机制。

当然，Evaluator 并不一定真的等于第二个独立模型。它也可能是同一个模型在不同阶段扮演不同角色。关键不在于用了几个模型，而在于系统中是否存在明确分离的“执行”和“判断”。

我目前还没有大量实际使用这个 Skill，所以不能确定它最终的修改质量究竟如何。但从设计上看，这个结构是比较优雅的。

## 我从这个项目里看到的几个可借鉴点

因为 Claude 已经记住了我的一些全局产品哲学，所以在 Slides 的最后，它主动增加了一页 “Steal This”，总结哪些设计可以借鉴到我自己的项目里。

其中比较重要的包括：

第一，给一个 Skill 设计不同模式。

例如这个项目既可以修改文章，也可以只做检测。用户不一定每次都希望模型直接动手，有时只是想获得判断。

第二，为每种规则提供正例和反例。

抽象规则往往不够稳定。具体例子能帮助模型理解边界，也能减少过度修改。

第三，为 Evaluator 设计明确的 rubric。

不能只让模型“检查一下”，而应该具体定义它需要检查什么、什么情况下算通过。

第四，展示修改轨迹和判断依据。

对于写作、分析、审核等高控制需求的任务，仅仅提供最终结果并不够。用户需要看到过程，才能建立信任并做出选择。

第五，只修改真正有问题的部分。

AI 产品经常会为了完成任务而过度干预。一个好的 Skill 需要知道什么时候不应该修改。

这些思路不只适用于写作工具，也可以迁移到其他 AI 工作流里。

例如，我可以检查自己现有的 Skill：

* 是否只有 Worker，却没有 Evaluator；
* 是否定义了成功标准；
* 是否允许用户看到中间判断；
* 是否区分“分析模式”和“执行模式”；
* 是否保留了用户对结果的控制权。

## 为什么我觉得这种学习方式很好用

这次体验让我觉得，用 Claude 把文档转化成课程，是一个非常灵活的使用方式。

当我精力充足时，当然可以直接读 README、代码和文档。但在下班后或者脑力已经耗尽的时候，长篇英文材料的阅读成本会非常高。

Slides 的优势是，它会主动替你完成一部分信息结构化：

* 提取重点；
* 建立章节；
* 设计视觉层级；
* 用 demo 展示抽象功能；
* 把项目的使用方式和设计思路分开解释。

我不需要一上来就理解所有细节，只需要先建立一个整体认知：这个项目是什么、解决什么问题、有哪些值得继续深挖的地方。

看完 Slides 后，我已经能够判断：

* 这个 Skill 值不值得安装；
* 它最核心的两个功能是什么；
* 哪些设计值得学习；
* 下一步我具体想研究什么。

当然，Slides 也有局限。

它相对静态，适合快速建立全局理解，但不适合深入研究所有细节。例如看完之后，我可能还会继续在聊天里追问：

* Evaluator 的 rubric 具体是怎么写的；
* 22 种 AI 写作特征分别是什么；
* 我的哪些项目适合加入 Worker + Evaluator 结构；
* 能不能用这些设计改进我现有的 Skill。

因此我更愿意把 Slides 看成一个入口，而不是终点。

## 一个可以直接复用的 Prompt 思路

当你不想读一个项目的 README 时，可以把链接发给 Claude，然后让它：

> 帮我把这个项目设计成一套 mini course。请像一个产品经理给客户做一对一产品 demo 一样，解释它是什么、解决什么问题、实际怎么使用、背后是怎么设计的，以及有哪些思路值得我借鉴。请用可交互的 HTML Slides 展示，并加入具体的使用 demo，而不只是文字摘要。【也可以根据自己的目标增加要求！】

未来也可以把同样的内容做成音频或视频课程。对于更大、更复杂的项目，我有时也会让模型直接生成视频形式的介绍。

不过从成本和效率上看，HTML Slides 对我来说是一个比较经济的中间方案：它比纯文字直观，又比生成完整视频更快、更省资源。 http://t.cn/AX96L3Bu