Claude Code SKILL实战：前端开发中AI代码可用率99%的真实体验

最近“SKILL”这个概念很火，网上讨论非常多，甚至让一些前端开发者感到焦虑。很多人没讲清楚SKILL到底是什么，导致它被渲染得很神秘。

首先需要明确，SKILL 并不是什么革命性的新东西，它本质上就是提示词（Prompt）。它是早期 Cursor Rules 的一种更灵活的实现形式，依然使用 md 格式编写。其核心逻辑没有变化，只是被更好地集成到了项目工程中，变得更加细化和灵活。

早期的 cursor rules 比较死板，因为它对整个项目全局生效，粒度不够细。后来出现了能细化作用范围的 .mdc 文件。而 SKILL 可以看作是提示词在工程化道路上朝着更灵活、更精细方向发展的必然结果。

它与 .mdc 的一个核心区别在于触发时机。SKILL 会在你输入需求后，由 Claude Code 动态匹配：系统会判断哪一段 SKILL 提示词与你的当前需求最相关，而不是无脑地直接应用所有规则。

例如，我们可以编写一个 SKILL.md 文件：

路径: .claude/skills/createTable/SKILL.md

---
name: 创建表格
description: 当我需要创建表格式，使用这个 skill
---

# 表格格式
- 数字右对齐
- 文字左对齐
- 标题加粗
- 字母使用斜体
...

当你输入需求：“在 xxx 页面创建一个表格，数据从 users 表中获取”，Claude Code 就会自动匹配并使用我们刚刚创建的那个“创建表格”SKILL。你可以把它理解为给提示词套上了一层 if (条件匹配) 判断，或者类比为函数的封装。

SKILL.md 的主要优势在于：

1. 按需使用：仅在匹配时触发，而非强制全局应用。
2. 可复用性与可移植性强：可以轻松地在不同项目间迁移。
3. 可扩展性：可以关联本地脚本，让编程工具执行更复杂的逻辑（不过大多数情况下，只写提示词就足够了）。

我的真实使用体验

我曾在自己的付费专栏《React 19 架构尊享版》中，为了帮助用户更高效地借助 AI 编程应用专栏的架构思路，将其核心逻辑提炼成了一个 SKILL.md。

另外，在我关于 Zustand 的专栏中，针对管理非异步状态交互的场景，我也设计了一套专门的 SKILL.md。这套技能的核心原则是必须保证生成代码的高度可维护性。

我用它们总共测试了40多个需求，在 Claude Code 的加持下，生成代码的直接可用率达到了99%。

但是，我只说了真相的一半。

完整的真实情况是，剩下的那1%纯粹是来“恶心人”的。AI会在一些非常细节的地方，做出提示词要求之外的事情。我收集了以下几个典型问题：

1. 出现一次 export default 与 export 的引入关系错误，尽管提示词中已有明确约束。
2. 出现一次 useMemo 依赖项填写错误，导致缓存失效产生Bug。
3. 多次出现样式细节纰漏，例如边距不对、宽高尺寸不合理等。
4. 出现一次默认值传错，导致显示结果不符合预期。
5. 多次额外添加了不想要的功能。
6. 出现一次控制子元素滚动条时，意外影响了 body 的滚动条。
7. 重灾区：当我试图增加一些提升交互体验的动画时，不符合预期的概率会极大增加。有时即使经过多轮对话，也无法修正，最终需要手动调整。
8. 过度编写TS类型，没有充分利用类型推导来简化代码。

如果仅以“80%或90%的代码由AI生成”为标准，那么我的SKILL确实很强。因为我是基于一套成熟的、强调可读性、简洁性和可扩展性的代码架构来约束生成的，所以最终代码与我手写的相似度极高。

从这个结果看，似乎值得吹嘘一番。但我的实际使用体验并不好。因为每次让AI执行需求，你都无法预知结果，内心会充满不安全感。有些问题容易修复，尚可接受；但有些问题，即便多轮对话也解决不了，我必须非常仔细地阅读代码，才能理清问题所在。

最大的痛点在于动画交互上。如果对动画效果不满意，调整成本非常大。例如下面这个案例的交互效果不理想，我调整了一个多小时才勉强达到可接受的状态，过程非常难受。

总结

1. 场景差异：长期从事增删改查等基础项目的前端开发，可能更容易“神话”AI的编程能力。
2. 本质未变：SKILL.md 与之前的提示词相比，没有本质变化。它只是让我们能更精准地利用AI能力。以前是封装一个函数，现在是封装一段提示词。因此，未来项目中包含各种精细化的提示词将是一个必然趋势。
3. 能力边界：AI编程并非万能解药。它非常擅长生成那些原本就可以通过复制粘贴快速实现的模板化代码（这也是CRUD开发者推崇它的原因之一），但在其他需要高度可控性的任务上，Claude Code 的表现并不完美。
4. 可靠性与个人能力：无法做到100%可靠，其实际意义就会打折扣。因为你需要为那不可控的1%兜底，这对个人技术能力提出了更高要求。你既不知道它何时出现，也不知道它出现在哪里。因此，程序员要想站稳脚跟，必须持续提升自身技术实力，不能长期停留在CRUD水平。
5. 调试局限：Claude Code 能自动修复一些运行时错误（有明确报错信息的）。但对于那些“程序能运行，只是UI输出不符合预期”的逻辑错误或细节问题，它就无能为力了。因此，重视UI表现与不重视UI表现的程序员，使用 Claude Code 的体验会截然不同。
6. 提效的现实：如果需要为最终的1%问题兜底，那么一个人不可能同时利用AI完成五份工作。当我们对最终产出有可靠性要求时，AI编程带来的效率提升并非指数级的。正如有赞团队分享的数据，其整体提效约为30%。

当然，如果你从个人开发者角度出发，对项目质量没有严格的商业化约束，那么提效的感知可能不同。但因此就盲目吹捧，并不客观。关于 React 与其他前端技术的更多实践讨论，欢迎在云栈社区交流。