自演化技能层
让 Claude Code、Codex、OpenCode 等智能编码代理在真实项目执行中持续沉淀经验，而不是反复手动修补同一套技能。
OrnnSkills 是一个给智能编码代理使用的自演化技能层。它通过观察真实执行轨迹，识别重复人工修补、回退复用、技能漂移等信号，自动迭代项目内的影子技能，并为每次改动记录版本、差异、快照与回滚路径。
核心亮点
- 把静态技能从经验标本推进成可随项目环境持续生长的影子技能
- 用原始技能、项目影子技能和演化日志重构技能演化模型
- 以“观察、评估、修补、记录”的闭环，把执行反馈转成长期经验复利
它解决什么问题
- 同一个技能在不同项目里逐渐失效，命中后也越来越偏离真实环境。
- 代理经常需要人工补同类回退逻辑，但这些补丁只停留在聊天记录里，无法沉淀成系统经验。
- 团队经验散落在临时修补、会话上下文和个人习惯中，没有项目级的统一沉淀层。
- 技能被反复手改，却没有清晰的版本、差异、快照和回滚机制。
- 项目运行得越久，提示词越来越长，但系统并没有真正“学会”这个项目。
核心理念
- 原始技能：全局通用技能作为稳定主干，默认不被自动污染。
- 项目影子技能：每个项目只维护一份真实消费的项目级副本，让技能按项目环境持续生长。
- 演化日志：每次修补都记录版本、原因、快照和回滚路径，把演化纳入治理。
最小示例
下面这个例子比抽象论证更能说明 OrnnSkills 到底在做什么。
变更前
- 技能：修复 TypeScript 构建错误
- 触发条件：出现 TypeScript 报错
- 动作：查看报错并修复
观测到
- 同类错误在多个会话里重复出现。
- 代理每次都要人工补跑
pnpm typecheck。 - 关于
tsconfig路径别名的检查总是靠人手动补充。
修补
- 收紧触发条件：把泛化的 TypeScript 报错收紧到构建型错误。
- 增加回退动作：自动补入
pnpm typecheck。 - 追加上下文：增加“修复前先检查
tsconfig路径别名”。
变更后
- 影子技能进入
rev_7。 - 新增回退动作与路径别名检查项。
- 这次补丁可比较差异、可回滚、可继续演化。
当前进度
它已经不是纯概念稿，但也还没到“全自动演化闭环完全可用”的阶段。
已完成
- 命令行骨架与核心模块边界已建立。
- Codex 观察器到结构化轨迹的链路已跑通。
- NDJSON 与 SQLite 轨迹存储已落地。
- 影子技能、版本、日志、快照与回滚都已进入实现层。
进行中
- 轨迹到技能命中的映射。
- 修补触发条件的校准。
下一步
- 打通“观察、评估、修补、记录”闭环。
- 补齐多运行时观察器。
- 补审阅、风控和策略治理。
OrnnSkills 核心架构
- 主代理运行时：Codex、Claude、OpenCode 等主代理正常执行任务，OrnnSkills 不替代它，只观察它。
- 观察层：监听用户输入、助手输出、工具调用、文件变更、重试等外显事件，形成可分析轨迹。
- 轨迹存储层：用 NDJSON 保存原始轨迹，用 SQLite 建索引，让执行记录既能回放，也能被持续评估。
- 影子技能管理器：围绕影子技能做分叉、状态管理、版本递增、差异、回滚与快照编排。
- 评估与修补引擎：从重复人工修补、漂移、回退等信号里判断优化机会，并生成小步补丁。
- 演化日志：所有自动改动都带原因、版本、快照与回滚路径，保证演化不是污染，而是治理下的积累。
为什么它重要
项目展示页不需要把所有论证都扛上来，下面两张卡只保留最关键的价值判断。
为什么这不是另一个提示词模板库
OrnnSkills 关心的不是“技能写得够不够长”，而是技能为什么在真实项目里总会逐渐失效。
- 今天很多技能更像静态方法包。它们能复用经验，却不会随着项目环境、工具链和错误模式变化而自己修正。结果就是同一个技能经常被团队一次次手工补丁，却始终没有真正形成长期学习。
- OrnnSkills 把“主代理执行任务”和“系统积累经验”拆成两层。前者继续解决当下任务，后者在后台观察哪些回退逻辑被重复使用、哪些段落总被绕开、哪些说明已经不适合当前项目。
- 一旦这层能力成立，技能的价值就不再是一次性交付，而是越用越贴近项目环境的长期资产。这是经验系统，不是模板仓库。
为什么它可能成为智能编码的基础设施
真正长期拖慢团队效率的，不是模型不够强，而是经验无法沉淀成系统。
- 很多团队已经从“能不能跑代理”进入“怎么长期维护代理”的阶段。重复错误、人工回退、项目级技能漂移，这些已经是运维现实，而不是边缘问题。
- OrnnSkills 尝试补上智能工程体系里长期缺失的一层：把会话里的零散补丁，变成项目级、可治理、可持续复利的经验系统。
- 如果这条路线成立，未来技能的竞争力就不只来自谁写得更全，而是来自谁的系统更会根据真实执行持续生长。
路线图
当前最关键的不是继续堆概念，而是把两个决定系统价值的主缺口补齐。
打通执行轨迹到影子技能的真实映射闭环
这是当前最关键的产品化缺口，也是自动演化真正开始发生的起点。
- 现在最大的工程问题不是修补策略不够多，而是系统还需要可靠判断一批执行轨迹实际对应了哪个技能、哪个技能片段，以及它是否真的被命中后又被绕开。没有这层映射，自动优化就还停留在骨架阶段。
- 这一层一旦补上，“观察、评估、修补、记录”才能形成真正闭环。届时系统不只是“能记录执行”，而是“能把执行转成对具体影子技能的迭代信号”。这是从原型迈向可用产品的第一道门槛。
把单运行时原型推进成多运行时、可治理的经验平台
产品需求文档的目标不是只服务一个 Codex 观察器，而是成为跨代理运行时的技能演化基础设施。
- 下一阶段要补的不只是更多观察器，还包括更完整的修补策略、冷却机制、风险控制、人工审阅节点以及重整、优化、冻结等生命周期命令的完善实现。
- 当多个运行时都能把外显执行流接入到同一个影子技能系统里，OrnnSkills 才真正具备平台属性。那时它不再只是一个项目实验，而会成为“智能团队如何维护长期经验资产”的基础设施产品。
下一步
目前 OrnnSkills 仍处于原型阶段，正在打通执行轨迹到影子技能的真实映射闭环。继续了解最直接的入口是代码仓库，产品需求文档和开发日志也都可以从仓库继续展开。