我做了一个开源项目，让 AI 记住我们解决过的问题：Usora

Usora：让不同 AI 从真实实践中持续沉淀、验证并复用 Skills

让下一次，记得这一次。

过去一段时间，我越来越频繁地使用 Codex、Claude Code、Kimi 等 AI Agent 参与开发。

它们已经不只是帮我补几行代码。

排查问题、分析架构、Review、重构、生成测试、制定实施计划......很多原本需要自己完成的工作，现在都开始变成「人与 AI 一起完成」。

但用得越多，我越明显地感觉到一个问题：

AI 很强，但我们的很多经验依然是一次性的。

今天花一个小时和 AI 找到了一个很好的 Vue 内存泄漏排查方法。

下周换一个项目，又要重新告诉它：

应该检查哪些生命周期；
怎么排查事件监听；
怎么处理 keep-alive；
哪些地方容易出现误判；
最终报告应该按照什么格式输出。

又或者，好不容易调出了一套非常适合自己项目的 Prompt。

过几周之后：

它可能已经沉在某个对话历史里，再也找不到了。

于是我开始思考：

如果 AI 已经开始参与我们的日常研发，那么这些真实实践中形成的方法，为什么不能像代码一样被沉淀下来？

这就是我开始做 Usora 的原因。

Usora 是什么？

Usora --- The Aura of Practice

Usora 是一个面向 AI Agent 时代的个人 Skill Hub 与开放技能生态。

如果只用一句话解释：

让不同 AI 从真实实践中持续提炼、验证并复用 Skills。

官方文档：Usora --- 从实践到能力

它想解决的不是「怎么写更多 Prompt」。

而是另一个问题：

如何让人与 AI 共同完成过的事情，逐渐变成真正属于自己的能力资产？

我不想每次都从 Prompt 开始

现在我们使用 AI，大部分工作流其实还是这样的：

复制代码

遇到问题
   ↓
打开 AI
   ↓
重新描述背景
   ↓
重新告诉它规则
   ↓
反复调整 Prompt
   ↓
得到一个不错的结果
   ↓
关闭对话

然后下一次：

复制代码

再来一遍。

真正浪费的并不是写 Prompt 的几分钟。

而是之前已经形成的：

Context + 方法 + 判断标准 + Workflow + 验证经验。

这些东西其实已经越来越接近一种「能力」。

比如：

复制代码

frontend-memory-leak-analysis

它不应该只是：

帮我检查 Vue 项目有没有内存泄漏。

一个真正可复用的 Skill 应该知道：

从哪里开始扫描；
哪些 API 是高风险点；
如何追踪子组件；
如何分析 composables；
如何判断事件监听是否释放；
如何检查 Timer / Observer / Worker；
如何处理 keep-alive；
如何降低误报；
最终应该输出什么；
哪些情况下只分析、不修改代码。

这时候，它就已经不是一句 Prompt。

而是一套：

可以被 Agent 执行的方法。

所以，我想让 AI 开始「沉淀能力」

这也是 Usora 最核心的想法。

假设今天我和 Codex 一起解决了一个复杂问题。

传统方式是：

sql 复制代码

Conversation
     ↓
  Result
     ↓
    End

而在 Usora 的设想里：

markdown 复制代码

Conversation / Coding / Debugging
                ↓
             Activity
                ↓
             Foundry
                ↓
        Candidate Skill
                ↓
        Review / Validate
                ↓
              Skill
                ↓
               Hub

一次实践不应该在任务结束之后消失。

它应该有机会成为下一次可以直接调用的能力。

这也是 The Aura of Practice 这个名字背后的含义：

真正有价值的能力，来自实践留下来的痕迹。

Foundry：Usora 最重要的一环

Usora 中有一个我非常喜欢的概念：

Foundry。

直译过来就是：

铸造厂。

它负责把散落在日常 AI 协作过程中的经验，逐渐「铸造」成 Skill。

理想情况下，我们每天可能产生大量这样的 Activity：

vbscript 复制代码

修复一个 Vue keep-alive 生命周期问题

完成一次大型重构

排查一次内存泄漏

设计一个新的 CI Workflow

优化一个复杂 Prompt

Review 一个 Pull Request

完成一次架构设计

但不是每一次 Activity 都值得成为 Skill。

所以 Foundry 做的并不是：

复制代码

Activity → Skill

而是：

sql 复制代码

Activity
   ↓
Collect
   ↓
Analyze
   ↓
Extract
   ↓
Candidate
   ↓
Evaluate
   ↓
Validate
   ↓
Publish

也就是说：

先观察实践，再决定什么值得留下。

我认为这一点非常重要。

否则最后得到的不是 Skill Hub，而是另一个垃圾场。

多 AI，不应该意味着多个孤岛

另一个让我非常在意的问题，是：

现在每个 AI 都有自己的生态。

今天使用 Codex。

明天使用 Claude Code。

另一个任务可能更适合 Kimi。

以后还会出现更多 Agent。

如果我们的能力只能绑定在某一个 AI 上：

复制代码

Codex Skills

Claude Skills

Kimi Skills

Gemini Skills

那么随着 Agent 越来越多，我们的能力反而会越来越碎片化。

所以 Usora 从一开始就不希望绑定某一个模型或者 Agent。

我更希望它变成：

markdown 复制代码

                 Usora Hub
                     │
       ┌─────────────┼─────────────┐
       │             │             │
     Codex        Claude         Kimi
       │             │             │
       └─────────────┼─────────────┘
                     │
                  Gemini

Agent 可以变化。

模型可以变化。

IDE 可以变化。

但是：

你的能力应该属于你自己。

但如果所有 AI 都能修改 Skill，会不会失控？

会。

所以 Usora 没有设计成：

所有 Agent 都可以随便修改 Skill。

而是区分了两个角色。

Candidate

其他 AI 可以：

复制代码

观察实践
分析 Activity
发现值得沉淀的方法
生成 Candidate Skill
提出改进建议

但不能直接发布。

Maintainer

Maintainer 负责：

复制代码

Review
Evaluate
Test
Version
Publish

默认情况下，我更倾向于让 Codex 承担 Maintainer。

于是整个过程变成：

复制代码

Claude ──┐
Kimi ────┤
Gemini ──┼──→ Candidate ──→ Maintainer ──→ Skill
Other ───┘

这样既可以利用不同 AI 的能力，又不会让自己的 Skill Hub 变成一个不可控的自动生成仓库。

Skill 也应该像代码一样演进

还有一个原则：

Skill 不应该是复制粘贴出来的一堆 Markdown。

如果它真的开始成为 AI 的能力基础设施，那么它至少应该拥有：

复制代码

版本
来源
变更记录
验证
测试
发布
回滚

甚至应该知道：

复制代码

这个 Skill 为什么出现？

来自哪一次实践？

谁生成了 Candidate？

谁 Review 了它？

经过了什么验证？

为什么从 v1.2.0 变成 v1.3.0？

于是 Skill 的演进可以变成：

sql 复制代码

Practice
   ↓
Candidate
   ↓
Skill v1.0.0
   ↓
New Practice
   ↓
Improvement
   ↓
Skill v1.1.0
   ↓
More Practice
   ↓
Skill v2.0.0

这也是为什么 Usora 会非常重视：

Git、Versioning、Test、Release。

因为我希望 Skill 最终是一种真正可以维护的工程资产。

从 Skill Hub 到 Skill Market

如果事情只做到这里，那么 Usora 只是一个：

Personal Skill Hub。

但我觉得还有一个更有意思的方向。

假设有一天，我已经沉淀出了一个很好用的：

复制代码

frontend-memory-leak-analysis

它经过很多真实项目验证。

那么为什么只有我可以使用？

另一个开发者可能也有一个非常成熟的：

复制代码

react-performance-audit

或者：

arduino 复制代码

github-actions-release

于是就自然产生了下一层：

Skill Market。

未来我们可以：

复制代码

Discover
   ↓
Install
   ↓
Use
   ↓
Practice
   ↓
Improve
   ↓
Contribute

一个 Skill 不再只是：

某个人写的一份 Prompt。

而是：

被真实实践不断验证和改进的方法。

我更期待的是一个「能力网络」

如果继续往前推一步，我觉得未来真正有意思的可能不是：

复制代码

Prompt Market

甚至也不只是：

复制代码

Skill Market

而是：

复制代码

Capability Network

不同的人：

css 复制代码

Developer A
Developer B
Designer
Architect
PM
Researcher

不同的 Agent：

erlang 复制代码

Codex
Claude
Kimi
Gemini
...

以及不同的 Skill：

sql 复制代码

Debugging
Testing
Architecture
Design
Research
Release
Review
...

最终连接在一起。

AI 提供基础智能。

Skill 提供方法。

Practice 提供经验。

而人决定：

什么值得留下。

为什么叫 Usora？

Usora 的完整表达是：

Usora --- The Aura of Practice

Aura 是一种留下来的气息、痕迹。

我希望每一次真正解决问题的过程，都不会随着 Conversation 的结束彻底消失。

而是留下某种东西。

它可能是一条规则。

一种判断方法。

一个 Workflow。

一个 Skill。

甚至最终成为一个完整的能力体系。

所以 Usora 想表达的是：

Practice leaves an aura.

实践会留下痕迹。

而我们要做的，是把这些痕迹变成可以再次调用的能力。

「让下一次，记得这一次」

这是我最后给 Usora 定下来的 Landing Page 文案：

让下一次，记得这一次

我很喜欢这句话。

因为它基本就是整个项目最简单的解释。

我们每天都在：

复制代码

Coding
Debugging
Searching
Thinking
Reviewing
Designing

AI 也越来越深入地参与这些过程。

真正值得思考的问题可能已经不再只是：

AI 能不能帮我完成这一次任务？

而是：

这一次完成之后，有什么东西可以留下来？

如果下一次遇到类似的问题：

我们能不能不用重新开始？

AI 能不能知道：

「这个问题，我们以前解决过。」

如果可以，

那么 AI 才真正开始从：

Tool

走向：

Partner

再走向：

Capability Infrastructure。

这就是我正在做的：

Usora

The Aura of Practice.

让下一次，记得这一次。

目前 Usora 仍然处于持续设计和开发阶段，很多关于 Skill Protocol、Foundry、多 Agent 协作、Skill Market 的设计也还在不断演进。

如果你也在大量使用 Codex、Claude Code 或其他 AI Agent，欢迎一起讨论：

你觉得 AI 时代，我们应该如何保存自己的「能力」？

也欢迎关注项目后续进展。

GitHub：LuoMingxiang/usora: The Aura of Practice

如果这个方向恰好也是你正在思考的问题，欢迎 Star、Issue，或者一起参与 Usora 的设计与建设。