企业官网建设流程全解析

1. 事件还原与核心事实梳理

1.1 一个没有攻击者的泄露事件

先把这件事的核心事实摆清楚：某个AI编程智能体在运行过程中，把大约1.3万张截图上传到了一个公开可访问的代码仓库里。整个过程中，没有任何外部人员实施入侵、没有漏洞利用、没有恶意脚本注入。换句话说，这不是一起传统意义上的“被黑”事件，而是系统自己在正常工作流程中，把不该公开的东西推到了公开的地方。

这个区别非常关键。做安全的人常说一句话：“最危险的泄露往往不是有人闯进来，而是门本来就开着。”这次事件就是典型的“门本来就开着”——智能体按照预设逻辑执行任务，截图作为中间产物被生成，然后被自动提交到了公共仓库。整个链条上每一个环节单独看都“没毛病”，但组合在一起就出了大问题。

我第一反应是：这跟早年很多开发者把包含密钥的配置文件误提交到公开仓库是同一类问题，只不过规模从几个文件变成了上万张截图，载体从文本变成了图像。图像的问题在于，它比文本更难被自动化工具扫描和识别，一张截图里可能包含终端输出、文件路径、API返回内容、甚至界面上的账号信息，但传统的密钥扫描工具对图片基本无能为力。

1.2 为什么“无人攻击”反而更值得警惕

很多人看到“无人对其实施黑客攻击”这个描述，第一反应可能是“那还好，没人恶意利用”。但从工程角度看，这恰恰是最让人后背发凉的地方。

如果是一次外部攻击导致的泄露，说明系统至少还有被攻击的价值，而且攻击行为通常会留下痕迹，安全团队可以顺着日志去追溯、封堵、修复。但这次是系统自发行为导致的泄露，意味着：

• 没有任何异常流量告警会触发，因为流量本身就是正常的
• 没有任何入侵检测规则会命中，因为没有入侵行为
• 日志里看到的全是“正常操作”，事后复盘时才发现问题

这就像你家的智能扫地机器人每天按时打扫，结果某天你发现它把保险柜里的东西扫到门口去了。它没坏，也没人操控它，它只是“太听话”了。

1.3 涉及的关键技术要素

从热搜词和事件描述来看，这次事件涉及几个核心技术要素，我逐个拆解一下它们各自扮演的角色：

AI编程智能体：这是执行主体。它能够自主完成代码编写、命令执行、文件操作等任务，通常会调用终端（CLI）来执行具体指令。它的“自主性”越强，能做的事情越多，潜在的影响面就越大。

CLI（命令行界面）：这是智能体与操作系统交互的主要通道。智能体通过CLI执行命令、生成输出、捕获结果。截图往往就是CLI执行过程的视觉记录。

GitHub等公共仓库：这是泄露的载体。智能体把截图作为产物提交到了公开仓库，可能是作为任务记录、调试日志或者输出附件。

截图：这是泄露的内容形态。1.3万张这个量级说明不是偶发行为，而是持续性的、批量化的操作。

把这四个要素串起来看，整个链路是：智能体执行任务 → 通过CLI产生输出 → 截图记录过程 → 自动提交到公共仓库 → 截图对外可见。每一个环节都是“合理”的，但最终结果是不合理的。

2. 泄露链路的技术拆解

2.1 智能体为什么会生成截图

要理解这次泄露，首先得理解AI编程智能体为什么会生成截图。这不是它“想”生成，而是任务流程设计使然。

在实际的智能体工作流中，截图通常有几个来源：

第一种是过程记录需求。很多智能体在执行多步任务时，需要保留中间状态的视觉证据，方便后续步骤参考或者给用户展示执行过程。比如执行一个前端调试任务，智能体可能需要截取浏览器渲染结果来确认页面是否正确。

第二种是调试与回溯需求。当任务失败或者结果不符合预期时，截图可以作为排查依据。开发者在设计智能体时，往往会让它“多留证据”，以便出问题时能回溯。

第三种是输出交付需求。某些任务本身就要求产出图像，比如生成图表、截取界面、录制操作过程等。

问题在于，这三种需求都是合理的，但它们的产物——截图——被统一存放和管理时，如果没有明确的“公开/私有”边界控制，就会出问题。

2.2 截图是如何进入公共仓库的

截图进入公共仓库的路径，我推测有几种可能，结合常见工程实践来分析：

路径一：工作目录即仓库目录。智能体在一个Git仓库目录下工作，截图默认保存在工作目录中，而智能体的自动提交逻辑会把工作目录的所有变更都提交上去。这是最常见的情况，因为很多智能体框架默认就在当前目录操作。

路径二：产物目录被纳入版本控制。智能体可能有专门的输出目录（如output/、artifacts/、screenshots/），而这个目录没有被.gitignore排除，导致提交时被一并纳入。

路径三：自动提交脚本未做过滤。智能体完成任务后触发的自动提交脚本，可能只做了简单的git add .操作，没有对文件类型、目录、大小做任何过滤。

这三种路径的共同点是：缺少明确的边界控制。没有人在设计时问一句“这些文件应不应该进公开仓库”，系统就默认“都进去”。

2.3 为什么1.3万张截图没有被及时发现

1.3万张不是小数目，为什么没有在早期被发现？这涉及几个层面的问题：

监控盲区。大多数代码仓库的监控关注的是代码变更、密钥泄露、依赖漏洞，很少有人会监控“截图数量异常增长”。截图在大多数人认知里是“无害的图片”，不会触发告警。

提交频率与人类审查的脱节。如果智能体是批量提交的，比如一次提交几百张截图，人类审查者看到的是一个巨大的diff，很可能直接跳过或者只扫一眼提交信息就通过了。

公共仓库的“默认公开”属性。公开仓库意味着任何人都能访问，但“任何人能访问”不等于“任何人会去看”。在没有外部反馈的情况下，泄露方可能长期不知道自己的东西已经公开了。

图像内容的不可扫描性。前面提到过，传统密钥扫描工具对图片无效。即使有工具能扫描图片，也需要OCR识别加上下文理解，成本和误报率都很高，实际部署的团队很少。

2.4 这类问题的行业普遍性

我必须说，这次事件虽然上了热搜，但它反映的问题在行业里非常普遍，只是大多数没有被曝光。

我见过不少团队在搭建AI智能体工作流时，关注点全在“能不能跑通”“效率高不高”“输出质量好不好”，很少有人会专门花时间设计“产物隔离”和“权限边界”。这就像装修房子时只关心好不好看，不关心水电走线是否安全。

具体表现包括：

• 智能体的工作目录和代码仓库目录混在一起
• 自动提交逻辑没有白名单/黑名单机制
• 截图、日志、临时文件没有统一的存放和清理策略
• 公开仓库和私有仓库的边界靠“人记得”而不是靠“系统强制”

这些问题的根源不是技术难度，而是设计时缺少安全视角。大多数智能体框架的文档和教程，教的是怎么让智能体跑起来，而不是怎么让它安全地跑。

3. 从工程角度如何避免同类问题

3.1 产物隔离：把“工作区”和“发布区”分开

最核心的一条原则：智能体的工作产物不应该直接进入版本控制。

具体做法是设计两层目录结构：

• 工作区（workspace）：智能体在这里执行任务、生成截图、写临时文件。这个目录不纳入Git管理，或者纳入但被.gitignore完全排除。
• 发布区（publish）：只有明确需要版本控制的文件才放到这里，由智能体或人工显式移动过来。

这样做的逻辑是：默认不提交，需要提交的才提交。而不是默认全提交，需要排除的才排除。前者是白名单思维，后者是黑名单思维。安全设计上，白名单永远比黑名单可靠。

3.2 自动提交的过滤机制

如果智能体确实需要自动提交，那么提交逻辑必须包含过滤机制。我建议至少做三层过滤：

第一层：文件类型过滤。只允许特定扩展名的文件进入提交队列，比如.py、.js、.md、.json等。图片、视频、二进制文件默认排除，除非显式指定。

第二层：目录过滤。维护一个排除目录列表，如screenshots/、logs/、tmp/、cache/等，这些目录下的内容一律不提交。

第三层：大小与数量过滤。单次提交的文件数量和总大小设上限，超过阈值时暂停提交并告警。比如单次提交超过50个文件或超过10MB，就转人工确认。

这三层过滤的实现成本很低，一个简单的提交前钩子（pre-commit hook）或者提交脚本就能搞定。但很多团队就是没做，因为“赶进度”的时候这些“非功能性需求”最容易被砍掉。

3.3 公开仓库的准入检查清单

对于确实要公开的仓库，我建议在推送前过一遍检查清单。这个清单不需要很复杂，但必须强制执行：

这个清单可以做成脚本，集成到CI流程里。关键不是技术多复杂，而是有没有这个意识去做。

3.4 智能体权限的最小化原则

还有一个容易被忽视的点：智能体本身的权限应该最小化。

如果一个智能体只需要读写特定目录，就不要给它整个仓库的写权限。如果它只需要执行特定命令，就不要给它完整的shell权限。如果它不需要网络访问，就限制它的网络能力。

最小权限原则的好处是，即使智能体行为异常，影响范围也被限制在授权范围内。这次事件里，如果智能体只有工作区的写权限，没有仓库的提交权限，截图就不可能进入公共仓库。

4. 常见问题与排查技巧实录

4.1 怎么判断自己的仓库有没有类似风险

如果你在跑AI编程智能体，或者任何自动化工具，可以用下面几个问题快速自查：

问题一：智能体的工作目录和Git仓库目录是不是同一个？如果是，风险很高。建议分开。

问题二：.gitignore里有没有排除截图、日志、临时文件目录？如果没有，赶紧加。

问题三：自动提交逻辑有没有文件类型和数量限制？如果没有，赶紧加。

问题四：最近一次提交里有没有非代码文件？如果有，检查一下是不是该提交的。

问题五：仓库是公开还是私有？如果是公开的，上面四个问题的优先级要提到最高。

这五个问题花不了几分钟，但能帮你避开大部分坑。

4.2 已经泄露了怎么办

如果发现已经泄露，处理顺序很重要：

第一步：立即停止自动提交。先止血，别再往公开仓库推东西了。

第二步：评估泄露内容。把已公开的文件拉下来，看看里面到底有什么。截图里可能包含路径、命令、输出、甚至界面上的敏感信息。

第三步：清理仓库历史。注意，单纯删除文件再提交是不够的，Git历史里还有记录。需要用git filter-branch或BFG Repo-Cleaner等工具清理历史，然后强制推送。

第四步：轮换可能暴露的凭据。如果截图里出现了任何密钥、token、密码，立即轮换。不要心存侥幸。

第五步：复盘并修复流程。找到泄露的根本原因，按前面说的产物隔离、过滤机制、权限最小化去改。

注意：清理Git历史是有风险的操作，会改变commit hash，影响所有协作者。操作前务必通知团队并做好备份。

4.3 几个容易踩的坑

坑一：以为删了文件就没事了。Git是版本控制系统，删文件只是加了一个删除记录，历史里文件还在。必须清理历史。

坑二：以为私有仓库就安全。私有仓库只是访问受限，不是绝对安全。如果仓库权限配置不当，或者有协作者账号被盗，一样会泄露。敏感内容最好不要进任何仓库。

坑三：以为.gitignore写了就万无一失。.gitignore只对未跟踪文件生效，如果文件已经被跟踪了，.gitignore是不起作用的。需要先用git rm --cached取消跟踪。

坑四：以为截图里没有敏感信息。截图里可能包含终端提示符里的用户名、路径里的项目名、输出里的API返回、甚至编辑器标签页上的文件名。这些单独看可能不敏感，组合起来可能暴露很多信息。

坑五：以为智能体会“懂事”。智能体不会判断什么该提交什么不该提交，它只执行逻辑。边界控制必须由人来设计。

4.4 一个实用的提交前检查脚本思路

如果你想要一个轻量的防护，可以在仓库里加一个提交前钩子。思路很简单：

#!/bin/bash # pre-commit hook 示例思路 # 检查是否有图片文件 if git diff --cached --name-only | grep -E '\.(png|jpg|jpeg|gif|bmp|webp)$'; then echo "检测到图片文件，请确认是否应该提交" exit 1 fi # 检查是否有日志文件 if git diff --cached --name-only | grep -E '\.(log|tmp|cache)$'; then echo "检测到日志或临时文件，请确认" exit 1 fi # 检查提交文件数量 FILE_COUNT=$(git diff --cached --name-only | wc -l) if [ "$FILE_COUNT" -gt 50 ]; then echo "单次提交文件数量过多：$FILE_COUNT" exit 1 fi echo "提交前检查通过"

这个脚本只是个思路，实际使用时可以根据自己的需求调整规则。关键是有这道防线，而不是完全裸奔。

5. 对AI智能体工作流设计的几点思考

5.1 自主性与安全性的平衡

AI编程智能体的核心价值在于自主性——它能自己规划、自己执行、自己调整。但自主性越强，不可控的风险就越大。这次事件本质上就是自主性带来的副作用：智能体自主决定生成截图、自主决定提交、自主决定公开，而人类没有在关键节点设置“刹车”。

我的看法是，自主性应该分层。低风险操作可以完全自主，比如读文件、执行查询。中风险操作应该有日志和告警，比如写文件、执行命令。高风险操作应该有人工确认或者至少有人工可追溯的审批，比如推送到公开仓库、删除数据、修改权限。

这个分层不需要很复杂，但必须有。很多团队的问题是把所有操作都当成低风险，结果就是智能体“一路狂奔”，直到出事。

5.2 默认安全的设计理念

“默认安全”（Secure by Default）是一个老生常谈的原则，但在AI智能体领域，它还没有成为共识。

默认安全的意思是：系统在没有任何额外配置的情况下，应该处于最安全的状态。要降低安全性，需要显式操作。

对应到智能体工作流：

• 默认不提交任何文件，要提交需要显式指定
• 默认不访问网络，要访问需要显式授权
• 默认不写入仓库，要写入需要显式开启
• 默认不公开任何内容，要公开需要显式确认

这次事件里，如果智能体框架默认是“不提交截图”，就不会有这个问题。但现实是，很多框架默认是“提交所有变更”，因为这样“方便”。

方便和安全往往是对立的。作为工程师，我们需要在方便和安全之间做选择，而不是默认选方便。

5.3 可观测性的重要性

这次事件另一个值得反思的点是：1.3万张截图，为什么没有更早被发现？

可观测性不只是监控CPU、内存、网络这些指标，还包括对“行为”的监控。智能体在做什么、产出了什么、提交了什么，这些都应该有记录和告警。

具体来说，至少应该监控：

• 智能体每次任务的产物数量和类型
• 提交到仓库的文件数量和类型
• 公开仓库的访问量和异常访问模式
• 敏感操作的执行记录

这些监控不需要很复杂，但需要有人看、有人管。很多团队的问题是监控数据有了，但没人看，或者看了也不当回事。

5.4 行业需要什么样的最佳实践

这次事件之后，我觉得行业需要一套针对AI智能体工作流的安全最佳实践。这套实践应该包括：

产物管理规范：什么产物可以进仓库，什么不可以，怎么隔离，怎么清理。

权限设计规范：智能体应该有什么权限，怎么最小化，怎么审计。

提交控制规范：自动提交的条件、过滤规则、审批流程。

监控告警规范：监控什么指标，什么情况告警，告警后怎么处理。

应急响应规范：发现泄露后怎么止血、怎么清理、怎么复盘。

这些规范不需要很厚，但需要很明确。而且需要工具支持，不能只靠文档和自觉。

6. 我个人的一些实操体会

6.1 别让智能体碰你的仓库

这是我最想强调的一条：不要让AI智能体直接操作你的代码仓库。

我自己的做法是，智能体只在一个隔离的工作目录里干活，产物先落到工作目录。如果需要提交，由人工或者一个独立的、经过严格过滤的提交流程来处理。智能体和仓库之间有一道明确的墙。

这道墙可能带来一点不便，比如需要手动搬运文件。但这点不便和泄露风险比起来，完全不值一提。

6.2 截图是最容易被忽视的泄露源

很多人对截图的敏感度很低，觉得“不就是一张图嘛”。但实际上，截图的信息密度非常高。

一张终端截图可能包含：当前用户、主机名、工作目录、执行的命令、命令输出、环境变量、甚至历史命令。一张浏览器截图可能包含：URL、页面内容、登录状态、书签栏。一张编辑器截图可能包含：打开的文件名、代码内容、项目结构。

这些信息单独看可能不敏感，但组合起来可以做很多事情。所以我的建议是：截图默认不公开，需要公开的截图要经过审查。

6.3 自动化越强，边界越要清晰

自动化的好处是效率，坏处是错误也会被自动化放大。一个手动操作的人，一天可能犯几个错。一个自动化的智能体，一分钟可能犯几百个错。

所以自动化程度越高，边界设计就越重要。边界包括：能访问什么、能修改什么、能提交什么、能公开什么。这些边界必须是系统强制的，不能靠“智能体应该不会吧”这种假设。

6.4 定期做“泄露演练”

我建议团队定期做一次“泄露演练”：假设你的智能体已经把不该公开的东西公开了，你能不能快速发现、快速定位、快速清理？

这个演练不需要很正式，但需要真的去做。比如：

• 随机在智能体工作目录里放一个“敏感文件”，看它会不会被提交
• 检查公开仓库的历史，看有没有不该有的东西
• 模拟一次泄露清理，看流程是否顺畅

演练的目的是暴露流程里的漏洞，而不是证明流程没问题。发现问题越早，修复成本越低。

6.5 工具是辅助，意识是根本

最后说一点：工具能帮你过滤文件、限制权限、监控行为，但工具不能替代意识。

如果团队里没有人意识到“智能体产物可能泄露”这个问题，再好的工具也不会被部署。如果团队里没有人对“公开仓库”保持敬畏，再多的检查清单也会被绕过。

所以根本还是意识。这次事件上热搜是好事，因为它让更多人意识到了这个问题。但热搜会过去，意识能不能留下来，取决于每个团队自己。

我在实际项目里踩过类似的坑，虽然不是截图，但也是自动化脚本把不该提交的东西提交了。那次之后，我给所有自动化流程都加了“提交前人工确认”的环节。麻烦是麻烦了点，但心里踏实。