Featured image of post Claude Code使用后的感受：独立编程、日常助手与深度定制
技术

Claude Code使用后的感受：独立编程、日常助手与深度定制

用了一个多月 Claude Code 后，记录一下哪些认知变了。

用了一个多月Claude Code后，记录一下哪些认知变了。

为什么写这篇后续

这几个月持续在用Claude Code，确实有一些新的感受。如果用一句话来总结：“强烈推荐体验”。

最近经常看到关于前同事被蒸馏成token、xxx.skill，本来想用下面这张图片做博客首图的，想了想这样非常不尊重事实，一味地追求哗众取众，早晚都会遍体鳞伤。Claude的能力确实非常强大，但不要为此而焦虑，学会利用好这个工具，让工具来武装自己才是硬道理。个人非常认同李想这句话：“ 前提是顶级专家要全面拥抱Agent，指望AI和Agent抹平专业价值差距的观点，纯属做梦。普通水平和顶级专家在非AI时代的差距是100倍，AI时代会扩大到10000倍 ”。

下面GitHub项目有很多有意思的skills

https://github.com/tmstack/awesome-persona-skills?tab=readme-ov-file

先回应关于封号

上篇博客评论区最多的问题不是技术相关的，而是——“会不会封号”。毕竟订阅不便宜，被封一次挺肉疼的，而且戒掉Claude的瘾也很痛苦。我把几个常见的问题整理一下，说说我的看法。刚开始用Claude的时候，我一天得看账号几十遍，偶尔还盯着 V 站、L 站以及群里其他同学的封号状况，现在已经平常心了， 因为这个事一旦发生了，也没办法，不如尽快搞替代品或者其他号呗 。

很多同学关于封号的结论都非常有道理，因为他们肯定都是过来人，我也逐一留言回复了。下面是我自己对于封号的看法，当然还有 账号概况 这个大前提。如果这个账号后续被封了，我第一时间写博客。

爽一天、是一天 ，封了就找替代品。今天担心中转被封、明天担心 IP 不够纯。这篇文章从草稿到发布大概整理了 3-4 天，这不就等来了 实名认证。

  • 富哥账号是通过AppleID订阅的Max Plan x20

  • 这个账号是 2024 年底注册

  • 已经自动续费成功

  • 目前还在用sub2api

“我们被封过吗？”

被封过。富哥还有另一个账号，账号注册了不到 1 个月，订阅了同样的套餐，没有用中转，突然被封了。我哥们还有在海鲜市场买Claude充值卡的，这种就别碰运气了，大概率是黑卡，他几天就被封了。

这确实是一个需要接受的现实。如果你因为封号风险完全不敢用，那也无可厚非，每个人对风险的容忍度不同。我的选择是——不去过度焦虑。毕竟工具的价值是实实在在的，因噎废食不太划算。

Vibe Coding

聊完封号，说回正题。

用了这么久，如果让我只说Claude Code一个最大的优点，那就是：vibe coding 的完成度非常高 。

这句话看起来平平无奇，但仔细想想，原来我用 AI 编程工具做的事情是"辅助你写代码"——你写一行，它帮你补全下一行；你选中一段代码，它帮你重构。本质上， 你还是那个在写代码的人 ，AI 只是一个更聪明的自动补全。

Claude Code不一样。你可以跟它说"给用户列表加个按角色筛选的功能"，然后它会：

  1. 自己去读现有代码，理解项目结构
  2. 找到相关的model、controller、前端组件
  3. 写实现代码
  4. 跑测试，如果测试挂了自己修
  5. 最后给你一个完整的、可以工作的功能 全程你可以去倒杯水，回来看diff就行。

这不是"辅助"，这是"干活"。区别很大。

一个实际的例子

前段时间小试牛刀，vibe了一个论坛自动签到的工具。

什么任务适合交给它

经验上来看，这类任务它做得最好：

  • CRUD 类功能 ：加个接口、加个页面、加个字段，这种活它闭着眼都能干

  • 重构和迁移 ：比如把一批 API 从 v1 升级到 v2，改数据结构，它对上下文的理解能力很强

  • 写测试 ：这是它特别擅长的，给它一个函数它能写出覆盖各种边界情况的测试

  • Bug 修复 ：给它报错信息和复现步骤，很多时候它能自己定位到问题

不太适合的场景也有：

  • 高度创新性的架构设计 ：它能执行你的设计，但让它从零设计一个复杂架构，结果往往偏保守

  • 原有业务非常复杂的业务逻辑 ：比如内部系统有很多复杂的业务逻辑，它可能写出看起来对但实际有坑的代码！！！

  • 需要频繁和你确认的交互式开发 ：如果你自己都没想清楚要什么，它也没办法

和 Cursor 的区别到底在哪

原来用过Cursor，对比说说感受。

Cursor的核心体验是 实时协作 。你在写代码，它在旁边看着，随时给你建议，Tab 一按就补上。这种体验非常丝滑，特别适合你思路清晰、知道要写什么的时候。

Claude Code的核心体验是 委托执行 。你描述任务，它去完成。你不需要一行行写，甚至不需要打开代码文件。

打个比方：Cursor像一个坐在你旁边的同事，你写一行他接一行；Claude Code像一个你把需求讲清楚之后就能自己干活的同事，你只需要最后review。

不是谁好谁差，是两种完全不同的工作模式。我现在的习惯是：用Claude Code先沟通出计划方案，然后确认执行，完成后用VS Code看最终的代码diff。

日常助手：写代码之外的事

Claude Code不只是一个编程工具，这一点用久了之后感受越来越明显。

因为它本质上是一个 能访问你文件系统、能执行命令的 AI ，很多日常任务它都能做。

Git 操作 。我现在基本不手敲git commit了。/commit-msg命令会自动分析 diff 生成结构化的commit message，比我自己写的还规范。Code review也是，/review一下就能得到一份还不错的审查报告。

查文档 。有了Context7插件之后，查文档这件事变得很自然。不需要离开终端去开浏览器搜索，直接问就行，而且拿到的是最新的文档内容，不是训练数据里可能过时的信息。

文件操作 。批量重命名、格式转换、日志分析、数据清洗……这些琐碎的事情用自然语言描述一下就搞定了，不用每次都去搜"bash 怎么批量替换文件名"。

排查问题 。服务起不来了？日志报错看不懂？把错误信息贴给它，它会自己去翻日志、查配置、定位原因。有时候比自己手动排查快得多，特别是那种不太熟悉的技术栈。

用久了之后你会发现，它改变的不只是"写代码"这个环节，而是整个工作流中涉及到"和电脑交互"的部分。以前需要打开浏览器搜索、打开文件管理器翻文件、打开终端敲命令的事情，现在在一个地方就能做完。

CLI 如何替代 IDE 编程

“只有命令行没有GUI，能写代码吗？”

我理解这种困惑，毕竟大家都习惯了VS Code或JetBrains那种有文件树、有语法高亮、有 Tab 补全的 IDE 环境。突然跟你说"在终端里写代码"，第一反应确实是"开玩笑吧"。

但用了这么久，我想说的是： 这不是"替代"，而是工作方式本身变了。

传统 IDE 的工作流是什么

你打开一个项目，左边看文件树，中间写代码，底下看终端。你需要：

  1. 自己找到要改的文件
  2. 自己定位到要改的位置
  3. 自己写代码
  4. 自己切到终端跑测试
  5. 看报错，回到编辑器改
  6. 循环 整个过程中， 你是操作者 ，IDE 是你的工具。

Claude Code 的工作流是什么

你描述你要做什么，它去做。

不需要自己找文件——它会通过Glob、Grep、LSP自己定位。不需要自己写代码——它直接Edit或Write。不需要自己跑测试——它用Bash执行命令并读结果。

你的角色从"操作者"变成了"决策者"。你决定做什么、怎么做、做得对不对，但具体的操作不需要你来。

这个转变需要一点时间适应， 但一旦适应了，回不去了 。

LSP 让它不是"瞎改"

有人担心"它不打开文件怎么知道代码结构"。这个担心在有 LSP 插件之前确实成立，但现在不成立了。

我装了gopls（Go）、typescript-lsp（前端）等语言服务插件，Claude Code可以做到：

  • 跳转定义 ：问"这个函数在哪定义的"，它直接跳过去

  • 查找引用 ：改一个接口签名前，先看哪些地方在调用

  • Hover 信息 ：查看变量类型、函数签名

这些能力和你在VS Code里右键 “Go to Definition” 是一样的，只是它自己来做了。

我现在的混合工作流

说完全不用 IDE 是假的。我的实际情况是：

  • Claude Code 处理大块工作 ：新功能开发、重构、Bug 修复、写测试

  • VS Code 处理精细活 ：需要视觉化地对比 diff 的时候、在 debug 时需要打断点单步调试的时候、内部系统复杂的业务逻辑变动的时候

大概的时间分配是Claude Code占 70%，VS Code占 30%。

这不是因为Claude Code做不了那 30% 的事，一旦做错了付出的代价会非常大。

选择用什么工具，唯一的标准是 在当前这个任务上哪个更高效 ，没必要非此即彼。

定制自己的 Claude Code

原来写过关于Claude Code定制的博客，既然是定制，原来写的那篇文章也是入门，后续每个人都会有自己的个性化定制。

很多人可能觉得CLAUDE.md就是写点提示词，有没有无所谓。

不是的。它是 真的会改变 AI 的行为 。

举个具体的例子。在我的CLAUDE.md里有一条：

1
2
3
4

禁止做的：
- 过度重构已工作的代码
- 添加未要求的功能
- 修改测试来匹配错误代码

没有这条的时候，Claude Code经常会"好心办坏事"——你让它修一个Bug，它顺手把周围的代码也重构了；你让它加个字段，它顺手给你加了三个相关的字段和一堆验证逻辑。这些东西单独看都没错，但 你没有要求它做这些 ，review的时候你得花额外的精力去确认这些"赠品"有没有引入新问题。

加了这条约束之后，它的行为收敛了很多。让它做什么它就做什么，不多不少。

再比如我的技术栈偏好配置：

1
2
3
4

| 场景 | 首选 |
|------|------|
| Go 后端 | Gin + GORM |
| 前端 | Vue 3 + TS + TailwindCSS |

没有这个的话，你每次让它写代码它都可能给你用不同的框架。今天Echo明天Fiber，今天React明天Vue。有了这个，它默认就用你熟悉的技术栈，不用每次都提醒。

从通用 AI 到"你的 AI"

技能系统是让Claude Code真正变成"你的 AI"的关键。

拿我的go-dev技能来说，里面有我们团队的 Go 编码规范：命名约定、错误处理方式、包结构组织、测试写法。Claude Code加载这个技能之后，写出来的 Go 代码风格和我们团队手写的几乎一样。

这意味着什么？意味着它写的代码 不需要大改就能合进代码库 。没有技能配置的话，它写的代码可能功能上是对的，但风格上和你的项目格格不入，review的时候光改风格就得花不少时间。

规则系统也是同理。比如file-size-limit规则限制了单文件行数（Go 400 行、Vue 200 行），有了这个约束它不会生成一个 800 行的巨型文件给你。

我的配置演进

我配置不是一天建好的，是用着用着慢慢长出来的，现在我感觉缺点什么，就让Claude自己调整配置。

回头看，整个过程就像是在"训练"一个新同事。一开始它能力很强但不了解你的习惯，你得不断告诉它"这个不要"、“设计风格要大胆一些”、“交互要有动态效果”，慢慢地它就越来越合拍了。区别在于，这个"训练"过程是调整配置文件而不是反复口头交代。

配置建议

如果你刚开始用，不用一步到位。建议的路径：

  1. 先写 CLAUDE.md ：声明你是谁、用什么技术栈、有什么硬性约束。20 分钟能搞定
  2. 遇到问题加规则 ：每次它做了你不想要的事情，想想能不能用一条规则约束住
  3. 稳定后写技能 ：当你发现自己反复在不同项目里给它讲同样的编码规范，就该把规范写成技能了
  4. 最后做命令 ：把高频操作封装成斜杠命令，这是锦上添花的事 别试图一开始就搞一套完美的配置体系，配置是养出来的，不是设计出来的。

最后

工具就是工具。好用就多用，不好用就少用，不需要信仰。

Claude Code对我来说是目前最顺手的 AI 编程工具，但这个判断是基于我的使用场景和习惯。你的情况可能不一样。

📎 参考文章