导语
前两天我刷 GitHot，本来只是想随便找几个新项目看看。结果越看越觉得，这次不太像往常那种“又一个 AI 工具火了”的热榜。
几个与 Claude Code、skills、Codex 相关社区项目和 AI 编程工作流有关的仓库，几乎在同一时间成为了开发者的讨论的热点。
你说它们是一类吧，也不能说完全是。
你说它们没关系吧，却也不能说没有。
我后来把几个仓库 README、Anthropic 的 Claude Code 公开文档，乃至一些社区说明来回看了几遍，脑子里慢慢冒出一个比“AI 编程进入新阶段”更精准的判断： 这波变化真正值得我们关注的，不只是 AI 能不能写代码，而是工程经验正在被拆成可以复制使用、可调用的方法模块。
接下来我展开讲一下。
之前，大家聊 到AI 编程，主线几乎都是“模型能不能写代码”“能不能修 bug”“能不能读仓库”。这条线并没有错，但它却只讲了表面的一层。
真正难复制的，从来不是一段代码。
真正难复制的，是一个有经验的工程师处理问题时脑子里的那道程序。
他看到 bug，不会直接去改。
他会先判断范围，再确认是否重复出现，再看是不是最近提交引起的，再决定要不要先补测试，再决定修补还是重构。
这个顺序，可谓真是好家伙。 以前，这些东西基本都是人的脑子里的东西，或者散落在团队文档、代码规范、review 习惯和老同事的经验里的。 可现在，Claude Code、skills 相关项目，以及 Codex 相关社区整理内容，正在指向一个变化： 工程经验正在从“人脑里的东西”，逐渐变成“系统可以调用的模块”。 这个件事情一旦成立，那么AI 编程就不仅仅是“代码生成工具”了。
图片来源：Unsplash（免费可商用）
一、先别急着看模型能力，这次更值得看的是“经验开始资产化”
如果只看表面，这一波热度很容易被理解成：
- Claude Code 生态热度还在持续上涨；
- 开发者开始收集模板；
- 大家都在研究 skills；
- 不同 AI 编程工具的 agent 使用方式越来越接近。
这些都对。 但这些说法都还只是停留在工具层。 我觉得换个说法更直观些： 为什么开发者们最近都在关注这个skills 是否重要了？ 根据如今情况来看，模型变得够聪明之后，真正稀缺的并不是“答案”，是解决问题的方法。
现在很多人都在用 AI 写代码，最大的问题不是“模型会不会写”，而是“如何用模型怎么写”。 它的随机性很高有时会给你一个准确无误的答案，但也可能会给你一段看似很顺、很对、却有一大堆坑的东西。
工程师真正值钱的地方，不是每次写出来的代码都是最好的。
而是不断重复复杂的工作，琢磨出一套自己独有的处理问题的方法。
这就是引出我这篇文章的核心框架。
图片来源：Unsplash（免费可商用）
二、我们把这些变化拆成三层：模型层、经验层、执行层
接下来我就把自己的理解框架直接亮出来。 这个框架不是官方定义，只是我的个人归纳。各位只作参考即可。
第一层：模型层
这层可以理解是负责的是基础能力，例如：
- 理解用户需求；
- 生成代码；
- 推理；
- 改写；
- 解释；
- 长上下文阅读。
这一层是大家最熟悉的地方。 OpenAI、Anthropic、Google 等公司这些年卷的核心，也基本都是这些。
第二层：经验层
这层才是我觉得这次真正冒头的地方。 它不直接等同于输出代码，而是把工程经验压缩成可复用的动作模块。 比如：
- 怎么拆 PRD；
- 怎么拆 issue；
- 怎么 triage 一个 bug；
- 怎么做 TDD；
- 怎么写重构计划；
- 怎么给 git 操作加护栏。
这层的本质，不只是智力，而是方法存档。
第三层：执行层
这一层负责把前两层真正接到开发现场里，比如：
- 终端；
- Git；
- GitHub CLI；
- 测试命令；
- hooks；
- API；
- 调度逻辑。
没有这一层，前面两层整的再漂亮，也都是徒劳。 工程认的并不是“会说”，却是能落地。 这个可以简单理解为：
模型层：负责理解和生成
↓
经验层：负责定义做事方法
↓
执行层：负责把方法跑起来
如果能看懂这三层框架，后面的那就更容易能看懂了。
Claude Code 为什么重要？因为它更像是执行层的入口。
skills 为什么会备受关注？因为它卡在了经验层。
Codex 相关社区项目为什么值得去看？因为它说明“经验模块化”不是单一产品现象，可以理解为是在跨生态扩散。
图片来源：Unsplash（免费可商用）
三、Claude Code 真正补上的，不只是能力，而是“经验的宿主”
很多人聊 Claude Code，容易把重点放在“它能读代码库”“能跨文件修改”“能运行测试”。 根据 Anthropic 公开文档表示，目前Claude Code 已经具备读取项目上下文、跨文件修改、在终端环境中辅助执行开发任务等部分能力。部分扩展能力如 memory、hooks、subagents 等，具体支持范围和使用方式应以官方通报为准。
不过说实话，我倒是觉得这些还不是最关键的描述。
我倒是觉得可以把 Claude Code 理解成：
它给工程经验找到了一个默认宿主。
这话听起来有些抽象，我这里解释一下：
就好比以前你写 prompt，本质上是在临场指挥一个模型：
“帮我看这个 bug。”
“然后帮我测试，修改。”
“最后帮我重构一下。”
问题是，这些 prompt 却很难沉淀。
今天你这么写，明天同事那么写，后天另一个项目代码又换了一种写法。 大模型都能回答解决，但其回答的稳定性、动作顺序和边界感，却是没有预想的那么理想。 Claude Code 这类终端型 agent 的出现，像是把事情给改变了。 给人的感觉它不仅是个聊天窗口，还是一个有工具接口、运行环境、行为能力的执行者。
也就是说，如果这个说法成立，那么我们可以这样理解：
Prompt 只是是一次性的指令。
Skill 就是一种可重复调用的方法。
Claude Code 这类 agent，就好比
是承载理论方法的工作台。
比如以前你是要请一个人帮忙。
而现在你可直接分配岗位配操作手册。
图片来源：Unsplash（免费可商用）
四、一些工程场景：以前可以靠老同事帮忙，现在开始靠 skill
我们可以这样假设到一个常见工程场景里。 如果团队接到一个 issue：
用户反馈导出功能偶发失败，日志里出现超时，但只有部分租户会复现。
这类似的问题非常典型，也特别烦。 并不是那种一眼就能看出来问题，也不是简单改一下配置就能完事。 以前，一些有经验的工程师都会这样去处理：
接到 issue
↓
先确认被影响的范围
↓
查询最近相关提交
↓
看看日志和监控
↓
尝试复现 ↓
判断是环境、数据、并发还是逻辑问题
↓
决定先补测试还是先打临时日志
↓
再进入修复或重构
注意，真正值钱的不是最后那几行修复代码。 真正值钱的是这个排查顺序。 现在如果你去看一些 skills 相关仓库里的命名，比如 triage-issue、request-refactor-plan、tdd 等，会发现它们想做的，恰恰是把这个顺序拆出来。 也就是说，未来一个更完整的 agent 工作流，可能是这样：
收到 issue
↓
调用 triage-issue
↓
先整理问题范围、复现条件、怀疑路径
↓
如果确认要结构性调整
↓
调用 request-refactor-plan
↓
生成分阶段改动建议
↓
如果要补验证
↓
调用 tdd 或测试相关 skill
↓
最后交给 Claude Code 等工具执行具体改动、跑测试、检查结果
你看，最重要的那些变化并不在“AI 会不会写修复代码”。 最重要的变化在于： 那些存在人脑子里的排查顺序，第一次有机会变成团队可循环复制使用的东西。
这也就是我为什么一直强调的经验资产化。
以前，团队最怕的是什么？
怕资深同事走了，很多有点经验也跟着走了。
现在的skills 真正有意思的地方在于它给了工程经验一种全新的存储形式。
它目前还不够成熟，但大体方向是已经出来了。
图片来源：Unsplash（免费可商用）
五、skills 项目让我停下来的思考的不是热度，而是它确实很像一个“经验仓库”
我去查找一些 skills 相关项目时，却发现不是 README 写得多花多漂亮，而很多 skill 名字真的太像工程师了。 比如：
- to-prd；
- to-issues；
- triage-issue；
- request-refactor-plan；
- tdd；
- design-an-interface；
- improve-codebase-architecture；
- git-guardrails；
- write-a-skill。
这些名字很诚实。 它们没有那种“万能生成器”的浮夸感。相反，它们全都指向真实工作流里的固定动作。 我后来反应过来，这类项目真正有价值的地方，不是“提供很多 skill”。 而是它在提醒开发者一件事：
以后最值钱的，可能不是你临时写出来的 prompt，而是你能不能把自己的做事方式沉淀成一个别人也能调用的 skill。
这个变化其实很深。 因为 prompt 是个人习惯。 skill 更像团队资产。 这两者的差别，跟“会做事”和“能教会别人做事”有点像。 后者的杠杆明显更大。
六、Codex 相关社区项目说明：经验不只要能存，还要能按条件加载
需要说明的是，本文提到的 Codex 相关 skills 内容，主要来自开源社区整理和讨论，不等同于 OpenAI 官方发布或背书。具体能力边界，应以官方文档和相关项目说明为准。
如果只有 Claude 生态在讲 skill，我还会觉得这件事有一点产品策略色彩。 但 Codex 相关社区项目的出现，让我更确定这不是某一家公司的单独动作。 从部分社区项目的设计思路看，skills 正在尝试通过 metadata、触发条件、正文延迟加载、CLI/API 调用等方式，降低上下文压力，并让经验模块更容易被系统调用。
不同项目的实现方式并不相同，具体能力仍需以各自文档为准。 这几个点放在一起看，其实指向的是一个更成熟的问题： 经验不只是要存下来，还要在合适的时候被系统准确调出来。
这属于另一个层级了。 很多团队其实并不是没有方法。 是方法太散、太碎、太依赖具体的的某人了，而这个人却没法100%的稳定。 如果说 Claude Code 解决的是“经验有没有执行者”，那么 Codex 关于 skills 的讨论更像是在补全另一个问题： 经验能不能被系统按条件调度，不是每次都靠人手动提醒。 这就更像工程系统，而不仅仅是提示词技巧了。
七、接下来拼的很可能不是模型是否更强，是更低成本的经验复制模式
这句话说得更直白一点。 现在行业里都在谈ai大模型替代程序员。 我觉得这个说法既粗糙，也没说到重点。 程序员真正不可替代的，不是写代码的能力，而是经验丰富的密度。 而 AI 编程如果想真正走进团队，迟早要面对一个问题：
怎么把人的经验密度，拆成机器能持续调用的东西。
所以我现在的判断是： AI 编程接下来的竞争，表面上看还是模型竞争，底层其实会越来越像“经验复制效率”的竞争。 谁能更低成本地复制经验，谁就更有生产力杠杆。 这个逻辑一旦成立，很多事情都要重写：
- skill 市场会变得重要；
- 工作流模板会变得重要；
- 团队自己的方法库会变得重要；
- 经验沉淀方式会变得重要；
- 甚至“谁来维护经验资产”都会变成一个新角色。
这个方向，我觉得比“下一个模型还能多强一点”更值得长期关注。
八、当然，冷水还是要泼：经验资产化没那么简单
写到这儿，我只负责鼓吹，不够还是得把问题说完。
第一，很多所谓的 skill 还只是“包装过的提示词”
这点特别现实。 有些 skill 看起来像模块，其实只是换了一个很长目录结构的 prompt。 它没有真的定义：
- 输入边界；
- 触发条件；
- 失败处理；
- 输出格式；
- 权限限制。
这种东西可以演示，但不太像是经验资产化。 真正能沉淀成团队资产的东西，必须是可维护、可解释、可复用。
第二，经验一旦资产化，就会遇到治理问题
一旦团队开始积累 skill，很快就会碰到这些问题：
- 谁能创建 skill？
- 谁来审核？
- 谁负责淘汰旧版本？
- skill 冲突怎么办？
- skill 和团队规范不一致怎么办？
以前经验在脑子里，问题是“传不下来”。
现在经验写成 skill，问题是成了“谁来管理”。
这其实是好问题，但也是难问题。
图片来源：Unsplash（免费可商用）
第三，个人爽感不等于团队效率
个人开发者用 Claude Code 加 skills，往往很爽。 这我完全信。 但团队场景更复杂。团队还要面对：
- 权限边界；
- 代码审查；
- CI/CD；
- 安全审计；
- 回滚；
- 合规要求。
所以我不会说“skills 一来，开发流程就被重构了”。 这太早了。 我更愿意说： 我们终于看到了一个可能成立的方向，但这个方向刚刚从概念走到工程起点。
九、最后：真正值得写下来的，是工程经验开始变成可调用资产
如果你读到这里，只想记住一句，那我希望是这一句： 从 Claude Code 到 skills 相关项目，这波变化真正开始沉淀的，不只是代码，而是工程经验。 我为什么觉得这句话比“AI 编程进入新阶段”更重要？ 因为“进入新阶段”太空了。 而“工程经验开始从个人经验，变成可调用资产”，是一个非常具体的判断。
这意味着什么？ 意味着未来团队里最值钱的，不一定是谁最会写 prompt，却是：
- 谁能把方法讲清楚；
- 谁能把经验知识封装出来；
- 谁能把这些封装成稳定的 skill；
- 谁能让这些 skill 真的跑进工作流。
过去我们说知识管理。 也许现在开始要说知识经验管理了。 而且这一次，知识经验管理不只是写在 wiki 里等人看。 它有机会直接接到 agent 身上，接到终端里，接到代码库旁边。 说实话，我觉得这件事的分量，比热榜本身大得多。 热榜只是在提醒我们：风向变了。 真正变的，不是 AI 会不会写。 是工程师终于开始想办法，把自己的做事方式也可以交给系统。 这一步，才像是 AI 编程真正摸到生产力天花板之前，最值得认真准备的一步。
