企业官网建设流程全解析

这次我们来看一个和“装模型、跑显存”完全不是一个路子的 AI 项目：DAIR.AI 推荐的/eli5技能。它的目标不是让你生成一张图或一段语音，而是让 AI Agent 把那些又深又硬的技术概念，用“给 5 岁小孩讲清楚”的方式解释出来，并且优先输出可视化内容。换句话说，它是解决“技术文档看不懂、AI 回答太硬核、汇报 PPT 不好画”这类问题的一种技能包。

先说结论：这个技能不需要 GPU，不需要一键包，不需要处理 CUDA 和显存占用。你只要有一个支持自定义技能（Skill）的 AI Agent 环境，比如 Claude Code、Codex、OpenClaw 这类框架，把 DAIR.AI 推荐的技能 Markdown 放进去，就能直接让 Agent 按“一句话版本 → 5 岁版本 → 生活类比 → 可视化图示”的结构输出。它是目前 AI Agent 技能生态里最实用的方向之一：与其重复输入提示词，不如把解释逻辑沉淀成一个可复用的技能文件。

这篇文章会以/eli5技能为例，完整演示怎么把一个技能文件装进 Agent、怎么测试它的解释与可视化效果、怎么通过 API 做批量概念解释、以及实际使用中容易踩的坑。无论你是做技术文档、做新人培训、写方案汇报，还是单纯想让 AI 给自己讲明白一个新概念，这篇内容都值得收藏备用。

1. 核心能力速览

这里要明确一点：/eli5不是一个独立的软件项目，也没有可下载的模型权重。它是一个定义好“解释逻辑”的技能文件，核心价值在于让 Agent 的输出从“堆名词”变成“讲人话”。DAIR.AI 长期以来维护 LLM、Prompt Engineering 和 Agent 相关开源资源，它把这个技能单独挑出来推荐，本质上是在推动“AI 输出的可解释性”落地到日常工作中。

1.1 /eli5 技能到底是什么

/eli5的全称是 “Explain Like I'm 5”，意思是“像对 5 岁小孩解释一样”。它和普通提示词的区别在于：提示词只是一次性指令，而技能文件是一套完整的、可复用、可约束输出格式的解释框架。

一个标准的/eli5技能文件会包含：

• 技能触发条件：哪些场景下应该使用这个技能。
• 解释步骤：先给一个核心结论，再用简单语言拆解。
• 输出格式约束：强制要求包含类比、可视化、示例。
• 可视化生成规则：优先用 SVG 或 ASCII 图表达结构和关系。

所以它在实际工作中的价值很大：团队周会让 AI 解释一个复杂的系统架构，生成的 SVG 图可以直接贴进文档；学习新技术时让 Agent 用“5 岁版本 + 生活类比”讲一遍，理解速度会明显提升。

2. 适用场景与使用边界

从适用场景看，/eli5技能最合适的用户有三类。

第一类是技术文档写作者和内容运营。技术博客、产品说明书、公众号科普文章都强调“通俗易懂”，但把注意力机制、RAG 检索增强生成这类概念讲清楚并不容易。把概念丢给/eli5技能，让它先输出 5 岁版本和生活类比，再由人工补充细节，效率会高很多。

第二类是开发者和算法工程师。遇到一个新框架、新协议、新模型时，可以先让 Agent 按/eli5结构化解释一遍，快速建立整体认知，再去读源码和论文。这样可以减少“打开文档一小时，还不知道这项目是干嘛的”的挫败感。

第三类是非技术角色的协作场景。产品经理、设计师、运营在和研发沟通时，经常会遇到术语障碍。用/eli5技能把技术方案转成“人话版本”和可视化图示，能显著降低沟通成本。

不过使用边界也要说清楚。这个技能的输出质量完全依赖于底层模型的理解能力，模型本身对某些前沿概念的理解可能不够准确。所以/eli5适合辅助理解，不适合作为最终技术决策的唯一依据，尤其是涉及模型架构、安全机制、协议规范这类严肃内容时，必须核对原始资料。

另外，如果要把/eli5生成的解释用于对外发布或商用，需要确认内容有没有错误、有没有侵犯版权；如果解释的内容涉及内部系统架构、算法逻辑、用户数据，还要注意不能把敏感信息直接喂给外部 API 服务，建议在私有化部署的模型环境中使用。

3. 环境准备与安装部署

3.1 环境准备

因为/eli5是一个技能文件，不是独立服务，所以没有复杂的依赖安装。准备重点在 Agent 框架本身。

• 操作系统：Windows / macOS / Linux 都可以，取决于你用的 Agent 工具是否支持。
• Agent 运行时：需要一个支持自定义技能的 Agent 框架，比如 Claude Code、Codex、OpenClaw，或者其他基于 Skills 机制的 AI 编码工具。
• 模型服务：可以是用 Anthropic API、OpenAI API，也可以是本地部署的开源模型。如果走本地模型，需要按模型实际要求准备显卡和显存；如果走云端 API，则不需要 GPU。
• 磁盘空间：技能文件本身只有几 KB，基本可以忽略。
• 网络环境：需要保证 Agent 框架能够正常访问它依赖的模型接口。

3.2 技能目录与加载方式

不同的 Agent 框架对技能目录的约定不完全一样。以常见的 Claude Code 和 OpenClaw 为例，技能文件通常会放在固定的skills目录下，每个技能一个子目录，子目录里至少包含一个SKILL.md文件。

# 示例：技能目录结构 ~/.claude/skills/ ├── eli5/ │ ├── SKILL.md │ └── examples/ │ └── rag_example.md

如果是 OpenClaw 这类框架，技能目录可能位于：

# OpenClaw 技能目录示例 ~/.openclaw/skills/

更稳妥的做法是直接查看你使用的 Agent 框架的官方文档，确认技能目录和加载方式。技能文件放入对应目录后，通常需要重启 Agent 进程才能生效。

3.3 /eli5 技能文件参考模板

下面是一个可以直接参考的/eli5技能模板。它定义了技能名称、描述、触发方式和输出结构，实际使用时可以按需修改。这个模板遵循通用 Agent 技能格式，放到具体框架时可能需要微调字段名。

--- name: eli5 description: 当用户要求解释复杂技术概念、术语、论文、系统架构时， 使用“像对5岁小孩解释一样”的方式，分步骤输出简单解释和可视化图示。 --- # ELI5 技能 ## 触发场景 1. 用户直接输入 `/eli5 <概念名>`。 2. 用户要求“用简单的话解释”“讲给非技术人员听”“做成可视化说明”。 3. 用户要求将技术文档或代码结构转成通俗版本。 ## 执行步骤 1. 先输出一句话核心结论。 2. 用生活化的类比解释核心机制。 3. 拆解关键组成，每个组成用不超过两句话说明。 4. 生成一张可视化图示，优先采用 SVG 内联格式或 ASCII 图。 5. 最后补充 1 到 3 个真实场景例子。 ## 输出格式约束 - 禁止直接复制原术语定义。 - 禁止在解释中出现超过 2 个未解释的专业名词。 - 可视化部分必须和解释结论对应。 - 如果概念过于复杂，先输出最核心的子概念，再逐步扩展。 ## 参考类比库 - 数据库索引：书的目录。 - 缓存：冰箱里常用的食材。 - 卷积：用放大镜扫描图片。 - 注意力机制：聚光灯扫过舞台。

这个模板的用意是把“解释逻辑”固化下来。AI Agent 每次执行/eli5时都会遵循这套步骤，而不是自由发挥，这样输出质量会更稳定。

3.4 技能启用自检

技能文件放好后，建议先做一次启用自检。

# 进入 Agent 交互界面，直接测试技能触发 > /eli5 什么是数据库索引？ # 如果 Agent 没有按模板输出，而是当成普通问题回答， # 说明技能没有被正确加载，需要检查目录路径和文件格式。

判断标准很简单：如果 Agent 的输出结构符合模板要求，说明技能生效；如果输出结构比较随意，优先排查技能目录是否挂载正确、文件头部格式是否被框架识别。

4. 功能测试与效果验证

4.1 测试案例 1：RAG 的图文解释

RAG（Retrieval-Augmented Generation，检索增强生成）是当前大模型应用里的高频概念。用/eli5技能解释 RAG，可以比较直观地验证技能有没有生效。

输入示例：

/eli5 什么是RAG？

按照技能模板，预期输出应该包括：

1. 核心结论：RAG 是让大模型先查资料再回答问题的机制。
2. 生活类比：就像考试时允许翻书，先找到相关章节，再组织答案。
3. 组成拆解：检索模块负责找资料，生成模块负责组织语言。
4. 可视化图示：一张用户→检索→知识库→拼接→生成的流程图。
5. 真实例子：客服机器人查产品手册后再回复用户。

其中可视化部分可以用简单的 SVG 表示。下面这段代码是对“RAG 流程”的一种可视化输出示例，实际由模型生成时会根据上下文调整。

<svg width="700" height="220" xmlns="http://www.w3.org/2000/svg"> <rect x="10" y="70" width="90" height="50" rx="6" fill="#e8f4fd" stroke="#333"/> <text x="30" y="98" font-size="14">用户提问</text> <line x1="100" y1="95" x2="190" y2="95" stroke="#666" stroke-width="2" marker-end="url(#arrow)"/> <rect x="190" y="70" width="100" height="50" rx="6" fill="#fff3cd" stroke="#333"/> <text x="205" y="98" font-size="14">检索模块</text> <line x1="240" y1="70" x2="240" y2="20" stroke="#666" stroke-width="2"/> <rect x="150" y="10" width="180" height="40" rx="6" fill="#d4edda" stroke="#333"/> <text x="170" y="35" font-size="14">知识库/文档</text> <line x1="290" y1="95" x2="380" y2="95" stroke="#666" stroke-width="2"/> <rect x="380" y="70" width="100" height="50" rx="6" fill="#d1cfe2" stroke="#333"/> <text x="395" y="98" font-size="14">生成模块</text> <line x1="480" y1="95" x2="570" y2="95" stroke="#666" stroke-width="2"/> <rect x="570" y="70" width="110" height="50" rx="6" fill="#f8d7da" stroke="#333"/> <text x="585" y="98" font-size="14">最终回答</text> </svg>

4.2 测试案例 2：Cross-Attention 机制

第二个测试可以用多模态模型里的 Cross-Attention（交叉注意力）机制，这个相对更抽象。输入：

/eli5 什么是Cross-Attention？

预期输出结构：

1. 核心结论：Cross-Attention 是模型让文本和图像相互对齐的机制。
2. 生活类比：就像两个人对话时，一边听对方说话，一边看着对方表情来理解意思。
3. 组成拆解：Query 来自当前任务，Key 和 Value 来自待对齐信息。
4. 可视化图示：用两组输入之间的连接线表示注意力权重分配。
5. 真实场景：文生图模型根据文字提示生成对应图像。

如果这一步的输出仍然包含大量“Query”“Key”“矩阵”等术语，说明技能模板或模型指令约束不够强，可以适当加强模板中的“禁止出现专业名词”约束。

4.3 判断成功与失败的标准

技能执行成功的判断标准可以归纳为四点：

• 解释结构完整：一句话版本、类比、拆解、图示、例子都在。
• 非技术读者能懂：解释里没有未说明的专业黑话。
• 可视化有信息量：图示不只是装饰，而是真的帮助理解关系或流程。
• 内容基本准确：类比和描述没有实质性错误。

最常见的失败情况是 Agent 忽略技能模板，直接按普通问答模式输出。这种情况通常不是/eli5模板本身的问题，而是技能加载失败，需要重新检查技能目录。另一种常见问题是模型对前沿概念理解不够，导致类比变味，这时候需要人工修正，不能直接照搬输出。

5. 接口 API 调用与批量任务

5.1 单条接口调用

/eli5技能在有 API 能力的 Agent 框架中，可以作为 Prompt 层面的能力被外部程序调用。下面给出一个通用的 API 调用示例，实际请求地址和参数需要按你使用的 Agent 框架或模型服务商调整。

# 通用 curl 示例，实际 URL 和 Header 按服务商文档修改 curl -X POST "https://api.example.com/v1/chat/completions" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{ "model": "your-model-name", "messages": [ { "role": "system", "content": "你是一个擅长通俗解释技术的助手，请严格按 /eli5 技能模板输出。" }, { "role": "user", "content": "/eli5 什么是向量数据库？" } ], "max_tokens": 1200 }'

如果使用的是 Claude Code 之类的框架，还可以通过它提供的 CLI 模式直接传参，把/eli5技能作为 prompt 前缀注入。

5.2 批量概念解释脚本

批量解释是/eli5技能最有工程价值的使用方式。比如有一份术语表，想一次性生成通俗解释和图示，可以写一个 Python 脚本逐条调用 API。

import time import requests # 按实际服务接口和鉴权方式修改 API_URL = "https://api.example.com/v1/chat/completions" API_KEY = "YOUR_API_KEY" HEADERS = { "Content-Type": "application/json", "Authorization": f"Bearer {API_KEY}" } concepts = [ "RAG", "Attention Mechanism", "Vector Database", "LoRA" ] def explain(concept: str) -> str: payload = { "model": "your-model-name", "messages": [ { "role": "system", "content": "你是 ELI5 解释助手。请按如下结构输出：一句话结论、5岁版本、生活类比、组成拆解、SVG可视化、真实例子。" }, { "role": "user", "content": f"/eli5 {concept}" } ], "max_tokens": 1200 } resp = requests.post(API_URL, json=payload, headers=HEADERS, timeout=120) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] if __name__ == "__main__": for concept in concepts: print(f"========== {concept} ==========") try: result = explain(concept) print(result) except Exception as e: print(f"[error] {concept}: {e}") time.sleep(2) # 控制请求频率，避免触发限流

批量任务设计上建议注意几点：

• 每个概念单独请求，避免一个长任务失败导致整批重来。
• 增加请求间隔，避免并发过高触发限流。
• 给单个请求设置超时，默认 120 秒比较稳妥，模型输出长文本时需要时间。
• 把失败概念单独记录，最后统一重试。

如果你使用的是本地私有化模型，可以把 API 地址改成本地服务地址，这样处理内部术语表时不需要担心数据外传问题。

6. 资源占用与性能观察

/eli5技能本身几乎不消耗任何计算资源。整个技能文件的大小只有几 KB，运行时也不会在本地启动任何模型服务。真正的资源开销取决于 Agent 框架底层使用的是云端模型 API，还是本地 GPU 模型。

如果使用云端 API，需要关注的指标主要是单次请求的 Token 消耗和响应时间。/eli5的输出比普通问答长很多，因为要求同时输出文本解释、类比和 SVG 图示。一次完整的解释可能消耗 500 到 1500 Token，比普通问答高出不少，实际数值以模型计费页面为准。

如果使用本地模型推理，显存占用和推理速度取决于模型参数量、上下文长度和输出长度。生成 SVG 图示的部分会明显增加输出 Token 数量，所以单次请求耗时也会相应增加。要观察性能，可以用自带监控工具或者简单的脚本打印耗时：

# 伪代码，记录单次请求耗时 start_time=$(date +%s) # 执行 /eli5 请求 end_time=$(date +%s) echo "elapsed: $((end_time - start_time))s"

资源优化上，优先推荐两条路。一是把可视化图默认改为 ASCII 图，而不是 SVG，这样 Token 消耗会更低，也更容易预览。二是限制输出长度，在技能模板中设置“可视化图不超过 10 行”，可以有效控制成本。对于内部高频批量任务，建议提前用几个中等复杂度的术语测试单次耗时，再决定是并发调用还是串行调用。

7. 常见问题与排查方法

排查时有一个基本原则：先确认技能是否被加载，再检查模板约束是否生效，最后才怀疑模型能力问题。大多数情况下，技能不生效都出在前两步。

8. 最佳实践与使用建议

基于/eli5技能的使用逻辑，下面这些实践值得收藏。

第一，先建立自己的解释模板，不要直接照搬别人写的。DAIR.AI 推荐的/eli5只是一个起点，真正适合自己的技能文件应该包含自己熟悉领域的类比库。比如数据库工程师可以内置“索引=书的目录”“事务=银行的转账流程”等类比，这样相同技能在不同团队里效果会差很多。

第二，对输出格式做硬约束。可视化图尽量指定格式，比如“必须输出一个 SVG，宽 600，高 300，不能包含外部图片引用”，减少模型自由发挥的空间；文本部分限定段落结构，先一句话，再类比，再分点，这样每次输出结构稳定，方便二次编辑。

第三，批量任务要带日志和重试。调用外部 API 时，网络抖动、限流、超时都很常见。建议引入tenacity之类的重试库，或者写一个简单的重试循环，记录每次请求的输入、输出、耗时和失败原因。

第四，合规和安全意识不能少。用/eli5解释公开技术概念没有问题，但不要把公司内部架构、用户数据、未公开算法细节直接提交到外部 API。需要处理敏感信息时，优先选择私有化部署模型，或者对输入内容做脱敏处理。

第五，输出内容需要人工复核。AI 生成的类比往往生动，但不一定完全准确。尤其是用于培训、教学、对外文档时，一定要让有经验的工程师把一遍关，不能直接把模型输出当成最终交付物。

9. 总结与下一步

/eli5这个技能最值得尝试的点，是它把“技术解释”这件本来非常依赖个人表达经验的事情，变成了一个可复用、可约束、可批量执行的工程流程。它不需要显卡，不需要复杂的部署，只要有一个支持技能的 Agent 环境就能跑起来。先验证一个自己经常讲不清楚的技术概念，让 Agent 用“一句话版本 + 生活类比 + 可视化图示”输出一遍，然后对照原始资料检查准确性，你就能很快判断这个技能在自己的工作流里值不值得长期用。最容易踩的坑是技能文件没有被正确加载，导致 Agent 仍然以普通问答模式输出，所以第一步一定是从技能目录自检开始。后续如果要把/eli5沉淀成团队工具，可以继续扩展：按团队领域内置专用类比库、把批量解释服务封装成 HTTP 接口、接入文档生成流水线，或者发布成团队内部可共享的技能包。