夜雨聆风
最近我把一个缺陷修复流程，整理成了 AI 可以反复执行的 Skill。
一开始，我以为自己只是在给 AI 写一份更长的 Prompt。
但连续用下来才发现，真正被复用的不是那几句话，而是我过去处理问题的步骤、判断和验证习惯。
也就是这个时候，我才重新理解最近程序员圈子里调侃的两个词："蒸馏同事"和"skill 永生"。
前者说的是用 AI 把人的经验、方法和判断力提取成可执行指令。后者说的是人会离职，但 skill 不会。
听起来像玩笑，但背后有一个很真实的问题：
当 AI 越来越能写代码，程序员到底还能沉淀什么？
我自己的判断是：不是代码，不是 prompt，而是 skill。
不是因为这个词多高级，而是因为在我自己的实践里，skill 是目前普通人驾驭 AI 最实在的方式。
它不只是告诉 AI "做什么"，还包括"怎么做"、"在什么条件下做"、"怎么判断做对了"。
而且它能持续迭代——每用一次，就比上一次更好一点。
Prompt 很快会过时，Skill 不会
很多人开始用 AI 以后，会有一个自然的习惯：把用过的好 prompt 收藏起来。
"帮我写一个 XX 函数。"
"请按照以下格式整理代码。"
"分析这段日志里的异常。"
这些 prompt 确实有用。但它们有一个问题：换了模型、换了项目、换了上下文，同一个 prompt 可能就不管用了。
prompt 本质上是一次性的指令。它只在当时那个场景下有效。
skill 不一样。
skill 不只是"说什么"，它还包括：
•在什么场景下触发。
•按什么步骤执行。
•遇到什么情况要暂停。
•怎么判断结果是对的。
•哪些地方不能偷懒。
如果做个类比的话：prompt 像一句话的嘱咐，skill 像一份经过验证的岗位手册。
嘱咐容易忘，也容易走样。
手册可以被反复使用，也可以被不断改进。
这也是为什么我现在更愿意把时间花在沉淀 skill 上，而不是收集 prompt。
Skill 到底是什么——从一个真实例子说起
说 skill 有价值，不能只停留在概念上。
我用一个自己工作中的真实例子来说明。
工作里最常做的一类任务是缺陷修复：收到工单 → 理解问题 → 分析根因 → 修复代码 → 验证 → 提交 → 回写处理结果。
这个流程每天都在做。
后来我开始让 AI 参与这件事。
一开始的做法很直接：把工单内容贴给 AI，让它帮我分析和修代码。
但很快发现一个问题：每次都要重新交代一遍。项目背景、代码结构、处理流程、验证方式、提交规范、回写格式——AI 不记得上次是怎么做的。
而且 AI 的执行质量很不稳定。有时候它跳过验证就宣布完成，有时候它修错了方向，有时候它修了一个点但漏掉了同模式的其他路径。
于是我开始把这套流程逐步提取成一个 skill，叫 bug-fix-flow。
它不是一段 prompt，而是一组文件：
skills/bug-fix-flow/├── SKILL.md # 编排器：流程阶段、输入参数、路由规则├── references/│ ├── common-workflow.md # 通用底本：所有项目共用的修复方法论│ ├── HOW-TO-ADD-PROFILE.md # 接入指南：新项目怎么写配置│ └── profiles/│ ├── product-a.md # 产品 A 的工程配置│ └── product-b.md # 产品 B 的工程配置
这个 skill 有几个特征：
第一，它有明确的输入和输出。输入是一个工单编号，输出是修复结果加工单回写。
第二，它有完整的流程。不是一句话的指令，而是一系列有顺序的阶段：
第三，它有边界。什么时候必须暂停（需求语义不清），什么时候必须验证（修完代码不等于完成），什么时候不能伪造进度（定位不到根因就老实说定位不到）。
第四，它有分层。
SKILL.md 只管编排——定义阶段顺序和节奏，不绑定具体项目。
common-workflow.md 管方法论——怎样澄清需求、怎样分析根因、怎样做扩散检查、怎样输出验证矩阵。这些方法论适用于所有项目。
profiles/ 管项目差异——每个具体项目的代码仓库在哪里、提交格式是什么、需要额外检查哪些维度。
这种分层的好处是：流程变了改编排层，方法论进步了改方法论层，换了项目只需加一份配置。三层独立演进，互不干扰。
说到这里，skill 就不再是一个抽象概念了。
它是一组具体的文件，有结构，有流程，有边界，有分层。
它是写给 AI 执行的方法。但它的内容，来自人在真实工作中积累的经验和判断。
Skill 从哪里来——不是设计出来的，是踩坑踩出来的
bug-fix-flow 不是一开始就设计成现在这样的。
它是从一次又一次踩坑中长出来的。
每一条规则背后，都有一个真实的教训。
需求澄清门。 有几次在工单描述语义不清时，AI 直接按自己的理解修了代码。结果修错了方向，返工比不用 AI 还慢。后来我加了一道强制机制——工单描述有歧义时，必须先在工单里留言澄清，确认后才能动手。这个门跳不过去。
扩散分析。 有几次"修了一个点，漏了同模式的其他路径"。比如改了编辑入口的某个校验逻辑，但同一个功能还有新增、查看、导出等入口，用了同样的错误逻辑，结果只改了一处。后来在通用底本里形成了一份逐项检查清单，A 到 H 八个维度：读路径、写路径、调用链、分支覆盖、前后端契约、多实现差异、多入口一致性、回归边界。产品 profile 还可以在通用维度上叠加自己特有的检查轴。每一项都必须写结论，不能留空。
症状验证矩阵。 有几次一个工单里报了三个症状，AI 只修了最明显的一个就宣布完成。后来加了要求：逐症状输出验证结果——已修复加证据，或者确认不属于本次问题加原因。没有矩阵，就不允许进入提交阶段。
同等环境校验。 有几次缺陷在特定部署环境下才出现——比如集群模式、升级路径。但验证时用的是单机全新环境，结果放过了问题。后来加了铁律：缺陷在什么环境暴露的，就必须在同等环境下验证。
结构化回填。 有一次复盘时发现，几十个缺陷的根因分类字段全部留空。复盘时只能靠事后推断，效率很低，结论也不可靠。后来加了强制要求：修复完成前必须回填根因分类、原因说明等结构化字段，不能只写一段自由文本评论。
这些规则看起来像"流程管控"。
但它们真正的来源不是管控，而是痛。
每一条都是因为踩过坑，才反过来补进 skill 的。
这也是我想说的一个关键点：不要等"想好了"再提取 skill。先做任务，做完再回头看，能提取什么就提取什么。
踩坑本身，就是 skill 最好的养分。
Skill 不是一次写完的——在使用中打磨、在复盘中进化
第一版 skill 一定是粗的。
但关键是它能被复用，并且在复用中持续变好。
以 bug-fix-flow 为例。
最早只有几条处理步骤："看工单 → 改代码 → 提交"。
后来发现不同产品的仓库路径、提交格式、检查维度差异很大，不能硬编码在流程里。于是加了 profile 机制——每个产品写一份配置，编排器自动按工单编号前缀路由到对应的 profile。
一份 profile 不需要很神秘，本质上就是回答几类问题：
profile 的正文章节里还会写模块职责、扩散维度的详细检查清单、提交信息样例。这些信息都是根因分析和扩散检查时直接要用的。
后来又做了跨 AI 工具的适配。同一个 skill 在 Claude Code 和 Codex 里都要能用，但方法论只维护一份。不同工具只做少量适配，不重写业务流程。
后来还写了一份接入指南 HOW-TO-ADD-PROFILE.md，让新项目只需要复制一份现有 profile，替换里面的字段，就能复用整套流程。
这个过程不是"重构"。
它更像是 skill 自然的生长过程。
每用一次，就发现一个不够的地方。
每复盘一次，就补上一块缺口。
这也是为什么 skill 比 prompt 更有生命力。
prompt 用完就丢了。
skill 越用越好。
还有一个设计我觉得值得提一下。
bug-fix-flow 本身是一个编排器。它在不同阶段挂接其他方法论 skill：
编排器不重写这些方法论，只在合适的时机调用它们。
这也是 skill 的一个设计特征：好的 skill 知道什么时候该用什么方法，而不是把所有方法论都自己写一遍。
我现在怎么判断一个任务值得沉淀成 Skill
写到这里，可能会有一个问题：是不是所有任务都要沉淀成 skill？
当然不是。
如果一件事只做一次，或者结果完全依赖当下判断，那就没必要急着沉淀。
但如果一个任务反复出现，而且每次都要重新交代背景、步骤、边界和验证方式，那它就值得被提取出来。
现在我做完一个 AI 协作任务后，会问自己四个问题：
1. 哪些步骤下次还会重复？ 2. 哪些判断不能交给 AI 自由发挥？ 3. 哪些验证必须强制执行？ 4. 哪些项目差异应该做成配置，而不是写死在 Prompt 里？
只要这四个问题里有两个答案比较明确，我就会先写一个很粗的 skill。
第一版不用完整。
它可以只有一页说明，甚至只有几个阶段和几条边界。
关键是先把"下次还会重复交代的东西"留下来。
后面每用一次，再补一个缺口。
这比收藏十几个 prompt 更有用。因为 prompt 收藏得越多，下一次你还是要靠自己判断该用哪一个；而 skill 沉淀得越清楚，AI 才越有机会稳定地执行一类任务。
行业为什么都在强调 Skill 沉淀
不只是我自己在做这件事。
从工具层面看，主流 AI 编程工具已经在围绕 skill 沉淀来设计了。
Codex 的 AGENTS.md，本质上就是最基础的 skill——告诉 AI 这个项目是什么、技术栈是什么、哪些规则必须遵守。
Superpowers 更进一步，把开发实践组织成一组可组合的 skill：brainstorming、test-driven-development、verification-before-completion，每一个都是独立的方法论模块。
Cursor 的 Rules，Claude 的 CLAUDE.md，本质上都在做同一件事：让团队的工作方法变成 AI 能理解和执行的结构化知识。
从公司层面看，越来越多团队开始要求沉淀 AI 协作规范和工程 skill。
原因很朴素：AI 模型在快速迭代，可能今天用这个模型，明天用那个。但团队的工作方法和质量标准不能每换一次模型就从零开始。
skill 就是把这些方法固化下来的方式。
而且好的 skill 是跨模型、跨工具的。
因为它沉淀的不是某个模型的用法，而是你理解问题和解决问题的方式。
这个方式不会因为底层模型换了就失效。
面对"蒸馏同事"和裁员焦虑
回到开头那两个词。
"蒸馏同事"听起来很刺激。
但仔细想想，它背后的焦虑是真实的：如果我的经验可以被提取成 skill，那我还有什么不可替代性？
我自己的看法是这样的。
焦虑很正常。但焦虑本身不产生竞争力。
与其被动等着被"蒸馏"，不如主动沉淀自己的方法。
真正不可替代的，从来不是某段代码，也不是某个 prompt。
而是持续定义问题、判断取舍、迭代方法的能力。
这些能力恰恰是通过打磨 skill 来锻炼的。
你在沉淀 skill 的过程中，不只是在教 AI 怎么工作。你也在逼自己回答：这件事的核心步骤到底是什么？哪些判断是真正关键的？哪些验证是不能省的？哪些边界是容易被忽略的？
这些问题的答案，不是 AI 能替你想出来的。
至于"skill 永生"这个说法，我觉得它只说对了一半。
skill 确实可以在人不在的时候继续产生价值。
但离开了创造者的持续维护和迭代，skill 也会过时。
它不是写完就永远有效的。它需要被使用、被检验、被更新。
这也意味着，真正有价值的不只是"拥有一份 skill"，而是"持续打磨 skill 的能力"。
所以我对职场上这些话题的态度很简单：
先做好自己。
适应 AI 的发展，与 AI 的节奏同频。
用沉淀证明价值，而不是用焦虑消耗自己。
AI 确实会改变很多岗位。
但在变化中，有沉淀的人比没沉淀的人走得更稳。
留下什么，比用了什么更重要
与 AI 同频，不是追每一个新模型、每一个新工具。
更实在的方式是：在自己的工作里，把 AI 协作中有效的方法持续沉淀成 skill。
这些 skill 不会因为模型换代而失效。因为它们沉淀的不是 prompt，而是你理解问题和解决问题的方式。
如果说前面几篇文章在讲"怎么用 AI"，这篇想说的是"用完以后，留下什么"。
留下的不应该只是代码。
应该是一套你自己的方法——经过实践、经过踩坑、经过迭代，能被 AI 理解和执行，也能被未来的你继续改进。
这可能没有"十倍效率"听起来刺激。
但它更接近我在真实工作里愿意长期走下去的方式。
