微信扫码
添加专属顾问
我要投稿
Claude Code Pro 使用体验大公开,从零到一打造 VSCode 扩展的实战心得! 核心内容: 1. 作者选择 VSCode 扩展作为试水项目的独特考量 2. docpilot 插件的三大核心功能与开发历程 3. Claude Code 令人上瘾的编程体验与效率提升
这个月,我开通了 Claude Code,不是 Max,而是 Pro。因为还有其他厂家送的 Pro 订阅,虽然每月一审;加之还有 Zed 等其他工具的免费额度,所以对于现阶段尚在摸索新方向的我来说,当前的配置足够了。
开通之后,便是一通乱试,如同开始上手新游戏时先在游戏里探探路,实际感受一下玩法再说。之后,才大致扫了一下官网上的文档。再之后,才开始去看一些视频,学习人家的先进经验。
并且,直到前天,我甚至连 Claude.md 也懒得设置,没有借助太多的生态工具和花里胡哨的技巧。主打一个简单粗暴,用了再说。
与大多数人不一样,试水项目并不是 Web 网站或是移动 App。而是选择了一个偏门:vscode extension。
试水的项目有两个:
在这上面没花太多精力。由于是第一个尝试,主要目的就是看看 CC 能力和熟悉它的使用。前后也就是半天而已,看到基本能用就甩一边没管了。
这是一个正在花精力做的项目,看 CC 生成的简介吧:
A comprehensive VSCode extension that combines advanced PDF viewing with intelligent AI summarization capabilities. View, navigate, and understand PDF documents through seamless Copilot Chat integration.
我个人觉得值得吹嘘的功能:
为何要做它:
在我的视频号里有早期版本的演示,那时还没有 inspector 和 extraction,感兴趣的可以去看看。
哦,忘了说:虽然它没有 100% 的覆盖测试,但已经具备了坚实的测试基础:
该插件目前还在高速演化中……
使用 CC 的感觉跟使用 vscode copilot Agent 模式的感觉完全不一样,相当容易上瘾,仿佛回到了当年为了通关大菠萝 2 而熬夜的日子。
之前的文摘中曾将其称之为“程序员的猫薄荷”,从个人体验来看,没错!
这也随之带来了一些问题,典型的就是:容易沉迷,影响其他事情,以及生活。最典型的就是:跟它激情对话完之后,一抬眼,已经过了十二点了!
还好我是 pro plan,就当它的 limit 耗尽之时就是我的休息之始了。比如下面的消息:
Claude usage limit reached. Your limit will reset at 3pm (Australia/Sydney).
所以,我不建议改造你的手机让你也能在上面使用 CC 的做法,尤其是对于自制力不高的人。
也正是因为它的能力强,所以才容易上瘾。相比起其他家,水平不在一个代际。
当心中所念在短时间内可以呈现在你眼前但却又并非 100% 完美时,你的第一直觉就是:微调。于是乎,你就陷了进去,完了时间。
是不是有点像找人帮忙砍价时,总是差那么一点,你不断找人的情形?
虽然它的能力很强,但在使用时建议不要抱有过高的期望。我的感受:
注意,以上是“任务”非项目。而且所谓的“大小”之分,也因人而异。
同时,随着 code base 的增大,放任不管,它就会出现顾此失彼的情况。此时,人的重要性就会凸显出来。
不就是上下文么?
我就估计有同学会这么想,但就我个人来看还真不止于此!
不过,好消息是,程序员不需要担心失业了!
比如我之前曾写过的帮我灌水的那些工具,结合 slash command 可以方便的实现。
无独有偶,我在 Awesome CC Repo 中发现了类似的 blog 生成的 slash command,它用的模板是 Hugo。
这也意味着一大类套壳工具可以直接被 CC 替代,虽然是 cli 的方式。但对于开发来讲,有了这个基础,再这之上再去套个 UI 并不困难。这种方式虽然写代码简单粗暴,但用来验证想法没啥问题。
这种协作相当于多找了几个小弟,让它们不要单兵作战,各自发挥所长。
比如:ChatGPT 写文案或 UI 设计、CC 来写设计和代码、Gemini 来 Review。不论你是手动还是自动,多找几个小弟总归没错。
甚至于现在进入新领域,我都是让 Gemini 先生成一个 Deep Research Report,让我有一个高层理解。当然,作为一个负责任的家长,我已经把这个技巧传授给我娃了。
这个趋势其实已经有了,没见 Claude 之前推出了 Sharable Artifact 吗?它可以运行在 Claude 应用内。这样,Claude 本身成了应用商店,Artifact 成内置的小程序。
单一功能套壳应用当属被淘汰的最早一批。
这对于应用开发者来讲不是好事。但压力并非首先来自于非开发者,因为我相信他们还需要时间去适应,而是来自于同行。因为抄袭成本降低了。
如此一来,通用应用的价值会大幅降低。要赚钱,就必须手快,并不断迭代,以期在后续版本中建立起壁垒。
但是单纯靠工具建立起来的壁垒很弱,最好的方式是,工具只是销售渠道或生产工具,而不是单纯的工具。这也符合:卖服务而不是卖工具的理念(这是在哪看到的,我已经忘了)。
比如网上常见的那种:用 AI 写爆款文章,卖的是文章,而不是写文章的工具。虽然真实性待考证,但思路没有问题。
再比如,我把我独有的知识以类 ChatBot 的形式卖出去,也属于此类。此时,工具只是销售渠道。并且,我甚至于可以不需要写这个 ChatBot,而是干脆把知识包装成 MCP Server 形式,直接卖给用户。让所有 AI 工具都是我的销售渠道。
关于壁垒,我能想到的有:
对 AI 抱有敌意,觉得它是跟自己抢饭碗的开发者,最终将面临困境。
只知道将需求翻译成代码,但无法体会需求背后业务含义的开发者,最终将面临困境。比如传统的外包队伍,我个人认为会很快受到比较大的冲击。
不善于学习代码之外的知识的开发者,最终将面临困境。单一知识结构无法支撑起复杂的交互,同时也无法给 AI 指明方向。不是有人总是说“品味”才是 AI 时代的大杀器吗?很难想象知识面不广的人会有多少品味。
不会协作,没有计划的能力的开发者,最终将面临困境。
沟通技巧不佳的开发者,最终将面临困境。这里并非是指巧舌如簧,而是指能清晰地表达自己的想法。不论什么方式:如果你文字胜于代码,那就文字;反之,传入伪代码或图片都行。
最后说点正面的:脑洞大的开发者,将在 AI 时代收获最大的红利。
前阵子不是已经有所谓 AI Native Developer 了么?
当生产端的速度被极大提升之后,是否还有必要按原有的流程去开发呢?我对于所谓的用 AI 来写需求文档的做法都持强烈否定态度,因为这还是按照传统方式去做事,只不过是由 AI 代写了。
我宁可看到在软件生产的环节之中,没有什么明确的:需求分析人员、架构师、前端、后端、测试、运维等等。
现在不是到处都在吹嘘“超级个体”吗?那么软件生产为何不能是超级个体间的协作呢?
此时当然不是干一个破网站或事小应用。都是超级个体了,那当然可以去干比以往更大的事情。
于是乎,这就是我前面说的:如何在团队中使用 CC。相关网站和视频已有探讨,这里就不展开了。
AI,作为新型生产工具,如果你不上心,那么你就会被淘汰。
如果你还在担心引入 AI 会让员工摸鱼,那么你也会被淘汰,因为思维方式太落伍了。
作为全新形态的生产工具,AI 将很多原来不可能的事情变为可能。将之前高不可攀的领域变得亲民,降低了门槛。此时,你如果还在固守原有的一亩三分地,那么淘汰是必然的。
推动 AI 在公司内使用,使每个员工成为超级个体,提高营收进而给大家涨工资,这才是老板们应该做的事!
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2025-07-31
进阶版|企业级 AI Agent 的构建实践
2025-07-31
餐饮业卷生卷死的当下,麦当劳如何用AI突围
2025-07-31
全网疯传GPT-5泄露!首次统一GPT和o系列,编程实测demo抢先曝光,下周发布?
2025-07-31
ODPS重磅升级!全面支撑AI应用爆发
2025-07-31
四步搞定Cursor地区限制
2025-07-31
当AI成为团队“隐形搭档”:Anthropic内部如何用AI重构工作流?
2025-07-31
解锁日志分析新姿势:n8n 工作流 + ES 日志 + AI,数据洞察一键 get
2025-07-31
微软花重金做的Copilot,居然被WPS一个按钮给秒了?
2025-05-29
2025-05-23
2025-06-01
2025-05-07
2025-05-07
2025-05-07
2025-06-07
2025-06-21
2025-06-12
2025-05-20
2025-07-31
2025-07-31
2025-07-31
2025-07-30
2025-07-30
2025-07-30
2025-07-30
2025-07-29