将 Claude Code Skills 嵌入 JAR 包——积木报表的创新突破
在国内低代码工具领域，积木报表（JimuReport）v2.5.0 首次实现了突破性尝试：它将 Claude Code 的 Skills 机制直接封装进产品 JAR，成为内置的领域知识专家。用户启动服务后即可即刻使用，完全无需安装 Claude Code 或配置 CLI 环境。
要理解这一举措，得先回顾一个背景。过去两年，业界纷纷喊出“接入大模型”的口号，然而真正让人满意的产品寥寥无几。问题根源并非模型能力不足，而是接入方式过于浅层——多数产品仅在界面中嵌入一个对话框，用户输入后交给通用 API，返回文本简单展示。模型根本不了解“这个产品是什么”、“用户正在执行什么任务”、“正确的操作路径是什么”。当你让它“帮我做一张分组交叉报表”，它只能给出泛泛的文字建议，无法真正操作设计器、生成数据集或配置字段绑定。
Claude Code 的 Skills 机制，原本就是为了攻克这一难题而生。它允许开发者将特定领域的知识和操作规范封装成“技能包”，AI 严格按照 Skill 定义的流程执行，而非自由发挥。但问题在于，Skills 最初面向的是开发者：你需要先安装 Claude Code CLI、配置 Skills 目录、理解触发规则，普通业务用户根本无法上手。
积木报表的做法，是直接跨越这道门槛：将积木报表的操作规范、API 调用流程、字段绑定规则全部封装成产品内置的 Skills，随产品 JAR 一同分发。用户只需配置一个 DeepSeek API Key，无需了解任何 Skills 工作原理，就能获得与 Claude Code Skills 等效的领域 AI 智能。这一步，实现了从“开发者工具”到“产品能力”的跃升。
Claude Code Skills 是一套怎样的机制？
要理解“内置 Skills”，必须先搞清楚 Claude Code 的 Skills 究竟是什么。
Claude Code 是 Anthropic 推出的 AI 编程工具。它的 Skills 系统运转逻辑十分清晰：开发者可以将特定领域的知识、操作规范、执行步骤打包成一个个“技能包”。当 AI 接收到任务时，会先检查是否有匹配的 Skill，若有，则严格按照 Skill 中规定的流程执行，而不是完全自由发挥。
这样一来，带来了三个关键改变：
- 可预期：AI 的行为不再是“看心情”，每次执行路径都是确定的。
- 可控制：域外操作不会被 Skill 涉及，越界风险显著降低。
- 领域专精：Skill 内封装了大量产品知识，AI 能够理解“什么是分组”、“如何绑定数据集”，无需从头推理。
用一个类比：通用大模型就像一个什么都懂一点的全科医生，而带有 Skills 的 AI 则是一位经过系统培训、熟悉你医院系统、了解你病历规范的专科医生。同样是接诊，深度完全不同。
问题在于，Claude Code 是一个独立工具，普通用户不会主动安装并配置它。如果产品的 AI 能力依赖 Claude Code，推广门槛过高，等于把产品智能化建立在用户环境配置的不确定性之上。
内置 Skills：将专家认知“熔铸”进产品
积木报表 v2.5.0 走的路子非常清晰：不依赖 Claude Code 工具，而是将 Claude Code 的 Skills 设计思想直接内化到产品中。
具体来说，产品团队将积木报表领域的知识——什么是分组报表、什么是交叉报表、数据集如何绑定、图表如何配置、SQL 如何生成——全部封装成产品内置的 Skill，底层模型替换为 DeepSeek。用户只需在配置文件中填写几行 API Key，无需安装 Claude Code，也无需了解 Skills 的工作原理，开箱即可使用与 Skills 等效的领域 AI 能力。
jeecg:jmreport:ai:base-url: https://api.deepseek.comapi-key: sk-xxxxxxxxmodel: deepseek-v4-protemperature: 0max-tokens: 16384autoTableEnabled: false # 生产环境建议关闭自动建表集成积木的 Maven 依赖：
org.jeecgframework.jimureport jimureport-spring-boot3-starter 2.5.0 org.jeecgframework.jimureport jimubi-spring-boot3-starter 2.5.0 这几行配置背后，是产品内置的完整报表 Skill 体系：支持 18 类报表类型的自然语言生成、对话式样式修改、一键回滚、AI 数据建模……用户感知到的是“一句话生成报表”，但 AI 之所以能做到，是因为它已经掌握了报表设计器的每一个操作节点该如何处理。
这与“直接调用通用 LLM API”有本质区别：
| 对比维度 | 通用 API 接入 | 内置 Skills |
|---|---|---|
| AI 对产品的理解 | 无，依赖临时 Prompt 描述 | 深度，封装在 Skill 内 |
| 执行路径 | 每次都不确定 | 固定、可预期 |
| 领域深度 | 浅，受 Prompt 质量影响 | 深，Skill 内包含完整操作规范 |
| 用户门槛 | 需要掌握 Prompt Engineering | 自然语言即可 |
| 稳定性 | 高度依赖模型状态 | Skill 兜底，稳定性更高 |
为什么 AI 产品都需要内置 Skills？
这不仅仅是积木报表一个产品的问题，而是所有 AI 垂直产品都必须面对的选择。
根本原因在于：通用大模型的泛化能力与垂直产品的专业深度，是两个不同维度的目标。
大模型在泛化方面已经足够强大——理解意图、生成内容、逻辑推理，这些基础能力都具备。但“在这个具体产品中应该如何操作”、“这个业务术语对应的配置路径是什么”——这些产品级别的知识，不可能通过通用预训练获得，必须由产品方自行注入。
Skills 机制正是解决这一问题的标准化方式。它并非 Prompt Engineering 的升级版，而是将产品知识和操作规范系统化地注入 AI 决策链路，使模型在特定产品场景中的表现，从“勉强能用”升级为“真正好用”。
实测中，积木报表的 AI 修改报表能力（对话式改样式、加合计、改图表）稳定性极高，这正是内置 Skill 的体现——修改操作具有明确的步骤和边界，Skill 规范了 AI 的行为，而不是让模型自由发挥。
Skills 的趋势：从工具脚本到认知基础设施
展望未来，Skills 机制的演化方向值得深入思考。
趋势一：Skills 成为垂直 AI 产品的标准配置。
积木报表是国内低代码/报表工具中首个将 Claude Code Skills 能力产品化落地的案例，但它不会是最后一个。随着更多产品团队意识到“接入大模型”与“拥有领域 AI 智能”是两件不同的事，Skills 体系将从先发者的竞争优势，逐渐演变为行业标准配置。未来两年，不带内置 Skills 的 AI 垂直产品，可能就像今天没有搜索功能的应用——不是不能用，但用户会觉得缺了点什么。
趋势二：Skills 粒度越来越细，可组合性越来越强。
早期的 Skills 较为粗粒度，比如“生成报表”算一个 Skill。随着实践积累，Skills 会拆分为更细粒度的单元：解析用户意图、选择报表类型、生成 SQL、绑定数据集……每个单元独立可测、可替换，组合起来完成复杂任务。这种细粒度化，使 Skills 的维护和迭代变得更加工程化，也为不同产品之间的 Skills 复用创造了空间。
趋势三：底层模型与 Skills 体系解耦。
积木报表用 DeepSeek 驱动内置 Skills，但 Skills 本身与模型无关。未来成熟的产品，会把 Skills 体系做成可对接任意模型的中间层——今天用 DeepSeek，明天换成更好的模型，Skills 体系无需重写，只需更换底层模型接口。这样一来，产品不再被某一家模型厂商绑定，Skills 也真正成为产品的核心资产，而非模型的附属品。
总结
“内置 Skills”这个术语背后，代表的是 AI 产品化的一次认知升级：从“接入大模型”到“拥有领域智能”。
通用大模型是原材料，Skills 是加工工艺，产品才是最终交付物。只有将产品知识、操作规范、边界约束系统化地封装进 AI 的决策链路，大模型的能力才能在具体产品场景中稳定落地，而不是停留在 Demo 演示的水平。
积木报表 v2.5.0 的这次尝试，是一个值得借鉴的行业先例。它证明了 Skills 机制可以脱离 Claude Code 工具独立存在，可以用更轻量的方式内化到任何产品中，让任何用户都能享受到领域专精 AI 的价值。这条路，值得更多产品团队认真研究和跟进。
