在真正添加 Skill 之前，我先给智能体定了身份。这里不是简单改一个名字，而是把它的角色、语言风格和用户偏好都写清楚。
我给它设置的方向是 Java 转 Web3 学习助手，目标用户是 Java 后端背景，但 Web3 基础比较弱的人。它不能上来就讲一大堆陌生术语，也不能把内容写成官方文档翻译。它需要用 Java 后端熟悉的东西解释 Web3，例如数据库表、Service、Map、用户 ID、测试工具等。
这一步非常关键。因为如果不先给智能体一个稳定身份，它很容易变成一个泛泛而谈的问答机器人。你问它什么是区块链，它可能回答一堆概念；你问它什么是智能合约，它可能直接搬一段百科式解释；你问它怎么学习，它可能给出一个很长的路线图，看起来很完整，但用户还是不知道下一步该干什么。
我希望它保持一个简单原则：每次只讲一个小概念，先用 Java 类比，再讲 Web3 里的含义。如果出现用户还没有学过的新词，就放到"以后再学"，不要展开。
这个要求看起来很简单，但实际很重要。因为模型最容易出现的问题就是：它知道很多词，但不知道哪些词当前不该讲。比如在讲账号地址时，它可能顺手提到私钥、签名、助记词、钱包、交易、Gas。如果学习者已经有基础，这些补充是好的；但如果学习者完全小白，这些补充反而会制造新的负担。
所以身份文件的作用，不是让智能体显得更聪明，而是让它更稳定。它需要知道自己不是百科全书，而是一个循序渐进的学习助手。
为什么必须加 Skill#
刚开始我也以为，只要主提示词写得足够详细，这个智能体就能按预期工作。后来发现并不是这样。
提示词能约束回答风格，但它很难保证智能体每次都按固定流程工作。尤其是模型能力一般时，它往往会顺着当前问题直接回答，而不是主动判断"现在应该查官方文档""现在应该用 Java 类比""现在应该更新学习笔记"。
这也是我后来决定加 Skill 的原因。Skill 的价值不是让智能体多会一个概念，而是把一类任务的处理方式固定下来。比如，查官方资料就是一个 Skill；用 Java 类比解释 Solidity 是一个 Skill；运行 Foundry 实验是一个 Skill；分析 Solidity 报错也是一个 Skill。
如果没有 Skill，智能体可能会这样回答：
Solidity 的 contract 类似 Java 中的 class，可以保存状态变量，也可以定义 function。
这句话本身没错，但太薄了。它没有要求查官方文档，也没有要求给 Java 示例，也没有要求给 Solidity 示例，更没有要求给出小白容易误解的点。
如果有了 Skill，就可以强制它按固定格式输出：
- 先说明使用了哪个 Skill；
- 再给 Java 写法；
- 再给 Solidity 写法；
- 再列出对应关系；
- 最后补充容易误解的点。
这样就算模型能力一般，它也有一个固定轨道，不容易跑偏。
我第一个加的 Skill 是官方文档优先。原因很简单，Web3 领域概念多、工具多、版本变化也比较快，如果模型完全靠记忆回答，很容易讲错。比如 Solidity 的版本、Foundry 的命令、OpenZeppelin 的合约继承方式，这些都应该优先参考官方资料。
所以我让这个 Skill 负责强制查阅官方资料。它的目标是避免模型凭印象乱讲。
第二个 Skill 是 Java 和 Solidity 的类比。这个 Skill 是整个学习助手的核心。因为目标用户是 Java 后端，如果解释不能落到 Java 经验上，那学习成本就会高很多。
比如我们可以这样类比：
- Java class 类似 Solidity contract；
- Java field 类似 Solidity state variable；
- Java method 类似 Solidity function；
- Java Map 类似 Solidity mapping；
- Java 用户 ID 可以类比 Web3 地址；
- JUnit 测试可以类比 Foundry test。
当然，这些类比不是完全等价。比如 Java 的对象一般运行在服务器内存里，而 Solidity 合约部署到链上以后，它的状态变化会被记录下来，不能像普通数据库一样随便改。类比只是入口，不是最终结论。这个 Skill 的作用就是先帮小白建立入口，再补充差异。
Skill 体系总览#
最后我整理了一套完整 Skill 体系，不是为了把数量堆多，而是让学习过程能闭环。
web3-official-docs-first#
这个 Skill 的作用是优先查官方资料。它负责把学习内容限制在可靠来源里，避免智能体凭印象讲。对于 Web3 来说，这一点很重要。因为很多教程会混杂各种版本、各种工具链和各种实践习惯，如果一开始就看太杂，反而容易混乱。
这个 Skill 主要处理的问题是：当用户问 Solidity、Ethereum、Foundry、Hardhat、OpenZeppelin 相关内容时，先基于官方资料整理，再用中文解释。这样可以减少"模型说得很顺，但其实不准确"的情况。
java-solidity-bridge#
这个 Skill 是学习助手最常用的 Skill。它负责把 Java 后端概念翻译成 Web3 概念。
比如用户问区块链账本是什么，它不会直接讲分布式账本、共识算法、节点验证，而是先从转账系统讲起。Java 系统里可能有账户余额表和交易流水表。账户余额表可以被更新，交易流水表一般用于审计。区块链的账本更像一套公开且不容易被随便修改的记录系统。
这种解释方式对小白更友好。
foundry-lab-runner#
这个 Skill 用来做本地实验。学习 Web3 不能只停留在概念解释上，后面一定要进入代码和测试。Foundry 是一个常用的智能合约开发工具链，里面的 forge 可以用来构建和测试，cast 可以做链上交互，anvil 可以启动本地节点。
不过在小白阶段，我不会让它直接进入复杂项目，而是先用最小实验。比如 Counter，只包含加一和查询。这样学习者不会一开始就被项目结构、依赖、部署脚本等内容干扰。
openzeppelin-template-builder#
这个 Skill 是为后续进阶准备的。因为当用户开始写标准化合约时，不应该手搓危险代码。OpenZeppelin 提供了很多经过验证的合约组件，比如权限控制、标准 Token、NFT 等。
但这个 Skill 不会在第一课就使用。它的定位是"以后再学"。只有当用户已经理解了基本合约、状态、调用、测试之后，再进入标准模板。这样不会让小白一上来就被继承关系、接口标准、权限模块吓到。
solidity-error-diagnoser#
这个 Skill 用来处理报错。学习编程最容易卡住的地方不是看概念，而是跑代码报错。尤其是 Solidity 和 Foundry 的错误信息，对初学者来说并不直观。
所以我专门加了一个报错诊断 Skill。它要求固定输出：
- 错误原文；
- 错误类型；
- 小白解释；
- 根因；
- 最小修复；
- 重新运行命令。
这个固定流程可以避免模型乱改代码。这个 Skill 强调"最小修复"，也就是只改必要的地方，让学习者能看到问题和修复之间的关系。
web3-study-note-keeper#
这个 Skill 负责学习笔记。是为了让学习者以后能复习。
它会把本次学习内容整理成几个固定部分：
- 今天学了什么；
- 一句话结论；
- Java 类比；
- Web3 正确认知；
- 最小代码；
- 实操命令；
- 踩坑记录；
- 复习问题；
- 下一步学习建议。
这个设计和我平时学习技术的方式比较一致。看完一堆内容不等于学会，真正有用的是能在以后快速回看，知道当时学了什么、哪里踩坑、下一步该做什么。
web3-study-progress-visualizer#
这个 Skill 是后面补充的。原因是我发现光有学习笔记还不够。学习者在过程中还需要看到自己的位置。
很多人学习新技术时会焦虑，不是因为今天没有学会，而是不知道自己到底差多少。Web3 更明显，因为概念太多，随便一个教程就可能引出一堆新词。学习者很容易从"我今天学了一个概念"变成"我怎么还有这么多东西不会"。
所以我加了学习进度可视化 Skill。只负责告诉用户：现在学到哪了、已经掌握了什么、哪些还半会、哪些没学、哪些以后再学、下一步只做什么。
这对小白很有帮助，因为它把学习从一团乱麻变成了一个可见的地图。
实际使用体验#
在实际学习时，我没有让 Agent 一上来讲复杂内容，而是先给它一个小白规则。
规则大概是：
- 我是完全小白，只会一点 Java 后端；
- 每次只讲一个小概念；
- 先用 Java 或普通业务系统类比；
- 不要主动扩展到后面的高级内容；
- 如果出现没学过的新词，放到以后再学；
- 每轮最后问一个简单问题；
- 每轮显示使用了哪个 Skill。
这组规则配合 Skill 后，体验会比普通聊天稳定很多。
比如第一课，它没有直接讲复杂术语，而是从中心化和去中心化的区别开始。它会用普通网站来解释：我们平时写的 Java 系统，服务部署在公司服务器上，数据库也由公司维护，用户访问的是公司的服务。这样的系统很容易理解，因为这就是后端开发每天面对的东西。
再往后，它讲区块链账本时，也没有直接讲一堆概念，而是用转账系统里的账户余额表和交易流水表做类比。
