一位产品经理用12天深度学习Claude Code，却意外发现“用AI学AI”本身就是一个值得设计的产品。本文从亲身经历的每日闭环出发，暴露了AI导师的四个设计盲点，并基于真实学习数据迭代出六角色模型。这不是一个学习故事，而是一次从用户到设计师的递归式产品构建。

上一篇文章讲了 Claude Code 的能力设计逻辑——记忆、协议、自动化、分工、复制，五层递进。那篇的结尾我留了一个悬念：12 天的学习不是一般的自学，而是把我的学习过程用一次“录播+回放”的反蒸馏机制，提炼出六个AI角色，在边学边做中构建出了一个AI导师学习平台。

这不是“我学完了一个顶流agent然后用它做了一个项目”的传统故事。是我在学Claude Code的过程中，发现“用AI学AI”的方式本身就是一个值得设计的产品——然后还是沿用一贯的“做中学”思路，把它搭建起来了。

一、递归的起点：每天被 AI 导师“追着学”是什么体验

先说说我这深度学习的 12 天到底是怎么过的。

我给自己定的计划是系统学完 Claude Code 的 10 个核心模块，每天一个主题（剩下两天利用所学知识亲手完成一个毕业设计）。但不是看文档了事——每天的学习有一个完整的闭环：

开始前，AI 导师先给我做当日主题的 Pre-test，5-10 道题，定位我的起点。它每次都习惯在结尾强调“这是摸底，不是评判，请根据真实情况作答”——这句话后来被我原封不动地写进了自己设计的测评官 Skill 里。

自学阶段，我根据AI导师列示的推荐材料开始阅读、动手做做小实验、思考知识点与我的项目关联。

结束后，AI 导师做 Post-test，同等难度但不同的题目，量化我今天到底学到了什么。然后是多维度评分——不是简单打个总分，而是从概念理解、项目映射、设计质量、启发深度、行动导向等多个维度分别打星评级，每个维度都带具体的证据说明。

举个例子，Day 5 学 Subagent 那天，AI 导师的评语里写道：“最突出的能力是独立判断力——不盲从模板预置的 4 个候选 Subagent，而是用学到的标准逐一排除。”这不是“做得好”三个字能给的信息量。

评分之后还有两个动作：一是留作业——“基于今天的学习，你的知识库项目可以做哪些改进？”每天 3-5 条，当天可完成的当天会检查复盘；二是预告明天的学习重点，还会抛出 2-3 个值得思考的问题，让你带着问题进入下一天。

最后，每天结束时它会引导我做一件事：写一句话总结今天最大的收获。 不是写给它看的，是写给自己看的。Day 4 我写的是：“Hook 是绑定 Claude Code 事件的自动化——源头用阻断，治理用提醒。”Day 7 我写的是：“这周最大的收获不是学了某个功能，而是打开了一个新的认知窗口——每个功能背后都藏着工程师对人机协作的深度思考。”

这个每日闭环跑了 10 天，Pre-test 平均分 2.7，Post-test 平均分 8.4，平均增量 +5.7。但数据不是最重要的——最重要的是，这个闭环让我亲身体验了一个“有温度的 AI 导师”应该是什么样子，以及我期望的导师还应该具备哪些素质。 它不只是在传递信息，它在关注我的学习状态、记住我的项目背景、追踪我的成长轨迹、在我受挫时换一种方式解释。

这种体验本身，成了后来设计学习平台时最核心的灵感来源。

但 10 天跑下来，4 个学习过程中的痛点也真实地浮出水面。

痛点一：学习过程中没人带。 测评管的是“学了没有”，项目导师管的是“学了怎么用”，但“学的时候看不懂怎么办”——没有人管。读英文技术文档卡在一个概念上，要么是自己开另一个窗口去查，要么是通过/btw问问，再切回来继续读，生怕污染了整个学习过程的上下文。

痛点二：学习模式一刀切。 我是带着自己的知识库项目去学的，所以每天都被要求“今天学的东西对你项目有什么用”。但 Day 10 学 Plugin 底层配置时，确实之前没接触过，映射起来也着实牵强——让我意识到不是所有学习内容都必须有对应的项目可以关联。

痛点三：测评维度太窄。 每天的测试主要测“能不能用起来”。但“知道自己不知道什么”和“能把概念和其他领域联系起来”——这两种更高阶的认知能力，完全没有被衡量。

痛点四：交互缺人格。 AI 导师执行任务高效，但大部分时候交互是冰冷的。分数提高时它说“你的分数提高了”，而不是说“你还记得 Day 1 只拿了 2 分吗？今天同样难度的题你拿了 8.3 分”。

这 4 个痛点不太会在初始的毕设计划中预知。必须亲身经历一次完整的学习过程，才能发现哪里有裂缝。最好的需求调研不是访谈用户，而是自己当一回用户。

二、一张观察表暴露了初始设计的盲点

第 11 天的学习主题是“毕业项目设计”。但在启动设计之前，我做了一件事：回看了自己 10 天来每天填写的“AI 导师五角色观察表”。 这是我初始设计这个学习平台时构想的5种AI角色，大家各司其职，共同辅助我的学习过程。

这张表是我从 Day 1 就开始维护的——每天花 2 分钟记录：AI 导师的五个角色中，哪个今天发挥了作用？哪里好用？哪里失效？

这张表的价值不在于验证了“哪些角色有用”，而在于暴露了“哪些角色应该适配哪些学习场景”。好的设计不是从白板上画出来的，是从真实使用数据中长出来的。

原因也不复杂——我的这次学习旅程其实是“设计导向型”的：学一个功能 → 映射到项目 → 做决策。在这个模式下，我不需要检索外部资料，每天的学习材料也是预先分配好的（来自于Claude howto的仓库）。资料管家和垂直资料库假设的“研究型学习”场景，在我身上没有发生，但不代表不应该存在。

更关键的发现是表格里反复出现的一个“改进想法”：Day 4 写的是“技术细节太多缺少直观感受，可能需要更多实例演示”；Day 5 写的是“建议亲手配一个最小 Hook 建立直觉”。 这些改进想法指向的是同一个缺口——学习过程中遇到理解障碍时，没有一个“讲解员”角色随时待命，帮我真正吃透一个概念。

Day 7 的 Week 1 小结里，我直接写下了设计方案修正建议：“增加‘实战教练’角色——帮助用户在日常使用中建立直观感受。Week 1 最大的‘欠账’是实战体验不足，这个缺口不是资料检索能补的，需要有人推着去动手。“

这就是最终六角色模型的雏形。 不是坐在白板前画架构图画出来的，是从 10 天真实学习数据中”长“出来的——五角色模型覆盖了学习的”前后环节“（规划、测评、应用），但学习过程本身——阅读、理解、消化——完全交给了自学。讲解员就是在这个时候横空出世的。

三、从角色到组件：六角色不等于六个 Agent

有了六个角色框架，下一个问题是：怎么把它们落地到 Claude Code 的组件体系中？

最直觉的做法是每个角色做一个 Subagent。但这个做法犯了一个常见错误——多 Agent 协作的核心问题不是“怎么分工”，而是“围绕什么协作”。 六个角色不是六个独立数字员工，它们围绕的是同一个学习者、同一份学习记录。

我逐一分析了六个角色的特性，发现它们对 Claude Code 组件的需求完全不同：

最终方案是 3 个 Skill + 3 个 Subagent + 2 个 Hook + 4 个 Command + 1 个 MCP 占位——六角色不是六个 Agent，而是一个异构组件系统。

这里面有几个值得记录的设计判断。

讲解员为什么每次解释不超过 3 个概念？ 这是我第 7 天的亲身体验——有一次我一口气问了 5 个概念，结果 AI 的解释越往后越敷衍，我自己的理解也越来越浅。信息过载不是解释不够，是一次塞太多。这个约束是从真实使用中提炼出来的，不是拍脑袋定的。

测评官为什么做五维度评分？ 因为我被原来那套“只测能不能用”的评估方式折磨了 10 天。Day 5 我 Post-test 拿了 9.5 分——整个学习周期的最高分。但我当时就在想：这个 9.5 只说明我“会用”Subagent 了，不说明我理解它和其他组件的关系，也不说明我知道它的边界在哪里。所以新设计的测评官把评分拆成了概念理解（30%）、场景应用（25%）、边界认知（20%）、跨域联想（15%）和术语理解（10%）五个维度，而且不同学习模式会调整权重——项目驱动模式加重场景应用，纯粹认知模式加重概念理解。

项目导师为什么要三种学习模式？ 痛点二的直接产物。项目驱动模式输出改进动作列表（具体到文件/模块），领域探索模式输出领域洞察列表（趋势/机会/风险），纯粹认知模式输出知识网络图（新概念→旧概念的连接）。三种模式不是写死的——路径规划师可以在阶段检查点建议切换。

四、一个 800 字的文件定义了整个系统的灵魂

Day 12 是实现日。我创建了 22 个文件来落地整个 Plugin。

这 22 个文件中，最有设计价值的不是任何一个 Skill 或 Subagent，而是一个 800 字的共享文件——teaching-style-guide.md。

这个文件的灵感直接来自我 10 天的学习体验。每天结束时，AI 导师都会给我做多维度评分和反馈。我注意到一个细节：它的反馈风格对我的学习状态影响巨大。 当它在 Day 5 说“最突出的能力是独立判断力”时，我知道自己做对了什么，以及为什么做对了。当它在 Day 10 指出“用户对配置/协议类细节的学习效率低于架构/设计类讨论”时，它没有说“你这里不行”，而是用了一种让我愿意去改进的表达方式。

还有它在我连续受挫时的表现——Day 8 学 MCP，Post-test 只拿了 6.1 分，是 10 天里最低的。它没有说“别灰心”，而是精准定位了问题：“Post-test 分数低于 Round 表现，协议细节和调试手段是持续弱项”，然后建议“Week 2 可尝试用更多实战案例来填补细节空白”。不是虚假安慰，是换策略。

我把这些真实体验提炼成了六种交互规则，写进 teaching-style-guide.md，被所有组件通过 @import 共享引用：

学习者理解正确时：

• ❌ “答对了”
• ✅ “你抓住了关键点——X 的核心确实是 Y，这个观察很敏锐”
• 原则：肯定要有具体原因，让学习者知道为什么对

学习者理解有偏差时：

• ❌ “错了，正确的是……”
• ✅ “前半部分理解得很准确，不过后半部分有个常见的误区——很多人都会在这里踩坑”
• 原则：先肯定正确的部分，再用”常见误区”的框架指出偏差

学习者连续受挫时：

• ❌ “别灰心”
• ✅ “这个概念确实不好理解——你卡在了 Z 这个环节。我们换个角度：不从头讲，我从你觉得理解的部分接着往下推”
• 原则：定位具体的卡点，换策略而非重复解释

学习者提出好问题时：

• ❌ “好问题！”
• ✅ “这个问题问到了点子上——它其实是理解 X 和 Y 之间关系的关键”
• 原则：解释为什么这是好问题，而不是空洞赞美

问题超出当前范围时：

• ❌ 强行回答或敷衍
• ✅ “这个问题很有价值，会在 Day N 学到。现在先记住它——到时候你会发现它和今天的内容有关联”
• 原则：承认价值，给出时间线，制造期待感

学习者取得明显进步时：

• ❌ “进步很大”
• ✅ “你还记得 Day 1 只拿了 2 分吗？今天同样难度的题你拿了 8.3 分”
• 原则：用具体数据展示成长轨迹，让进步可感知

六种交互规则被所有组件共享——路径规划师、讲解员、测评官、项目导师都引用同一个文件。一个文件改变了，整个系统的“人格”就跟着变。

这个设计选择来自学习 Plugin 章节的一个认知：好的 Plugin 不是功能的合集，而是共享基因的载体。teaching-style-guide.md 就是这个系统的“基因”——它定义了“亦师亦友”的交互基调，让六个角色不管各自在做什么，都用同一种方式和学习者对话。

AI 导师学习平台最核心的文件，不是任何一个功能组件，而是一份定义了“怎么和人说话”的风格指引。

五、冒烟测试：用学习过程本身来验证系统

完成整体构建后，冒烟测试。我对 22 个文件做端到端审查，用的测试场景是“Claude Code 2 周冲刺学习”本身——也就是我正在经历的这次学习。

结果：4 个 Bug + 4 个设计缺陷。

最有意思的是这些问题的共同特征：单个组件审查时全部通过，问题全部出在组件间的交互点。

• 进度追踪脚本的正则表达式和会话日志模板的表格格式不匹配——两个文件各自正确，组合时才发现格式不兼容
• 6 个文件的 @import 路径深度错误——每个文件的相对路径单独看都“合理”，放在 Plugin 目录结构中才暴露
• 资料管家没有 memory 字段，导致无法避免重复推荐——Subagent 每次调用都是干净的上下文窗口，天然没有跨会话记忆

单个组件正确 ≠ 系统正确。 构建和验证必须分离——你不能用“我写的时候觉得是对的”来代替“我验证过它确实是对的”。

8 个问题修复过程中新增了 2 个配置文件，系统从 22 个扩展到 24 个。修复后冒烟测试矩阵 20/20 通过。冒烟测试的价值不在于找 Bug，在于验证你对系统的理解和现实之间的差距。

Day 12 还有一个意外收获：从 11 天的学习数据中收割了 5 张方法论卡片（配合我的知识库体系）。其中一张叫“先体验后设计”——Day 1-10 的体验让 Day 11 的设计方案包含了 4 个只有亲身经历才能发现的痛点，这些痛点恰恰成了系统最核心的差异化价值。

学习过程本身就是最好的需求调研——你不需要采访用户，你自己就是那个最诚实的用户。

收束：一个递归闭环

回头看这 12 天，产出的不只是一个学习系统。

我学到了 Claude Code 的能力体系（上一篇文章的内容），然后用这些能力构建了一个学习 Claude Code 的系统（或者说是可以学习任何其他知识的通用系统）。学习产出成为设计素材，设计过程成为学习内容，验证过程又使用了学习过程本身。

这个递归结构不是刻意设计的，是做到某个阶段自然浮现的。当你用“先手动跑通一遍 → 从产出中反向拆解成功路径 → 将关键步骤固化为可复用系统”的方法论来学习时，递归就会发生。

最终的系统包含 24 个文件：3 个 Skill、3 个 Subagent、4 个 Command、2 个 Hook、1 个 MCP 占位、1 个全局风格指引、3 个模板、1 个 Plugin 清单，以及若干配置和文档。但最有价值的不是任何单个文件，而是两个设计决策：讲解员角色的加入（从 10 天观察表中“长”出来的需求），和 teaching-style-guide.md 的抽取（从 10 天被 AI 导师“追着学”的体验中提炼出来的交互基因）。

如果有人问我“用 AI 学 AI 是什么体验”，我会说：

不是你学会了 AI 然后做了一个 AI 项目。是你在学习 AI 的过程中，发现“学”这个动作本身就是一个值得用 AI 来解决的问题——然后你用它解决了。

感兴趣的小伙伴欢迎体验看看

GitHub 地址：https://github.com/Sean-xhz/ai-learning-platform