先说结论：Skill 不是壁垒，是必要的工程手段。但 Skill 确实造成了平台锁定——这个矛盾值得拆开看。

一、Skill 到底是什么

把问题拉回原点：Skill 本质上是一组结构化的系统提示词，这个判断没错。但"结构化"三个字才是关键。

裸 prompt 能干活吗？能。写个"帮我写一个 Go 的 HTTP 服务"，任何模型都能吐出一段能跑的代码。但如果你要的是一个完整的工程——有分层架构、错误处理规范、日志策略、输入校验——裸 prompt 就撑不住了。不是因为模型不行，是因为你没法在一句 prompt 里塞进去 800 行的编码规范。

Skill 做的事情是把这些规范固化、模块化、按需加载。你不需要每次都把"函数参数不超过 5 个"“内层只返回错误不记日志"写在 prompt 里——Skill 帮你带着走。

说得更直白点：裸 prompt 是跟 AI 说"你帮我写代码”，Skill 是跟 AI 说"你按我们团队的规矩写代码"。前者是临时工，后者是入职员工。

二、平台锁定才是真问题

题主说到点子上了——“Skill 只有 Claude Code 这一个平台支持”。

这才是关键矛盾。Skill 的价值是真实的，但它绑定在特定平台上：你在 Claude Code 上积累的 Skill 不能直接搬到 Cursor、Windsurf、或者自己搭的 Agent 框架上。平台有动机维持这种绑定——锁定越深，你越离不开。社区生态围绕特定平台生长，进一步加固锁定。

那为什么不能直接复制粘贴系统提示词？理论上可以，但实践中会撞上三个硬壁。上下文窗口有限——一个 Skill 200 行，十个就是 2000 行，全塞进去留给对话的空间就没了。Skill 的按需加载机制解决的就是这个。然后是组合冲突——不同 Skill 可能互相矛盾，一个要详细注释，一个要精简代码，手动管理比写代码还累。最后是版本同步——规范会变，Skill 更新一次所有项目自动生效，手动复制粘贴？你追着十个项目逐个改。

用 openai 库调 API 确实更自由。但自由是有代价的：你得自己处理上下文管理、工具调用编排、Skill 加载调度——这些 Claude Code 帮你做了。说具体点，Claude Code 的 Skill 加载机制会在你输入时自动判断需要哪些 Skill、按优先级组装、处理冲突——这一套编排逻辑你自己写至少几百行。

这种权衡不是新鲜事。IntelliJ 的插件只能在 JetBrains 系 IDE 上跑，VS Code 扩展也不能直接装到 Vim 里。没有人说 JetBrains 在造壁垒——它就是选了一种生态，你享受了它的便利，就得接受它的边界。

三、壁垒？在别处，但不是你想的那样

很多人说"真正的壁垒是架构决策、问题定义、系统思维"——这话没错，但也只是把问题往后推了一层。

说具体点。我见过一个团队用 AI 把整个 CRUD 层自动生成了，效率提升很明显。但当他们想加一个跨服务的分布式事务时，AI 给了三种方案——Saga、TCC、本地消息表——每种都写得有模有样。问题来了：选哪个？这取决于业务容忍的一致性窗口、团队对补偿逻辑的维护能力、现有基础设施的支持程度。这些判断，AI 做不了。不是能力不够，是它没有你的上下文。

所以壁垒不是某个抽象的"系统思维"，而是一个很具体的东西：你有没有在真实系统里踩过坑、做过取舍、为某个决策承担过后果。这种经验是不可迁移的——你读再多架构文章也没用，得自己疼过才知道。

Skill 解决的问题离这个层次还远得很。它管的是"怎么写"，不是"写什么"和"为什么这么写"。把 Skill 当壁垒，就像把 lint 规则当壁垒一样——确实有人不会配 ESLint，但没人觉得 ESLint 是程序员在对抗 AI。

Skill 是工具，不是护城河。平台锁定是真实的代价。想清楚一件事就行：你用 Agent 是为了效率，还是为了可控性？两个都要，就得接受权衡。没有免费午餐。