![图片](https://developer.qcloudimg.com/http-save/yehe-6190096/f6348da52d90070fb489b5bd1ee404f0.jpg)

我最初做 SKILL Alchemy只有一个朴素目标：少被坑。

因为现实是：
- 上周你刚强调“改完要启动服务真实验证”，这周它又只跑了 pytest 就说“完成了”。
- 上个月你纠正“不要顺手改无关代码”，这个月它修 A 顺手把 B/C/D 也动了。

你当然可以把约束写进 AGENTS.md。问题是：写了也不等于它会稳定执行。

我在 300 个 session 的测试里看到：即使这些约束都写在 AGENTS.md 中，AI 仍然会反复违反

| 反复要求的约束 | 重复 session 数 | AI 还是犯错了 | 已在 AGENTS.md？ |
|--------------|:------------:|:-----------:|:--------------:|
| 启动服务真实验证，别只跑 pytest | 88 | ✅ | ✅（但仍然违反） |
| 简化，别过度工程 | 30 | ✅ | ✅ |
| 先出方案再写代码 | 28 | ✅ | ✅ |
| 先定位问题再修复 | 23 | ✅ | ⚠️ 部分覆盖 |
| 只改我要求的，别扩展 | 23 | ✅ | ✅ |
| 确认环境（本地/测试/生产） | 34 | ✅ | ✅ |
| 提交前等用户确认 | 12 | ✅ | ✅ |
| 根因修复，别打补丁 | 3 | ✅ | ✅ |


关键原因其实很简单：** “应该做（Should）”不等于“会做（Do）”。规则写的是“要验证”，但没写“什么时候触发、检查什么、怎么检查、什么算通过”。** 当然AGENTS.md中规则的碎片化、长上文导致的指令稀释也都有影响。

这篇文章记录的，就是我为了解决这个问题，从本地近 1000 条 AI 对话记录中，系统提炼出一套从历史回话中提炼有效技能的Meta 技能：技能炼金术。这样大家可以根据自己的对话持续提炼技能，并把冗长的AGENTS.md进行极致的压缩。技能在我的git仓库[SKILL-ALCHEMY](https://github.com/DSXiangLi/Skill-Alchemy)

-----

这篇文章我们倒叙来聊：先看炼金术的成果（炼出了哪些技能），最后再聊炼金术本身是怎么工作的。这样你可以先感受到"技能是什么样的"，再去理解"它从哪里来"。
----

## 🏆 炼金术的成果
对近 1000 条本地历史 session 扫描之后，我初步验收了 9 个核心技能，覆盖从需求收到、到设计、到开发、到修复、再到提交上线的完整链路：
![image](https://developer.qcloudimg.com/http-save/yehe-6190096/8027f12317a673e46d480ad910535533.png)
> 没有最好的技能，只有和你的场景、你使用的模型最相匹配的技能。

有些炼金术得到的技能，在当前模型版本下已经用处不大了——按照模型迭代的周期，积累一段时间就可以清理旧技能、重新炼制新的。

所以这里只给大家推荐 3 个日常使用率高达 90% 的核心技能。

### 🔍 技能一：技能健康检查
> 一句话价值：技能创建后会腐坏，这个技能负责定期体检。

技能文件在反复迭代之后，会出现我称之为"技能腐坏"的现象，包括：
- 僵尸脚本和失效引用文件
- SKILL.md 中充斥着迭代历史和原因解释，而非"如何执行"
- 技能描述（Description）细节堆砌，却缺少 When to Use / What to Solve
- 信息在 SKILL.md 和 reference 文件之间大量冗余
- 大量弱约束的文字 QA，没有合理脚本化

我自己的炼金术技能文件就经历了一轮技能健康检查，检查出上述一堆问题后，SKILL.md 从 357 行压缩到 285 行，整整精简了 20%。

![image](https://developer.qcloudimg.com/http-save/yehe-6190096/c3f77b875d927e8b66d248c74dfca780.png)

### 🐛 技能二：修复代码验收
> 一句话价值：让 AI 修完 Bug 后，强制做一次"副作用体检"。

天天离不开修 Bug，自从有了 AI Coding，能同时修复 N 个 Bug——但你会发现，不少修复都会附赠新的"彩蛋"。Bug 越修越多，代码越写越长，简直是死亡循环。

解决方式是在 AGENTS.md 中加入约束，要求每次修复结束后，自动派发一个子 Agent，使用此技能对修复进行验收，核心检查项包括：
- 当前修改的影响范围与外溢风险分析
- 回归验收与测试补充
- 上下游完整调用链检查
- 各场景细节审查（性能影响、向前兼容性、生产/消费者同步验证等）

以下是一个真实案例：Kimi-2.6在修复一个 Agent 工作区归档 Bug 后，代码验收技能发现——修复不仅引入了更多编码问题，顺序不对导致数据丢失，还遗漏了大量存在相同问题的其他场景。

![image](https://developer.qcloudimg.com/http-save/yehe-6190096/681ec5b3bfd12d6c41d3b08d576cf283.png)

### 🧊 技能三：修复方案审核
>  一句话价值：修一次Bug顶10次，能顺手移走整座冰山，为何每次都只铲掉冰渣。

当修复不再引入新彩蛋之后，下一步自然是：能不能每次修复都直接解决根因，而不是一周修来修去、最后才发现底层是同一个问题？

修复文档给出后直接分派智能体进行审核：
- 根本问题深度挖掘：当前 Bug 的真实根因是什么？
- 同类问题全景扫描：其他模块是否存在相同问题？
- 外溢影响评估：修复对整体系统的影响，而不只是"Bug 有没有消失"
- 维护成本评估：这个修复方案未来好不好维护？
- 向前兼容性：是否兼容线上已有数据和行为？
- Corner Case 覆盖：边界情况考虑是否充分？

以下是我在修复harness下载大文件失败时，kimi-code第一轮给出的修复建议。

![image](https://developer.qcloudimg.com/http-save/yehe-6190096/17ebb78f799e1575269a77e769f451a4.jpg)

**但是它缺少了全局思维，缺少了关联思维。** 没有站在全局视角思考是否其他上传下载功能也有类似的问题，是否当前框架中还有其他没有考虑到大文件问题的模块。这些都在后面的方案审核中被挖掘出来。

![image](https://developer.qcloudimg.com/http-save/yehe-6190096/b8e3d682649638ffe5e33406486196e2.jpg)

另一个更典型的案例：排查子 Agent 自动记忆更新后为何没有触发 Git 版本更新——GLM-5.2直接定位到是子 Agent 的 hook没有向下传递，导致自动推送 Git 的操作未生效。修复方案简单直接：把 hook 传进去。

但"修复方案审核"执行后发现：现有大量 hook 对子 Agent 需要差异化处理，否则会引入子 Agent 嵌套、Agent 日志异常等一大堆连锁问题……

![截图_选择区域_20260904171153](https://developer.qcloudimg.com/http-save/yehe-6190096/a3dcc3d7ad9c422be767ee3e89b4b1e7.png)

### 🚪 其他：开发全链路门控技能

除上述三个核心技能外，剩余技能主要作为开发各阶段的质量门控，在关键节点拦截常见问题：
|门控名称|	触发时机|	核心价值|
|-----|-----|----|
|简化门|	设计阶段|	审核是否充分复用已有功能，避免重复造轮子|
|开发门|	编码阶段|	控制开发范围，防止过度重构和代码外溢|
|提交门|	代码提交后|	强制完成设计文档、进度文档、测试验收文档的回归更新|

这样把散落在AGENTS.md中的规则，陆续从对话中挖掘出来并沉淀成技能后，原本600多行的AGENTS.md也陆续压缩到280行。除了主要的项目概述、文档索引和核心常用的开发规则，其余都变成
不同时机dispatch子Agent，使用不同技能进行审核验收的描述。当然部分技能位置，比如提交本我也补充了hook。

## 联动Google WIKISKill

刚好前两天刚好看到google的WIKISKill，一种基于"知识层"的技能进化方案，能在持续的多轮对话使用中自动积累和更新技能顿感不谋二和。记忆炼金术，同样是跨 session、通过历史对话的关联分析来自动挖掘新技能。

两者有两个共同点：
- **信息来自多个 session**：过去的技能挖掘大多聚焦于单次任务的执行轨迹，但更有价值的信息往往藏在不同场景下的重复、迁移、回溯和延伸里。
- **技能不直接从 session 构建，而要经过至少一层沉淀**：WikiSKILL 通过持续更新 Wiki 层来完成这一步，Memory Alchemy 则直接把对话中的行为模式拆分归类再从规则中构建技能。

当然也有一些关键差异：
- **Skill Alchemy 只关注"人如何纠正 AI"，不关注 AI 自身的执行轨迹。**

原因是：AI 面向任务完成的技能沉淀，很容易被下一次模型版本迭代"吃掉"——因为单任务轨迹中的反馈信号，本身也会被纳入模型训练优化。而人类的纠正反馈则千人千面。

- **Skill Alchemy 不设置中间 Wiki 层，而是每次以最近 N 轮 session 为"锚点"，回溯关联历史对话。**

在真实使用场景中，每个 session 的上下文信息是不均匀的——我们会持续发现问题、沉淀技能、更新规则，模型版本也在持续迭代。因此不能把所有历史 session 一视同仁，只有最近 N 轮对话才真正贴近你当前的使用状态。

## ⚗️ Meta Skill：记忆炼金术是怎么工作的？

![图片](https://developer.qcloudimg.com/http-save/yehe-6190096/bbcb7e7d4f56d2cb82f15417f4254ee5.jpg)

### 工作原理：三步炼金

**Step 1：挖矿（Mining）——从对话记录中提取原料**

从各个不同的harness框架中存储的对话轨迹里进行提取，只保留用户输入和 AI 回复，丢掉中间的思考过程和工具调用记录。

目前我提供了适配 Codex、Claude Code、Kimi 和 Hermes 四个框架的提取脚本。

**Step 2：选矿（Selection）——筛选真正有价值的信号**

提取完原料后，用最近 N 次 session 作为锚点，先把所有历史对话构建成索引文件，然后从锚点 session 中识别出：哪些场景下，人对 AI 的干预是真实有效的纠正？

| 类型 | 含义 | 要不要提炼 |
|------|------|:---------:|
| **真正纠正** | AI 做错了，用户指出，AI 确实改了方向 | ✅ |
| **有效指引** | 用户给了 AI 没想到的方向，AI 采纳了 | ✅ |
| **冗余确认** | AI 本来就在做，用户只是确认 | ❌ |
| **纯推进** | "继续""下一步" | ❌ |

确定有价值的纠正信号后，再去历史对话中定位关联场景、重复要求、常见错误、可复用的行为准则，分门别类汇总成规则手册：

```text
output/run/
├── action-guides/         # 行动指南
├── error-patterns/        # 错误模式
├── repeated-requirements/ # 重复要求
├── conflicting-requirements/ # 冲突要求
└── related-findings/      # 关联发现
```

这里的关联我们主要引入以下几个分析维度

- **时间关联**（过去 → 现在）：追溯 bug 到编写 session——编写时能否预防？
- **空间关联**（此处 → 彼处）：检查其他模块是否有同样问题
- **方案关联**（此法 → 彼法）：检查优化能否推广到其他模块
- **重复要求**（到处都是）：用户相同的干预在多场景重复生效

**Step 3：技能炼金（Alchemy）——从规则到可执行技能**

从上一步挖掘到的各类规则中，进一步按照**条件触发机制（When to Use）**进行技能抽象——或提炼成新技能，或更新已有技能。

为什么不直接从 Session 一步炼出技能？

这是很多人会问的问题。以下是我实验过程中总结出的三个原因：

① **避免过拟合**：直接通过单个 session 构建技能，往往得到"项目特异化"的规则，缺乏通用性。就像机器学习中 batch 越大、梯度方向越稳定一样，跨 session 的归纳能带来更通用的技能。

② **避免技能碎片化**：AGENTS.md 和 action-guide 中抽取的信息，往往是大量碎片化规则的堆积，需要经过一次归类和抽象，才能形成结构清晰的技能。

③ **补充触发时机**：规则层描述的是"应该怎么做"，但缺少"什么时机做"的概念。开发场景中的技能，必须明确"何时触发、什么场景触发"，否则规则再好也无法被正确应用。

读完 WikiSKILL 论文后，我感觉论文中对这一点的总结非常切实：**认知带宽**——如果让模型一步到位完成技能压缩，任务认知复杂度太高、效果会打折扣；而经过中间层逐步归纳压缩，能有效降低每一步的思考难度，从而得到更高质量的技能。

上周你刚强调“改完要启动服务真实验证”，这周它又只跑了 pytest 就说“完成了”。

和AI一起搞事情#8. 分析1000+对话得到：技能炼金术

你是否也发现有时AGENTS.md中明明有规则，但AI依旧我行我素？你是否也烦恼随着开发AGENTS.md越来越长但效果却没越来越好？不妨试试技能炼金术，把用户自己的历史对话压缩成技能，把冗长的AGENTS.md变成技能触发命令。

人工智能

从近1000条历史对话中提炼出AI纠错技能炼金术，将300个session中反复违反的AGENTS.md规则压缩为9个可执行技能，覆盖开发全链路。核心技能包括技能健康检查、修复代码验收和修复方案审核，通过三步炼金法（挖矿-选矿-炼金）跨session关联分析，解决规则失效问题，将600行AGENTS.md精简至280行。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从近1000条历史对话中提炼出AI纠错技能炼金术，将300个session中反复违反的AGENTS.md规则压缩为9个可执行技能，覆盖开发全链路。核心技能包括技能健康检查、修复代码验收和修复方案审核，通过三步炼金法（挖矿-选矿-炼金）跨session关联分析，解决规则失效问题，将600行AGENTS.md精简至280行...

和AI一起搞事情#8. 分析1000+对话得到：技能炼金术-腾讯云开发者社区-腾讯云

和AI一起搞事情#8. 分析1000+对话得到：技能炼金术

和AI一起搞事情#8. 分析1000+对话得到：技能炼金术

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐