目录
一、提示词工程师这个岗位正在被取消
二、提示词不值钱，值钱的是技能封装
三、Skill库的本质：把高频决策变成低代码资产
四、OpenClaw、Cursor、Claude Code的Skill资产对比
五、从0到1构建你的私有Skill库
六、三年后，你的团队靠什么拉开差距
如果你所在的公司还在招“提示词工程师”，大概率踩坑了。
不是危言耸听。今年一季度，北美已经有超过30%的AI岗位从“Prompt Engineer”改成了“Agent Engineer”或“LLM Tooling Engineer”。国内几家大厂的内部调整更直接——提示词优化被归入基础模型团队的常规工作，不再单独设岗。
为什么？
因为提示词的壁垒太薄了。
你花两周调出来的一套CoT提示词，对手花半天就能逆向出来。你用Few-shot让模型输出结构化JSON，换个模型版本可能就不灵了。更致命的是，提示词无法积累——你今天为A场景写的提示词，明天做B场景几乎用不上。
但培训机构和自媒体还在制造焦虑：再不学提示词就晚了。
真正在一线做Agent落地的人已经看清了：能拉开护城河的，不是提示词，是私有Skill库。
Skill库就是你团队独有的、可复用的、带容错逻辑的执行单元集合。它不像提示词那样可以被几句prompt扒走。它跟你的业务逻辑、你的失败处理经验、你的合规边界深度绑定。
本文从工程视角拆一次：为什么私有Skill库才是壁垒，以及你该怎么建自己的Skill库。
一、提示词工程师这个岗位正在被取消
先看几个信号。
Claude Code的底层调用根本不依赖外部提示词工程。用户输入自然语言，Agent自己规划任务，调用Skill，Skill内部自带了针对不同子任务的默认提示词模板。用户不需要调提示词。
Cursor同样。它的核心能力是“理解项目结构”和“多文件编辑”，这两个能力的实现靠的不是公开的提示词配方，而是大量工程化的代码分析和上下文注入逻辑。提示词只是最表层的胶水。
OpenClaw早期版本严重依赖提示词来规划浏览器操作，结果经常卡在复杂页面上。后来他们将大部分决策逻辑移到了Skill内部，提示词只负责最粗粒度的意图识别。稳定性大幅提升。
这三家公司的共性不是“提示词写得好”，而是“尽量少依赖提示词”。
一线工程经验也佐证了这一点：我们做过一轮对照实验。同样一个“UI视觉回归”任务，纯提示词方案（给模型截图+长指令）的成功率只有67%，而且每次运行成本高。换成Skill封装方案，成功率91%，单次成本下降40%。
差别在于：Skill把“什么时候截图、比对阈值设多少、失败重试几次”这些决策从提示词里抽出来，写成了确定性代码。模型只做它擅长的事——判断“这两张截图是否有语义差异”。
本质上，提示词适合做一次性、探索性任务。一旦任务频率高了，就应该把流程固化到Skill里。
所以不是提示词没用，是它只能作为临时方案。长期来看，你积累的是Skill，不是提示词。
二、提示词不值钱，值钱的是技能封装
为什么说提示词不值钱？
三个原因。
第一，提示词易复制。你写了一套惊艳的系统提示词，发给别人，人家直接拿去用。最多改几个词。没有护城河。
第二，提示词不跨场景。你在电商场景调的提示词，换到金融场景基本要重写。因为业务语义、输出格式、错误处理都不一样。
第三，提示词不跨模型。GPT-4下能跑的提示词，换到Claude或国产模型上可能完全失效。你被绑定在单一模型上。
Skill库不一样。
一个Skill封装的是“输入-处理-输出-容错”的完整逻辑。别人拿到你Skill的代码，不代表能直接用，因为Skill依赖你的内部API、你的数据格式、你的失败处理策略。
比如我们内部有一个“数据库查询Skill”，它知道公司内部测试环境的连接池配置、慢查询告警阈值、结果集大小限制。这些配置不在代码里，在环境变量和私有配置中心。别人拷走Skill代码，连不上数据库。
另一个例子是“Jira工单自动分类Skill”。它内置了我们的工单类型枚举、优先级映射规则、责任人分配表。这些规则每个公司都不一样。Skill可以分享框架，但真正的业务价值在那些私有配置里。
核心在于：Skill是资产，提示词是技巧。资产可以增值、复用、形成网络效应；技巧用完就忘。
三、Skill库的本质：把高频决策变成低代码资产
从工程架构看，一个成熟的Skill库长什么样？
我拆一张图。
这张图想表达的核心：Skill库不是一堆代码文件，而是一个分层的、与私有资产绑定的能力体系。
原子Skill：单次操作，如“读文件”“执行SQL”“截图”。几乎没有业务逻辑。
复合Skill：组合多个原子Skill，如“读取配置-连接数据库-执行查询-格式化输出”。
业务Skill：绑定具体业务规则，如“判定订单是否异常”需要调用你们的异常判定规则库。
私有资产层才是真正的护城河。别人可以模仿Skill的调用结构，但拿不到你们的API凭证、业务规则、回滚策略。
构建Skill库的过程，本质上是对团队高频任务的梳理和固化。每固化一个Skill，就减少一次重复的提示词调试。长期积累下来，你的Agent做事越来越准，新人上手越来越快。
一个可量化的案例：我们固化“接口自动化测试Skill”后，新测试同学写一个接口用例的时间从平均25分钟降到6分钟。因为Skill内部已经封装了认证、数据清理、断言模板。他们只需要填URL和预期返回值。
四、OpenClaw、Cursor、Claude Code的Skill资产对比
不同产品对Skill资产的策略不同，直接决定了它们的护城河深浅。
OpenClaw：开源Skill，护城河浅
OpenClaw的Skill全部开源。任何人都可以拷走它的浏览器自动化Skill库。好处是社区贡献活跃，坏处是你无法基于它构建独家竞争力。如果你的业务重度依赖OpenClaw，你和竞品没有差异。
Cursor：闭源深度Skill，护城河中等
Cursor的Project Understanding Skill没有开源。你只知道它能理解项目结构，但具体怎么解析依赖、怎么构建AST、怎么做跨文件引用追踪，你看不到。想自己实现一个类似的，投入非常大。但Cursor的Skill偏向通用代码场景，不针对特定行业，所以对垂直领域的企业来说，还不够深。
Claude Code：基础Skill开源 + 私有Skill扩展，护城河可深可浅
Claude Code提供一组开源的基础Skill（读写文件、执行命令等），同时支持企业挂载私有Skill。你可以在它的框架上不断沉淀自己的业务Skill。基础能力通用了，上层竞争力完全取决于你自己的积累。
这个模式最接近理想状态：不需要重复造轮子，但核心业务逻辑掌握在自己手里。
我建议大多数团队走Claude Code这条路。不要自己从零搭Skill框架，用现成的开源底座，然后把精力放在业务Skill的积累上。
这里有个判断标准：如果某个Skill换个公司就不能直接跑通，那它就是私有资产，值得投人做。如果换个公司改几个配置就能跑，那直接用开源方案。
五、从0到1构建你的私有Skill库
说了这么多，落地怎么做？我按优先级给三步。
第一步：盘点高频痛任务
拉出你团队过去一个月重复做过三次以上的事情。不限于技术任务，包括流程性的、沟通性的。
举例：
每次提测前，人工跑一遍环境检查（5个服务状态、3个数据库连接、2个消息队列）。
每次收到线上告警，手动登录服务器查日志、分析堆栈、判断是否重启。
每次回归测试，手动对比UI截图，圈出变化点，写报告。
选其中一个，频率最高的，开始封装第一个Skill。
第二步：先写死逻辑，再引入模型
新手容易犯的错：一上来就让模型做决策。Skill的稳定核心应该是确定性代码，模型只在需要判断的地方介入。
拿UI回归举例。确定性部分：Playwright截图、pixel diff计算、超过阈值触发告警。模型介入的部分：判断diff是否属于有意义的变化（比如动态广告导致的大面积diff，但UI没变）。
不要把整个Skill都交给模型。成本高，还不稳定。
第三步：建立Skill寄存器
当Skill数量超过5个，就需要一个地方管理它们的元数据：名称、描述、输入输出格式、依赖哪些私有资产、版本号、负责人。
最简单的寄存器可以是一个Markdown表格。进阶可以用JSON Schema + 目录结构。目的是让团队的Agent（或人）能快速找到该用哪个Skill。
我们内部的做法是每个Skill目录下放一个skill.json：
{
"name": "db_query_executor",
"description": "执行只读SQL查询并返回JSON结果。不要用于写操作。",
"input_schema": {...},
"output_schema": {...},
"dependencies": ["internal_db_ro_token", "slow_query_threshold"],
"version": "2.1.0"
}
Agent读到这个文件就知道：什么场景调用、需要什么权限、输出长什么样。
做到这三步，你的团队就有了一个可生长的私有Skill库雏形。以后每个新任务，先问一句：“有没有现成Skill可以用？”没有，就写一个新的。写完加到库里。
三个月后，你对竞品的优势不是模型更强，而是完成同样任务需要的代码和人时少一半。
六、三年后，你的团队靠什么拉开差距
模型会持续进化，API价格会持续下降，开源Skill会越来越多。
到那时候，什么才是你团队独特的价值？
不是调提示词的手艺，模型自己就会调了。
不是写通用Skill的能力，开源社区做得更好。
是你对自己业务领域的深刻理解，以及把这些理解固化到私有Skill库的能力。
你们的订单审核流程里有三个特殊审批分支，只有你们知道。你们的UI组件库有二十个自定义属性，只有你们的Skill知道怎么处理。你们的测试环境配置了特殊的Mock数据，只有你们的Skill知道怎么注入。
这些东西，模型学不会，开源项目拿不走。
这才是护城河。
最后问一个判断性问题：
如果今天让你盘点团队里所有“每周重复超过三次、且目前由人工完成”的任务，你能立刻写出前三名吗？如果写不出，说明你离构建私有Skill库还有多远？
