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

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