Claude Code封杀第三方模型后，我用GLM-5.2写代码跑了一周
引子：Claude封杀，我被迫找替代方案
上周Claude Code封杀了第三方模型，我第一时间把Hermes Agent配上了OpenStarry，切换到GLM-5.2。
说实话，换之前心里没底。国产模型写代码行不行？跨文件重构能搞定吗？单元测试能自动生成吗？
带着这些疑问，我花了一周时间，用GLM-5.2跑了真实项目。以下是实际结果，不吹不黑。
测试环境
模型：GLM-5.2（1M上下文）
接入方式：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代码的性能问题，重点关注：
数据库查询效率
循环中的N+1查询问题
缓存使用是否合理
[粘贴代码]
结果：
生成时间：约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
文章写完了！
你觉得这个角度和内容怎么样？
想发哪个平台？
好的！让我帮你调整一下，去掉明显的产品痕迹，让它更适合CSDN：
CSDN版本（去掉产品痕迹）
标题：
代码
Claude Code封杀第三方模型后，我用GLM-5.2写代码跑了一周
正文：
引子
上周Claude Code封杀了第三方模型，我第一时间切换到了GLM-5.2。
说实话，换之前心里没底。国产模型写代码行不行？跨文件重构能搞定吗？单元测试能自动生成吗？
带着这些疑问，我花了一周时间，用GLM-5.2跑了真实项目。以下是实际结果，不吹不黑。
测试环境
模型：GLM-5.2（1M上下文）
接入方式：通过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代码的性能问题，重点关注：
数据库查询效率
循环中的N+1查询问题
缓存使用是否合理
结果：
生成时间：约6秒
输出质量：准确指出了3个性能问题，给出了具体的优化建议
评分：⭐⭐⭐⭐⭐
一周使用下来的真实感受
优点：
长上下文确实强。1M token的窗口，扔一整个模块的代码进去分析，完全不费力。
中文prompt理解很准确。用中文描述需求，生成的结果基本不用大改。
国内节点延迟低。调用基本在100ms以内，体感上和本地跑差不多。
成本是真便宜。GLM-5.2单次调用折合人民币4厘，同样的需求用Claude要贵十几倍。
缺点：
某些复杂的多步骤Agent场景，偶尔会有规划不合理的问题。
代码生成有时候会"过度设计"。需要明确约束条件。
和Claude比怎么样？
老实说，Agent能力还有差距。但纯写代码这个维度，GLM-5.2已经能cover日常开发中80%的需求了。
结论
GLM-5.2写代码行不行？我的答案是：行。
不是所有场景都行，但日常开发中80%的任务它都能搞定。省下的钱和时间，用来做什么不好？