Claude Code插件遇运维阻挡，glm-5.2竟出3次错误

背景

在LINUX DO·AI的AI技能与提示词分享版块，一位用户分享了自己在使用AI工具时的实际体验。他表示“感觉glm5.2也降智了，现在像是傻了一样”，并详细描述了具体操作问题。用户使用的是公司的高级坐席coding计划，在VSCode环境中借助claude code插件进行开发。由于公司运维安装了奇安信安全软件，导致claude code的cli端无法正常安装安装上，因此选择在VSCode插件中操作AI模型。

用户的主要任务是让AI操作共享盘上的文件，使用的是Smb协议进行文件传输和处理。过程中，AI在一次尝试中处理好文件后出现错误，随后用户被迫重新提问了三次。最为突出的是，AI在配置.env文件时，本应调用公司的专业OCR API，却拒绝使用，而是自行瞎编了一套逻辑，导致OCR功能始终无法正常工作，造成多次错误。

核心内容

用户明确指出当前使用的AI模型为glm-5.2（即glm5.2），并认为该模型“降智”了，与以往相比“像是傻了一样”。在具体使用场景中，用户在公司高级坐席的coding计划下运行AI任务，依托VSCode的claude code插件完成工作流。问题根源在于公司运维为本机安装了奇安信安全软件，这直接导致claude code的cli版本在终端中无法正常安装安装上（即无法通过命令行安装claude code cli工具）。

面对任务需求——操作共享盘上的文件并使用Smb协议——AI在第一个处理环节就犯下三次错误，用户不得不三次重新提问。用户进一步指出现实中最为离谱的情况是，当AI需要配置.env文件并调用公司专业OCR API时，它完全拒绝执行正确的API调用逻辑，而是自己“瞎编”了一套不正确的处理流程，最终导致OCR功能持续出错，文件处理质量持续下降。

整个故事围绕“AI能力下降”的主观感受展开，强调了环境限制（奇安信）、工具选择（claude code vs cli）和实际执行错误（三次错误 + 瞎编OCR流程）之间的关联，用户最终通过多次重新提问才勉强维持工作流。

关键要点

• 用户明确表示“glm5.2也降智了”，将当前AI模型与以往表现对比，认为其“像是傻了一样”。
• 使用场景为公司高级坐席coding计划，在VSCode中借助claude code插件。
• 插件依赖失败的直接原因：公司运维安装奇安信安全软件，导致claude code的cli端无法正常安装安装上。
• AI任务核心：操作共享盘文件，使用Smb协议。
• 首次尝试即出现三次错误，用户被迫三次重新提问。
• 最严重失误：配置.env文件时拒绝调用公司专业OCR API，而是自行瞎编，导致OCR持续错误。
• 整体工作流因多次重新提问而受阻，最终AI仍未能正确完成OCR配置。

意义与影响

这一分享在AI社区中引发了对“AI能力衰退”或“模型稳定性”的广泛讨论，凸显了当前AI工具在企业级应用中面临的现实挑战：安全软件兼容性问题、插件限制以及多轮错误累积对工作效率的直接负面影响。用户通过多次重新提问维持任务，反映出AI在复杂Smb文件操作和专业API调用场景下的鲁棒性不足，同时也提醒从业者需关注特定企业环境（奇安信等）对本地工具安装的潜在干扰。

更深层而言，这则帖子的传播可能加速行业对“模型降智”现象的重视，推动开发者优化提示词工程、环境配置和安全兼容策略。用户最终仍需依赖多次人工干预才能完成OCR任务，表明在高要求coding工作中，AI与人类协作模式仍存在明显差距，未来优化方向可能集中在降低错误容忍度和增强环境适配性上。对于高级坐席和coding团队来说，这一案例提供了可复制的经验教训：选择工具时必须提前评估本地安全软件的干扰，提前准备多轮迭代机制，并优先验证API调用逻辑的可靠性。