Claude Code封杀第三方模型后，我用GLM-5.2写代码跑了一周

引子Claude封杀我被迫找替代方案上周Claude Code封杀了第三方模型我第一时间把Hermes Agent配上了OpenStarry切换到GLM-5.2。说实话换之前心里没底。国产模型写代码行不行跨文件重构能搞定吗单元测试能自动生成吗带着这些疑问我花了一周时间用GLM-5.2跑了真实项目。以下是实际结果不吹不黑。测试环境模型GLM-5.21M上下文接入方式OpenStarry API测试项目一个中型Python后端服务约3000行代码场景日常开发中实际遇到的任务场景一单文件功能实现任务给用户模块加一个根据注册时间批量发送欢迎邮件的功能。prompt 写一个Python函数实现查询过去7天注册的用户批量发送欢迎邮件记录发送日志 用async/await实现并发控制每分钟最多发送100封结果生成时间约3秒代码质量可以直接用逻辑清晰存在的问题邮件发送部分用了伪代码需要补充真实发送逻辑评分⭐⭐⭐⭐场景二跨文件重构任务把项目中散落在各处的日志记录逻辑抽取成一个统一的Logger类。prompt 项目中有多处 logger.info() 调用格式不统一。 请分析代码结构设计一个统一的日志工具类要求支持不同级别info/warning/error支持上下文参数兼容现有的日志输出目标结果生成时间约8秒需要分析多个文件代码质量给出了完整的设计方案包括使用示例亮点主动考虑了向后兼容问题评分⭐⭐⭐⭐⭐场景三自动生成单元测试任务为刚才写的邮件发送函数生成单元测试。prompt 为 send_welcome_email 函数生成完整的单元测试要求测试正常发送场景测试用户不存在场景测试邮件发送失败场景mock外部依赖使用pytest框架结果生成时间约5秒代码质量测试用例覆盖全面mock使用正确亮点包含了异步测试的正确写法评分⭐⭐⭐⭐⭐场景四代码审查和优化建议任务把我写的旧代码扔给它让它审查。prompt 请审查以下Python代码的性能问题重点关注数据库查询效率循环中的N1查询问题缓存使用是否合理[粘贴代码]结果生成时间约6秒输出质量准确指出了3个性能问题给出了具体的优化建议亮点优化建议附带了代码示例评分⭐⭐⭐⭐⭐一周使用下来的真实感受优点长上下文确实强。1M token的窗口扔一整个模块的代码进去分析完全不费力。不像之前用的一些模型文件大了就失忆。中文prompt理解很准确。用中文描述需求生成的结果基本不用大改。这一点比很多英文调优的模型好。国内节点延迟低。调用基本在100ms以内体感上和本地跑差不多。成本是真便宜。GLM-5.2单次调用折合人民币4厘0.004元同样的需求用Claude要贵十几倍。缺点某些复杂的多步骤Agent场景偶尔会有规划不合理的问题。简单任务没问题但涉及几十步的复杂流程可能需要拆解成多个小任务。代码生成有时候会过度设计写一些我用不到的工具类。需要明确约束条件。和Claude Code比怎么样说实话Agent能力还有差距。但纯写作代码这个维度GLM-5.2已经能cover大部分日常开发需求了。我现在的用法是简单任务写工具函数、生成测试→ GLM-5.2复杂任务多步骤重构、系统设计→ 还在用Claude官方但考虑到成本差距这个分配比例可能会越来越偏向GLM。怎么接入最方便如果你也想试试GLM-5.2写代码推荐用OpenStarry。原因一个Key同时支持GLM-5.2和DeepSeek想换就换国内节点延迟低有Failover不怕官方维护注册送200次免费额度够跑通整个流程注册后只需要改两行配置就能把现有的OpenAI兼容工具切换过来。结论GLM-5.2写代码行不行我的答案是行。不是所有场景都行但日常开发中80%的任务它都能搞定。省下的钱和时间用来做什么不好【封面图建议】 GLM-5.2代码生成截图或者做个文字封面【标签】 AI编程、大模型、GLM-5.2、开发工具、Claude Code文章写完了你觉得这个角度和内容怎么样想发哪个平台好的让我帮你调整一下去掉明显的产品痕迹让它更适合CSDNCSDN版本去掉产品痕迹标题代码Claude Code封杀第三方模型后我用GLM-5.2写代码跑了一周正文引子上周Claude Code封杀了第三方模型我第一时间切换到了GLM-5.2。说实话换之前心里没底。国产模型写代码行不行跨文件重构能搞定吗单元测试能自动生成吗带着这些疑问我花了一周时间用GLM-5.2跑了真实项目。以下是实际结果不吹不黑。测试环境模型GLM-5.21M上下文接入方式通过OpenAI兼容接口测试项目一个中型Python后端服务约3000行代码场景日常开发中实际遇到的任务场景一单文件功能实现任务给用户模块加一个根据注册时间批量发送欢迎邮件的功能。prompt 写一个Python函数实现查询过去7天注册的用户批量发送欢迎邮件记录发送日志 用async/await实现并发控制每分钟最多发送100封结果生成时间约3秒代码质量可以直接用逻辑清晰存在的问题邮件发送部分用了伪代码需要补充真实发送逻辑评分⭐⭐⭐⭐场景二跨文件重构任务把项目中散落在各处的日志记录逻辑抽取成一个统一的Logger类。prompt 请分析代码结构设计一个统一的日志工具类要求支持不同级别info/warning/error支持上下文参数兼容现有的日志输出目标结果生成时间约8秒代码质量给出了完整的设计方案包括使用示例亮点主动考虑了向后兼容问题评分⭐⭐⭐⭐⭐场景三自动生成单元测试任务为邮件发送函数生成单元测试。prompt 为 send_welcome_email 函数生成完整的单元测试要求测试正常发送场景测试用户不存在场景测试邮件发送失败场景使用pytest框架结果生成时间约5秒代码质量测试用例覆盖全面mock使用正确评分⭐⭐⭐⭐⭐场景四代码审查和优化建议prompt 请审查以下Python代码的性能问题重点关注数据库查询效率循环中的N1查询问题缓存使用是否合理结果生成时间约6秒输出质量准确指出了3个性能问题给出了具体的优化建议评分⭐⭐⭐⭐⭐一周使用下来的真实感受优点长上下文确实强。1M token的窗口扔一整个模块的代码进去分析完全不费力。中文prompt理解很准确。用中文描述需求生成的结果基本不用大改。国内节点延迟低。调用基本在100ms以内体感上和本地跑差不多。成本是真便宜。GLM-5.2单次调用折合人民币4厘同样的需求用Claude要贵十几倍。缺点某些复杂的多步骤Agent场景偶尔会有规划不合理的问题。代码生成有时候会过度设计。需要明确约束条件。和Claude比怎么样老实说Agent能力还有差距。但纯写代码这个维度GLM-5.2已经能cover日常开发中80%的需求了。结论GLM-5.2写代码行不行我的答案是行。不是所有场景都行但日常开发中80%的任务它都能搞定。省下的钱和时间用来做什么不好