[程序员] claude 被封之后尝试国产替代

一句话看懂：一名开发者因Claude被封，系统性地测试了多款国产大模型的实际编码能力，发现DeepSeek V4 Pro在修复Android启动器bug时的表现最接近理想，而其他模型在逻辑连贯性和验证环节各有明显短板。这件事暴露了当前国产模型在真实开发场景中“能用但不够可靠”的现状。

事件核心：发生了什么

近日，一位匿名开发者在V2EX社区分享了自己在Claude被封后，尝试使用国产模型完成Android启动器项目bug修复的经历。他测试了Minimax 2.7、Kimi 2.7、GLM 5.2、DeepSeek V4以及Qwen 3.7等主流国产模型，统一开启“YOLO模式”（单次尝试、不调提示词），要求模型解决“启动器抽屉背景不扩展到状态栏”的UI问题。结果差异显著：Qwen 3.7 Max未能修复底部搜索栏的背景覆盖；Minimax 2.7虽有修复但改动过大；Kimi 2.7思考时间过长且“修好”后截屏图片未更新；GLM 5.2同样思考时间长且额度中途耗尽。只有DeepSeek V4 Pro成功修复并通过模拟器验证，但在项目管理环节连续出错——错误地关闭了正确分支并额外创建了新的PR。整个测试仅代表单次非严谨体验，但足够反映各模型的实战水平。

为什么重要

这个案例之所以值得关注，在于它剥离了基准测试的线性评测，还原了开发者使用AI编码的真实痛点。模型在纯文本理解和代码生成上的得分，与实际上手调试、保持会话上下文、正确管理Git工作流的能力之间存在显著落差。DeepSeek V4 Pro在修复层面的胜出，表明更先进的基础模型在具体指令遵循上仍有优势，但它的多步管理失误也说明，当前国产模型在“工程项目协作”这一维度的通用能力仍未成熟。对于正加速追赶OpenAI和Anthropic的国产大模型厂商而言，这提醒他们除了刷榜，更需要在开发工具链的稳定性与代理能力上补课。

对用户/开发者/创作者的影响

对于依赖AI进行日常编码的开发者来说，这次实测传递了几个清晰信号：一是“国产替代”目前仍需在关键环节留神核查——即使模型写对了代码，也可能会搞错提交历史或忘记验证；二是不同模型各有所长，但尚无一个能替代Claude在完整开发工作流中的连贯表现，尤其是跨会话记忆和任务管理能力；三是使用国产模型时需要接受额外的容错成本，比如更频繁的手动检查和更严格的PR审核流程。对于非技术类创作者，这个案例也暗示，如果模型连“截屏后保留确认结果”这种基本操作都做不到，那么在生成内容、处理稿件等场景中也可能出现“看起来对了实际上没改”的风险。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

值得关注的后续

第一，DeepSeek V4 Pro在修复任务上的表现是否可复现，以及其团队是否会改善代理（Agent）在Git操作中的稳定性；第二，Kimi、GLM等模型的新版本是否会在思考时间和验证自动化上做出优化，尤其是将截图校验纳入标准流程；第三，这类非官方、非基准的开发者实测是否会形成常态化的社区评价体系，倒逼模型厂商在发布前增加更多类似的“实战场景压力测试”。

来源：V2EX (创意工作者社区)