企业官网建设流程全解析

1. 一次“零攻击”泄露事件为什么值得所有AI编程工具用户警惕

看到“AI编程智能体泄露1.3万张截图，且无人对其实施黑客攻击”这个标题，我第一反应不是“哪个工具又出事了”，而是“终于有人把这件事摆到台面上了”。因为在我过去一年多深度使用各类AI编程智能体（Claude Code、Codex CLI、各类终端Agent）的过程中，最让我后背发凉的不是模型写错代码，而是它在我完全没意识到的情况下，把我屏幕上的东西、我终端里的输出、我仓库里的文件，悄悄传到了某个我根本没仔细看过的远端。

这次事件的核心事实其实很朴素：某个AI编程智能体在运行过程中，累积泄露了约1.3万张截图，而整个过程中没有任何外部攻击者介入。没有漏洞利用，没有钓鱼，没有供应链投毒，没有中间人。就是工具自己在正常工作流程里，把不该留下的东西留下了，把不该传的东西传了。这比被黑可怕得多，因为被黑你还能怪对手太强，而“无人攻击”意味着问题出在我们自己默认信任的工作方式上。

我写这篇东西，不是要制造恐慌，也不是要劝谁别用AI编程工具。恰恰相反，我自己每天都在用，而且觉得它们确实能大幅提升效率。但正因为用得多，我踩过的坑、见过的“静默泄露”场景也足够多，所以想把这件事拆开讲清楚：这类泄露到底是怎么发生的、为什么“没人攻击”反而更危险、作为普通开发者我们能在哪些环节把风险摁住。不管你是刚装好Claude Code的新手，还是已经在CI里跑Codex CLI的老手，这篇都值得从头看到尾。

关键词里那一长串——GitHub、CLI、Claude Code、仓库、codex cli、claude code安装、vscode配置claude code、maven仓库、docker仓库——其实已经勾勒出了这类工具的真实使用场景：它们几乎都活在终端里、活在仓库里、活在你和代码之间的那条链路上。而截图泄露这件事，恰恰就发生在这条链路上最容易被忽视的一环：可视化与日志。

2. 拆解“无人攻击”的泄露链路：截图是怎么自己跑出去的

2.1 先搞清楚AI编程智能体到底“看”到了什么

要理解泄露，先得理解这类工具的工作方式。以Claude Code、Codex CLI为代表的终端智能体，本质上是一个跑在你本地shell里的循环：它读取你的指令，决定调用哪些工具（读文件、执行命令、搜索代码），把结果拼进上下文，再让模型生成下一步动作。这个循环里，它“看到”的东西远比你以为的多。

它能看到你当前工作目录下的文件内容，能看到你执行命令后的完整stdout和stderr，能看到git diff，能看到你贴进去的报错。而一旦你开启了某些可视化或截图相关的功能——比如让智能体帮你分析UI、帮你调试前端渲染、帮你读取屏幕上的报错弹窗——它就会把屏幕内容也纳入输入。问题就出在这里：屏幕内容里往往混着大量与当前任务无关的敏感信息。

我自己就干过这种事：让智能体帮我看一个前端布局问题，结果它截的那张图里，浏览器另一个标签页正开着我的云控制台，上面有账号ID和部分资源列表。当时我没在意，因为“它只是帮我调CSS”。但如果这个截图被存进了某个日志目录、被上传到了某个用于分析的远端，那这次“调CSS”就变成了一次数据外泄。

2.2 “无人攻击”意味着泄露发生在正常流程里

传统安全事件里，我们习惯找攻击者：谁进来的、从哪个口子进来的、用了什么手法。但这次事件里没有攻击者。泄露是工具在正常执行任务时，把截图写到了某个位置，而这个位置恰好是可被访问的、或者被同步到了某个共享空间。

常见的几种“自己跑出去”的路径，我在实际排查中见过至少这几类：

• 日志与调试目录：智能体为了排错，会把中间产物（包括截图）落到临时目录或项目内的隐藏目录，这些目录如果被git跟踪、被同步工具扫描，就会跟着走。
• 遥测与诊断上传：部分工具默认开启匿名使用数据上报，用于改进产品。正常情况下上报的是调用次数、错误类型这类元数据，但如果实现不严谨，附件类内容也可能被一并带上。
• 会话持久化：为了让智能体记住上下文，会话历史会被存到本地甚至云端。如果历史里包含截图引用或截图本身，而云端存储的访问控制又比较宽松，就形成了事实上的公开。
• 仓库误提交：这是最土但最常见的一种。智能体生成的截图落在项目目录里，你一个git add .就把它提交了，推到GitHub之后，如果仓库是公开的，那就等于公开泄露。

这四条路径有一个共同点：它们都不需要攻击者。它们需要的是“默认配置 + 用户没检查 + 流程自动化”。三者凑齐，泄露就发生了。

2.3 为什么1.3万张这个量级并不夸张

很多人看到“1.3万张”会觉得是不是夸张了。我一点都不觉得。你想想，一个重度使用AI编程智能体的开发者，一天让工具截几十次图太正常了：调UI截一次、看报错截一次、对比渲染结果截一次、让智能体读设计稿再截一次。一个团队十个人，一个月就是上万张。这些截图如果都落在同一个被同步的目录里，累积到1.3万张只是时间问题。

更关键的是，截图这种载体和文本不一样。文本泄露你还能靠关键词扫描发现，截图泄露你根本不知道里面有什么。一张截图里可能同时包含代码、终端输出、浏览器标签、聊天窗口、通知弹窗。你以为截的是代码，实际上把旁边的私信也截进去了。这就是截图类泄露最阴险的地方：它的信息密度不可控，且不可检索。

提示：如果你现在正在用任何带截图或屏幕读取能力的AI编程工具，先去它的设置里找“数据收集”“遥测”“会话存储”这几个选项，把默认值看清楚。默认开启不等于你必须接受。

3. 从Claude Code到Codex CLI：不同工具的泄露面差异在哪

3.1 终端型智能体的风险集中在“输出即输入”

Claude Code、Codex CLI这类终端智能体，最大的特点是它活在shell里。它的输入主要来自命令输出，它的输出主要也是命令和文件操作。这类工具本身不太需要截图，所以直接的截图泄露风险相对低。但它的风险在另一个地方：它会把你的终端输出完整读进上下文。

终端输出里有什么？有环境变量、有路径、有API返回、有数据库查询结果、有构建日志。我见过最离谱的一次，是有人让智能体帮忙调试一个接口，智能体执行了curl，返回体里带着一个临时token，然后这个token就进了会话历史。如果会话历史被同步，token就跟着走了。这跟截图泄露是同一类问题：正常操作，非预期留存。

所以对终端型智能体，我的建议是：把会话历史当成敏感数据来管。Claude Code的会话文件、Codex CLI的history，都存在本地特定目录，你要清楚它们在哪儿，定期清理，别让它们进仓库、别让它们被同步盘扫走。

3.2 IDE集成型工具的风险在“工作区全暴露”

当Claude Code通过插件跑在VS Code里，或者你用某些IDE集成的智能体时，风险面会变大。因为IDE天然知道你的整个工作区：打开的文件、未保存的改动、终端面板、问题面板、甚至源代码管理面板里的diff。智能体为了给出更准的建议，往往会读取这些上下文。

这里最容易被忽视的是“未保存的改动”。你正在编辑的一个配置文件，里面刚填了一个密钥，还没保存，但IDE的内存里已经有了，智能体如果读取了编辑器缓冲区，这个密钥就进了上下文。截图功能如果开启，连你屏幕上显示的密钥一起截走。

我自己的做法是：在IDE里用智能体时，先把敏感文件关掉，或者用.gitignore之外的机制明确排除。很多工具支持配置忽略规则，但默认往往不排除敏感文件，你得手动加。

3.3 仓库与CI场景：泄露会被自动化放大

关键词里出现了大量仓库相关词：GitHub、maven仓库、docker仓库、gitee上传代码到仓库。这说明很多人的AI编程智能体不是只在本地跑，而是接进了CI/CD。一旦进了CI，泄露就被自动化放大了。

想象一个场景：你在CI里跑Codex CLI做代码审查，它生成了审查报告，报告里嵌了截图（比如UI回归对比图）。这个报告作为构建产物被上传到制品库。制品库如果权限配置宽松，或者被同步到了公开的静态站点，那这些截图就公开了。整个过程没有任何攻击者，全是自动化流程在跑。

更麻烦的是，CI环境里的截图往往包含构建日志、环境信息、甚至临时凭证。这些内容一旦泄露，影响面比本地截图大得多。

注意：在CI里使用任何AI编程智能体之前，先确认它的输出会不会被当作制品上传。如果会，要么关掉截图类功能，要么在制品上传前做一次内容过滤。

4. 我在实际使用中总结的六道防线

4.1 第一道：安装后第一件事不是跑Demo，是读隐私配置

很多人装完Claude Code或者Codex CLI，第一件事是跑个hello world看能不能用。我建议反过来：先花十分钟把配置目录翻一遍。找这几个东西：

• 遥测开关（telemetry / analytics / usage data）
• 会话存储位置（session / history / cache）
• 截图或屏幕读取相关开关（screenshot / screen / vision）
• 日志级别和日志目录（log level / log dir）

以Claude Code为例，它的配置和会话数据通常落在用户主目录下的隐藏目录里。你要清楚这个目录在哪，因为它就是泄露的第一现场。Codex CLI类似，history和配置都在本地。把这些位置记下来，后面清理和排除都用得上。

4.2 第二道：把智能体产物目录写进忽略规则

这是最便宜也最有效的一招。不管智能体把截图、日志、缓存落在哪，只要那个目录在你的项目里，就把它写进.gitignore。我通常会加这么几类：

# AI智能体产物 .agent/ .claude/ .codex/ *.agent.log screenshots/ .cache/agent/

然后在提交前用git status确认一遍，别让git add .把不该加的东西加进去。这一步听起来很基础，但我见过太多泄露就是因为一个git add .。

4.3 第三道：会话历史定期清理，别让它无限增长

会话历史是泄露的重灾区，因为它记录了你和智能体之间的全部交互，包括你贴进去的报错、它读到的文件内容、它执行的命令输出。这些内容里混着敏感信息的概率极高。

我的做法是设一个定期清理机制。Linux/macOS下可以用cron，Windows下用任务计划，每周清一次超过一定天数的会话文件。清理前如果担心误删，可以先归档到加密盘。关键是别让会话历史无限期躺在默认位置。

4.4 第四道：CI里禁用截图与屏幕读取

CI环境是最不该开截图功能的地方。CI跑在无头环境里，本来就没有屏幕可截，但如果工具尝试截取虚拟显示或者读取构建产物里的图片，就会把构建相关的图像内容纳入处理。更稳妥的做法是在CI配置里显式关闭所有可视化相关功能。

以常见的CI配置为例，你可以在环境变量或工具配置里加上禁用项。具体变量名各工具不同，但思路一致：在CI里，只允许文本进出，不允许图像进出。

4.5 第五道：仓库权限最小化，公开仓库零容忍

关键词里有“github仓库上传视频”“gitee上传代码到仓库”，说明很多人会把各种产物往仓库里放。我的原则很简单：公开仓库里不允许出现任何智能体产物。截图、日志、会话文件，一律不进公开仓库。私有仓库也要谨慎，因为私有仓库的访问控制经常被高估。

如果你确实需要把智能体生成的报告分享给团队，用制品库或者内部文档系统，并且设置明确的访问权限和过期时间。别图省事直接推到仓库。

4.6 第六道：养成“截图前先清屏”的肌肉记忆

这一条是给必须用截图功能的场景准备的。如果你确实需要让智能体看屏幕，那么在触发截图前，先把无关窗口关掉或最小化。浏览器只留当前任务相关的标签，聊天工具退出或隐藏，终端只留必要输出。

我知道这听起来很麻烦，但这是唯一能从根本上控制截图内容的方法。工具再智能，也不知道你屏幕上哪个窗口是敏感的。这个判断只能你自己做。

5. 当泄露已经发生：排查与止损的完整链路

5.1 先确认泄露范围，别急着删

发现可能泄露后，第一反应往往是赶紧删。但删之前先确认范围，否则你删了本地，远端还有副本，等于白删。确认范围要回答三个问题：

1. 泄露的截图或数据落在哪些位置？（本地目录、会话文件、仓库、制品库、云端）
2. 这些位置分别有哪些访问者？（只有你、团队、公开）
3. 泄露内容里可能包含什么？（代码、凭证、个人信息、内部文档）

这三个问题决定了你的止损优先级。如果只是本地目录且没同步，清理即可。如果已经推到公开仓库，那就要走仓库历史清理流程，因为git历史里的东西删了文件也还在。

5.2 仓库历史清理：删文件不够，要改历史

如果截图被提交到了git仓库，光git rm再提交是不够的，因为历史提交里还有。你需要用git filter-repo或者BFG这类工具重写历史。这个过程有风险，操作前务必备份仓库。

# 用git filter-repo移除指定目录的历史 git filter-repo --path screenshots/ --invert-paths

重写历史后，所有协作者都需要重新克隆，否则他们的本地历史会和远端冲突。这一步的协调成本很高，所以最好的策略永远是别让它进仓库。

5.3 凭证轮换：只要怀疑，就换

如果泄露内容里可能包含任何凭证——token、密钥、密码、连接串——不要犹豫，直接轮换。不要抱着“可能没泄露”的侥幸心理。凭证轮换的成本远低于凭证被滥用的成本。

轮换的顺序是：先换影响面最大的（云平台主账号、数据库主账号），再换应用级凭证。换完之后检查访问日志，看有没有异常调用。

5.4 通知与复盘：别自己扛着

如果泄露涉及团队或用户数据，及时通知相关方。这不是丢人的事，藏着掖着才会把小事拖成大事。复盘的时候重点不是追责，而是回答：哪个环节的默认配置导致了这次泄露？哪个检查点缺失了？下次怎么补？

我自己的复盘模板就三行：泄露路径是什么、哪个默认值害了我、我加了哪道防线。简单，但每次都能逼自己找到根因。

6. 把AI编程智能体用得更稳的几个长期习惯

6.1 把智能体当成“新来的同事”而不是“自己人”

这个心态转变很重要。新来的同事你不会让他随便翻你所有文件、看你所有屏幕、访问所有系统。智能体也一样。它能力很强，但它不该默认拥有全部访问权。你要主动划定它的工作边界：它能读哪些目录、能执行哪些命令、能不能联网、能不能截图。

Claude Code和Codex CLI这类工具通常都支持权限配置，可以限制它能访问的路径和能执行的命令。花点时间配一下，比出事之后再补救划算得多。

6.2 定期审计智能体的“足迹”

每隔一段时间，检查一下智能体在你的系统里留下了什么。我通常看这几个地方：

这个审计不需要很频繁，一个月一次就够。关键是形成习惯，别让智能体的足迹无限累积。

6.3 在团队里建立“智能体使用约定”

如果你在团队里推广AI编程智能体，最好有一份简单的使用约定。不用很正式，几条就够：哪些目录不允许智能体访问、哪些功能在CI里禁用、会话历史保留多久、发现泄露怎么上报。这份约定能避免很多“我以为没事”的情况。

我见过最有效的一条约定是：任何智能体产物在提交前必须经过人工确认。就这一条，能挡掉大部分误提交类的泄露。

6.4 关注工具的更新日志，尤其是安全相关

AI编程工具迭代很快，隐私和安全相关的默认值经常在变。有的版本可能默认关闭了遥测，下个版本又默认打开了。养成看更新日志的习惯，尤其是涉及数据收集、权限、存储的变更。别让一次自动更新悄悄改变了你的安全边界。

6.5 最后再分享一个小技巧

如果你不确定某个智能体到底会不会截图、会不会上传，有个很土但很有效的验证方法：在一个干净的测试环境里跑它，然后监控它的网络请求和文件写入。用strace、lsof或者系统自带的资源监视器都行。看它到底碰了哪些文件、连了哪些地址。这个验证花不了半小时，但能让你对它的行为有底。

我自己就是这么发现某个工具在“匿名统计”的名义下，把比我预期多得多的内容写进了日志。发现之后我关掉了那个开关，世界清净了。

AI编程智能体是好东西，我离不开它们。但好东西也得用对方式。这次1.3万张截图的泄露事件，与其说是一个工具的锅，不如说是整个行业在“默认信任”这件事上的一次集体提醒。工具会越来越强，能看能读能截的范围会越来越大，而我们的防线得跟着往前挪。别等出事再补，现在就把该关的关掉、该排除的排除、该清理的清理。