1. 命令行使用claude

        我安装了Alacritty工具来运行claude， 感觉它默认的界面风格就满足了我的喜好，在命令上输入：claude。

        用claude从本周一下午开始，从opencode切换过来的，4天半时间里，只会最简单使用方式，就是给它写短需求让它去执行，甚至plan模式都很少用，直接edit模式开干，直接解决真实客户的项目。

        目前我只用到三个命令：/init,  /model, /diff, 前两个基本是一次性使用，/diff偶尔使用。

        基本上是写清楚在哪个类中，新增方法还是在某个已有方法中添加什么功能，这种函数方法级的编程模式，其效率和质量基本是让我满足的。如果是跨多个类添加功能或修改功能，常常一次性是不能准确实现功能的，毕竟真实项目需求细节有时是很不好描述的。

2. vscode使用claude

        命令行上要告诉claude在哪个类哪个方法上做新增或修改，描述起来还是麻烦的，不如在界面上用鼠标选中来的简单。

        安装claude扩展，如：

 安装完成后有两个地方添加了claude图标，左下角：

另一个图标在右上角：

编程时主要点击右上角这个图标弹出操作界面：

这里也是一个输入窗口，和claude cli没什么差别，不同就是vscode左边区域，我们可以打开相关的代码文件，鼠标选择我们要添加和修改的地方，比手写描述方便多了。

据说这是最原始的使用方法。

还有一个让我惊喜的是，客户给的word模版，中间有好几个表格，列也是要动态的，前面好几个我都用文字来很麻烦给cc描述，后来一个实在不想描述了，直接截图给它看看，看它聪明不，因为我们的LLM是多模态的qwen-3.5, 支持图片和视频的，claude竟然正确识别了，还知道去数据结构中找相应的实际字段，写对了！

3. 使用claude几点感想

1)  如果坚持AI生成的代码，自己都要去阅读审查明白，至少90%以上吧，那一次性生成那么多功能代码干什么，自己也看不过来啊。

2）单元测试分两种：一种是让AI自己生成自己测试，或者多Agent来保证；另一种就是坚持人来测试，保证功能的正确性。前者肯定对LLM要求就高了，后者自然低很多。那么多年TDD，又有谁真正坚持后台开发都做了TDD, 反正我经历过的大小公司，都是开发人员手测，然后依赖测试团队?

3）我的思路是：先把CC本身功能用熟悉，能解决以前手工coding的效率问题，又控制住代码质量，然后再去一个个安装学习使用skill, mcp这些附加技能；另一个方面就是，先把个人单一角色，纯coding这个工作搞熟悉了，然后去摸索多角色、多Agent, 团队之间流程交互搭配问题。

4）如果AI产生了大量代码，其实平时又没有一行行去看明白，正常使用一下功能是可以用的，这不代表边界问题，异常问题，各种隐藏bug就没有了，更不用说代码层次结构混乱，数据结构混乱；上周看到一个翻译的国外文章，就是讲不管哪家工具和模型，AI编程目前都是尽力解决问题，看似代码写得格式很好，细看一下就发现非功能的质量问题还是很大的，总有一天，这种项目到了一定规模，会不会失去控制，谁也搞不定，包括AI和人工。

5）我一个感觉：如果开发人员一味追求写好需求就自动编程，自动测试通过，不去看实际AI的代码，不修正AI代码的可读性问题，正交性问题，数据结构定义的不合理性（发现它喜欢一堆字段放在一起），《重构》讲的23种坏味道（没编程的人根本不知道这个东西的重要性），当AI代码量到达一定规模之后，质量问题就会爆发，那时简单修补就很吃力了，改东墙塌了西墙，这个时候就想全项目重构，那不是浪费时间么，所以又依赖更强大的LLM推理能力。
6）目前的各种网文，似乎我们有找到了银弹。但是《人月神话》讲的东西，多少年过去了都不见过时：没有银弹！
从Java，Python, Go， Ruby, Rust， TS等开发语言，从分布式架构，面向组件服务，微服务架构，云原生技术到AI，只有一定程度的改进改善，没有谁能真正解决真实软件系统世界的本质复杂性。---- 没有银弹。

7）客户真实使用的具有一定年龄和规模的老系统，不要想着用AI去重构，谁来保证真正的回归测试？

8）现在基于claude的各种技能插件，讲得天花乱坠，特别那种模拟出多种角色的多Agent,  一个真人指挥一堆木偶很灵活地干活，大有取代90%程序员，测试人员完全就是不需要存在了，产品人员完全一脚踢，业务人员也可以顶半边天。---- 为什么人人都这么急？

4. 结束语

        LLM巨大能量毋庸置疑，但是开发人员要脚踏实地用好基本功能，然后随着不断熟悉而不断引入自己需要的周边技能，真正解决真实项目的实际需求和问题，不要想着一来就一人干了一个团队的活。