返回博客首页
把复杂概念讲明白：从 ELI5 Skill 拆出一套可复用的解释工作流
很多 AI 的解释失败，不是因为它不知道知识，而是它没有决定该省掉什么、该保留什么。读者问“RAG 是什么”，回答却从向量维度、嵌入模型一路讲到索引参数；看似完整，读完仍不知道它在产品里解决什么问题。
Anthropic 公开的 Claude Plugins Community 仓库 中有一个 eli5 Skill。它的目标很直接：面对零基础读者，用“大图、少文字”的 HTML 页面解释一个主题。这个公开定义没有规定固定的学科内容或结论，却给了一个很实用的约束：解释不是把资料缩短，而是为某个读者重新组织资料。
上图把一份可读解释拆成六层。读者每通过一层，都能回答一个新的问题；如果某一层答不上来，前面的术语堆得再漂亮也没有用。
先别让 AI “通俗一点”，先写清这四个输入
“给我讲简单些”几乎没有约束。把下面四项补齐，模型才知道该删什么、举什么例子。
| 输入 | 要写清的内容 | 例子 |
|---|---|---|
| 读者 | 已经知道什么、容易混淆什么 | 会写 SQL，但没接触过向量检索的产品经理 |
| 任务 | 读完后要做什么 | 能判断一个客服问答是否需要 RAG |
| 范围 | 本次不展开哪些内容 | 不讲 embedding 训练和向量库选型 |
| 证据 | 可引用的材料和不能猜的部分 | 产品文档、真实接口字段、待核验数据 |
如果这些输入缺失，AI 往往用“全面”来掩盖不确定：塞入三四个定义、许多优点和一串术语。对新手而言，这比明确说“这里先不展开”更难理解。
一份能落地的 ELI5 解释，至少经过五次改写
1. 用一句话说清“它替谁省掉了哪一步”
先写产品或概念的职责，限制在 30 字左右。不要从定义开头。
- 不好：RAG 是把检索与生成结合的技术路线。
- 更好：RAG 先从你的资料里找证据，再让模型基于这些证据回答。
第二句让读者知道为什么要用它：当客服答案必须来自最新知识库，而不是只靠模型记忆时，RAG 才有价值。
2. 只保留一个类比，并说明它在哪里失效
类比的作用是搭起第一座桥，不是替代事实。RAG 可以类比成“开卷考试”：模型先翻指定资料，再回答问题。紧接着补上边界：检索到的资料也可能过期、无关或自相矛盾，模型不会因为“开卷”就自动正确。
这样做能避免两种常见问题：把类比讲成原理，或只给比喻不给操作。每个类比后都应有一句“它不等于什么”。
3. 用一个可检查的微型案例走完全程
不要给十个行业场景。选择一个输入、一个中间过程、一个输出就够了：
用户提问：退款多久到账？
检索范围：售后知识库中最近 90 天、已发布的规则
取回证据：退款时效说明、节假日例外条款
回答要求：引用命中的条款；未命中时明确转人工
读者看到这个例子，才会理解“检索”发生在哪里、“回答”受什么约束。没有证据时，示例必须标成示意，不能编造成真实后台结果。
4. 让图示承担结构，别让图里塞进段落
ELI5 的公开描述要求“大图、少文字”。把它翻译成页面动作，就是让图片解释关系，让文字解释判断。适合画成图的内容包括流程、层级、输入输出和取舍；适合留在文字中的内容包括条件、例外、数字口径和行动要求。
一张解释图通常只回答一个问题：步骤先后是什么、两件事如何连接，或为什么要做选择。图中每个节点只保留短词；把“为什么”放在图前后的两三句话里。
5. 在结尾写出边界和下一步
好解释会告诉读者什么时候不能照做。例如，RAG 不适合把权限、更新频率和文档质量都留空后再指望模型补救。结尾给一件可执行的事：拿十条真实问题测试检索命中率，记录未命中的原因，再决定补文档还是改检索规则。
可直接复制的提示词：把资料变成解释页
下面这段比“用小白能懂的话解释”更稳定。把方括号替换为你的材料即可。
你是面向[读者类型]的解释编辑。请用一个独立 HTML 页面解释[主题]。
读者已知：[已有知识]
读完后要能做：[具体行动]
材料与事实边界：[粘贴链接、原始材料或已核验事实]
本次不展开：[排除范围]
输出要求：
1. 开头用不超过 32 字的一句话说明“它替谁解决什么问题”；
2. 只用一个贴近日常的类比，并紧接着说明类比失效的地方；
3. 给一个从输入到输出的微型案例，未知数据标记为【待核】；
4. 设计一张 SVG 或 HTML 流程图，图中每个节点不超过 8 个字；
5. 用“什么时候别用它”列出 2 个边界；
6. 结尾给出今天能完成的一个验证动作；
7. 不编造数字、引用、产品能力或用户案例。
如果交付的是 HTML，额外要求它在手机上可读：正文最大宽度、足够大的字号、深浅对比清楚；图示使用可缩放 SVG 或 CSS，而不是把小字号文字烤进图片。这样读者还能复制术语、搜索页面、用阅读器朗读。
用这张检查表验收，不要只看“像不像人话”
| 检查项 | 通过标准 | 失败信号 |
|---|---|---|
| 首句 | 不看后文也知道它解决什么问题 | 仍以百科定义开头 |
| 术语 | 第一次出现就被翻译或替换 | 连续出现三个没有解释的名词 |
| 案例 | 有明确输入、过程、输出 | 只有“可以用于很多场景” |
| 类比 | 明确指出不适用之处 | 类比被当成机制本身 |
| 视觉 | 图解释关系，文字解释判断 | 把一段文章缩小塞进流程图 |
| 事实 | 数字、能力和引用能回到原始材料 | 为了顺畅补出未知细节 |
可以让另一位不了解主题的人只看页面三分钟，然后回答：它解决什么、需要什么输入、不能解决什么、下一步该做什么。四题中有两题答不上来，就回到输入定义和微型案例重写。
把解释规则接进日常 AI 工作流
把这段提示词保存成团队模板，要求每次解释都附上读者、行动、范围和证据字段。通过 Code0 调用模型时，也可以把这些字段作为固定的请求结构；模型、接口和可用能力以控制台当前信息为准。重点不是让解释显得更“聪明”，而是让读者能复述、能验证、能接着做事。
本文依据公开项目说明整理，不代表 Anthropic 或任何第三方的官方发布。项目内容、接口和可用性请以对应仓库与产品文档为准。
