前言
最近我一直在想一个问题：如果一个 Java 后端开发想学习 Web3，到底应该从哪里开始？
如果直接去搜 Web3 入门，大概率会看到一堆陌生词，比如钱包、地址、合约、链上、交易、Gas、Token、ERC20、NFT、部署、测试网等。对于已经有区块链基础的人来说，这些词可能很正常，但对于一个只熟悉 Java 后端、Spring、数据库、接口、MQ、测试环境的人来说，这些词其实是有门槛的。
我一开始也想得比较简单，觉得既然是 Java 转 Web3，那就直接让智能体讲 Solidity，再让它写一个合约，然后跑一下测试就行了。后来实际使用下来发现，这个思路并不适合纯小白。因为小白真正的问题不是不会写 Solidity，而是还没建立 Web3 的基础认知。你上来让他看 ERC20，他可能连 ERC20 是一个标准都不知道。你让他理解 mint，他甚至不知道为什么链上要有这种操作。你让他看智能合约，他脑子里也没有"链上的程序"这个模型。
所以我最后调整了方向：不再一上来追求复杂代码，而是做一个真正从 Java 后端视角出发的 Web3 学习助手。它的目标不是炫技，也不是生成一堆看起来很厉害的合约代码，而是让学习者先从熟悉的概念开始，比如数据库表、流水表、用户 ID、Service 方法、Map、测试工具，然后再慢慢过渡到 Web3 里的账本、地址、链上程序、状态、调用和本地测试。
这次我用 QClaw 做了一个 Java 转 Web3 学习助手，并且给它补充了一整套 Skills。最终的效果是，它不是只靠一句提示词来回答问题，而是可以按照固定的学习流程工作：先查官方资料，再用 Java 类比解释，再生成最小实验，再运行工具，再解释报错，最后沉淀学习笔记和学习进度面板。
这篇文章就记录一下我从设计思路到落地过程中的一些调整，也看一下这种 Agent 对一个 Web3 小白到底有没有帮助。
一开始的思路其实不对
一开始我想做的学习链路是比较"技术视角"的。比如：Java 积分系统对应 ERC20，账户余额对应 Token balance，管理员发积分对应 mint，然后再用 OpenZeppelin 生成一个 ERC20 模板，最后用 Foundry 跑测试。
从技术角度看，这条链路没有问题。因为 ERC20 确实是 Web3 开发里非常常见的内容，mint 也是 Token 合约里常见的操作，OpenZeppelin 也是写标准合约时经常使用的安全组件库。问题在于，这条路线默认学习者已经知道很多背景知识。
对于一个完全小白来说，他可能并不知道什么是 Token，也不知道为什么需要 ERC20。如果一开始就把这些词丢给他，其实很容易让人产生一种感觉：这东西是不是离我太远了？
这和我们学习 Java 时是一样的。一个刚接触 Java 的人，你不能上来就讲 JVM 调优、AQS、分布式事务、Netty、线程池参数调优。虽然这些东西很重要，但它们不是入口。真正的入口应该是变量、方法、类、对象、集合、数据库、接口调用。只有这些基础概念建立起来以后，再去看高级内容才不会那么痛苦。
所以我后来把学习链路重新拆了一遍。第一步不是 ERC20，而是公开账本。第二步不是 mint，而是账号地址。第三步不是合约模板，而是链上的小程序。再往后才是最小代码、本地实验、多人数据、权限控制等内容。
也就是说，我希望这个智能体先回答这样的问题：
- Web3 的"账本"到底像 Java 系统里的什么？
- Web3 里的"地址"是不是类似用户 ID？
- 智能合约是不是可以理解成链上的 Service？
这些问题看起来很基础，但对于小白来说非常重要。因为只有这些概念先对齐了，后面学习 Solidity、Foundry、OpenZeppelin 才有意义。
先给智能体定身份
在真正添加 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 系统，服务部署在公司服务器上，数据库也由公司维护，用户访问的是公司的服务。这样的系统很容易理解，因为这就是后端开发每天面对的东西。
再往后，它讲区块链账本时，也没有直接讲一堆概念，而是用转账系统里的账户余额表和交易流水表做类比。
这个例子对 Java 后端很友好。因为账户余额表和交易流水表都是熟悉的东西。账户余额表可以更新，交易流水表用于审计。区块链账本可以先粗略理解为一种公开、可追溯、不容易随便改的记录系统。
这种解释不是最完整的区块链定义，但它适合作为入口。小白先知道"它大概像什么"，后面再慢慢补充差异。
再比如账号地址，它也用 Java 用户 ID 来类比。
在 Java 系统里，我们通常用用户 ID 标识一个用户。Web3 里的地址，也可以先理解为链上识别用户或账户的标识。当然，地址和普通 ID 不完全一样，但小白阶段先理解"它代表谁"就够了。
这几轮学习下来，我明显感觉到它比普通问答更适合小白。普通 AI 工具会给你一个完整答案，但完整不一定适合学习。这个 Agent 会尽量把内容压成一个小概念，再用熟悉的东西解释。
学习进度可视化
这和我们学习 Java 时也一样。如果你刚学完变量，就看到别人讨论 JVM、分布式事务、微服务、消息队列、高并发，你也会觉得压力很大。但实际上你不是落后，你只是处在当前阶段。问题是需要一个东西告诉你：你现在在哪，已经会了什么，下一步只做什么。
所以我又加了一个 web3-study-progress-visualizer Skill。
这个 Skill 的设计不是每次生成一份新的报告，而是固定一个 HTML 模板，再用一个数据文件更新学习状态。也就是说，页面本身不需要反复创建，智能体只需要更新数据，打开同一个页面就能看到最新进度。
它展示的信息包括：当前学习阶段；总体进度；学习地图；已掌握内容；半会内容；未学内容；以后再学内容；Skill 使用情况；学习时间线；下一步行动；不需要焦虑的原因；复习问题。
这个面板里有一个我认为比较重要的设计，就是把内容分成"已会、半会、未学、以后再学"。
很多学习焦虑来自于把所有不会的东西都看成"我必须马上掌握"。但实际上不是这样。有些内容今天必须学，有些内容只需要知道名字，有些内容以后再学就行。
后续计划
后面我准备继续沿着这条路线往下做。
第一步是继续完善小白课程。当前已经可以从中心化网站、公开账本、账号地址开始讲，后面可以继续讲链上的小程序、最小代码、多人数据、本地实验和权限控制。
第二步是让 Foundry 实验真正贯穿学习过程。比如每学一个概念，都有一个最小代码和测试，不追求复杂，但必须能跑。
第三步是继续优化报错诊断。学习者真正容易卡住的地方往往是报错，而不是概念。报错解释 Skill 如果做得足够好，会非常有帮助。
第四步是把学习笔记和进度面板联动起来。学完一课后，自动生成笔记，同时更新进度面板。这样每次学习都有记录，也能看到自己的位置。
第五步是等基础阶段稳定后，再逐步引入 OpenZeppelin、标准合约、部署、前端交互等进阶内容。也就是说，不是不学高级内容，而是等基础模型建立以后再学。
总结
这次用 QClaw 做 Java 转 Web3 学习助手，我最大的感受是：学习类 Agent 的关键不是让它一次讲很多，而是让它按正确顺序少讲一点。
对于 Java 后端来说，Web3 入门最容易卡住的地方不是代码，而是概念入口。直接讲复杂术语，很容易让小白放弃。更好的方式是先从熟悉的东西开始，比如数据库表、交易流水、用户 ID、Service 方法、Map、测试工具。等这些类比建立起来以后，再慢慢进入 Web3 自己的体系。
QClaw 的价值在这里体现得比较明显。通过身份配置和 Skills，我可以把自己的学习要求固化进去，让它不再只是一个普通聊天机器人，而是一个有流程的学习助手。
当然，它还不完美。模型仍然需要强约束，Skill 也需要写得很细，触发词要明确，学习路线要控制得足够小。但从这次实践来看，它已经能解决一部分真实问题：让小白知道从哪里开始，让学习过程有节奏，让每次学习有记录，让进度能被看见。
我觉得这就是 AI Agent 在学习场景里的价值。它不是替你直接掌握知识，而是帮你降低开始的门槛，减少中途的迷茫，并把学习过程变得更可控。