Kulaxyz/self-learning-skills

当开发者使用Claude Code、Cursor或任何遵循AGENTS.md规范的AI编程助手时，一个常见的挫败感在于：每次对话都像一场失忆的轮回。你刚刚花了一个小时，通过反复试错，终于找到了连接生产数据库的正确命令、部署项目的特定脚本，或是绕过一个已知的编译陷阱。然而，一旦关闭会话窗口，这些宝贵的“黄金路径”便烟消云散。下一次，当你或你的AI助手面对类似任务时，一切又得从头摸索。self-learning-skills这个项目，正是为了解决这种“会话失忆症”而出现的。它是一个元技能插件，本身不直接写代码，而是教会你的AI助手识别并捕获那些来之不易的成功经验与失败教训，将其转化为可复用的技能或规则，供下一次会话自动加载。

今天，开发者解决这个问题的方式是零散且手动的。他们可能会在项目根目录的AGENTS.md文件中手动添加一条备注，比如“# 部署：使用 `npm run deploy:prod` 而非 `npm run deploy`”。或者，在Cursor中，他们需要手动创建一个`.cursor/rules`目录下的规则文件。更常见的情况是，开发者将这些“部落知识”记在脑子里、写在便签上，或是散落在不同会话的历史记录中。当任务复杂、团队协作或项目切换频繁时，这种依赖个人记忆和手动整理的方式便捉襟见肘。具体卡点在于：第一，识别时机困难。开发者需要在问题解决后，主动且有意识地去“归档”这个解决方案，但此时注意力往往已转移到下一个任务。第二，格式与位置不统一。不同AI助手（Claude Code, Cursor, Zed等）对技能或规则的存储格式、文件位置要求各异，手动创建容易出错。第三，缺乏失败记录。成功的路径固然重要，但知道哪些路是死胡同、哪些命令会报错，往往能节省更多时间，而手动记录很少会系统性地包含这些“负向知识”。

self-learning-skills精准地切入了**上下文管理层**。它不替代AI模型的核心推理能力，也不直接管理代码执行，而是专注于管理AI助手在特定项目或工作流中积累的、具有持久价值的上下文知识。它充当了一个智能的“会话记忆收割机”，将一次性的、临时的对话成果，转化为结构化的、可继承的项目资产。

旧方案之所以不够好，正是因为它们要么完全依赖开发者的手动操作（记在AGENTS.md、自己写脚本整理历史记录），要么完全依赖AI模型在单次会话内的有限上下文。手动流程繁琐、易被遗忘，且难以规模化到团队和多个项目。而仅靠模型自身的上下文，其容量有限且会话结束后即清零，无法形成持续的知识沉淀。像Claude Code的技能库或Cursor的规则系统虽然提供了存储能力，但缺乏自动化的捕获机制，需要开发者手动“喂食”，这就在“发现问题-解决问题”和“记录方案”之间制造了一个断层。

这个项目之所以现在成立，直接源于**AI编程助手从聊天对话转向持续执行复杂任务**这一趋势。当AI助手被用于真实的、长期的项目开发时，它不再仅仅是回答一次性问题，而是需要像人类开发者一样，在项目的生命周期中不断学习、积累项目特定的知识。同时，**开源生态出现了可拼装的方案**，例如Vercel Labs的`skills` CLI，为不同AI助手提供了一个统一的技能管理接口，使得像self-learning-skills这样的元技能能够跨平台部署，降低了集成成本。此外，**MCP（Model Context Protocol）等协议的普及**，虽然项目未直接提及，但反映了整个生态正朝着标准化、可扩展的上下文管理方向演进，为这类工具的生存提供了土壤。

它透露出一个清晰的变化：AI编程工具的价值重心，正从“单次对话的即时智能”向“跨会话的持续智能与知识沉淀”迁移。AI助手不再被视作一个每次都要从零开始教学的临时工，而是一个能够随着项目成长、积累团队智慧、越用越聪明的长期伙伴。这种“学习型助手”的范式，是AI深度融入生产工作流、解决复杂现实问题的必然要求。

对于Builder而言，这个项目今天就可以通过`npx skills add`命令快速集成到现有的Claude Code、Cursor等工具中，立即开始自动捕获项目中的“黄金路径”。它最值得学习的，不是其实现的具体代码，而是其**“元认知”的设计思路**：即设计一个系统，让它能够观察并优化另一个系统（AI助手）的学习过程本身。这种将“学习如何学习”的能力封装成可插拔组件的做法，极具启发性。这种设计模式可以迁移到许多领域，例如：为AI设计助手自动总结并复用常用的数据查询模式；为自动化运维Agent捕获处理特定告警的有效步骤序列；甚至为创意生成类AI工具学习并复现用户偏好的风格调整流程。其核心在于，在任何存在重复性探索和试错的智能体交互场景中，为“经验”的自动沉淀和复用提供一个轻量化的管道。