我盯着屏幕上那行报错信息愣了几秒——不是代码编译不过，而是我的AI编码助手Claude Code在调试日志里吐出了一段不该出现的内部路径，指向某个几乎不可能被普通用户接触到的私密配置。下意识去搜索“Claude Code 源码泄露”相关讨论时才发现，整个技术圈已经炸开了锅：这款被无数开发者奉为“AI结对编程神器”的工具，其核心源码和内部文档已经以超出预期的姿态暴露在公众视野中。

这起事件像一记闷棍，敲在所有激进拥抱AI编码工具的人头上。过去一年多，我几乎是第一批把Claude Code塞进日常开发流程的深度用户——用它在深夜改写重构脚本、让它接管繁琐的测试用例生成、甚至把整个项目的架构决策权交给它的上下文窗口。我太清楚这类工具能读多少东西、能碰多少敏感数据了。所以当“源码泄露”四个字出现时，我首先关心的不是谁泄露的、会不会被追责，而是一个更尖锐的问题：我和团队那些通过API发送出去的私有代码、环境变量、业务逻辑，现在到底安不安全？这次的泄露事件，对继续使用AI编码工具的开发者来说，究竟意味着什么？

1. 源码泄露事件的台前幕后：先搞清楚到底发生了什么

1.1 泄露的不是“你的代码”，但这不代表不用慌

首先要给所有还在惊慌的朋友泼盆冷水：从目前各方披露的公开信息看，这次Claude Code所谓的“源码泄露”，指的并不是哪家企业的私有代码库被拖库，也不是开发者的本地对话记录和代码片段被公之于众。泄露的主体是Claude Code自身核心代码仓库的访问凭证和一部分内部源码、构建配置、测试脚本、内部文档，甚至可能包含了一些后续功能的规划说明。

听起来好像“只伤了自家元气”，但实际上这事的风险等级一点都不低。原因在于：Claude Code这种AI编码代理工具，它的核心源码里藏着大量的内部处理逻辑，包括它是如何解析用户请求的、如何调用底层大模型的、如何设计上下文截断策略的、如何做工具调用的权限边界判断的。一旦这些内部实现细节被彻底拆解，攻击者就能精准找到绕过安全机制的方法——就像一个保险柜生产商把图纸泄露了，你当然知道保险柜的常规密码还打不开，但那些精心设计的防撬结构、传感器位置、锁芯死角，全都变成了纸面上的透明信息。

更麻烦的是，许多第三方开发者基于Claude Code做二次开发，源码泄露可能导致他们集成的私有插件、内部patch方案跟着暴露。我在几个开发者社群里看到不少人担忧自己的闭源插件逻辑被人逆向对照参考。这一层影响往往被低估。

1.2 事件发酵路径中的几个关键节点

把这些分散信息捋一遍，事件的发酵路径大致是这样的：最初是某个匿名渠道露出了零星的代码片段，很快有技术能力较强的开发者根据代码指纹锁定了来源属于Anthropic官方Claude Code仓库的私有部分。接着，包含大量内部协作文档和CI/CD配置的压缩包开始在小范围技术圈流传，有人提取出API端点地址、内网服务名、密钥轮换计划等敏感信息。消息传到国内技术社区后，先是各大AI编程交流群炸锅，然后陆续有技术媒体跟进报道，标题一个比一个惊悚，最后演变成“AI编码工具被脱库”这类让非技术背景的项目经理都紧张的说法。

针对这个演化链，我想提醒大家注意三个容易被忽略的事实：

• 泄露代码的时效性尚不明确。目前流传的版本里有相当部分可能是历史版本代码，不代表当前线上版本的逻辑。
• 密钥和令牌类信息有大概率已经被Anthropic紧急轮换失效，直接拿泄露凭据去尝试访问官方服务，基本行不通。
• 真正的风险点不在于“旧源码暴露”，而在于后续基于旧源码的分析会持续产出新的攻击思路，这是一个长尾效应。

换句话说，这起事件更像是一次针对头部AI编码工具的定向“拆解报告发布会”，而非一起简单的账号密码泄露。它对安全圈的真正冲击在于：大模型编码代理的内部防御细节，从此不再是黑盒。

1.3 对普通开发者而言，事件的真实影响面有多大

放下技术圈那些“源码细节分析”不谈，换个姿势问一个最实在的问题：对我这种正经拿Claude Code写业务代码的人来说，到底有什么实际影响？

我的判断是分三个层面。第一层是目前即刻可见的——如果你在泄露发生前后使用了Claude Code，且你的环境中存在被泄露的API密钥或者内部令牌，那这批凭据应该果断作废重置，这是最基本的操作。第二层是短期内间接的——攻击者可能利用泄露的源码逆向出绕过官方安全策略的方法，比如伪造合法签名、模拟可信插件、构造恶意指令来诱导模型向外发送数据，这些攻击手法落地需要一定时间，属于“安全预警期”风险。第三层是长期心理层面的——它让所有开发者被迫重新审视“把代码交给AI代理”这件事的信任边界。

我强烈建议所有使用Claude Code（以及Cursor、GitHub Copilot等同类AI编码工具）的团队，别被热搜词带节奏只盯着“要不要卸载工具”，而是把注意力放到“现在起我该用怎样的安全姿势继续使用”上。这也是我写这篇文章的出发点：从这次事件出发，以实际落地视角整理一套AI编码场景下的安全操作指南和事故应对手册，帮你把损失和风险都控制住。

2. 当编码助手成为核心开发工具，攻击面到底被拉大了多少

2.1 AI编码工具凭什么让攻击者垂涎三尺

聊安全指南之前，必须先把底层逻辑讲透：为什么AI编码工具会成为安全事件的高发地？为什么一个源码泄露能引发如此大的连锁讨论？

答案藏在Claude Code的工作机制里。它不是一个简单的“AI自动补全插件”，而是一个拥有文件系统读写能力、命令执行权限、网络访问能力的智能代理。为了让AI能真正干活，它需要接触你的项目结构、源码内容、版本控制信息、运行环境变量、依赖配置、数据库连接字符串、云服务凭据，甚至还要读取你本地的配置文件、SSH公钥、密钥链信息。打个不太恰当的比方：过去你请一个程序员帮忙，他能看到你给他展示的那部分代码；今天你用AI编码代理，等于请了一个拥有项目目录全部只读权限、还能在你终端里执行命令的“影子员工”。

这个权限模型决定了AI编码工具的信任等级，几乎等同于将整个本地开发环境开放给第三方服务。一旦这类工具有任何环节出纰漏——本地缓存未加密、网络传输被中间人攻击、插件市场混入恶意组件、云端会话记录被未授权访问——攻击者能拿到的数据量，远比一次常规的源码仓库泄露要多得多。Claude Code每次会话的日志文件、自动保存的会话快照、~/.claude目录下的配置和历史记录，都是潜在的敏感信息富矿。

2.2 从源码泄露事件延伸出的三类典型攻击路径

结合此次Claude Code源码泄露，安全研究员们普遍关注三类新的攻击路径。我整理了下面的对照表，方便你快速理解：

三种攻击路径有一个共同特点：都不是直接攻击Anthropic的服务端，而是把矛头对准了“开发者本地的Claude Code环境”。这也解释了为什么事件发生后，官方安全建议的核心不是“不要再用AI了”，而是“确保你本地环境是干净且隔离的”。

2.3 每个开发者的终端里都藏着哪些AI工具敏感资产

顺着这个思路，我花了一晚上把常见AI编码工具在本地的“数据指纹”摸排了一遍。以Claude Code为例，你机器上至少有这几类资产属于高敏感度：

• ~/.claude目录下的配置文件：存储了你的认证凭据、API密钥、历史会话记录、自定义指令、hooks脚本等。一旦被读取，等于有人复制了你和AI的全部协作记忆。
• 项目的.env文件与运行环境变量：Claude Code为了能帮你调试，会主动读取环境配置。很多团队习惯把数据库密码、云服务密钥放在环境变量里，AI能读到，恶意软件自然也想读。
• 自动生成的会话日志和快照：默认情况下它会记录每次交互的详细信息，有些版本还能恢复历史对话。那些聊过架构设计、提过内部系统逻辑的对话记录，落到外人手里就是免费的情报。

注意，我上面列的这些，并非要吓唬你不用AI，而是想强调一个事实：AI编码助手在你开发机里的“可见范围”，可能比你的同事还要大。源码泄露事件是一个再明显不过的信号——整个安全行业对AI编程工具的关注，正从“它写代码写得对不对”转向“它读走的那些东西最终去了哪里”。

3. 事件发生后，个人开发者最该做的八项安全自查与加固

3.1 第一步：立即轮换所有涉及AI服务的凭据

无论你这几天是否接收到官方通报，第一件要做的事永远是凭据回收。这不是对Anthropic的不信任，而是标准的安全事故响应流程——只要你的环境中存在可能被波及的令牌、API Key、访问凭证，就默认它们已经暴露，立刻轮换。

具体来说，检查以下三类凭据是否与你日常使用的AI工具关联：

• Anthropic Console / Claude API Key：登录后台，查看最近调用记录，建议直接吊销并创建新Key。
• GitHub、GitLab等代码托管平台的Personal Access Token：如果Claude Code配置过仓库读写权限，务必轮换。
• 云服务商密钥和数据库连接凭据：AI工具虽不直接接触云平台，但你的项目环境变量可能被AI读取过，所以只要代码库接触过的凭据都建议轮换一次。

轮换时有个细节容易漏：某些长期运行的后台服务可能把旧凭据缓存下来了。轮换完Key之后，记得重启Claude Code相关进程、清空旧会话缓存，再继续干活。

3.2 第二步：审查Claude Code的本地数据留存策略

这次事件给了我一个直接教训：不能默认AI工具本地的数据留存策略是安全的。去翻了下Claude Code的配置文档，发现官方提供了不少与隐私相关的开关，只是藏得比较深。

我建议按下面的优先级改配置：

• 关闭自动会话分享或统计诊断数据上报功能，从源头上减少数据外流。
• 设置历史记录保留天数或最大文件大小，避免本地无限堆积敏感会话。
• 检查hooks脚本里是否有自定义的网络请求逻辑，防止某些第三方配置在每次对话时向外发送元数据。

配置完成后，用一条指令直接确认当前生效的配置项，避免改完不生效。以Claude Code的CLI为例，可以执行code或claude命令，输入/config或/settings来查看交互界面中的隐私开关。不同版本入口有差异，但核心逻辑是：所有涉及“发送诊断信息”“自动更新”“匿名统计”的选项，全部关到最严格档位。

3.3 第三步：对项目工作区做敏感信息专项扫描

解决完AI自身的数据留存，下一步就轮到你项目里的敏感信息了。很多开发者对“敏感文件”的理解还停留在.env文件上，但实际操作中，最容易泄露的是这几类：

• 配置文件中的注释里遗留的旧密码和连接串
• 测试代码里硬编码的Mock密钥和假令牌
• 日志目录下结构完整的HTTP请求报文
• 文档和Markdown文件里粘贴过的云服务ARN、Bucket名称、内部IP地址段

扫描工具建议直接用trufflehog和gitleaks这类敏感信息检测工具扫一遍整个项目目录，配合正则表达式重点匹配API Key、私钥块、云凭据等模式。扫出来的每一个命中项都不要抱有侥幸心理，全部按“已经暴露”处理——删除、轮换、重写配置，一步到位。

许多人对这个步骤不耐烦，觉得自己的项目是私有仓库，不至于泄密。但根据我这些年接触的安全案例如实说，绝大多数真实泄露的起点都不是“有人攻破GitHub”，而是“项目压缩包被分享”“代码片段被贴到论坛”“测试环境被人爆破”。敏感信息一旦进入文件系统，它就脱离你的控制了。

3.4 第四步：重构AI工具的工作目录与权限边界

想要提升长期安全性，最有效的方法不是改配置，而是从操作系统层面限制AI编码工具的“视野”。我现在的主力开发机做了这样的隔离处理：

• 为Claude Code这类AI代理单独创建一个低权限系统账户，给它分配一个专用目录，只有该目录下的文件对其可见。
• 在仓库根目录里维护一个.aiignore或.claudeignore文件，把.env、密钥目录、部署配置等敏感路径全部列入排除清单。Claude Code和同类工具多数支持类似.gitignore的忽略规则语法。
• 终端层面，用操作系统的安全策略禁止Claude Code衍生的子进程访问钥匙串、Keychain或系统级凭据存储。这个操作略微激进，但把“AI代理能读系统密钥”的口子堵死了。

你还应该意识到：所谓“权限隔离”做的并不是防Claude Code本身，而是防那些将来可能利用Claude Code执行恶意指令的攻击者。AI代理在你机器上拥有的权限越大，恶意指令的破坏力就越大。把权限缩小到“项目目录内部”，即使哪天真跑了一段恶意代码，损失范围也可控。

3.5 第五步：给会话记录和日志加一层物理保护

应对源码泄露这种事件，很多人只盯着代码本身，却忽略了会话记录的价值密度其实更高。Claude Code的会话记录里包含的不只是你问过什么问题，还有你调试时的报错内容、临时输出、测试数据，甚至你随手贴给AI看的内部文档片段。

对这批资产的保护方案，我推荐这样三层：

1. 存储加密：将~/.claude目录和项目内的.claude目录做整目录加密。macOS上可以用APFS卷宗加密或FileVault，Linux下则建议对home目录打LUKS加密的dm-crypt卷。这样即使笔记本丢失或被其他进程越权读取，数据也不会瞬间裸奔。
2. 定期清理：设定每周或每两周的清理任务，删除超过30天的历史会话记录文件。信息留存时间越短，泄露风险越小。
3. 备份隔离：用加密压缩包把项目中需要长期保留的AI协作日志封存，放回加密容器中，从普通工作目录里移除。

别嫌麻烦。你想想，如果源码泄露事件里流的那些代码里，混着几百条你与AI的完整实战对话，攻击者对你的项目了解程度可能直接反超你的CTO，那得多吓人。

3.6 第六步：建立本地环境的异常行为监测点

安全不只是被动防御，还需要一点主动观测能力。个人开发者的机器通常没有专业的安全监控，但我们可以用轻量手段建立一个简单的“异常行为哨兵”。

操作不复杂，两步走。第一，定期检查Claude Code的配置文件是否被改动过。用ls -l或者stat命令查看配置文件的修改时间，如果发现某个配置文件的mtime发生在你没有改动过配置的时刻，就要警惕是否有恶意脚本自动篡改权限。第二，检查是否有非预期的网络连接。在终端里用lsof -i或者netstat -an命令查看本机对外连接情况，重点关注那些半夜或待机时段建立的长连接，它们很可能来自AI工具的后台更新或未知组件。

更稳妥起见，你可以用开源工具如chneau/falcon或类似轻量HIDS定期扫描目录哈希变化。把这些监测动作做成每早一条定时执行结果发到自己邮箱，只需要花十分钟部署，就能获得一个持续运行的“哨兵”。

3.7 第七步：换个姿势理解AI编码的安全使用规则

排查完环境层面的风险，还有个“人”的因素需要更新。这次源码泄露事件之后，我对自己和团队用AI编码工具的习惯做了几个硬性调整，在这里分享出来供你参考：

• 不再把最敏感的生产环境密钥、数据库内容、用户个人信息直接贴进对话里。需要AI处理脱敏后的结构化数据。
• 不再让AI读取超出当前任务范围的文件。以前习惯性直接把整个src目录塞给Claude Code做全局分析，现在会先明确“只让它看定位到的那几个文件”。
• 对AI生成的代码新增“供应链意识”。以前觉得AI生成代码有逻辑bug才需要担心，现在更要关注AI可能会基于训练数据中的过时或恶意模式生成带安全缺陷的代码。每次让AI引入新的依赖包之前，会先查一下包名是否抢注、版本是否可疑。

一个现实是：AI编码工具只会越来越渗透进开发流程，与其因噎废食地拒绝使用，不如学会控制它在每项任务中的数据接触范围。就像你不会把公司数据库root密码贴在白板上一样，有些信息也不该走进AI对话的输入框。

3.8 第八步：为“AI不可用”的突发状况留一条后路

源码泄露事件往往伴随服务波动、限流或者下线整改。作为重度依赖AI编码的人，我这两年吃过最大的亏就是“过度依赖后的空白期”。在一次Claude Code服务连续数小时不可用的情况下，我的开发进度几乎瘫了一半——平时被AI代劳的测试用例编写、接口文档生成、边界条件枚举，突然全得自己手工做。

所以我给自己的“AI编码安全体系”里加了一条残酷但实用的规则：永远让AI帮你写代码，但永远不让自己失去不靠AI写代码的能力。具体做法包括：

• 每周保留半天不使用AI编码工具，纯手工编写核心业务逻辑，保持手感。
• 对AI生成的关键代码模块，手工补充设计文档和数据流说明，保证后续没有AI也能读懂能维护。
• 定期手工跑一遍完整的构建、测试、部署流程，确认对AI工具的依赖点都能通过替代方案兜底。

这套“留后路”机制在安全事件频发的当下尤其重要——因为你无法预测哪天哪个工具的源码又泄露了、服务又整改了、模型策略又调整了，但你可以确保自己永远具备“关了AI也能把活干完”的能力。

4. 对于团队和技术负责人：把AI编码工具纳入统一安全治理

4.1 别让员工的AI工具成为企业的监视器

个人开发者的安全加固做到第八步基本可以收手，但如果你带了团队，情况要复杂得多。团队场景中，AI编码工具的安全问题从“个人隐私风险”升级为“组织数据资产风险”。

我见过太多团队把手里的AI编码工具当成普通IDE插件，既没有统一配置管理，也没有后台审计，员工各自为政地注册账号、接入API、分享上下文。后果就是：企业根本不知道哪些代码被发给了哪家大模型厂商，哪些员工在对话记录里贴了数据库备份路径，哪些项目资料在AI的训练数据里转了一圈又回到了员工的另一台设备上。

负责任的技术负责人，应该起码做到四点：

• 建立AI工具的准入审批机制，不随便让开发者在生产项目里接入新的AI编码插件。
• 统一配置企业级账号和代理出口，让所有AI调用流量经过可控的审查网关或满足合规的数据脱敏层。
• 组织覆盖率100%的安全意识培训，重点讲清“哪些类型的内容不该发给AI代理”。
• 给AI工具配置的企业凭据单独设立最小权限，不与代码仓库主账号共用。

所谓“把AI编码工具纳入安全治理”，本质上是把你和团队对AI工具的信任模式，从“被动的、分散的、默认信任”切换为“主动的、集中的、按需授权”。

4.2 在代码审查流水线中嵌入对AI生成内容的检测环节

除了治理工具的接入，还需要治理AI工具的产出。源码泄露事件后，攻击者可能基于内部实现生成大量带特定后门模式的代码片段，投放到公共仓库或作为开源模板传播。AI编码助手一旦引用这些片段，无异于把你的生产环境变成一个等待触发的后门。

对团队而言，最好的应对是在CI/CD流水线里增加一道针对AI生成代码的“安全风格检查”和“供应链依赖审计”关卡。这里不是要你完全禁用AI代码，而是要确保AI代码进入主干前经过同样的严格审查。

实操上，可以配置这样的流水线步骤：

1. 对所有新引入的第三方依赖跑一遍依赖项版本比对库（如OSV-Scanner或Trivy），确认依赖名不是仿冒包。
2. 用静态代码分析工具（Semgrep、CodeQL）扫描AI改动过的代码文件，重点检查命令注入、文件路径穿越、反序列化漏洞这几类AI容易犯的错误模式。
3. 对可疑的“高复杂度低注释”代码段增加人工审查提醒。AI生成代码通常存在过度抽象和异常判断逻辑，这两类地方最容易藏恶意逻辑。

4.3 制定AI会话数据留存规范与应急响应预案

最后一个团队动作，是我认为大部分公司目前都缺失的：为AI编码工具单独写一份应急响应预案。大多数公司的安全预案针对的是“服务器被攻击”“数据库被拖走”这类经典事故，几乎没有想过如果有一天，团队与AI编码工具的交互日志、员工粘贴的内部代码片段、AI调用记录被公之于众，应该怎么响应。

一份可用的AI工具安全应急预案，至少要覆盖几个问题：

• 事件定级标准：什么级别的AI工具安全问题需要启动应急流程？
• 数据暴露面评估：立刻梳理过去N天内哪些项目被AI访问过、哪些员工账号涉及其中。
• 外部沟通模板：是否需要向客户或监管方说明，确认应由哪个岗位对外表态。
• 业务降级方案：如果AI编码工具被停用48小时，团队开发流程如何切换回传统模式。

这份预案的价值未必体现在日常使用中，但真要碰上类似“Claude Code源码泄露”甚至更严重的连带事故时，你会发现，提前写过预案的团队和没写过的团队，反应速度和止损效果完全是两个量级。

5. 后续实操补充：基于这次事件的长效工具箱与常见问题排查

5.1 一张清单：源码泄露事件后的AI工具安全自检表

为了让你上手更直接，我把前面讲的个人开发者和团队两步内容合并成一张可在半天内执行完的自检表。建议你直接复制到工作笔记里，按顺序逐项核对：

• [ ] 轮换所有AI服务相关API Key和访问令牌
• [ ] 关闭AI工具的诊断上报和自动更新渠道
• [ ] 扫描项目目录内的硬编码密钥和敏感配置
• [ ] 设置Claude Code的ignore规则，屏蔽.env、密钥目录、部署配置
• [ ] 加密或清理历史会话记录文件
• [ ] 检查配置文件的修改时间和异常网络连接
• [ ] 确认自己能脱离AI完成核心开发流程
• [ ] 更新团队安全制度，将AI编码工具纳入统一管理
• [ ] 编写AI工具专项应急响应预案并至少演练一次

5.2 几个常见疑问的快速解答

在我写作期间，社群和评论区里高频出现几个追问，这里统一答复一下。

问：Claude Code源码泄露之后，现在继续用还安全吗？

安全风险不可能清零，但从当前信息看，官方已做紧急处置，泄露源码主要为历史版本的可能性较大。继续使用本身没毛病，但务必按照上文步骤做环境加固。不要把“继续使用”和“什么防护都不做”画等号。

问：用DeepSeek、通义或其他国产模型接入Claude Code，安全风险是不是更大？

把第三方模型接入Claude Code这类工具，会形成新的数据链路。模型提供方、本地代理工具提供商、可能存在的第三方网关，每一环都可能接触到你的代码数据。如果你还没有审查过这条链路的数据流向与留存策略，我建议停止使用非官方渠道接入大模型，至少不要在生产项目里使用。

问：AI生成的代码是不是都要做额外的安全扫描？

如果AI生成的代码要进入生产环境，应该默认走和人类开发代码一样的安全扫描流程。尤其在涉及外部输入处理、身份认证、支付交易这类高风险领域时，AI生成代码必须强制加入安全测试环节。别被AI那种“一本正经写代码”的气势唬住——它只是在概率上模拟正确，并不代表它理解你的业务边界和安全上下文。

问：还需要继续购买Claude Code这类商业款AI编码工具吗？

我的观点是：购买决策不应只看这次事件，而要看服务商对安全事件的响应速度与透明度。等风头过去后，复盘一下官方发布的漏洞披露、事件分析报告、补救措施细节是否足够专业靠谱。一个能够扛住大型安全事件并给出高质量复盘报告的服务商，通常比从未经历风雨的对手更值得长期信任。

5.3 如何持续追踪AI编码安全动态

源码泄露不会是这个领域的最后一次安全事件。要想长期做好AI编码安全，关键不是追着热搜跑，而是建立一套持续获取安全情报的信息渠道。

我的日常跟踪方式是：

• 关注Anthropic、OpenAI等公司的官方安全公告页和状态页，信息可靠度最高。
• 订阅GitHub Security Advisories数据库中与AI开发工具相关的通告。
• 留意OSV、NVD等开源漏洞库中关于Claude Code、LangChain、Semantic Kernel等AI开发框架和工具的CVE条目。
• 加入几个高质量的安全技术社区或群组，在里面潜水看别人的事故复盘比看营销稿有价值得多。

所有渠道的核心不是“收集信息”，而是“提前布局”。你如果能比团队其他人早半天知道某个AI工具出现了高危漏洞，就能早半天做临时替代方案或缓解配置，等到漏洞细节公开的时候，你已经补完洞了。

把话说回开头那个让我愣住的瞬间。在AI编码工具的洪流里，真实的安全意识和系统的防护习惯，比工具本身的选择重要得多。这次Claude Code的源码泄露事件，给所有依赖AI加速开发的人提了个醒：AI编码工具给效率带来了极大跃升，但它的安全边界从来不是默认存在的，需要每一个使用者亲手去划。我的建议依然是——放心用，但别裸奔。从审核凭据开始，从加密会话记录开始，从限定工作权限开始，把这些基本功都补齐后再让AI替你冲锋陷阵。毕竟在真实的攻防世界里，决定你安全系数的往往不是AI写代码的能力上限，而是你为它设置的安全下限。