警长利用Flock监控跟踪前女友，执法者滥用技术凸显“搜查令”必要性

前沿哨所

• 即梦AI实战教程：利用DeepSeek与多模态大模型从零创作AI短片

  近日，Linux.do社区发布了一套名为“Ai短片创作-从零基础到实战落地”的综合性视频教程资源，该资源汇集了50余个教学视频，系统地展示了当前国产AI工具在视频生成与创作领域的全流程应用。该教程不仅涵盖了基础的“即梦AI”界面操作与提示词工程，还深入解析了智能画布、图生图等高阶功能。课程内容极具实操性，包含《山海经》异兽变身、萌宠做饭、特工营救等具体案例的制作过程，特别强调了在创作中植入DeepSeek大模型以及Agent模式的应用，展示了从剧本、绘图、配音到最终剪辑的完整商业短剧制作闭环。此外，教程还涉及了即梦AI 3.0至4.0版本的更新迭代对比，详细讲解了多模态大模型在视频生成中的角色一致性保持及对口型技术。这套资源为开发者及创作者提供了利用国产工具链进行低成本、高质量AI影视制作的详细路径。

  事件分析

  这套教程的发布标志着AI视频生成领域正在从单一的模型调用向系统化的工作流协作转变。从技术层面看，教程中涉及的DeepSeek植入与Agent模式解析，反映了业界正在尝试利用强大的推理模型来弥补纯视觉模型在叙事逻辑上的不足，即通过LLM（大语言模型）与CV（计算机视觉）模型的协同，实现更精准的画面控制和复杂的剧情编排。从产业视角来看，通过即梦AI等国产工具，配合AI音乐生成、智能画布等插件化能力，已经能够实现商业级TVC广告、古风短剧及绘本视频的批量生产。这意味着影视制作的门槛正在被技术极大地降低，未来的竞争核心将不再是软件操作，而是提示词编排能力与对多模态模型组合的深刻理解。国产多模态模型在视频领域的快速迭代，正在加速AIGC技术从娱乐化向专业生产力工具的进化。

  💡 核心观点：AI视频制作已进入“Agent+多模态”协同的新阶段，国产工具链的成熟正推动影视内容生产向标准化、流程化及低成本方向快速演进。

  原文链接：Linux.do

  5小时前

• 疑似OpenAI接口漏洞：仅需0.5美元即可解锁Codex无限智能体调用

  近日有开发者在技术社区发现一种利用 OpenAI Codex 工作区间的低成本调用方案。该技术方案仅需支付约 0.5 美元开通 Codex 工作区间权限，即可创建具有持续上下文记忆能力的 AI 智能体。根据分享的测试流程，用户在创建智能体并配置 MCP（模型上下文协议）连接本地或开源应用后，虽然界面端因缺乏额度或 ChatGPT 席位无法直接对话，但通过抓取编辑页面的 API 接口，利用特定 access token 和 conversion key（对话标识），即可实现通过 API 与智能体的持续交互。由于该 API 接口被实测为“不计费、无额度限制”，这实际上提供了一个极高性价比的 AI 编程与自动化入口。此外，用户还发现在设置中可将底层“思考模型”手动切换至名为“5.5 xhigh”的高性能版本。为了解决该 API 仅能发送消息无法读取回复的单向通讯缺陷，社区已开源基于 MCP 协议的双向中继项目（workspace-agent-relay-mcp），实现本地 UI 与远程智能体的稳定通讯。目前该消息在开发者圈层引发热议，关于这是 OpenAI 的计费延迟还是接口权限配置漏洞尚无官方定论。

  事件分析

  该事件揭示了大型模型厂商在推出新形态产品（如 Agent Workspace）时，前后端权限校验可能存在的不一致性。技术层面上，这利用了后端 API 对前端订阅状态的信任缺失或计费系统的盲区，使得普通的 Workspace 权限被提升到了近乎 API Key 的无限调用能力。值得注意的是，“思考模型”版本号的暴露（5.5 xhigh）暗示 OpenAI 内部正在进行高阶推理模型的灰度测试，且可能已集成至 Agent 体系内。这种低成本接入方式若大规模存在，将对 OpenAI 依赖订阅和 Token 计费的现有营收模式构成挑战，迫使厂商重新收紧 API 权限或调整 Agent 的部署策略。对于开发者而言，虽然短期降低了使用前沿 AI 编程工具的门槛，但构建在未授权接口之上的工作流存在极高的封号和服务中断风险。

  💡 核心观点：该漏洞不仅暴露了SaaS化AI Agent在权限隔离上的短板，更折射出市场对于低成本、无限制AI编程代理的极度渴望。

  原文链接：Linux.do

  5小时前

• 国产大模型套餐横评：MiniMax、DeepSeek、Kimi 与 GLM 的性价比深度对比

  本文针对国内主流大模型厂商的付费套餐进行了详细对比分析，旨在为开发者和个人用户提供购买建议。评测涵盖了 MiniMax、GLM（智谱）、DeepSeek、Kimi（月之暗面）及 MIMO 五家厂商。在性价比方面，MiniMax 被认为是首选，其 Plus 套餐周额度高达 4 亿 token，Max 套餐更是提供了约 12 亿 token 的海量额度，且搜索功能仅消耗 token 不额外计费，支持多模态生成，非常适合长时间 coding 和多模态开发。GLM 模型编程能力强，但 Lite 套餐额度偏低，且高峰期消耗三倍额度，视觉功能依赖 MCP 转述存在精度损失。DeepSeek 在 API 价格上优势明显，但在套餐模式下，若缓存命中率不高，实际成本并不便宜，且暂不支持视觉。Kimi 被指出额度体验较差，计费规则不透明，不适合作为主力 coding 工具。MIMO 则存在积分换算陷阱，实际可用额度需仔细折算。综合建议是：追求稳定大量使用选 MiniMax，特定强编码场景考虑 GLM，API 调用首选 DeepSeek。

  事件分析

  此次评测反映了国产大模型在商业化落地过程中从“API 价格战”向“订阅服务体系”的转型。厂商们正试图通过打包 token、多模态能力（图像、语音）及搜索功能来构建差异化竞争壁垒。技术层面上，各家在长文本处理和代码生成能力上已趋同，但在多模态交互的稳定性（如 GLM 的视觉转述精度）和高峰期服务调度（如 GLM 的三倍消耗）上仍存在明显差异。DeepSeek 的缓存机制和 MiniMax 的全功能整合策略表明，未来的竞争将不仅是模型能力的比拼，更是资源调度效率和生态整合能力的较量。对于开发者而言，混合使用不同模型以应对不同场景（如代码、多模态、搜索）将成为提升效率的最优解。

  💡 核心观点：大模型订阅制的核心竞争力已从单纯的低价转向高并发下的稳定性与多模态调用的灵活性，单一模型已难以覆盖全场景需求。

  原文链接：Linux.do

  5小时前

• 纯 Rust 构建的开源 SIP 服务器“鸣鹤”发布：主打安全加密与自托管语音通信

  一个名为“鸣鹤”的开源项目在技术社区引起关注。该项目是一个最小化且安全的 SIP 语音通信服务器，完全采用 Rust 语言编写，旨在为用户提供一个替代传统电话系统的自建通信方案，以隔绝诈骗和推销电话。在技术实现上，MingHe 充分利用了 Rust 的内存安全和高性能特性。安全性是其核心卖点：信令层面支持 TLS 1.2/1.3 加密（端口 5061）；媒体层面采用 AES_CM_128_HMAC_SHA1_80 算法进行 SRTP 加密；同时支持 SIP Digest 认证。针对内网环境，MingHe 支持直接使用 IP 地址签发 TLS 证书，并内置了证书自动续期机制。服务器侧实现了 RTP 媒体中继，能够隐藏内部网络拓扑。当前版本支持 1000-2000 号段配置，适配 Bria Mobile 客户端及 Linkvil 等桌面话机，并提供多架构 Docker 镜像以便快速部署。

  事件分析

  从网络通信安全的角度来看，MingHe 的推出体现了开源社区对数据隐私和通信主权的重视。传统的私有电话交换机（PBX）方案往往配置复杂或依赖商业闭源软件，而 MingHe 通过极简主义设计降低了自建语音系统的门槛。特别是其对 IP 地址直接签发 TLS 证书的支持，解决了内网环境下部署加密服务的痛点，这对于缺乏公网域名的家庭实验室或小型企业网络具有重要实用价值。在技术选型上，使用 Rust 重写网络基础设施服务正成为一种趋势。相比 C/C++ 实现的传统 Asterisk 或 FreeSWITCH，Rust 能够在保证高性能的同时，从编译层面杜绝缓冲区溢出等内存安全漏洞，这将显著减少长期运行服务的维护成本。

  💡 核心观点：用 Rust 重写网络基础设施是大势所趋，MingHe 以内存安全特性重新定义了极简私域通信的安全基线。

  原文链接：V2EX 分享发现

  5小时前

• AI Agent接管运维：开源项目Server Security Init实现服务器安全自动化

  针对新手用户在拿到服务器后不知如何进行安全配置的痛点，一项名为“Server Security Init Skill”的开源项目近日在社区发布。该项目旨在利用AI Agent的能力，自动完成Ubuntu/Debian服务器的全流程安全加固与初始化。该项目不仅是一个脚本工具，更被设计为一个AI Agent技能，可以直接将GitHub链接提供给具备Agent能力的AI（如Claude或OpenAI系列），由AI自主读取代码并执行安装。其功能涵盖了服务器安全初始化的完整闭环：首先是身份认证的安全加固，能够自动生成本地SSH密钥对，引导用户完成公钥上传，并验证登录可用性；随后创建具备免密sudo权限的非root用户，并修改SSH端口，彻底禁止不安全的root登录和密码登录方式。在网络防御层面，该Skill会自动配置UFW（Uncomplicated Firewall）防火墙策略，仅保留必要端口的放行规则，并部署Fail2ban防暴力破解工具，同时支持将管理员IP加入白名单以防误封。最后，它还能智能更新本地的SSH config配置文件，实现通过服务器别名直接连接。该项目已在GitHub完全开源，标志着AI技术在DevOps和基础设施自动化领域的实际落地，为开发者提供了一种无需手动编写脚本即可完成复杂系统配置的全新范式。

  事件分析

  该项目的核心价值在于验证了AI Agent从“信息处理”向“系统操作”转型的可行性。与传统的Shell脚本或Ansible Playbook不同，Agent Skill模式将操作逻辑封装为AI可理解、可调用的能力单元。这意味着大模型不再仅仅局限于生成代码片段，而是可以直接作为执行者，介入并控制底层Linux系统的关键配置。从技术角度看，这种模式体现了“意图驱动计算”的趋势：用户只需表达“初始化并加固服务器”的高层意图，Agent便能拆解任务并精准执行chmod、ufw、iptables等底层指令。这降低了服务器安全运维的门槛，同时也引发了对AI操作权限与系统风险的思考。随着此类垂直领域开源技能的积累，Agent生态正在从单纯的对话模型演变为具备复杂工程能力的自动化操作系统，未来有望重构开发与运维的工作流。

  💡 核心观点：AI Agent正从对话助手进化为系统级执行代理，标准化开源技能的涌现标志着运维自动化迈入意图驱动的新阶段。

  原文链接：Linux.do

  5小时前

• Claude Desktop 中文使用指南: 安装、中文交互与 MCP 配置

  很多人搜「claude desktop 中文」，心里其实有两个并列的问题：一是想找一份能照着做的中文安装与使用教程，二是想知道这个桌面客户端到底能不能切成简体中文界面、能不能用中文跟它对话。

  这两件事的答案不一样，而且必须先讲清楚，否则你会在「设置里翻语言选项」这条死路上浪费时间。本文就围绕「用中文把 Claude Desktop 用顺」这个目标，从安装、登录、让它始终用中文回答、界面语言现状，一直讲到 MCP 配置和中文场景下的常见问题排查。

  Claude Desktop 是什么，能不能用中文

  先把结论用一段话讲完，赶时间的人看这一节就够。

  Claude Desktop 是 Anthropic 官方推出的桌面客户端，把网页版 Claude 装进了一个独立的应用窗口，支持 macOS 和 Windows。它的核心价值不只是「网页套个壳」：桌面版能读本地文件、能通过 MCP（Model Context Protocol）协议接外部工具，相当于把一个能调用工具的 AI 助手放在你的电脑上。

  关于「中文」，要分成两层来理解，这也是本文最关键的一个判断：

  • 界面语言：Claude Desktop 的官方界面目前以英文为主，菜单、按钮、设置项基本是英文。它没有一个「设置 → 语言 → 简体中文」这样的一键切换 UI。如果你打开设置在找语言选项，是找不到的——不是你没找到，是它本来就没有。这一点必须先认清，否则后面全是无用功。
  • 对话语言：这一层完全没问题。Claude 对中文的理解和生成能力很强，你直接用中文提问，它就用中文回答；你让它「以后都说中文」，它就会一直说中文。也就是说，「用中文」主要体现在对话交互上，而不是界面汉化上。

  所以「Claude Desktop 中文怎么用」的正确答案是：界面用英文，但你和它之间全程可以是中文。 英文界面只是几十个固定按钮，看一遍就记住了；真正高频的交互是对话框，那里你想用什么语言都行。

  如果你还在纠结桌面客户端、命令行工具、网页版到底怎么选，可以参考我们写过的 AI 编程工具现状：从 IDE 到 CLI，开发者如何在 Cursor 与 Claude 间抉择，里面把不同形态的取舍讲得比较细。

  安装与登录

  桌面版的安装本身很简单，门槛主要不在「装」，而在「能不能正常登录与联网」。

  下载客户端

  从 Anthropic 官网（claude.ai 相关的下载入口）获取对应平台的安装包：

  • macOS：下载后是一个 .dmg，打开把 Claude 拖进「应用程序」文件夹即可。首次打开如果系统提示「来自互联网的应用」，按 macOS 的常规授权流程允许打开。
  • Windows：下载安装程序双击安装，按引导走完即可。

  具体的版本号、安装包大小、菜单措辞，请以你下载到的客户端实际版本为准——这类细节官方会随版本更新，没必要背。

  登录账号

  打开应用后会要求登录 Anthropic 账号。这里有两个现实问题中文用户经常碰到：

  1. 网络可达性：客户端需要稳定连接 Anthropic 的服务。如果一直卡在登录页或提示连接失败，先排查网络环境是否能正常访问对应服务，而不是反复重装。
  2. 账号与额度：免费账号有用量限制，重度使用一般要订阅 Pro 或更高档位。如果你卡在「官方订阅要海外信用卡、价格也不低」这一步，社区里常见的替代路径是走中转/聚合服务，我们实测过其中一家，写在 AnyRouter 实测：模型路由、API 兼容与价格稳定性，可以作为了解这类方案利弊的参考——但要注意，桌面客户端官方登录走的是官方账号体系，中转方案更多适用于 API/命令行场景，两者别混为一谈。

  登录成功后，你就进入了主对话界面。这时候第一件该做的事，不是急着提问，而是先把语言习惯设好。

  让 Claude 始终用中文回答

  这是把「Claude Desktop 用成中文助手」的核心动作。既然没有界面汉化，那就让模型在对话层面始终说中文。有两种做法，建议两种都用。

  做法一：每次对话直接用中文问

  最朴素的办法：你用中文提问，Claude 默认就会用中文回答。对绝大多数日常使用，这就够了。Claude 会跟随你输入的语言，你说中文它回中文，你贴一段英文文档让它「用中文总结」，它也会用中文输出。

  这种做法的唯一缺点是：偶尔在长对话里、或你贴了大段英文资料后，模型可能「顺着英文语境」飘回英文。要彻底锁定，就要用做法二。

  做法二：用自定义指令 / 个人偏好把「说中文」写死

  Claude 提供了让你设置个人偏好 / 自定义指令的地方（在设置里，通常叫 Profile、Personalization 或 Custom Instructions 一类，具体措辞以你的客户端版本为准）。这相当于一段「常驻系统提示」，每次新对话都会自动生效。把语言偏好写进去，就不用每次手动叮嘱。

  下面这段中文指令模板可以直接复制进去：

  请始终用简体中文回答我，无论我用什么语言提问。
  保留专业术语、代码、API 名称、命令、文件路径的英文原文，不要硬翻译。
  代码注释用中文，变量名和函数名保持英文。
  回答先给结论，再给步骤或理由，不要绕弯子。
  不确定的地方明确说明，不要编造不存在的菜单、版本号或参数。
  

  如果你主要拿 Claude 写代码或做工程，可以再补一句偏好，让它的输出风格更贴合开发场景：

  涉及命令行操作时，给出可直接复制运行的完整命令，并标注它在哪个操作系统下有效。
  解释报错时，先定位根因，再给修复步骤，不要只贴一段「可能的原因」。
  

  设置完这段偏好后，新开一个对话试一句英文提问，看它是否仍用中文回复。如果生效，恭喜你，往后界面是英文、交互全中文的状态就稳定了。

  顺带一提，这套「把规则写进常驻指令、让模型每次都遵守」的思路，和命令行端的 Claude Code 用 CLAUDE.md 约束模型行为是同一个逻辑。想深入理解这套配置范式怎么显著影响输出质量，可以读 CLAUDE.md 怎么写：提升 Claude Code 准确率的最小有效配置——桌面版的个人偏好，本质上就是一个轻量版的常驻配置。

  界面语言现状与替代办法

  前面反复强调「没有官方中文 UI」，这里把替代办法摊开讲，免得你觉得「那英文界面是不是就只能硬扛」。

  先接受现状

  Claude Desktop 的界面目前以英文为主，没有官方提供的简体中文界面切换。任何教程如果告诉你「进设置点 Language 选中文」，那要么是把它和别的软件搞混了，要么是凭空编的。请相信你自己——设置里确实没有那个选项。

  替代办法一：英文界面其实只需记十几个词

  桌面客户端的界面元素是高度固定的：新建对话、发送、设置、个人资料、模型选择、文件上传、停止生成……翻译过来就十几个高频词。对照记一遍，之后看英文界面跟看中文没差别。真正承载信息量的是对话内容，而那部分你已经全程用中文了。

  替代办法二：用浏览器翻译看网页版

  如果你实在更习惯中文界面，可以退一步用网页版 Claude，配合浏览器自带的「翻译此页面」功能，把界面机翻成中文。代价是：浏览器翻译有时会误翻对话区里的代码或专有名词，且你会失去桌面版独有的本地文件访问和 MCP 能力。所以这条路适合「只想聊天、不需要工具」的轻量用户，重度用户还是建议留在桌面版、接受英文界面。

  替代办法三：让 Claude 自己当「界面翻译」

  遇到某个英文设置项不确定是什么意思，可以直接截图丢给 Claude，让它用中文解释这个选项是干嘛的。这是最省事的办法——你手里就有一个最强的翻译工具，没必要去别处找汉化包。顺便提醒：网上流传的第三方「Claude 汉化补丁/汉化版」要格外警惕，桌面客户端涉及你的账号和本地文件权限，来路不明的修改版有账号和数据安全风险，不建议碰。

  MCP 配置：claude_desktop_config.json 怎么写

  桌面版相对网页版最大的增量能力，是能通过 MCP（Model Context Protocol） 接入外部工具——让 Claude 能读你的本地文件、查数据库、调用各种服务。这部分配置是真实存在、可照做的，下面给一份能落地的说明。

  配置文件在哪

  MCP 的配置写在一个名为 claude_desktop_config.json 的文件里，位置在不同系统下分别是：

  • macOS：~/Library/Application Support/Claude/claude_desktop_config.json
  • Windows：%APPDATA%Claudeclaude_desktop_config.json

  最稳妥的打开方式不是手动去翻文件夹，而是在客户端里走 Settings → Developer → Edit Config（开发者设置里的「编辑配置」），它会直接帮你定位并打开这个文件。如果这个文件还不存在，新建一个、写入最小内容 {"mcpServers": {}} 即可。

  注意：这里走的是 Developer（开发者） 设置，不是语言设置——再次强调，设置里没有语言切换项，但有这个开发者配置入口。

  配置文件的基本结构

  整个文件是一个 JSON 对象，核心是 mcpServers 这个键，里面每一项就是一个你要接入的工具服务器，结构大致如下：

  {
    "mcpServers": {
      "服务器名称": {
        "command": "启动命令",
        "args": ["参数1", "参数2"]
      }
    }
  }
  

  举一个官方文档里常见的本地文件服务器为例（具体的包名、参数请以该服务器自己的官方文档为准，不同服务器写法不同，不要照搬别处的参数）：

  {
    "mcpServers": {
      "filesystem": {
        "command": "npx",
        "args": [
          "-y",
          "@modelcontextprotocol/server-filesystem",
          "/你想让 Claude 访问的目录路径"
        ]
      }
    }
  }
  

  这段配置的意思是：注册一个叫 filesystem 的工具，用 npx 启动一个能访问指定目录的文件服务器，之后 Claude 就能在对话里读写那个目录下的内容。

  三个最容易踩的坑

  写 MCP 配置时，下面三点几乎是新手必踩的：

  1. JSON 语法不能错：少一个逗号、多一个逗号、引号没闭合，整个配置就加载失败。改完先检查一遍语法，或者让 Claude 帮你核对这段 JSON。
  2. 改完必须完全重启客户端：MCP 配置是在客户端启动时加载的，你保存了文件但不重启，是不会生效的。要彻底退出 Claude Desktop（不是关窗口，是整个退出进程）再重新打开。
  3. command 最好写完整路径：客户端启动子进程时用的环境变量（PATH）往往很精简，导致 npx、docker 这类短命令在终端能跑、在这里却报「找不到命令」。稳妥做法是把可执行文件的完整路径填进去。

  如果你同时在桌面版、命令行、IDE 插件里都配了 MCP，配置文件散在好几个地方、各自为政，管理起来很烦。社区里已经有人做了聚合管理这类配置的开源工具，比如 开源工具 SMRmanager 发布 v0.2：聚合管理多客户端 MCP 协议，新增 WSL 支持，以及更早的介绍 开源工具 SMRmanager：一键统一管理 Claude、Cursor 等 AI 编程工具配置，多客户端混用的人可以了解一下。

  MCP 这套「让 AI 接外部工具」的能力，也是当下桌面客户端和编程 Agent 的共同方向。如果你想把本地知识库接进来，可以看 开源 AI 笔记工具 OpenKnowledge 登场：集成 Claude 和 Cursor，打造本地优先的知识库；想理解工具调用能力在不同模型间的差异，1M 上下文已经可用：Claude、Gemini 与编程 Agent 怎么选 也值得一读。

  中文场景常见问题排查

  把中文用户最常遇到的几类卡点集中处理一下，对照自查。

  它又开始说英文了怎么办

  如果中途模型飘回英文，多半是因为：你贴了大段英文资料、或者对话很长导致语境被英文主导。两个解法：一是回到上一节用「自定义指令」把中文锁死；二是当场补一句「请继续用中文回答」，模型会立刻切回来。把偏好设好之后，这种情况会大幅减少。

  中文输入法 / 快捷键冲突

  在英文界面下用中文输入法打字，偶尔会遇到回车键行为不符合预期（比如想换行却直接发送了，或者想发送却在输入法候选阶段被吞掉）。不同版本的发送键与换行键组合可能不一样，以你的客户端实际版本为准；通用排查思路是：先确认输入法处于「已上屏」状态再按回车，必要时用「换行的组合键」单独换行。

  中文文档上传后乱码或理解偏差

  上传中文文档（尤其是 PDF、老编码的 txt）时，如果 Claude 的理解出现明显偏差，先怀疑文件编码或解析问题，而不是模型能力问题。可以把关键段落直接粘贴进对话框作为对照，或者把文件转成 UTF-8 编码的纯文本再上传。

  中文场景下该用哪个模型

  桌面版通常允许在不同模型档位间切换。涉及中文写作、中文资料处理时，主流的 Claude 模型表现都不错；如果你做的是中文为主、且对成本和部署灵活度敏感的工程任务，也值得横向比一比国产模型，我们写过 GLM-5.2 vs GPT-5.5：架构、Agent 与部署取舍对比，里面专门谈到了中文场景的取舍。

  桌面版和命令行版怎么分工

  不少人同时在用 Claude Desktop 和命令行的 Claude Code，容易混淆。简单说：桌面版偏「对话 + 桌面工具」，命令行版偏「在仓库里直接读写代码、跑命令」。两者的配置思路（系统提示、MCP）相通，但使用场景不同。想搞清楚命令行端在长项目里怎么用，可以看 Claude Code 长项目踩坑：vibe coding 与 spec coding 何时切换。

  相关阅读

  把 Claude Desktop 用顺之后，下面这些站内文章能帮你把整套 AI 编程/对话工作流补全：

  • Claude Code vs Codex vs WorkBuddy vs Zcode：AI 编程 Agent 怎么选 —— 桌面对话之外，命令行 Agent 的横向选型。
  • 将 Vibe Coding 工程化：开源项目详解 AI 辅助编程的正规化工作流 —— 把随性提问升级成有规范的工作流。
  • 开源项目「知返」破解 Vibe Coding 困境：让 AI 编程回归知识获取 —— 别让 AI 只产代码，把知识也留下来。
  • 多仓库开发的 AI 困境：如何实现从设计稿到多库代码的全链路自动化 —— 当你的项目跨多个仓库时的进阶用法。
  • Claude Code 界面重现「Fable-5」选项，Anthropic 或推进新特性测试 —— 关注客户端的新特性动向。
  • AI 文档平台 Kyber 招募工程主管，要求熟练掌握 Cursor 与 Claude Code —— 从招聘需求侧看这套工具链的行业认可度。
  • Codex 磁盘占用异常：失控写盘的根因与排查清理 —— 桌面客户端同样会在用户目录留配置和缓存，了解一下排查思路。

  FAQ

  Q1：Claude Desktop 能切换成简体中文界面吗？
  不能。官方目前没有提供简体中文界面的一键切换，界面以英文为主。但你可以全程用中文跟它对话，并通过自定义指令让它始终用中文回答——「用中文」靠的是对话，不是界面汉化。

  Q2：我在设置里找不到语言选项，是不是版本太老？
  不是版本问题。Claude Desktop 本来就没有语言切换设置，再新的版本也找不到。设置里有的是账号、个人偏好、开发者（MCP 配置）等入口，但没有界面语言项。

  Q3：怎么让 Claude 每次都用中文，不用我反复提醒？
  在客户端的个人偏好 / 自定义指令里写一段常驻指令（本文第三节给了可复制模板），明确要求「始终用简体中文回答、保留术语英文原文」。设好后每个新对话都会自动生效。

  Q4：MCP 的 claude_desktop_config.json 改了不生效？
  最常见原因是没有完全重启客户端，或者 JSON 写错了。改完要彻底退出 Claude Desktop 再打开，并检查 JSON 语法；如果用 npx 这类命令报「找不到」，把命令换成完整路径。

  Q5：用第三方汉化补丁安全吗？
  不建议。桌面客户端涉及账号登录和本地文件权限，来路不明的汉化/修改版有账号和数据安全风险。需要中文界面的话，优先用「网页版 + 浏览器翻译」这种不改客户端本体的方式。

  结语

  「Claude Desktop 中文怎么用」这件事，最容易走的弯路就是去设置里找一个并不存在的语言开关。把这个预期先纠正过来，剩下的就顺了：界面是固定的十几个英文按钮，记一遍就行；真正的交互全程可以是中文，靠的是「直接用中文问」加「自定义指令锁定中文」。需要更强能力时，再通过 claude_desktop_config.json 接上 MCP 工具。

  一句话总结：Claude Desktop 没有中文 UI，但它完全是一个能用中文工作的助手。 把语言偏好设好、把 MCP 配明白，你就拥有了一个装在本地、说中文、还能调用工具的 AI。剩下的，交给对话框就好。

  6小时前