前言
最近一直在用n多大语言模型辅助编码，真真切切感受到了大语言模型给程序员带来的实实在在的好处。在使用大语言模型解决编程问题的过程中，很早之前就对各家模型的代码能力有了一个初步的判断，但是，一直没有用同一个难度适中的问题对他们做过验证：就是说用相同的问题（prompt）提问不同的模型，并对比他们的解决方案的优劣，从而对不同语言模型的编码能力做出一个初步的判断。
这种判断当然不准，但是结合长时间使用下来的客观对比，我感觉，结论对得起他们各自的能力。
题外话
在开始今天的主题之前，我们先说一个题外话：AI最终会取代程序员岗位吗？
作为一个骨灰级程序员，我的判断是：大量的初级程序员岗位必然或是正在或者已经被取代，但是，高级程序员短期内甚至长期都不会被取代。
这是另外一个话题，今天不讨论，而且，这种问题理论性太强且见仁见智，不太容易得出认可度高的结论的。
但是，AI对程序员的帮助是巨大的，这个巨大如果想要量化的话，基本是：你的个人能力是基础，AI可以在你的能力基础上做加法或倍乘效应，如果你自己的能力有限，只能加法，如果你个人能力比较高，就可以是倍乘或指数级效应。
你自己的能力包括两方面，一方面是你的编码能力，另外一方面是你对AI的驾驭能力，主要体现在提示词工程上。
好了，这个题外话就说这么多。
问题
进入正题，先说我需要解决的编码问题。
我要交给AI的是一个项目中的实际问题，是关于设备停机时长和稼动率计算的问题。具体问题是：我有一个处理点位停机记录的表，是从PLC采集后加工出来的，记录了设备下各个和停机时长有关的点位的停机数据，比如：设备停机按钮被按下的开始、结束时间以及停机时长；设备暂停键被按下的开始、结束时间及停机时长；设备重要故障或告警按钮被按下的开始、结束时间及时长。
稼动率就是用这个停机记录进行计算的，算法相对比较复杂，而且，历史原因，刚上线的时候认为只有一个点位影响停机时长的计算，所以停机时长没有考虑同一个设备多个点位都会参与稼动率计算的情况下的重复计算问题，比如：
点位A：10:00 - 10:25停机
点位B： 10:20-10:40停机
那么，该设备从10点到10点40共40分钟停机。但是我目前的算法并没有考虑两个点位的重复时间的问题，会计算为点位A停机时长25分钟，点位B停机时长20分钟，共45分钟停机时长，两个点位共同停机的5分钟被重复计算。
这个就是我需要解决的问题，显然会有两种不同的方案，一种是从写入停机记录这一侧解决，避免同一设备不同点位相同时间段的停机记录；另外一种是后置解决方案，就是在计算稼动率的时候区间去重方案。
现在就让主角登场。
Google AI studio + Gemini 3 pro preview
这是我最喜欢的组合，目前为止我还没有发现除Google之外的其他大模型厂商能提供像Google AI Studio这样的工具，Google AI Studio可以支持Google最新的Gemini 3模型，最重要的是，它可以支持system Instruction，可以调节temperature。因此如果用一个单独的大模型直接跟基于Google AI Studio的Gemini对比的话，对其他模型来讲是不公平的，因为Gemini相当于拥有了一个其他大语言模型不具备的NB工具。
无论如何，我们先用Google AI Studio试一下，我把启停机记录的代码发给他，并告诉他这是我的工厂设备数采提取到的启停机记录数据，主要用来计算稼动率，并告诉他我的这段的代码在工厂生产环境运行的很好，没有bug，让他简单分析一下代码。
第一轮会话他告诉我，代码有几个不算太严重的并发问题，我根据他的提示修改了，之后发给他代码让他再检查一下，第二轮对话结束。
然后开始第三轮对话，告诉他我现在面临的多个启停机点位的问题，注意，我的问题中并没有告诉多个点位时间叠加重复计算、也没有告诉他会有两个不同的方案选择。 让他分析问题、给出方案，方案确定之前别给出代码。
他首先是分析问题，精准定位到问题痛点：
给出了一个后置去重的方案，不建议第一个方案：
之后我告诉他我其实有一个第一方案的设计思想，发给他，然后给出了现在的稼动率计算的代码，因为我觉得稼动率计算相对来说比较复杂，需要用休息时长切片计算、去掉休息期间的停机时间。让他考虑一下稼动率算法的复杂性，重新考虑方案。
然后他非常肯定的依然坚持他的方案，并且给出了稼动率分段切片算法的改进方案：
总结部分建议我立即采用这个方案进行改造：
而且顺便把我分段切片算法做了改进，原来的各种case的交叉判断变成了两个集合取交集的算法，100行代码变成10行。
我觉得我应该给满分，非常牛逼，用最小代价解决了我的问题。
Deepseek登场
接下来我用Deepseek。Deepseek作为编程助手我也试过了好多次，最早没用Gemini的时候、那个时候gpt也不算太好用（token限制、以及动不动假死不反馈），我用了一段时间的deepseek，也踩过坑，所以我其实对他一直有偏见，觉得他太爱显摆、其实很二。
公平起见，我的提示词都是从Gemini那边粘贴过来的，而且都是启用新的对话，没有会话历史。
第一轮会话还算可以，但是，一如既往的臭显摆，提出了很多根本就不是问题的问题，这个就不管了，直接进入到我的第三轮提出问题的环节。
然后他在分析问题环节就没有找到痛点，没有说出两个点位停机区间重叠导致的停机时间重复计算的问题：
然后方案建议中一如既往的给出方案一、方案二、方案三...数据处理建议、实施建议等等一堆废话，这是我在使用Deepseek中最烦的地方，每次都是没有确认是否精准定位到问题的时候就给出一堆方案。
然后他的方案基本是聚焦在我们前面提到的方案一，和Gemini的观点相反。
然后我继续和Gemini一样的操作，告诉他我有第一方案的想法，告诉他还有一种后置计算、也就是在稼动率计算的时候区间去重的方案，再发给他稼动率计算的代码，让他重新分析对比两个方案。这个操作和Gemini那边也完全一致。
之后他继续坚持第一个方案（因为我说我也有第一个方案的想法了，所以下面他就把这个方案叫做我的方案了）：
还说了后置处理方案的复杂度：
之后还给出了第一个方案的详细实现步骤，表结构的设计、状态机的管理...等等，一大堆。
这个时候就没办法继续比较下去了，相同的prompt已经用完了。所以，我就直接给出Gemini给出的后置方案的代码，因为那个代码特别简单，我就想看看Deepseek怎么看待这个方案，我的prompt是这样的：
但是我已经实现了时间区间合并，代码看起来非常简单，一个是merge方法mergeOverlappingRecords，另外一个是我改进后的calculateURByRestTimeN方法。你帮我分析一下，这个方案好不好，我还需不需要按照我之前的状态合并的方案修改？他就说我的merge方法有问题：
我实在看不懂他在说啥，后置方案计算的停机时长1.5小时他认为 多算停机时长。正确结果应该是：实际停机时长 1.5小时。实在搞不懂啥意思。
我有点烦了：
从这儿开始他就测底转向了...没有自己的观点了。但是依然一如既往装逼：
后面就干脆开始献媚了...还有，快速承认错误、但是马上有装逼...
他在代码方面表现很差。
豆包
豆包在最初拿到问题之后对问题的分析阶段，是识别到问题的痛点的：
但是接下来给出的方案无比复杂。
为了公平起见，我直接给出了稼动率计算的代码，让他重新给出方案。他还是坚持先前提出的什么状态机、前置修改写入switchRecord记录表的方案：
他认为稼动率计算的过程中在时间切片的基础上实现去重视非常复杂的。
我就把Gemini的方案给他分享一下：
和Deepseek不同的是，豆包很认可这个方案：
还给打了分：
我觉得在这个问题上，豆包比Deepseek要强、要务实的多。
Gemini 3 pro without Google AI Studio
我说过在Google AI Studio的加持下去对比豆包、Deepseek和Gemini是不公平的，所以我特别的、去掉Google AI Studio单独让Gemini 3做了一次测试。
详细的对话过程我就不说了，整体效果和有Google AI studio的情况差不多，无论是分析问题：
还是解决方案：
GPT5
网页的反应速度依然特别慢，特别烦。
我等了很久，也没有等到他的回复...
根据以往我对GPT5的了解，他的表现应该不会太差。改天等他能正常反馈的时候（确实有些时候他的反馈特别快）再补充。
Why
为什么会对大模型的编码能力做这样的对比？其实对我个人来说，分析对比之后得出一个相对可靠的结论，对日常工作过程中使用大模型解决实际编码问题非常重要。我就会根据他们的日常表现给他们分配、安排合适的工作，大模型在不同方向上的表现和能力应该是不一样的，而且，有些时候部分模型使用起来不是很方便，都懂。所以，不是太必要的情况下就可以不召唤他们。
总之，我认为你对自己的助手要有一个清晰的了解，这样你才能用好他们，让他们发挥正面作用。