大模型我是玩得比较晚的，25年3月份才开始用。那时LLM已经很火了。和大多数程序员最先用copliot不太一样，我最先用的是单位测试的的GPT，copliot现在其实也没用过。当时正好在搞一些java grpc interceptor的东西，这些功能都比较独立，一个class一个功能，我就在网页上让gpt生成代码，然后拷贝到IDE里面，写好代码就让它再去写测试。一个比较明确的功能需求GPT都可以做得比较好。稍微复杂的问题由于我这种手动代码交流方式，GPT网页很容易爆掉。这么调测试failure有时也很繁琐。这个阶段我很喜欢ai编程的地方集中在可以让它把一些none functional的需求写得很好，比如一些metric和logging，这些代码一般都会比较繁琐，在工作中是相对最没有priority的需求，交给AI搞，可以在不增加工作时间的情况搞定这些功能，是不错的选择。

这段时间，我还尝试用GPT搞一些架构设计的工作。这些大模型搞起来效果不是很稳定，有的问题解决很好，有的就都是幻觉瞎搞，代码不能compile或者测试问题解决不了。碰到这些问题，用我这种原始的没有agent能力的聊天模式搞，就很麻烦，效率也很低，agent下会比较省人工。

我对AI编程产生更大兴趣的契机是工作上有点闲时间，想研究一个数据分析的POC。问题需要解析一个asm的语法，然后进行一些分析和数据转换。asm这东西以前我接触的不多，自己看文档例子的话，需要不少时间。交给GPT，很快就把功能搞定了，虽然有这样那样的问题，但是架子有了，我改起来，或者让GPT再添加功能，都不是很难了。这次体验，为我后来的大模型使用方式提供了很好的范式：

• 通过大模型高效解决在我技术能力边界的问题。这里的边界指的是我了解或者知道，但是不精通
• 代码需要完整的unit test coverage。这里我追求的不是数值，而是这些test为将来重构提供足够的保障 后面我陆续用这个模式通过GPT解决了一系列类似的场景问题。这些问题都是工作中一些锦上添花或者可以大量简化问题调试的功能。在传统的项目模式下，很难去被prioritize，倒不是不重要，是这些问题的需求就很难讲清楚。现在，这些问题，有了想法，就可以通过大模型来解决，这极大提高了开发质量。

后面我开始使用claude code，在agent模式下编程。这个契机是我revive了一个3年多以前做的home project，代码当时用的是gradle kotlin配置，升级最新的jdk需要改动配置的语法，这些我自己弄起来还要看kotlin的语法，就交给了claude code试一下，没想到很快改好了。后面这个项目的代码有些调用的API已经不能用了，也需要升级，claude code都逐一解决了，这让我在很短的时间里就把这个项目恢复了，是我始料未及的。下面，我完全交给claude code去做一些POC的project，慢慢大模型也就越用越多了。

Claude code在这方面，的确是业界领先。但是封起号来也是雷厉风行。在封号的时候，我尝试了codex，gemini cli还有其他的模型。codex写代码的能力其实不差，但是agent模式做得的确不如claude code好，而且完全不像Claude code那样话痨。gemini能力上个人感觉就差了一点。国内的模型我也尝试了几个：

• qwen解决一些简单的问题是完全可以的，个人使用体验比gemini强，不如codex。有codex，我就不用qwen了
• GLM我是通过iflow用的，感觉比qwen好，和codex差不多。它的优势是可以用ilfow或者claude code的cli。这两个cli都比codex好用很多。不过我的习惯还是可以用codex就用codex
• kimi用了一下，一言难尽，api的计费方式让它没啥竞争力 现在我有claude code用就用，没有就用codex，GPT的月费肯定是要交的，codex等于是白送了。相比cli，IDE的集成我倒是基本没接触过，下面有时间我会试试Cursor或者Antigravity。

大模型使用了10个月，我的感觉就是它对过去编程的方式进行了底层的革命，对我的编程解决问题的能力和学习的效率产生了前所未有的提高。我很难想象退回到没有大模型编程的时代了。最后再总结一下我的一些使用习惯：

• 在每一个repo里面，我都会写好代码规范。比如需要配置devcontainer，所有代码的改动都要有测试，test coverage要达到多少等等
• 需要写代码之前，我都先会在qwen或者GPT的网页版上把问题和解决方式先聊清楚，然后生成一个需求文档，然后再进入cli根据repo代码规范改写一版需求
• 需求并不是越全面越好，很多时候，让大模型一下子解决一个大问题，写很多代码，他会搞出很多问题。大模型写代码的好处就是重构成本很低，所以不如循序渐进搞需求
• 大模型很能写代码，改问题的能力不如写代码。所以代码不应该是最终产出，有时候，有问题解决不了，让大模型推倒重建可能比让它不断地改更效率
• 大模型调试问题的时候，有时候是需要人为干预给方向的，要不很容易烧了很多token，但是搞错方向。这个方向并不需要精准说明问题，而是告诉它不要尝试啥

Last modified on 2026-01-08