1. 条件有限情况下接入本地vLLM服务

        为什么不介入互联网上各种强大的LLM服务，什么不使用专业的编程LLM？一个是穷、习惯和保守，一个是所在行业的安全需要，没有绝对的理由，各种方面的理由都有那么一点点。

        又刚好公司有那么一两块GPU，虽然小，但是自己可以随便折腾尝试啊，如我目前就有：8G显存和48G显存两块nvidia卡，小的用来部署人脸识别、人体识别和向量LLM，以及ollama服务，大的用来部署多模态LLM，vLLM和ollama都部署上了。

        本地部署的LLM服务，tokens随便烧起来，就是速度慢，让它日夜跑就是了，我的claude code cli, vscode claude code,  opencode, qwencode， openclaw, hermes agent，同事们的编程工具和openclaw都接入vLLM，至少它从来没有崩溃掉，GPU肯定是100%常跑。

2. claude依旧存在opencode出现的那些问题

        当一个class添加的功能越来越多，再往里面添加新功能，或者做代码重构，claude有时会效果很差，在同一个方法内部都出现低级错误，代码修改不完整，甚至编译都没通过就匆匆结束，提示可以测试验证了。

        代码文件和类越来越大，claude不会考虑代码的可读性可维护性，会继续往里面加新代码。

        数据结构方面也类似，喜欢添加大量字段，给几个功能共用，中途是不知道分拆的，问题是我叫它要分拆了，有时还不一定听话。

        不用的变量定义，不用的入参，class中没有使用的数据成员，都不会主动清理干净。

        这主要是后台LLM模型推理差的问题，还是Agent不会提问题、编排能力弱的问题，可能两方面都有。

3. 本地LLM搞不定的问题，时间再长它也搞不定

        昨天碰到一个问题：产品人员要求把数据分析预测接口改为异步流模式，就是要给前端界面提供实时报告执行进度，类似现在各家AI Web版上的深度思考功能。我写好需求交给claude去执行，claude 连接自建vllm+Qwen3.5-35B-A3B-FP8, 执行时间不长，听到成功提示播音还很欣喜，一看代码晕了：数据分析预测接口确实修改为异步模式了，但是也把已经测试通过的N -1 个接口全部删除掉了，好在有git仓库又找回来了。

        接口测试验证总是不能成功，发起访问就关闭，修改了几轮才搞定，然后能执行，但是客户端不能实时打印消息，不停让它修改，折腾有半天时间都没搞定，我已经失去调教它的耐心了，直接把model改为互联网上glm5免费模型，一次性分析搞定问题。

        以后碰到这种本地自建开源大模型，几轮修改还搞不定，就不要浪费时间，要么接入外网专业编程大模型快速搞定，要么自己动手解决掉，不然有时比手工编码更费时间。

4. 关于Vibe Coding氛围编程

        vibe coding被翻译为氛围编程，有些人说叫直觉式编程，不管是叫什么，就是不先搞一个严格的全面的需求分析和系统设计，而是直接开干，后果就是系统架构很差，功能代码积累到一定程度，不管是数据结构还是流程算法，都很难维护了。

5. 关于Spec Coding规范驱动编程

        spec coding叫规范驱动编程，就是编写代码前，先在plan模式下写清楚要实现功能的功能性描述、非功能描述、实现约束条件，目的就是要AI coding不要乱来，严格地像个经验丰富的高级工程师来编程一样，一次性搞定这个大功能模块，这个想法是好的，同时配套除了各种plugins/skills， 如andrej-karpathy-skills、superpowers、gstack等，多Agent来协作搞定，一个Agent来编码，一个Agent来审查代码。

        我只安装了andrej-karpathy-skills，其它的想安装还没有动，因为真实项目折腾了一个月，从首次结束LLM应用开发和AI Coding编程，各种技术调研和系统搭建耗费了大量时间，已经没太多精力折腾这些流程的东西。

        一个感觉就是，spec写得不详细不行，写得那么详细，太耗费时间了，还有，如果没有顶级的LLM编程模型来使用，目前使用一般开源编程大模型，而且是最小资源下部署的内网LLM，就算spec写得再详细，claude code + 内网vLLM+开源LLM小模型也搞定，编程推理能力没有那么强，一次性喂的功能点描述越多，搞出的问题就越多，最后就是不停修复bug，总体上耗费时间会让人吃惊。

        别问我为什么不接入国外Opus系列和GPT系列，我们不是发烧友，自掏腰包去翻墙的事情目前还没兴趣。

6. 结对编程

        前些年风霏一时的敏捷开发、极限编程XP、TDD、快速迭代、Scrum、结对编程、看板、CI/CD、用户故事story，今天有几个团队在遵守，有几个开发人员把一些东西融入到骨子里了，肯定没有严格遵循的，因为太累，肯定有一些留下来自觉融入自己的开发习惯中。

        那么在AI coding新模式下，这些东西很快被有识之士提出来，来解决AI coding的一些问题， 也可以说是AI +, 其中我比较看好的是结对编程。

        当年要2个开发人员结对，常常2个大男人在大夏天空调房搞基在一起，根本是不现实的东西，我也和一个小青年搞了几天，这太麻烦了，不如自己干，程序员就是喜欢安静自由，真人结对就不现实。

        然而现在，一个真人 + AI coder，开发人员负责需求分析、系统设计，AI coder负责编程干苦力，开发人员审查代码验收测试，不停地把AI coder当牛马来让它bugfix， 我最近就是这个工作模式，感觉总比自己一个人全流程干好很多，一天下来眼睛没有以前那么干涩了。

        编码毕竟是最耗时最累的，AI coder帮我们干了90%左右，我们自己手工搞一点关键代码，修复一点关键麻烦的bug，然后留下大量时间去做设计和测试，也是不错的。

7. 结束语

        那些想着无人值守，AI Agent多角色协作自动搞定一切的人，他们是不是真正负责开发真实项目的开发人员?  看到很多运维人员很兴奋，业务人员很从懂AI, 要知道运维工具是他自己使用，客户不会来使用，需求验收其实是AI说了算，自然是能搞定问题了。

        在AI + 时代怎么保证软件工程中需要坚守的东西，如代码质量、可读性、可维护性、性能、一定的系统设计文档，需要我们去不断尝试和反思，找到合适可靠的方法论。