做了十几个项目后，我得到一个代价惨痛的结论：对话式AI开发里，最大的成本不是写代码，而是"同一个坑反复踩"与"经验转头就忘"。
过去半年，我带着 AI 落地了十几个项目：微信视觉客服、抖音矩阵运营、城市治理大模型、销冠 AI 客服……每上一个项目，都像重新教一个"健忘的新人"。最让人崩溃的不是技术难，而是下面三件事反复发生。
很多需求一开始只是模糊的一句话。要让 AI 真正理解"打开好友→逐屏增量读取未读→语音转文字→媒体存缩略图"这种多步操作，往往要几十甚至上百轮对话，边做边纠偏，才把边界讲清楚。澄清需求本身，就吃掉了大量时间。
更气人的是：前面花大力气把一个点的问题解决了，AI 当时看起来也"学会了"，你以为下次它懂了。结果换个对话、换个环节再遇上同样的问题，它又从零开始绕圈，甚至把你刚教过的方法论忘得一干二净——前面几小时的调试，像从没发生过。
后来我们上了 skill 机制：把方法论写进 SKILL.md，需要时加载。这比纯对话好，但很快暴露一个更隐蔽的坑——skill 是被整体"复制"到使用点的。一旦在多个地方用到同一份 skill，就存在多份副本；在某处调通、把 skill 升级了，其他环节用的还是会话早期那份老副本。这就是下面要拆解的"版本漂移"。
要明白 skill 的局限，得看它真正的工作方式。
skill 本质上是一段被嵌入上下文的说明文档。当 AI 在任务 A、B、C 三个环节都"使用"同一个 skill，并不是三处都指向同一份文件，而是把 SKILL.md 的全文复制进各自的上下文。于是：
根本原因是：skill 模式没有单一事实来源（Single Source of Truth），也没有版本号约束。同一份知识以多份副本形式存在，任何一处修改都无法自动传播。
破局思路只有一条：把经验变成独立、可调用、带版本号的组件，并确立"单一事实来源"。所有使用点不再复制内容，而是调用同一个组件文件；组件升级后，所有调用方自动指向新版本。我们落地的工程实现包含四块。
建一个独立的组件库目录，每个组件一套 v1/ 冻结子目录。库根放一份 INDEX.md 索引文件——任何任务启动先读它，用"任务关键词→组件"检索表秒级匹配，找不到才研究。索引同时登记每个组件的触发条件、依赖、关键接口、当前版本。
# 目录结构（vx 为冻结版，不可改写） 组件库/ ├── INDEX.md # 总册：铁律 + 版本规则 + 检索表（任务第一入口） ├── ocr-small-window/ │ ├── README.md # current_version=v1 + changelog │ └── v1/ # 冻结版 │ ├── SKILL.md │ └── ocr_small_window.py └── ...（后续组件）
组件从 v1 起；要改进时，复制 v(n) 新建 v(n+1)，原 v(n) 原封保留，绝不覆盖旧版。这样"以前的调用"依然可溯源、可回退，也避免"改着改着把已验证的能力改坏了"。
光有目录不够，还要有"纪律"让经验真的进库：
再配一份《沉淀规范》+ 一个口令（如"沉淀经验"）：任意任务说出口令，AI 自动读规范、把本次经验拆成独立组件、归档 v1、登记索引。让"经验入库"变成一句话就能触发的标准动作。
沉淀完不能立刻宣布完成。必须做溯源对比质检：把新组件与源实现逐行比对、跑语法编译、核对接口文档一致、扫描旧路径残留、确认登记完整。全 PASS 才可收工——避免"以为沉淀好了，其实漏了关键函数或写错了逻辑"。
组件化带来的好处是结构性的，不只是"少写几行"：
| 维度 | 纯对话式 | skill 复制 | 组件化调用 |
|---|---|---|---|
| 经验复用方式 | 每次重教 | 全文复制（多副本） | 单一事实来源·调用 |
| 同类问题重复修复 | 每次都来一遍 | 改一处漏一片 | 沉淀一次，趋近于 0 |
| 版本一致性 | — | 易漂移 | v(n+1) 全员自动升级 |
| 主程序/上下文体积 | 臃肿 | 随副本膨胀 | 精简（只留调用语句） |
| 维护工时 | 高 | 中 | 低（改一处即全员） |
AI 对话式开发的最大陷阱，是以为"说过一遍 AI 就记住了"。现实是：模糊需求耗掉上百轮，刚解决的经验转头就忘，skill 复制又埋下版本漂移的雷。
解法不在更聪明的提示词，而在更朴素的工程纪律——把经验沉淀为带版本、可调用、有单一事实来源的组件，并用铁律和质检锁死质量。当你把第十三个项目里刚踩的坑，一句话就变成组件库里 v2 的新能力、并让前面十二个项目自动受益时，你就会明白：组件化不是锦上添花，而是 AI 规模化开发的必选项。