Claude Code 两个月的使用体验

date
Feb 1, 2026
slug
cc-intro
status
Published
tags
Technology
summary
两个月深度使用 Claude Code 的工具链、技巧和思考
type
Post

引入

用了两个月 Claude Code，再也回不去 Cursor 了。
Claude Code 发布于 2025 年 2 月，我在 12 月才开始用，后悔没早点发现。当然，这体验很大程度上是因为用了 opus4.5，Vibe Coding 体验独一档。

使用体验

先说说使用体验吧，在 12 月份用了之后，就再也回不去 Cursor 了（连 Cursor Pro 已有的额度都没有再使用了），只是把它当作编辑器了，时不时用一下 Tab，大部分工作直接让 Claude Code 去写就行了。
刚开始用 CC 有点不适应，之前用 Cursor 习惯了 IDE 界面，对纯终端方式有点抵触。当时是抱着尝试的心态，使用 opus 去完成一个需求，效果意外的好。然后就一去不复返了，开始去网上搜索资料，去了解使用方式、最佳实践，如何更高效的利用 CC，以及各种插件工具（Plugin、MCP、Skill、Agent…） 的使用，经过这两个月的探索和尝试，也慢慢掌握了一整套的使用体系了。正好也分享一下我个人目前的使用方式。

替代方案：Minimax M2.1

另外在 12 月底圣诞节的时候，Minimax M2.1 的推出，在网上也火了一把；而且当时看阮老师的周刊的时候，也看到推荐了这个工具；所以当时也买了一个月的 Coding Plan 体验了一下。
在一些复杂的任务上肯定还是没办法和 opus 去比的，但是来解决一些简单的任务体验还是不错的，而且响应速度上也比 opus 快不少；但因为有时存在乱改和删除源代码的原因，后续也用的少了。
但并不是说它不好，可能是我使用的方式有问题；M2.1 在国外是相当火爆的，作为 Claude 的平替很不错，性价比非常高，X 上不少人推荐过它。再加上最近爆火的 OpenClaw，也公开的推荐过 M2.1。所以说等后面如果 opus 无法使用之后，我还是会考虑 M2.1 的。

工具

Agent

还记得 CC 刚出 Agent 的时候，全网都在推各种各样的 Agent，前端、后端、运维、UI等等；甚至之前有一个很火的一个公司项目，里面包含了一个公司各种人员的 Agent，但是后面也渐渐没落下去了。
一方面是 token 的消费指数级的上升，这已经把绝大部分人给劝退了；另一方面，就算有了一整套公司体系，但是没有方向，也是等于 0。
虽然我也创建了几个 Agent，但也只是用于测试，看看效果啥的，平时根本用不到，用的基本都是自带的一些 Agent，如文件查询、批量任务执行等等，我觉得已经够了。

MCP

MCP 按需加载就行，不要添加太多，它会占用上下文窗口。
这个东西按需使用就行，除了几个必备的 MCP：filesystem、playwright、sequential-thinking，其他的根据实际使用添加就行了；其中的 playwright 可以替换成其他的自动化测试工具，最近也出了好几个其他的自动化测试工具，如 Agent Browser，能极大的节省 token 量，但还没有做尝试。
另外再说几个常用的工具：
  1. 设计稿转前端 UI
      2. 通过 Figma-Context-MCP，Figma 官方 MCP 需要付费，这个开源方案是替代选择。
      复制 Figma 组件链接，配合提示词"参考 Figma 设计稿：url，实现组件 UI"即可。
  1. 文章转化
      2. 利用 Notion MCP 来进行处理，分为两个方面：
    1. 将文章导出到本地，供 CC 读取了解文笔、风格等内容，生成一份 CLAUDE.md，以这个为参考。
    2. 根据 CLAUDE.md 进行文章编写，CC 处理完文章后，然后通过结合 Notion MCP 进行处理，同步到 Notion 文章里面去。
        3. 提示词：读取 Notion 工作区 NOBELIUM 表格 …

Skill

这个东西做的真的很巧妙，通过提示词识别或者指定添加的方式来加载某个 Skill，真正的按需加载，而且能很大程度上去节省上下文。
网上也有很多人去比较 MCP 和 Skill，但是这其实是两个完全不同的东西，MCP 的通往外部的工具，Skill 本身还是提示词，只是将其封装起来了。
接下来推荐一些常用的 Skill：
  • frontend-design
      • 用于前端页面设计，一般需要优化前端页面，主要是 UI、UX 向的时候，我都会手动载入：
      使用 frontend-design skill 来完成前端设计工作
  • planning-with-files
      • 参考 Manus 的 Skill，让 Claude 在处理多文件任务时先用 Markdown 文件记录完整规划，再逐步执行。
      像最近很火的 OpenClaw 就是，号称无限上下文，也就是通过和 planning-with-files skill 的方式一样，参考 Manus 通过文件去存储了所有的上下文。
对于其他需要的 Skill，可以去下面的网站查找：

Plugin

这里极力推荐 superpowers 这个工具，它提供了完整软件开发工作流程，建立在一组可组合的“技能”和一些确保您的代理使用它们的初始指令之上。
它里面包括整体流程的 Skill、Agent、Command。最终融汇成三个指令：
安装方式和详细的工作流以及内部的原理可以查看它的 README：
superpowers README（待补充）

技巧

  1. spec-kit
      2. GitHub 出品的 Spec-Driven Development 工具。核心理念：将稳定的"做什么"与灵活的"怎么做"分离，让意图成为事实的源头，而不是仅依赖于代码。
      spec-kit 的工作流程分为七个部分：
    1. Specify 阶段：你提供高层次的需求描述，AI 生成详细的规范。此阶段关注“做什么”和“为什么”，不涉及具体技术栈。
    2. Constitution 阶段：建立项目的管理原则和开发指导方针，指导所有后续的开发工作。
    3. Plan 阶段：你提供技术方向和约束条件，AI 制定全面的技术实现方案。
    4. Clarify 阶段：澄清规范中不够明确的需求，避免或减少后续工作返工。
    5. Tasks 阶段：AI 将规范和方案细化为可操作的小任务，每个任务都能独立实现和测试。
    6. Analyze 阶段：分析任务一致性和覆盖度，确保整个项目的实现质量。
    7. Implement 阶段：AI 逐步完成各项任务，你只需审查每次聚焦的变更，而不是一次性查看大量代码。
      8. 但是核心工作流程就是四个部分：Specify - Plan - Tasks - Analyze。
      其实现在基本我用 AI 开发也是这个流程。
      先用 Plan Mode，然后明确要实现的需求，再告诉它一些细节和注意的点。它查看项目代码进行规划，拆分出子任务，我再查看是否有问题，没有问题就执行即可。
      所以其实我们要做的也只是 Specify - Plan 即可。
  1. AskUserQuestion 技巧
      2. AskUserQuestion 是 CC 自带的一个小工具。用于 AI 向用户询问问题，在正常的使用过程中也会用到，只是不知道它的名称而已。
      当做一个不确定的需求的时候，可以通过这种方式来确定好需求边界，提示词：
      使用 AskUserQuestion 工具，像苏格拉底一样帮助我，无论是技术选型、潜在风险、需求对齐等等任何方向。
  1. 多开新 CC
      2. 一个需求只对一个 CC，全堆在一个 CC 里面的话，上下文会非常大，而且也非常的耗费 token。

思考

其实到现在可以看出来，SWE（软件工程师）已经渐渐不需要人类管控了，现在最重要的是领导能力、决策能力、产品能力、创意能力，这些是 AI 无法拥有的，也就是决策力和创意性。
Notion CEO 前几天说过：
我们引以为傲的脑力劳动，正在经历 200 年前体力劳动一样的命运 —— 彻底贬值，直至归零。
体力劳动已经被工业革命代替了，我们不是靠肌肉做工作了，都是靠机器。但脑力劳动到此为止还不是靠机器，现在人工智能把这事给做了。如果体力劳动被代替了，脑力劳动也被代替了，人还做什么？只有品味和领导力。这就是为什么我们实验室从 30 年前就非常重视领导力，但现在越来越重要了。
而且前几天达沃斯论坛中，DeepMind 和 Anthropic 的 CEO 同框对话时，Dario Amodei 说到：
AI 端到端接管软件工程师（SWEs）几乎全部的工作，倒计时仅剩 6-12 个月了！
那时候 SWE 的大部分将不再需要，其实我们现在所做的工作也已经慢慢偏离了。我们现在的工作已经变成：分析需求 → 拆分任务 → 和 AI 做计划 → AI 写代码 → 审查。甚至有的时候连审查都省了。
甚至 Claude Code 百分之 90 的代码都是由 Claude Code 自己写的，当时听到都尤为震惊。
这也印证了论坛里提到的一个令 AI 圈震动的判断：
AI 自己写代码 → AI 自己搞研究 → 完全自我迭代的闭环。
一旦这个正反馈闭环真正跑顺，研发速度会直接起飞，指数级冲刺。
 
所以我们也需要调整我们自己的重心：
  • 这个需求到底要解决什么业务问题？
  • 整体架构要怎么演进才可持续？
  • 安全性、扩展性、可观测性怎么保证？
  • 团队协作、代码规范、历史包袱怎么处理？
之前看到的一篇文章也提到：
软件开发的核心瓶颈是对复杂现实的理解与判断，AI 只是重塑而非取代开发者。
 
通过紧跟技术趋势并保持怀疑态度，你可以避免被炒作或末日论措手不及。通过更新技能、多样化能力并专注于创造力、批判性思维和协作等独特的人类方面，你将始终在场。无论未来带来的是编码复兴还是代码自我编写的世界，对那些能够整体思考、持续学习并推动技术解决实际问题的工程师的需求将永远存在。
 

© JinSo 2021 - 2026