如果你最近在折腾 Claude Code、Codex 这类编程智能体应该会注意到一个词开始频繁出现skill。它既不是新语言也不是新框架而是一种把 AI 的某项能力按任务封装成可复用包的做法。我把“图表生成”做成了这样一个 skill开源在 GitHub 上陆陆续续攒了一些 star。最近我完成了一次比较大的更新把之前零散的图表能力重新梳理成了一整套完整流程。这篇文章不想只列更新清单我想把这次更新背后的判断、内部结构、实际用法和容易踩的坑一起讲透。先说这次我最想强调的一个判断图表 skill 的价值不在于让 AI 多会画几种图而在于把“生成图表”从一次碰运气的对话变成一套可复用、可约束、可交付的工程流程。1. 为什么图表类任务最值得先做成 skill1.1 让 AI 画图真正的瓶颈从来不是“写代码”先说结论让大模型写一段 ECharts 配置现在已经不算难事。你给它一份数据它通常能写出像模像样的折线图、柱状图、饼图。但如果你真的要把这些图拿去做周报、放进数据看板或者交付给业务方问题马上就会冒出来——颜色不统一、坐标轴单位丢失、类型选得不合适、数据格式一换就报错。每一轮对话都要重新交代背景同一个需求换一个说法结果就完全不一样。这也是我最初想做图表 skill 的原因。把图表生成做成 skill本质上不是让 AI “多会一种画图方式”而是把一次碰运气的对话变成一套有约束、可复用、能交付的工程流程。智能体在生成图表时不再依赖临时发挥而是按照 skill 里约定好的步骤走看懂数据、选对图表类型、套用模板、补齐视觉细节、最后再做一次输出检查。1.2 图表任务为什么特别适合 skill 这种载体skill 之所以适合图表是因为图表任务有两个特点。第一个特点是输入和输出边界都很清晰。输入是结构化数据、字段说明、标题、主题风格输出是一份可运行的图表配置或 HTML 文件。边界清晰意味着封装成本低也意味着智能体不容易跑偏。第二个特点是过程里有大量需要固定的隐性经验。比如饼图不适合展示超过 8 个分类时间序列数据要优先考虑折线图而不是柱状图深色背景下要避免使用浅色系标签数据量大的时候要关闭过渡动画。这些经验写进系统提示词里会很啰嗦但如果沉淀成 skill 的规则和模板每次调用都能稳定生效而且可以随项目迭代。从工程角度看把隐性经验显性化本身就是一种生产力。过去这些经验只存在于资深前端或者数据分析师脑子里现在可以随 skill 文件一起分发。这也是为什么我坚定认为图表是 skill 化最值得做的方向之一。2. 这次大更新核心是把“会画”升级成“画得稳”2.1 从少数图表类型扩展成一套常见图表覆盖这次更新最直观的变化是图表类型覆盖面。早期版本只处理最基础的折线图、柱状图和饼图也就是很多教程里常说的扇形图。这次我把常见业务图表基本补齐了雷达图、散点图、漏斗图、热力图以及一个很多人专门提需求的六边形图表生成器。六边形图表适合表达能力雷达、画像分析、多维指标对比这类场景。它和普通雷达图最大的区别在于视觉密度更高每个维度之间的过渡更自然用来做个人能力评估或者产品优势对比时观感明显不一样。很多数学建模场景里也会用到这类图表做维度对比所以我把这个图表做成了独立模板。用户传一个维度列表和分值数组skill 会自动生成对应的 ECharts 配置。2.2 科技感图表模板数字占比环形图与动态线条除了常规图表这次还加入了一个非常有代表性的科技风视觉模板中心放一个占比数字周围发散出长短不一的动态线条。严格来说它是环形图加动态装饰层的组合。中心数字突出核心指标周围线条用来表达多维数据或时间序列变化动态效果让页面看起来有数据流动感。这个模板在数据大屏、技术宣传页、年终总结里很常见。实现思路并不算复杂中心用 ECharts 的 title 或 graph 节点放主数字外层用极坐标柱状图或者自定义 series 模拟长短线条再配合动画和渐变色。难点在于参数多而且第一次写很容易出现线条不齐、动画卡顿、中心数字被遮挡的问题。把它固化到 skill 里之后用户只需要提供指标名称、数值和配色剩下的细节由模板处理。2.3 更新过程中踩过的坑这次更新也踩了不少坑挑三个有代表性的说。第一个是 ECharts 版本兼容问题。模板里用了部分新版本特性但很多用户环境里装的是旧版本升级后出现配置不生效。后来我在模板头部加了版本说明同时把不兼容的写法改成兼容写法避免一上来就要求用户升级。第二个是数据注入方式。一开始模板里直接塞示例数据用户替换时经常改错位置。后来我把数据部分改成统一入口所有数据都从同一个对象传入模板内部做映射。这样用户只需要关心数据格式不需要理解图表配置的嵌套结构。第三个是动画效果和性能的平衡。动态线条看似简单数据量一大就容易掉帧。我加了一个开关项默认在数据量超过某个阈值时自动关闭部分动画同时允许用户手动控制。这类细节不是功能点但决定了你做的 skill 能不能在真实场景里被长期使用。3. 拆开一个图表 skill 的内部结构3.1 skill 的装载机制它像一张岗位说明书先解释一个基础问题skill 到底是怎么被 AI 使用的以常见的编程智能体为例agent 在启动时会扫描指定目录下的 skill 文件夹。每个 skill 文件夹里一般有一个说明文件用来描述这个 skill 什么时候触发、负责什么任务、有哪些步骤、有哪些规则。agent 遇到相关任务时会先读取说明文件再结合附带脚本、模板、示例按步骤执行。你可以把它理解成给 AI 发了一张岗位说明书。说明书写清楚岗位职责、工作流程和验收标准AI 就照着执行。没有说明书AI 就像一个新人进了公司没有人告诉他流程和标准只能临场发挥。这也是“图表 agent”和“图表 skill”的区别agent 是一个完整的执行体而 skill 更像是一份可以被复用、被分发、被改写的专业能力包。3.2 我的图表 skill 文件结构我的图表 skill 采用的是一个比较标准的结构核心文件包括SKILL.mdskill 的入口说明描述触发条件、工作流程、输出规范和禁忌。templates存放各类图表的 ECharts 配置模板按图表类型拆分。data存放示例数据、数据格式说明和字段映射规则。scripts存放辅助脚本比如把 CSV 转成图表所需 JSON、做数据清洗等。examples存放效果图和成品示例方便 AI 对照生成。SKILL.md 里我会明确要求 AI 按五步走读数据、选类型、匹配模板、填参数、自查输出。这五个步骤是这次更新里最重要的流程目的是让输出结果可预期。3.3 核心设计取舍用模板约束而不是让模型自由发挥这是整个 skill 设计里最关键的判断图表配置不能让大模型自由发挥。自由发挥的好处是灵活但坏处是输出不稳定。同一份数据生成十次可能有八种不同的配色、坐标轴和布局风格这对用户来说是不可接受的。尤其是在团队协作和交付场景里图表风格必须统一。所以我采用了一种偏保守的策略每个图表类型都有固定模板模板里只留数据、标题、配色、是否开启动画等几个参数槽位。AI 的任务是理解数据、选择合适的模板、把数据正确映射到参数槽里。这样既保留了适应性又把不确定性控制在一个可接受的范围里。换句话说我关心的不是 AI 能不能画出一张惊艳的图而是它能不能每次都稳定交出一张符合要求的图。稳定才是 skill 存在的价值。这个取舍也决定了用户拿到的不是一张秀肌肉的作品而是一套可持续用的工具。4. 从 GitHub 克隆到跑出第一张图完整上手路径4.1 环境准备和安装先说明一点这个 skill 不是独立桌面软件它需要配合支持 skill 机制的编程智能体来使用。不同 agent 对 skill 目录的规定不完全一样常见的做法是把项目克隆到 agent 指定的 skills 目录下。安装前先做三件事确认 agent 版本支持 skill 能力并确定它读取 skill 的目录路径。确认当前网络能正常访问 GitHub 仓库页面和下载文件。网络层面的前置问题需要先在自己的环境里解决这里不展开。确认运行环境里有 Node.js因为模板生成和示例脚本都用到了 Node。我用到的 ECharts 版本以项目的 package.json 为准。安装的核心动作就是克隆仓库然后把目录放到 agent 的 skills 路径下。具体路径不同 agent 不一样以你使用的 agent 文档为准。命令就是一个常规的 git clone我在这里不写死仓库地址避免误导。# 示例结构把克隆下来的 skill 目录放到 agent 的 skills 路径下 git clone 项目仓库地址4.2 用自然语言触发图表生成安装完成后直接在 agent 对话里描述需求即可。比如“请使用图表 skill把这份季度销售数据生成一张折线图Q1 120 万Q2 180 万Q3 210 万Q4 165 万。主题用科技风。”agent 识别到任务后会主动读取 skill 说明按流程生成 ECharts 配置。你也可以在提示词里补充更多约束指定图表类型、配色、是否显示数据标签、是否开启动画、输出 HTML 还是纯配置等。一个比较稳定的触发句式是“使用图表 skill 数据 图型类型 风格要求 输出格式”。这个句式来自我对用户使用习惯的观察也写进了 SKILL.md 的示例里。4.3 单张图验证与输出检查第一次跑通后不要急着直奔复杂模板。我建议先做一次单张图的输出检查重点看五个位置数据对应关系是否正确尤其是数值、单位、时间格式有没有被错误转写。图表类型是否符合预期不要出现“要饼图却给了环形图”这类偏差。标题和图例是否完整坐标轴是否丢失单位。配色和主题是否符合要求深色模板下文字是否可读。动画开关是否按预期生效数据量大时是否有卡顿。如果以上都正常再尝试批量生成或者接入自己的数据文件。单张图跑通只能说明流程没有断真正要验证的是模板和规则在更多数据形态下是否依然稳定。5. 最容易踩坑的五个环节以及排查顺序5.1 先看现象再看输入再看环境最后看参数和所有工程问题一样图表 skill 出问题时也不能上来就改模板。我建议按照这个顺序排查。第一步记录现象。是完全没输出、报错还是输出了但图不对、图丑、图卡不同现象对应不同层次的问题。第二步看输入数据。CSV 是不是用了中文逗号日期字段是不是被识别成字符串数值列里是不是混入了空值和单位很多图表异常根因都在数据格式上。第三步看运行环境。Node 版本是否满足要求ECharts 版本是否和模板匹配agent 是否真的读取到了 skill 目录权限是否正确。第四步看生成参数。有没有传错图表类型名配色参数是不是传成了非法字符串动画开关是 true 还是 on这类问题往往是模板和提示词之间的字段约定不一致导致的。最后才考虑工具边界。如果模板本身不覆盖某个特殊布局不要强行让它生成换一种图表类型或者手工调整是更务实的做法。5.2 输出“看起来对但细节不对”的典型场景下面是实际使用里频率最高的几个细节问题以及对应的处理思路。现象常见原因处理建议中文标签显示为方块字体资源或编码问题检查字符编码确认页面引入中文字体数据标签重叠图表宽度不足或标签过多调整标签角度、关闭部分标签或增大画布时间轴顺序错乱日期字段被当作字符串在数据预处理里转换为标准日期格式饼图分类太多看不清楚数据分类数量超限合并小类或用纵向柱状图替代动态线条不显示动画被阈值逻辑自动关闭查看模板开关确认数据量阈值配置tooltip 点击无反应事件绑定或版本不兼容检查 ECharts 版本和 tooltip 配置层级这张表不需要背它真正要传达的是大多数图表问题不是“AI 不会画”而是“数据没准备好”或者“模板参数没对齐”。所以排查的时候把 60% 的精力放在数据和参数上比反复改提示词更有效。5.3 明确边界这个 skill 不适合做什么作为开源项目作者我更想把这个边界说清楚避免用户产生不切实际的预期。这个 skill 适合数据探索阶段的快速可视化、会议材料里的示意图表、数据分析报告配图、个人博客或技术分享里的图表以及需要统一视觉风格的中小规模图表产出。它不太适合大数据量的实时监控大屏因为这类场景需要专门的流式数据方案和性能优化对像素级设计一致性要求极高的品牌图表这类场景应该用专业设计系统和代码模板维护需要复杂交互的 BI 看板比如联动、下钻、地图边界绘制这些需求交给成熟 BI 工具或专业前端方案更合适。清楚边界才能把 skill 用在它真正能发挥价值的地方。6. 从“画图”到“数据工作流”这类 skill 的长期价值6.1 生成图表不是终点交付图表报告才是我一直觉得图表 skill 的终局不是“生成一张图”而是“生成一个可以交付的物”。所谓交付可能是网页报告、PPT 配图、数据分析结论的视觉支撑或者是一个自动定时产出图表的脚本。这次更新里我刻意做了一件事把输出结构标准化。skill 既可以直接输出 ECharts option 配置也可以输出一个带图表和简要数据说明的 HTML 文件。用户后续可以把这个 HTML 直接分享也可以把它接入自己的模板系统。标准化的价值在单次使用时体现不明显但在长期复用和二次开发时非常重要。6.2 给不同用户的三条实践路径不同身份的用户使用这个 skill 的方式可以完全不同。如果你主要用 AI 辅助写代码我建议把 skill 当作一个代码生成工具箱。每次让 AI 生成图表时明确要求“使用图表 skill”并对照输出检查表做检查。如果你主要做数据分析或写报告我建议重点用数据预处理加图表模板这条链路。先让 skill 帮你清洗数据、识别字段再选择合适的图表模板形成“数据进来、图表出去”的工作流。如果你是开源爱好者我希望你把它当作一个可拆解的参考项目。看 skill 的目录设计、提示词组织、模板参数划分然后应用到你自己领域的 skill 建设中。三条路径遵循同一个框架先跑通单次任务再固化模板和规则最后接入真实数据源和输出流程。6.3 下一步计划关于后续方向我有几个明确的想法继续增加图表类型尤其是地图和时序大屏类把数据清洗能力做得更完整让用户可以直接上传 CSV 就能得到分析图表增加自定义主题导入能力让团队可以把品牌色系直接应用到所有图表模板上以及为更多的 agent 环境提供开箱即用的安装配置。这些方向不是一次更新能完成的而且开源项目最大的特点是真实用户的需求会不断重塑项目方向。所以我也建议使用者盯着自己的场景去用发现问题就去提 issue或者直接改模板。一个 skill 只有被真正用起来才会越用越顺。回到开头那个判断这次更新的重点不是多加了几个图表类型而是让图表生成这件事变得稳定、可复用、可交付。单次跑通只能说明流程没有断真正有价值的是把整个流程固定下来让 AI 每次都能交出一张符合预期的图让你的时间和注意力可以放到数据解读和业务判断上去。如果你也想试试先克隆项目、跑通一张最简单的折线图然后从你最常做的那类图表开始改造它。开源项目最迷人的地方就是它永远可以被下一个真实需求继续推着往前走。