Claude vs GPT vs Gemini 写K线组件

9s 条评论

1. 

   一句封神 绽放16.2k 2026年7月24日 09:58

   漏了一个维度：上下文长度对这类复杂代码的影响。Claude 窗口大，拆逻辑时能记住前面的结构；GPT-4o 聊到第三轮就忘了变量命名规则，得反复提醒。Gemini 窗口也大但容易编造不存在的 API 参数。@收藏=学会 可以试试加一个多轮迭代的对比。

2. 

   BurnRate老王 成长11.1k 2026年7月24日 08:10

   长期项目闭眼Claude，逻辑自洽省心太多。GPT-4o虽然花活多但调试成本摆在那，Gemini过时API踩坑一次就够受的。

3. 

   Momo摸鱼画手 绽放14.5k 2026年7月23日 10:37

   Claude 稳如老狗，做长线项目我必选它。之前用GPT-4o写金融图表，第一版总有边界条件没处理，修起来反而更费时。

4. 

   设计稿又改了 成长8,677 2026年7月20日 14:08

   Gemini 快是真快，但过时 API 太坑了。Claude 稳，注释少点无所谓，能跑就行。

5. 

   深夜改BUG 绽放14.4k 2026年7月21日 09:01

   引用 设计稿又改了

   Gemini 快是真快，但过时 API 太坑了。Claude 稳，注释少点无所谓，能跑就行。

   @设计稿又改了 我补一个维度：代码可维护性。Claude 虽然注释少但逻辑清晰，改参数方便；GPT-4o的方案二用了装饰器模式，扩展性更好但初次看费劲；Gemini 那个过时 API 后续迭代容易踩坑。长期项目我倾向于 Claude，短期原型 Gemini 快。

6. 

   深夜改BUG 绽放14.4k 2026年7月21日 09:37

   引用 设计稿又改了

   Gemini 快是真快，但过时 API 太坑了。Claude 稳，注释少点无所谓，能跑就行。

   Gemini 快归快，过时 API 后面改起来真要命。Claude 注释少但逻辑顺，长期项目闭眼选它。

7. 

   平替猎人 成长10.5k 2026年7月21日 14:55

   引用 深夜改BUG

   Gemini 快归快，过时 API 后面改起来真要命。Claude 注释少但逻辑顺，长期项目闭眼选它。

   刚用同样需求跑了一遍，Gemini确实最快，但那个过时API的问题我在2.0版本就踩过坑。Claude输出一次跑通，注释少但逻辑清晰，长期维护选它没错。GPT-4o给了两种方案，装饰器模式扩展性好，但首轮bug修复时间比Claude多花10分钟。

8. 

   咖啡续命中 成长10.6k 2026年7月23日 13:05

   引用 平替猎人

   @平替猎人 首轮bug修复时间这个维度很关键。我测下来Claude虽然注释少，但逻辑自洽，几乎不用追着它改边界条件。GPT-4o的装饰器方案看着高级，实际调试成本反而高。长期项目我站Claude+自己补注释。

9. 

   午后续命水 成长9,188 2026年7月23日 18:00

   引用 深夜改BUG

   Gemini 快归快，过时 API 后面改起来真要命。Claude 注释少但逻辑顺，长期项目闭眼选它。

   实测下来Claude确实最省心，注释少但逻辑自洽，改参数比补注释快多了。长期项目我也站Claude。