是否也发现有时AGENTS.md中明明有规则，但AI依旧我行我素？你是否也烦恼随着开发AGENTS.md越来越长但效果却没越来越好？不妨试试技能炼金术，把用户自己的历史对话压缩成技能，把冗长的AGENTS.md变成技能触发命令。
我最初做 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
这篇文章我们倒叙来聊：先看炼金术的成果（炼出了哪些技能），最后再聊炼金术本身是怎么工作的。这样你可以先感受到"技能是什么样的"，再去理解"它从哪里来"。
🏆 炼金术的成果
对近 1000 条本地历史 session 扫描之后，我初步验收了 9 个核心技能，覆盖从需求收到、到设计、到开发、到修复、再到提交上线的完整链路：
需求收到 → simplification_gate → change_scope_control → fix_plan_review → design_doc_review
→ [实现阶段]
→ issue_triage_gate → code_fix_acceptance → pre_completion_gate
→ pre_commit_doc_rescan
→ skill_health_check（元技能：创建/审计技能时）
没有最好的技能，只有和你的场景、你使用的模型最相匹配的技能。
有些炼金术得到的技能，在当前模型版本下已经用处不大了——基本按照模型迭代的周期，积累一段时间就可以清理旧技能、重新炼制新的。
所以这里只给大家推荐 3 个日常使用率高达 90% 的核心技能。
🔍 技能一：技能健康检查
一句话价值：技能创建后会腐坏，这个技能负责定期体检。
技能文件在反复迭代之后，会出现我称之为"技能腐坏"的现象，包括：
- 僵尸脚本和失效引用文件
- SKILL.md 中充斥着迭代历史和原因解释，而非"如何执行"
- 技能描述（Description）细节堆砌，却缺少 When to Use / What to Solve
- 信息在 SKILL.md 和 reference 文件之间大量冗余
- 大量弱约束的文字 QA，没有合理脚本化
我自己的炼金术技能文件就经历了一轮技能健康检查，检查出上述一堆问题后，SKILL.md 从 357 行压缩到 285 行，整整精简了 20%。
🐛 技能二：修复代码验收
一句话价值：让 AI 修完 Bug 后，强制做一次"副作用体检"。
天天离不开修 Bug，自从有了 AI Coding，能一次修复 N 个 Bug——但你会发现，不少修复都会附赠新的"彩蛋"。Bug 越修越多，代码越写越长，简直是死亡循环。
解决方式是在 AGENTS.md 中加入约束，要求每次修复结束后，自动派发一个子 Agent，使用此技能对修复进行验收，核心检查项包括：
- 当前修改的影响范围与外溢风险分析
- 回归验收与测试补充
- 上下游完整调用链检查
- 各场景细节审查（性能影响、向前兼容性、生产/消费者同步验证等）
以下是一个真实案例：Kimi 在修复一个 Agent 工作区归档 Bug 后，代码验收技能发现——修复不仅引入了更多编码问题，顺序不对导致数据丢失，还遗漏了大量存在相同问题的其他场景。哈哈当时差点没笑死我修复文档就几行，但子Agent修复审核写了两大页.....
🧊 技能三：修复方案审核
一句话价值：修一次Bug顶10次，能顺手移走整座冰山，为何每次都只铲掉冰渣。
当修复不再引入新彩蛋之后，下一步自然是：能不能每次修复都直接解决根因，而不是一周修来修去、最后才发现底层是同一个问题？
修复文档给出后直接分派智能体进行审核：
- 根本问题深度挖掘：当前 Bug 的真实根因是什么？
- 同类问题全景扫描：其他模块是否存在相同问题？
- 外溢影响评估：修复对整体系统的影响，而不只是"Bug 有没有消失"
- 维护成本评估：这个修复方案未来好不好维护？
- 向前兼容性：是否兼容线上已有数据和行为？
- Corner Case 覆盖：边界情况考虑是否充分？
以下是我在修复harness下载大文件失败时，kimi-code第一轮给出的修复建议。
但是它缺少了全局思维，缺少了关联思维。 没有站在全局视角思考是否其他上传下载功能也有类似的问题，是否当前框架中还有其他没有考虑到大文件问题的模块。这些都在后面的方案审核中被挖掘出来。
另一个更典型的案例：排查子 Agent 自动记忆更新后为何没有触发 Git 版本更新——GLM 直接定位到是子 Agent 的 hook没有向下传递，导致自动推送 Git 的操作未生效。修复方案简单直接：把 hook 传进去。
但"修复方案审核"执行后发现：现有大量 hook 对子 Agent 需要差异化处理，否则会引入子 Agent 嵌套、Agent 日志异常等一大堆连锁问题……
🚪 其他：开发全链路门控技能
除上述三个核心技能外，剩余技能主要作为开发各阶段的质量门控，在关键节点拦截常见问题：
| 门控名称 | 触发时机 | 核心价值 |
|---|---|---|
| 简化门 | 设计阶段 | 审核是否充分复用已有功能，避免重复造轮子 |
| 开发门 | 编码阶段 | 控制开发范围，防止过度重构和代码外溢 |
| 提交门 | 代码提交后 | 强制完成设计文档、进度文档、测试验收文档的回归更新 |
这样把散落在AGENTS.md中的规则，陆续从对话中挖掘出来并沉淀成技能后，原本600多行的AGENTS.md也陆续压缩到280行。除了主要的项目概述、文档索引和核心常用的开发规则，其余都变成
不同时机dispatch子Agent，使用不同技能进行审核验收的描述。
前两天刚好看到google的WIKISKill
一种基于"知识层"的技能进化方案，能在持续的多轮对话使用中自动积累和更新技能顿感不谋二和。记忆炼金术，同样是跨 session（跨对话轮次）、通过历史对话的关联分析来自动挖掘新技能。
两者有两个共同点：
- 信息来自多个 session：过去的技能挖掘大多聚焦于单次任务的执行轨迹，但更有价值的信息往往藏在不同场景下的重复、迁移、回溯和延伸里。
- 技能不直接从 session 构建，而要经过至少一层沉淀：WikiSKILL 通过持续更新 Wiki 层来完成这一步，Memory Alchemy 则直接把对话中的行为模式拆分归类再从规则中构建技能。
当然也有一些关键差异：
- Skill Alchemy 只关注"人如何纠正 AI"，不关注 AI 自身的执行轨迹。
原因是：AI 面向任务完成的技能沉淀，很容易被下一次模型版本迭代"吃掉"——因为单任务轨迹中的反馈信号，本身也会被纳入模型训练优化。
- Skill Alchemy 不设置中间 Wiki 层，而是每次以最近 N 轮 session 为"锚点"，回溯关联历史对话。
在真实使用场景中，每个 session 的上下文信息是不均匀的——我们会持续发现问题、沉淀技能、更新规则，模型版本也在持续迭代。因此不能把所有历史 session 一视同仁，只有最近 N 轮对话才真正贴近你当前的使用状态。
⚗️ Meta Skill：记忆炼金术是怎么工作的？
工作原理：三步炼金
Step 1：挖矿（Mining）——从对话记录中提取原料
从各个不同的harness框架中存储的对话轨迹里进行提取，只保留用户输入和 AI 回复，丢掉中间的思考过程和工具调用记录。
目前我提供了适配 Codex、Claude Code、Kimi 和 Hermes 四个框架的提取脚本。
Step 2：选矿（Selection）——筛选真正有价值的信号
提取完原料后，用最近 N 次 session 作为锚点，先把所有历史对话构建成索引文件，然后从锚点 session 中识别出：哪些场景下，人对 AI 的干预是真实有效的纠正？
| 类型 | 含义 | 要不要提炼 |
|---|---|---|
| 真正纠正 | AI 做错了，用户指出，AI 确实改了方向 | ✅ |
| 有效指引 | 用户给了 AI 没想到的方向，AI 采纳了 | ✅ |
| 冗余确认 | AI 本来就在做，用户只是确认 | ❌ |
| 纯推进 | "继续""下一步" | ❌ |
确定有价值的纠正信号后，再去历史对话中定位关联场景、重复要求、常见错误、可复用的行为准则，分门别类汇总成规则手册：
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 论文后，我感觉论文中对这一点的总结非常切实：认知带宽——如果让模型一步到位完成技能压缩，任务认知复杂度太高、效果会打折扣；而经过中间层逐步归纳压缩，能有效降低每一步的思考难度，从而得到更高质量的技能。