让 AI 在工作中自我进化——知识沉淀的工程化思路

我观察到一个让人有点难受的模式：每次 AI 帮我解决了一个棘手问题——某个坑、某个库的特殊行为、某个需要试错才能摸清的配置——对话结束，这份知识就消失了。下一次遇到类似的问题，AI 又从零开始探索。

这不是 AI 笨，是系统设计的缺陷。我们没有给 AI 提供「把经验固化」的机制。

核心想法：把「探索」转化为「规则」

Claudeception 是我用来应对这个问题的一套做法。它的核心逻辑很简单：

每次完成一个需要真正探索的任务之后，AI 回头审视刚才做了什么，把其中「下次会用到」的部分提炼出来，写成一个 skill 文件，供未来的会话直接调用。

skill 文件本质上是一段结构化的知识：触发条件（什么情况下该读这个 skill）、具体方法、验证方式、注意边界。形式类似于写给「下一个自己」的 checklist，但带着上下文。

这个思路不新鲜——人类的「SOP」「事后复盘」「作战手册」都是同样的逻辑。新鲜的是把它嵌入到 AI 的工作流里，让「提炼」本身也由 AI 来做。

什么值得沉淀，什么不值得

这是这套方法里最难判断的地方。提炼过多会产生噪音，提炼过少等于没用。

我的判断标准是四个维度：

• 可复用：这个知识下次还能用到吗？项目特定的一次性配置不值得。
• 非显而易见：如果查官方文档能直接找到，就不需要 skill，链接过去就行。
• 可触发：能不能描述清楚「遇到什么症状时该想起这个」？如果触发条件模糊，skill 也找不到。
• 已验证：只沉淀实际跑通的方法，不沉淀猜测或理论推断。

用这四条筛下来，大概只有 20% 的任务真正产出 skill。这个比例是正常的。

知识库的生命周期

skill 不是写完就放着的文档，它需要维护：

写入时标注版本号和日期，记录这个方法在什么环境下验证过。这样六个月后回看，能快速判断它是否还有效。

更新时有三种情况：同一触发条件发现了更好的解法，就更新版本；新发现了一个变体场景，就在原 skill 里追加「变体」小节；如果底层工具已经升级让原来的坑消失，就把 skill 标记为废弃并说明原因。

搜索时，描述字段的质量决定 skill 能不能在恰当的时机被召回。「Next.js 某功能出错」这种描述没什么用；「页面显示通用错误页、浏览器控制台为空、使用了 getServerSideProps」这种精确症状描述，才能在正确时刻浮出来。

这套思路的边界

它能解决的问题：跨会话的知识复用，降低重复探索成本，让 AI 的「专项能力」随着使用积累而增强。

它解决不了的问题：需要长期记忆的关系型信息（比如「这个客户喜欢什么风格」），以及高度依赖实时上下文、很难抽象化的判断。

另外，这套方法有隐性成本——写好 skill 需要花时间，维护知识库也需要纪律。如果项目很短、场景不重复，收益很小，不如直接存进文档。

一句话心法

不要让 AI 每次都重新发明轮子：把非显而易见的探索过程结构化成可被触发的知识，才是让 AI 越用越强的正确方式。