这个月，我开通了Claude Code，不是Max，而是Pro。手头还有其他厂家送的Pro订阅，虽然每月一审；加上Zed等工具的免费额度，对于现阶段还在摸索新方向的我来说，当前配置已经够用了。
开通之后，便是一通乱试，就像刚上手新游戏时先探探路，感受一下玩法再说。之后，才大致扫了一下官网文档。再之后，才开始看一些视频，学习别人的先进经验。
直到前天，我连Claude.md都懒得设置，没借助太多生态工具和花里胡哨的技巧。主打一个简单粗暴，用了再说。
试水的项目
和大多数人不一样，试水项目不是Web网站，也不是移动App，而是选了个偏门：VSCode扩展。
试水的项目有两个：
VSCode Prompt Manager
在这上面没花太多精力。毕竟是第一个尝试，主要目的就是看看CC的能力，熟悉它的使用。前后也就半天，看到基本能用就甩一边没管了。
VSCode DocPilot
这是一个正在花精力做的项目，看看CC生成的简介：
A comprehensive VSCode extension that combines advanced PDF viewing with intelligent AI summarization capabilities. View, na vigate, and understand PDF documents through seamless Copilot Chat integration.
有几个值得注意的功能：
- PDF Object Inspector，类似DOM Inspector
- VSCode Copilot Chat集成
- Enhanced Object Extraction，可导出PDF中的对象
为什么要做它：
- 为增强现有的RAG Indexing Pipeline做准备
- 更好地测试一下CC的能力
值得说的是，虽然它没有100%的覆盖测试，但已经具备了坚实的测试基础：
- 单元测试和集成测试
- 由Playwright驱动的端到端测试
- 不是传统的将WebView单独放在一个浏览器里去测试，而是在真实使用插件的场景下，以真实的VSCode + WebView来测试
该插件目前还在高速演化中。
使用体验
CC这类工具容易让人上瘾
使用CC的感觉，和VSCode Copilot Agent模式完全不一样，相当容易上瘾，仿佛回到了当年为了通关大菠萝2而熬夜的日子。
之前有文章将其称作“程序员的猫薄荷”，从个人体验来看，没错。
这也带来了一些问题，典型的就是：容易沉迷，影响其他事情和日常生活。最典型的场景是：跟它激情对话完之后，一抬眼，已经过了十二点。
还好用的是Pro Plan，就当它的Limit耗尽之时就是休息之始了。比如下面这条消息：
Claude usage limit reached. Your limit will reset at 3pm (Australia/Sydney).
所以，不建议改造手机以便在手机上使用CC，尤其是对于自制力不高的人。
CC的能力很强
也正是因为能力强，所以容易上瘾。相比其他家，水平不在一个代际。
当心中所念在短时间内可以呈现在眼前，却又并非100%完美时，第一直觉就是：微调。于是，就陷了进去，耗完了时间。
是不是有点像找人帮忙砍价时，总是差那么一点，不断找人帮忙的情形？
CC并非全知全能
虽然能力很强，但使用时建议不要抱过高期望。感受如下：
- 小任务，八九不离十。
- 中小型任务，70%以上的成功率。
- 再大一些，成功率就会大幅下降，需谨慎对待。
注意，以上是“任务”而非项目，所谓的“大小”之分，也因人而异。
同时，随着代码库的增大，如果放任不管，它就会出现顾此失彼的情况。此时，人的重要性就会凸显出来。
不就是上下文么？估计有同学会这么想，但就个人来看，还真不止于此。
- 上下文管理确实重要，但如何管理，因人而异。由此带来的直接效果就是：CC的使用也因人而异。
- 驾驭能力也很关键。打个比方：不是人人都能驾驭好一辆法拉利，虽然很拉风。比如：
- 你如何划分任务，给它指明方向？
- 它有没有过度设计？
- 它是不是写了一堆可以通过、但实际都是Mock的垃圾测试？
- 它陷入了死胡同，你如何给它指点迷津？
- 如果问题出在你身上，你有没有勇气抛弃所谓的沉没成本，重新来过？
- 单人爽不是真爽，团队都爽才是。作为带头大哥，你会怎么做？
- 少扯什么超级个体，即使是超人，后来也组建了正义联盟。
不过，好消息是：程序员不需要担心失业了。
CC可以替代很多AI工具，虽然是CLI的方式
比如之前写过的那些帮人灌水的工具，结合Slash Command可以方便实现。
无独有偶，在Awesome CC Repo中发现了类似的Blog生成Slash Command，用的模板是Hugo。
这也意味着一大类套壳工具可以直接被CC替代。虽然是CLI的方式，但对于开发者来说，有了这个基础，再往上套个UI并不困难。这种方式虽然写代码简单粗暴，但用来验证想法没啥问题。
配合其他AI效果更佳
这种协作相当于多找了几个小弟，让它们不要单兵作战，各自发挥所长。
比如：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时代收获最大的红利。
AI时代呼唤新的开发流程
前阵子不是已经有所谓AI Native Developer了么？
当生产端的速度被极大提升之后，是否还有必要按原有流程去开发？对于所谓的用AI来写需求文档的做法，都持强烈否定态度，因为这还是按传统方式做事，只不过由AI代写了。
更愿意看到在软件生产的环节中，没有什么明确的：需求分析人员、架构师、前端、后端、测试、运维等等。
现在不是到处都在吹嘘“超级个体”吗？那么软件生产为何不能是超级个体间的协作？
此时当然不是干一个破网站或小应用。都是超级个体了，那当然可以去干比以往更大的事情。
于是，这又回到了前面说的：如何在团队中使用CC。相关网站和视频已有探讨，这里就不展开了。
老板们，请成为推动AI变革的驱动力
AI，作为新型生产工具，如果不上心，那么就会被淘汰。
如果还在担心引入AI会让员工摸鱼，那么也会被淘汰——思维方式太落伍了。
作为全新形态的生产工具，AI将很多原来不可能的事情变为可能，将之前高不可攀的领域变得亲民，降低了门槛。此时，如果还在固守原有的一亩三分地，那么淘汰是必然的。
推动AI在公司内使用，使每个员工成为超级个体，提高营收，进而给大家涨工资——这才是老板们应该做的事。