1. 项目概述一个住在你编辑器里的学习伙伴如果你用过 Cursor大概率会和我有一样的感受这玩意儿太强了但用着用着就有点“失控”。它确实能帮你写代码、回答问题但对话经常是散的一个问题一个答案聊完就忘。你想用它系统性地学点东西比如备战一场技术面试或者啃下一个复杂的技术栈会发现它更像一个“知识速记员”而不是一个“学习教练”。它没法帮你规划学习路径没法帮你把零散的知识点结构化更没法在你学完一周后帮你安排复习对抗遗忘曲线。这就是 Lumi 诞生的背景。它不是一个独立的应用而是一套“长”在 Cursor 编辑器里的 AI 学习操作系统。你可以把它想象成你 Cursor 里的一个“学习伙伴”我给它起了个名字叫“小团子”。它的核心不是一个大而全的单一功能而是由 35 个独立的、可插拔的Cursor Skill组成。每个 Skill 都是一个微小的、聚焦的 AI 能力模块解决学习过程中的一个具体痛点。你可以单独安装使用其中任何一个也可以像搭乐高一样把它们组合起来形成一个从“学什么”到“怎么学”再到“怎么讲清楚”、“怎么不忘”的完整闭环。我设计它的初衷就是想解决自学和备战中最磨人的五个问题目标模糊、学了就忘、知识零散、无法抗遗忘、表达不清。Lumi 把这五个问题拆解到了七个层级Phase每个层级下用 5 个具体的 Skill 来攻克。目前最基础的“对话层”Phase A已经发布了 3 个核心 Skill你可以现在就装来试试让 AI 和你协作的方式先来一次升级。2. 核心设计思路从“对话工具”到“学习系统”传统的 AI 工具使用模式是“问答式”的用户提问AI 回答一轮结束。这种模式对于碎片化查询很高效但对于需要深度、系统性和持续性的学习任务来说是低效甚至有害的。它助长了知识的碎片化堆积而非结构化内化。Lumi 的设计哲学是“系统化干预学习全流程”。它不再把 AI 视为一个被动的回答者而是将其定位为一个主动的、具备“元认知”能力的学习协作者。这个思路体现在以下几个层面2.1 分层解耦的架构设计Lumi 的 7 个 Phase 并非随意排列而是模拟了一个高效学习者的心智模型和行动流L1 对话层 (Phase A)这是地基。如果 AI 连“人话”都说不好或者满嘴“AI 味”比如“作为一个 AI 模型…”后续的一切都无从谈起。这一层确保协作的基本质量。L2 输入层 (Phase E)解决“学什么”的问题。基于目标如岗位 JD进行情报收集和分析让学习从一开始就有的放矢而不是盲目地“从入门到放弃”。L3 组织层 (Phase B)解决“怎么存”的问题。将输入的知识通过编年史、个人 Wiki类似 Karpathy 的 LLM 知识库理念等方式进行结构化沉淀形成可连接、可检索的知识网络而非孤立笔记。L4 练习层 (Phase C)解决“怎么练”的问题。依据《认知天性》的原理通过主动回忆出题测验和间隔重复SM-2算法将短期记忆转化为长期记忆对抗艾宾浩斯遗忘曲线。L5 输出层 (Phase D)解决“怎么讲”的问题。运用费曼技巧和金字塔原理训练你将知识清晰、有结构地表达出来并能经受住层层追问。知道和能讲清楚是两回事。L6 实战层 (Phase F)解决“怎么备战”的问题。将前几层的能力整合生成可执行的作战计划Sprint Plan并进行每日复盘和心态调整模拟真实备战环境。L7 进化层 (Phase G)这是系统的“大脑”。通过观察你的使用模式自动识别高频、有效的对话模式Instinct并将其演化为新的 Skill让系统能自我成长。这种分层设计的好处是极度灵活。你不需要一次性部署整个庞然大物。比如你今天只想改善和 AI 的对话质量那就只装 Phase A 的三个 Skill。明天你需要准备面试再按需激活 Phase E情报和 Phase F作战的相关模块。2.2 Skill 即插即用的微服务理念每个 Lumi Skill 都是一个独立的文件夹里面包含一个SKILL.md文件。这正是 Cursor Skills 的机制。当你通过安装脚本将其放入~/.cursor/skills/目录后Cursor 就能在对话中识别并调用它们。关键设计在于“触发方式”。每个 Skill 的SKILL.md文件顶部都有一个 Frontmatter 区域其中的description字段定义了它的触发关键词或上下文场景。例如clarifySkill 的描述可能是“当用户提出一个模糊或开放性问题时主动提出一系列澄清问题”。这样当你下次在 Cursor 里问一个宽泛的问题时AI 就会自动调用clarify技能来与你互动而不是直接开始猜测回答。这种设计让 Lumi 不再是“另一个需要打开的应用”而是无缝嵌入到你最熟悉的工作流写代码、记笔记的编辑器中在你需要的时候以最自然的方式出现。2.3 方法论驱动的功能实现Lumi 的每一个功能点都不是凭空想象的其背后都有坚实的认知科学或学习方法论作为支撑clarify/challenge源于Meta 的 Chain-of-Verification验证链思想通过让 AI 自我质疑、交叉验证提升回答的准确性和深度避免“一本正经地胡说八道”。知识组织融合了Zettelkasten卡片盒笔记法的连接思想和Karpathy 的 LLM Wiki的结构化理念旨在建立知识间的关联而非简单堆砌。测验复习核心是《认知天性》强调的“主动检索”和SuperMemo 的 SM-2 间隔重复算法这是经过科学验证的最高效记忆方法。追问表达直接应用费曼技巧用简单的语言解释复杂概念和芭芭拉·明托的金字塔原理训练结构化表达。作战计划借鉴了《原子习惯》的体系化习惯养成和《刻意练习》的针对性突破理念。实操心得为什么是 35 个 Skill在设计初期我曾想过做几个“大而全”的超级 Skill。但很快发现这会导致使用复杂、维护困难且用户学习成本极高。拆分成 35 个微 Skill 后每个功能都足够聚焦用户可以根据当前任务像拼图一样自由组合。例如在“学习一个新框架”的场景下我可能会组合clarify明确学习目标→wiki-ingest将官方文档喂入知识库→quiz生成测试题→feynman尝试向 AI 讲解。这种灵活性是单一工具无法提供的。3. 已发布核心 Skill 深度解析与实操目前Phase A对话基础的 3 个 Skill 已经可用它们是整个系统的“敲门砖”。我们来深入看看每一个怎么用以及背后的设计考量。3.1clarify把模糊需求变清晰拒绝“猜谜游戏”这是我最推荐第一个安装的 Skill。它的作用极其简单却无比重要在你提出一个模糊问题时强制 AI 先向你提出最多 7 个澄清问题而不是直接开始回答。为什么需要它我们经常向 AI 提出诸如“帮我优化一下代码”、“怎么学习 React”、“解释一下闭包”这类问题。这些问题看似具体实则包含了大量隐藏的假设和模糊地带。“优化代码”是想提升性能还是可读性目标用户是谁“学习 React”是零基础还是已有 Vue 经验目的是做项目还是面试AI 如果直接回答很可能是在它自己的一套默认假设下进行的结果往往南辕北辙。clarifySkill 植入了一套基于“金字塔原理”的澄清框架AI 会从目标、范围、背景、约束、成功标准、现有认知、偏好格式等维度向你提问。实操示例假设你在 Cursor 中新建一个文件输入我想写一个用户管理系统。在没有clarify时AI 可能直接开始生成User类的代码。但安装了clarify后AI 的回复会变成我来帮你梳理一下这个用户管理系统的需求。为了给出最合适的方案我需要先了解一些细节核心目标这个系统的主要目的是什么例如内部员工管理、网站会员注册、还是 API 服务的使用者管理功能范围你期望包含哪些核心功能例如注册/登录、权限角色、个人资料、日志审计技术背景你打算用什么技术栈例如前端 React/Vue后端 Node.js/Python数据库 MySQL/MongoDB关键约束有没有必须遵守的要求例如需要支持单点登录 SSO、必须符合某个安全规范、预计用户量级交付形态你希望我提供什么形式的帮助例如数据库表结构设计、RESTful API 接口定义、一段核心代码示例、还是一个完整的项目脚手架经过这几轮问答你和 AI 对“用户管理系统”的认知就对齐了。接下来 AI 生成的任何代码或建议其针对性和可用性都会呈指数级提升。注意事项clarify的触发边界这个 Skill 被设计为在问题足够模糊时才触发。对于非常明确的指令如“把这段代码里的var改成let”AI 不会启动澄清流程而是直接执行。这依赖于 Cursor 对上下文意图的识别。有时你可能觉得问题已经很清楚但 AI 还是触发了澄清这时不妨耐心回答这往往能暴露出你自己都没意识到的需求盲区。3.2challenge让 AI 拥有“批判性思维”输入?即可触发如果说clarify是解决“问题不清晰”那么challenge就是解决“答案不靠谱”。它的核心功能是对 AI 刚刚给出的回答进行多维度、结构化的自我质疑和验证。设计原理AI 生成的内容尤其是复杂推理或知识性内容可能存在“幻觉”编造事实、逻辑漏洞、或考虑不周的情况。challengeSkill 让 AI 扮演自己的“反对派”从以下 7 个维度审视自己的输出事实核查回答中的关键事实、数据、API 名称是否准确逻辑一致性推理过程是否存在跳跃或矛盾完备性是否遗漏了重要的边界条件、异常场景或替代方案实用性给出的方案在现实环境中是否可行、成本如何安全性代码或建议是否存在潜在的安全风险可维护性方案是否会导致未来的代码难以理解和修改潜在误解当前的表述是否可能引起用户的误解如何使用使用方式极其简单。当 AI 给出一个长篇回答后你只需要在聊天框中输入一个?问号然后发送。AI 就会自动调用challenge技能对上一个回答进行一轮“灵魂拷问”。实操示例你问“Python 里最快的循环方式是什么” AI 回答“对于纯数值计算使用 NumPy 的向量化操作是最快的其次可能是列表推导式普通的for循环最慢。” 此时你输入?并发送。 AI 会这样回应我来挑战一下自己刚才的回答事实核查基本正确。但在非数值计算或小数据量时性能差异可能不明显甚至列表推导式可能因开销更小而更快。完备性遗漏了map/filter函数、itertools模块等选项。也忽略了 PyPy 等不同解释器对循环的优化差异。实用性对于刚接触 Python 的人来说过度追求“最快”可能过早优化。应优先考虑代码可读性。边界条件没有讨论数据规模。当数据无法全部装入内存时迭代器 (itertools) 可能是唯一选择。 因此更严谨的回答应该是“取决于具体场景和数据规模。通常NumPy向量化 列表推导式 ≈ map/filter 普通for循环。但在微秒级操作或小数据量时差异可忽略应首选可读性高的写法。”可以看到经过challenge之后答案从一句武断的结论变成了一个 nuanced有细微差别、全面且带有指导原则的优质回答。避坑技巧不要滥用?challenge是一个强大的工具但也会显著增加对话轮次和思考时间。建议在以下几种场景下使用AI 给出了一个非常重要的、可能影响项目决策的答案。答案涉及你不太熟悉的领域你需要一个“安全网”。你觉得答案听起来“太完美”或有点可疑时。 对于简单的、事实性的查询如“某个函数的参数是什么”则没有必要使用。3.3deai去除“AI 味”让回答更像资深工程师的分享这是让 Lumi 体验产生质变的一个 Skill。它的目标是识别并改写 AI 回答中那些刻板、啰嗦、充满“机器感”的表述使其更接近人类专家尤其是资深开发者的交流风格。什么是“AI 味”经过大量对话观察我总结了 5 种典型的“AI 味”免责声明体开头必是“作为一个人工智能模型…”、“我需要提醒您…”。教科书目录体回答结构僵化像教科书目录如“一、概述二、优点三、缺点四、总结”。过度礼貌冗余体大量使用“非常荣幸”、“请注意”、“重要的是要记住”等无信息量的客套话。假设枚举体喜欢说“这取决于…”然后罗列一堆可能性但没有给出基于常见场景的倾向性建议。空洞总结体结尾总要加一段“总之…”、“综上所述…”把前面的话换种说法再重复一遍。deaiSkill 内置了一系列改写规则。当 AI 生成回答后如果检测到上述模式会自动进行润色。实操示例开启deai前后对比开启前AI 可能这样回答关于“选择 React 还是 Vue”的问题“作为一个大型语言模型我需要指出选择 React 还是 Vue 取决于您的项目需求和个人偏好。React 由 Facebook 维护拥有更大的生态系统和更多的就业机会Vue 则以其渐进式和易于上手的特点著称。两者都是优秀的前端框架。重要的是要根据您的团队技能和项目规模来决定。综上所述没有绝对的好坏只有适合与否。”开启deai后同样的答案可能被润色为“React 和 Vue 选哪个这问题就像选 iOS 还是 Android核心看你和团队的习惯。如果项目大、团队人多或者你未来想进大厂React 的生态和就业市场是实打实的优势。如果你追求快速上手、开发体验顺畅或者项目是渐进式增强的Vue 的单文件组件和官方套件用起来很舒服。我个人的经验是新手从 Vue 开始挫败感少一点但 React 的思想对长远理解前端工程更有帮助。别太纠结先挑一个干起来核心概念都是相通的。”后者显然更像一个在技术社区里你会看到的、有经验有观点的开发者回复它去除了机器式的平衡论述加入了个人经验“我个人的经验是”和倾向性建议“新手从 Vue 开始…”语言也更口语化、更直接。实操心得deai的风格调校deai的改写规则是可以微调的。在 Skill 的SKILL.md文件里你可以找到prompt部分里面定义了改写的具体指令。如果你觉得改写后的风格过于随意或者想让它更接近某种特定风格如学术严谨型、简洁指令型可以在这里修改提示词。例如增加“保持专业性和准确性但避免冗余的礼貌用语”等指令。这让你能定制属于你自己的“AI 语气”。4. 如何安装、组合与定制你的 Lumi4.1 安装步骤详解Lumi 的安装完全通过命令行脚本完成非常清晰。克隆仓库打开你的终端命令行执行以下命令。这会把 Lumi 的所有 Skill 源码下载到本地。git clone https://github.com/NoSuchClass/lumi cd lumi一键安装全部已发布的 Skillbash install.sh这个脚本会遍历skills/目录下所有已完成的 Skill目前是clarify,challenge,deai并将它们复制到 Cursor 的技能目录~/.cursor/skills/下技能文件夹会被自动重命名为lumi-前缀的格式如lumi-clarify。选择性安装如果你只想安装其中几个可以在命令后跟上 Skill 的文件夹名。# 只安装 clarify, challenge, deai 这三个 bash install.sh clarify challenge deai开发/调试模式软链接如果你打算阅读或修改 Skill 的源码推荐使用软链接模式。这样你在lumi/项目目录里做的修改会立即在 Cursor 中生效无需重复运行安装脚本。bash install.sh --link预览模式如果你不确定安装脚本会做什么可以先“演习”一下。bash install.sh --dry-run这个命令只会打印出将要执行的操作复制哪些文件到哪里而不会实际执行非常安全。安装完成后完全重启你的 Cursor 编辑器。这是必须的因为 Cursor 只在启动时加载技能目录。重启后这些 Skill 就会在后台待命在合适的对话上下文中被自动触发。4.2 典型使用组合场景Lumi 的魅力在于组合。以下是我在真实工作流中常用的几种组合模式场景一深度学习一个新技术概念如“React Fiber”启动在 Cursor Chat 中输入“我想了解一下 React Fiber 架构”。clarify介入AI 会先问你“你是想了解其设计动机、核心算法原理、与旧架构的对比还是实际对开发者的影响” 你回答“核心算法原理和与旧架构的对比。”AI 生成回答AI 基于你的澄清生成一份详细的解释。challenge检验你输入?AI 会自我质疑“关于‘可中断渲染’的解释是否准确是否遗漏了 Concurrent Mode 这个关键关联概念对‘递归协调’的描述是否足够清晰”deai润色经过挑战后的回答再被自动润色去掉教科书式的结构更像一篇技术博客。未来可接wiki-ingest你可以将这份高质量的对话总结一键存入你的个人 LLM Wiki供日后查询。场景二准备一场技术面试情报收集Phase E使用intel-profile输入目标公司的岗位描述JD生成考点图谱。制定计划Phase F使用sprint-plan输入“我还有 21 天面试”生成一个三周的每日学习计划。每日学习Phase B, C按照计划使用wiki-ingest学习资料用quiz自我测试用review-sm2安排复习。模拟面试Phase D使用mock-interview让 AI 扮演面试官对你学过的考点进行多轮追问。每日复盘Phase F使用retro记录今天的收获和卡点调整明天的计划。场景三日常代码评审与设计讨论将一段你觉得有优化空间的代码贴入 Cursor。clarify会先让你明确优化目标性能、可读性、可扩展性。AI 给出优化建议。输入?让 AI 自我挑战这个建议是否引入了新 bug、是否过度设计、是否有更简单的方案。得到一份经过深度审视的、可执行的代码优化方案。4.3 高级技巧查看、调试与自定义 Skill每个 Lumi Skill 都是一个独立的文本文件SKILL.md其本质是一个加强版的 Cursor 提示词Prompt。理解其结构能让你更好地使用和定制它。查看 Skill 源码安装后你可以在~/.cursor/skills/lumi-[skill-name]/目录下找到SKILL.md。用任何文本编辑器打开它。理解结构一个典型的SKILL.md包含Frontmatter (YAML格式)定义了技能的名称、描述、触发条件、版本等元数据。description字段是关键它决定了 Cursor 何时调用这个技能。System Prompt这是技能的核心定义了 AI 在触发此技能时应扮演的角色、遵循的规则和思考框架。例如challenge的 System Prompt 就详细规定了那 7 个维度的质疑方法。示例对话 (Few-shot Examples)可选的提供一些输入输出的例子让 AI 更好地掌握技能的执行方式。自定义与调试修改触发条件如果你觉得某个技能触发得太频繁或不频繁可以编辑其description。调整行为如果你觉得deai的改写风格不合口味可以直接修改它的 System Prompt 中的改写规则。创建你自己的 Skill这是 Lumi 生态的终极玩法。你可以参考现有 Skill 的格式为你自己高频、重复的某个任务比如“生成数据库迁移脚本”、“编写单元测试模板”创建一个专属 Skill然后也放到~/.cursor/skills/下。Lumi 的安装脚本不会覆盖你私人的 Skill。重要提醒Skill 的冲突与优先级Cursor 的技能加载机制是当对话上下文匹配多个技能的description时Cursor 会尝试选择一个最相关的。理论上Lumi 的技能之间是互补的例如clarify在问题模糊时触发challenge在需要审查答案时手动触发它们一般不会冲突。但如果你安装了其他第三方技能或者创建了自定义技能可能会出现重叠。如果发生意外行为可以暂时将其他技能的文件夹移出~/.cursor/skills/目录来排查。5. 常见问题与故障排查在实际使用和与早期测试者交流中我总结了一些常见问题及其解决方法。5.1 安装与基础使用问题Q1运行install.sh脚本提示“Permission denied”或“Command not found”。A1这通常是脚本没有执行权限或不在 Bash 环境下。首先确保你在lumi项目目录内使用pwd命令查看。给脚本添加执行权限chmod x install.sh明确使用 bash 执行bash install.sh或./install.shQ2安装成功后在 Cursor 里对话感觉技能没有触发。A2请按以下步骤排查重启 Cursor这是最重要的步骤Cursor 只在启动时加载技能目录。检查技能目录在终端输入ls -la ~/.cursor/skills/确认里面有lumi-clarify、lumi-challenge等文件夹。检查 Cursor 设置确保你没有禁用技能功能。在 Cursor 设置中搜索 “Skills”确认其是启用状态。触发条件clarify只在问题足够模糊时触发。尝试问一个非常宽泛的问题如“如何设计一个系统”。challenge需要手动输入?。deai是后处理会自动生效你可能需要对比开启前后的回答风格。Q3我想卸载 Lumi 的所有技能怎么做A3项目根目录提供了uninstall.sh脚本。只需运行# 在 lumi 项目目录下执行 bash uninstall.sh这个脚本会删除~/.cursor/skills/目录下所有以lumi-开头的文件夹。你的其他自定义技能不会受影响。5.2 技能行为相关疑问Q4clarify有时候问的问题太多有点烦能跳过吗A4当然可以。clarify的设计是“建议性”的而非“强制性”的。当 AI 提出澄清问题时你可以直接打断它给出一个简短的答案或者说“不用澄清了直接基于通常的理解进行即可”。AI 会遵从你的指令继续推进。你也可以通过编辑clarifySkill 的 Prompt来减少默认提问的数量比如从7个减到3个。Q5使用?触发challenge后AI 的自我质疑推翻了之前的回答我该相信哪一个A5这是一个非常好的问题也是challenge的核心价值所在。你不应该盲目相信任何一方。AI 的自我质疑是为你提供了一个“第二意见”或“风险提示”。你应该把质疑点作为你自己思考的起点。例如AI 质疑自己“遗漏了边界条件”你就应该主动去思考“对我的具体场景来说这个边界条件重要吗如果重要我该如何处理” 最终的决定权在你。challenge的目标是帮你暴露盲点而不是替你决策。Q6deai会不会改变答案的准确性比如把一些重要的技术细节给“润色”掉了A6deai的改写规则首要原则是“不改变原意”。它主要针对的是表达风格而不是信息内容。它会删除冗余的套话、重组僵化的结构、将被动语态改为主动、将模糊表述具体化但不会删除或修改关键的技术名词、逻辑步骤和事实陈述。如果你发现某次改写导致了信息丢失这很可能是一个 bug欢迎在项目仓库提交 Issue。5.3 进阶与自定义问题Q7我可以同时使用 Lumi 和其他 Cursor Skill 吗A7可以。Cursor 的技能目录可以容纳多个来源的技能。Lumi 的技能都以lumi-开头与其他技能在命名上是隔离的。但是如果不同技能对同一类对话场景都定义了触发条件Cursor 可能会选择其中一个行为可能不可预测。建议观察一下如果出现冲突可以调整你更常用的那个技能的description使其触发条件更独特。Q8我想基于 Lumi 的某个 Skill 修改创建自己的版本怎么做A8最好的方式是“复制-修改-重命名”。在~/.cursor/skills/目录下复制一份lumi-clarify文件夹命名为my-clarify。修改my-clarify/SKILL.md文件中的name、description和内部的 Prompt 内容。重启 Cursor。现在你就拥有了一个自定义的澄清技能。Lumi 的安装和卸载脚本只会处理lumi-*文件夹你的my-*文件夹是安全的。Q9未来的 Skill如情报站、Wiki会如何与本地文件交互数据存在哪里A9这是一个架构上的关键设计点。根据 Roadmap像wiki-ingest、intel-crawl这类需要持久化数据的 Skill初步设计是将数据存储在本地采用开放格式如 Markdown、JSON。例如你的个人 Wiki 可能就是一个位于~/.lumi/wiki/目录下的 Markdown 文件集合。这样做的好处是隐私与安全你的所有学习数据完全在本地。可移植性你可以用任何文本编辑器或工具管理这些文件。与现有工作流集成你可以用 Git 管理你的 Wiki用 grep 进行搜索。 具体的实现细节会在相应的 Skill 开发时确定但“本地优先、开放格式”是核心原则。Lumi 目前还处于非常早期的阶段Phase A 的三个技能只是抛砖引玉。它的最终形态是希望成为每个知识工作者编辑器里的一个“副驾驶”不仅帮你写代码更帮你系统地构建知识、准备挑战、并清晰地表达出来。它的进化离不开使用者的反馈和共创。如果你在安装、使用中遇到任何问题或者有绝妙的想法项目仓库的 Issue 和 Discussion 页面永远开放。