社区里经常能看到这样的帖子：“分享我的 Claude Code 工作流：装了 12 个插件 + 5 个 MCP Server + 自定义 8 个 Skills，效率起飞 🚀”。评论区一片”收藏了”、“学到了”。然后你看看自己，打开 Claude Code，用自然语言说需求，讨论方案，让它实现，审阅修改。没有花哨的斜杠命令，没有插件流水线。
这种焦虑不是 Claude Code 独有的，每个工具生态都会经历这个阶段，工具数量 → 被误认为能力水平。VS Code 刚火的时候，社区也在卷”装了多少扩展”。有人恨不得把 Marketplace 搬空，装完发现编辑器启动要 15 秒，内存占 2GB，然后大家都开始写另一篇文章《我是怎么把 VS Code 扩展从 80 个精简到 12 个的》。
Vim 社区也一样。 写 500 行的人，并不比 只有 30 行的人更高效，往往还更容易在某次更新后花半天修配置冲突。
Claude Code 现在正处于这个”插件军备竞赛”的阶段。但如果你跳出来想一想，真正的问题其实是：你的产出质量提高了吗？还是只是工作流变复杂了？
这句话听起来太朴素了，但它是事实。
Claude Code 的底层是一个大语言模型。它最强的能力是理解自然语言、推理、生成代码。插件和 Skills 只是在这个能力上加了一层”预设 prompt”，本质上跟你在对话中说的话没有区别。
2.1 对比分析
(1) 用 Skill 的方式
Skill 内部展开后，Claude 实际收到的是：
(2) 用对话的方式
结果有本质区别吗？没有。 Skill 的好处是清单更完整、不会遗漏，但如果你只是偶尔做一次代码审查，对话方式完全够用。
2.2 分析
Skill 真正的价值是”消除重复”，不是”增加能力”。 Claude 不会因为你用了 Skill 就变得更聪明，它只是省得你每次都说同样的话。
我日常的工作流是非常简单的五步，全靠对话：
cursor 教程
从构思到交付，就是”人提方向→一起讨论→AI 实现→人来审阅→再迭代”的循环。注意看第②步和第④步，人始终在关键节点上做判断，AI 负责执行和提供选项。
没有任何斜杠命令，没有插件参与。但这个流程有几个被忽视的优势：
3.1 每次交互都是”定制 Skill”
当你说”代码拆成小块，每块之间穿插解释”时，这本身就是一条 Skill 指令——只不过是用自然语言实时传达的。而且它比固化在 SKILL.md 里的版本更灵活：你可以根据当前文章的具体情况随时调整，不受预设模板的限制。
3.2 讨论环节不可替代
Skill 能做的是”执行预定义流程”。但技术方案的讨论——“这个功能用 WebSocket 还是 SSE？”“这篇文章理论和实践要不要拆两篇？”——这些需要来回推敲、权衡取舍的环节，没有任何 Skill 可以替代。
而这恰恰是 AI 辅助开发中最有价值的部分：不是让 AI 帮你敲键盘，而是让 AI 帮你想问题。
3.3 CLAUDE.md 已经静默工作了
很多人没意识到，如果你写了一份好的 CLAUDE.md，你实际上已经拥有了一个”始终生效的 Skill”。
比如我的 CLAUDE.md 里写了：
这些约定每次对话自动加载，不需要我敲任何命令。别人用 Skill 才能做到的事情，我靠 CLAUDE.md 就解决了—而且更稳定，因为它不依赖安装和兼容性。
当然不是。它们在特定场景下很有价值——关键是识别你是否真的处于那个场景。
4.1 适合用 Skill 的信号
你在不同对话中反复说同样的话。
比如你是前端开发者，每次让 Claude 写组件时都说：“用 TailwindCSS，间距只用 4px 倍数，按钮高度 36px，所有可点击元素加 hover 和 focus-visible 状态。” 说了 20 遍之后，是时候把它做成 Skill 了。
注意：如果这些话放在 CLAUDE.md 里不嫌长（几十行以内），直接放 CLAUDE.md 更省事。做成 Skill 主要是为了不占用每次对话的上下文——当你的规范超过几百字、而且只在特定任务中需要时，Skill 才真正有意义。
4.2 适合用插件的信号
你需要把一套实践分享给团队。
一个人用的时候，Skill 文件手动创建就够了。但如果你想让团队 10 个人都遵循同一套代码审查标准，打包成插件、一条命令安装，比发一份文档说”请把这段内容复制到你的 .claude/skills/ 目录”靠谱得多。
4.3 适合用 MCP 的信号
你需要 Claude 直接访问外部系统。
对话中你可以手动复制粘贴 GitHub Issue 的内容给 Claude，但如果你每天要处理几十个 Issue，接入 GitHub MCP 让 Claude 自己查就合理了。
4.4 不需要任何扩展的信号
你的工作每次都不太一样，对话足以传达需求。
写技术文章、讨论架构方案、探索新技术……这些任务的共同特点是非标准化。每次的输入、约束、目标都不同，预设的 Skill 流程反而是一种束缚。
越是高级的 Claude Code 使用者，用的插件往往越少。
原因很简单：他们知道怎么用对话精确表达需求，知道怎么写好 CLAUDE.md 让约定自动生效，知道什么时候该讨论方案而不是直接让 AI 动手。这些”软技能”比任何插件都值钱。
反过来，依赖大量插件有时候是一个信号，你还没想清楚自己到底需要什么，所以用工具的丰富度来补偿思考的不足。
这不是在批评用插件的人。如果你真的有高频重复任务，插件和 Skills 是非常好的解决方案。但如果你只是因为看到别人在用而觉得自己应该用，那就本末倒置了。
如果你也有”工具焦虑”，这是我的建议：
1. 先把 CLAUDE.md 写好
这是投入产出比最高的一步。花 30 分钟把你的项目约定、技术栈、编码规范写进去，之后每次对话都会受益。
2. 用对话跑两周再考虑 Skill
在纯对话模式下工作两周，记录你重复说的话。如果某些指令出现了 5 次以上，再做成 Skill。
3. 不要一次装多个插件
每个插件都有学习成本和上下文开销。一次装一个，真正用起来了再考虑下一个。
4. 评估标准是产出，不是工具链
问自己：“我今天的代码质量/文章质量/方案质量比昨天高了吗？” 而不是”我今天用了几个 Skill？”
很多关于 Claude Code 的争论，本质上都源于一个误解：人们把所有工具当成“同时需要学习的东西”。但实际上，它们对应的是不同阶段的问题。你不需要一次掌握全部，而是随着使用自然演进。
可以用一条非常简单的路径来理解：
最后说一句可能有点扎心的话：社区里很多复杂工作流，本质是在炫耀工具，而不是炫耀产出。而真正长期有效的能力，始终只有一个：把问题想清楚，然后用最简单的方式解决它。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/274521.html原文链接：https://javaforall.net
