把近5万个源文件喂给AI之前，我先做了一件事

大型项目（46000+文件）直接喂给AI会token溢出或产生严重幻觉。正确做法是先用脚本做穷举式预扫描（文件分类、体积分布、技术栈、三方库清单、Git活跃度），输出结构化Markdown数据，再让AI基于这份"CT片"做深度分析。本文用一个21子项目的C++项目演示完整流程，发现了FFmpeg 2015版本还在跑、基础库被复制粘贴30+份、636MB构建垃圾入库等问题。

近5万个文件，AI说"我看不完"

你面前是一个五年历史的大型项目。

21个子项目，46000多个文件，C++、Java、ObjC、TypeScript四个技术栈混在一起。你刚接手，或者你就是原作者但已经半年没碰这块代码了。

你打开AI编程助手，让它帮你理清项目结构。

结果要么是token直接爆了------几万个源文件全部读一遍，几百万token打底，任何模型的上下文窗口都装不下。要么AI只扫了几个目录就开始一本正经地总结，告诉你"这是一个模块化设计良好的项目"。

你看了一眼那个塞满了.obj和Debug/目录的仓库，心想它可能在跟你开玩笑。

这不是AI的问题，是你喂给它的方式不对。

把几万个文件直接扔给AI，就像把一整个图书馆的书倒在桌上，跟人说"帮我总结一下"。信息量太大，没有结构，谁来都懵。

直接喂AI的后果	原因
Token爆炸	46000个文件的源码 = 几百万token，塞不进任何模型
幻觉严重	AI只看了冰山一角就开始"推断"全局，结论不可信
遗漏角落	藏在vendor目录里的过期三方库、构建垃圾永远不会被扫到

你得先帮它缩小范围、组织信息。

先给项目做个CT，再让AI读片

思路很简单：不要让AI直接读源码。先做一次高速扫描，把项目结构数据化，再把结构化数据喂给AI。

就像医生不会拿肉眼直接看你的骨头------先拍CT，再基于影像做诊断。

具体来说，你需要用脚本跑一遍整个项目目录，提取出这些结构化信息：

文件分类：哪些是项目自有代码、哪些是三方库、哪些是构建产物
体积分布：自有代码占多大、三方库占多大、垃圾文件占多大
技术栈分布：C++多少、Java多少、每个子项目用什么语言
三方库清单：每个库的名称、版本、许可证
Git活跃度：哪些目录最近还有人改、哪些三年没人碰

这些信息汇总起来，就是项目的一份"结构化体检报告"。

为什么这样做比直接喂源码好？三条理由：

Token高效。 46000个文件的结构化摘要可能只有几千token，原始源码要几百万。这不是省钱的问题------是根本塞不塞得进去的问题。

不遗漏角落。 脚本扫描是穷举式的，每个文件、每个目录都会被统计。AI读代码是采样式的------它优先看README和入口文件，然后"推断"其余部分。那些藏在角落里的过期三方库、被提交进仓库的600多MB构建垃圾，AI自己翻，可能一辈子都翻不到。

分析质量暴涨。 你给AI一份清晰的全景数据，它能画出依赖拓扑、识别重复代码、发现安全风险。你让它自己瞎翻源码，它只能跟你说"这个函数可能有问题"。基于结构化数据的分析和基于零散片段的猜测，可信度完全不在一个量级。

实操：从46000个文件到一份审计报告

方法论说完了，来看实操。

我把这个流程做成了一个 Claude Code Skill，最近用它对自己的一个大型C++项目做了完整审计------21个子项目，46000多个源文件，四个技术栈。下面是完整过程。

第一步：高速预扫描

第一步跑预扫描脚本。不需要编译项目，不需要配置构建环境，纯Python零依赖。

bash 复制代码

python scripts/pre-scan.py /path/to/project -d ./scan-output

几秒钟扫完，输出结构化Markdown数据------三分类统计（项目代码/三方库/构建产物各占多大）、目录树、三方库清单、技术栈分布、Git活跃度。

大型monorepo会被自动识别并拆分。我的项目被拆成了21个子项目，每个单独生成一份扫描报告。

第二步：AI逐子项目深度分析

预扫描输出的Markdown，就是喂给AI的"CT片子"。

但AI拿到这份数据后，并不是把所有源文件从头到尾读一遍------那和直接喂源码没区别，token照样爆。它用的是一个三层策略：

文件名推断：先从目录结构和文件名判断每个模块的职责和技术栈，不读内容就能建立全局骨架
关键文件精读：每个模块只挑2-5个关键文件深读------构建配置、核心头文件、入口文件------用最少的token抓住模块本质
质量抽样：针对性地检查线程安全、内存管理、错误处理等维度，不做地毯式扫描

这个策略可以按需调整深度：快速摸底时每个模块只读1-2个文件，深度审计时扩展到5-10个。我这次用的是标准模式------46000个文件里，AI实际精读的可能不到500个，但对每个模块的判断准确度远超穷举式阅读。

分析分两轮：21个子项目先各自独立分析，然后做全局交叉审阅------找跨项目的重复代码、共享依赖、潜在冲突。

第三步：一份HTML报告，全局视图

分析完成后生成一份可交互的本地HTML报告。

打开就是总览页面------21个子项目的卡片，每个展示文件数、体积、技术栈、判决分布。点击可以下钻到子项目详情。

点进其中一个子项目------一个跨平台RTSP播放器------数字就开始让人坐不住了：

自有代码只有3MB，三方库占了596MB。

整个项目里你实际写的代码连总体积的0.5%都不到。剩下99.5%是别人写的。而这些"别人写的"代码，你知道它们是什么版本、有没有已知漏洞吗？

我在46000个文件里发现了什么

扫描完成后，报告里的发现比我预想的触目惊心得多。

基础设施失控增殖

项目的基础库------线程、锁、缓冲、日志、H264解析------被完整复制到了30多个位置。不是引用，是复制粘贴。每份各自演进了好几年，接口已经不一致。编解码层15+份、编码器封装10+份、RTMP基础库12+份------整个项目的基础设施在失控增殖。

AI还自动理清了依赖层级：L0基础层被30+个项目依赖，动它就是动地基；L1协议层是中间件；L2业务层才是最终产品。一个L0层的API变更，可能导致30个项目同时编译不过。

8项严重风险 + 一堆过期依赖

全局风险扫描揪出了8项严重/高危问题------DataBuffer浅拷贝导致double-free、volatile bool全局误用（7+模块）、GPL v2许可证传染、4处硬编码exit(1)、636MB构建垃圾被提交进仓库。这些分散在不同子项目的角落里，靠人肉Review半年都发现不了。

三方依赖方面：FFmpeg还在用 2015年的2.x版本 （avcodec-56），当前主线已到7.x；FreeImage用的是2013年的版本，项目已停止维护；gSOAP生成代码占了467MB。这些库以源码或DLL形式塞在目录里，npm/pip/Gradle统统管不了------你不扫描，根本不知道它们的存在。

四色判决：先删什么，再改什么

发现问题是第一步。关键是给出可执行的判决。

审计对32个模块逐一做出了四级定性：

判决	含义	动作
🟢 核心基石	架构合理，持续维护	保持现状
🟡 提纯合并	存在重复，需要收敛	多份副本合并为一份
🟣 重塑提取	架构有问题	重写或重新设计
🔴 彻底淘汰	已废弃或完全冗余	直接删除

以其中一个跨平台播放器子项目为例：13个模块，7个核心基石不用动、4个提纯合并、1个重塑提取、2个直接淘汰。

这不是拍脑袋------是扫完所有代码之后的数据驱动判断。

拿到判决后，优先行动清单也清楚了：

统一基础库：30+份副本收敛到一份，消除DataBuffer的double-free隐患
升级FFmpeg：从2015年的2.x升级到5.x+，统一Windows/Android版本
排查GPL传染：确认oRTP的GPL v2是否扩散到商业模块
合并SDK封装：多份重复的SDK层整合为统一接口
清理构建垃圾：删除Debug/ipch/obj，释放636MB空间

有了这份清单，再谈重构工期、人力分配、优先级排序，就不是空对空了。

方法论总结：让AI看懂大项目的正确姿势

回到方法论。不管你用什么AI工具、什么编程语言、多大的项目，这三步都适用：

先用脚本穷举扫描------把项目结构数据化：目录、文件、体积、技术栈、三方库、Git活跃度
把结构化数据喂给AI------而不是让它自己翻源码
AI基于结构化数据做深度分析------给出可执行的行动建议

这三步，把AI从"盲人摸象"变成"精准读片"。

本文的扫描和分析流程，我用的是 repo-scan------一个开源的 Claude Code Skill，一条命令完成全流程：预扫描 → AI分析 → HTML报告。Python 3 零依赖，C++/Android/iOS/Web 四大技术栈全覆盖。

如果你也有一个"看不清全貌"的大项目，试试先给它做个CT。

作者：海滨code | 10年+码农，曾任某互联网大厂技术专家。常年专注于原生应用和高性能服务器开发、视频传输和处理技术以及AI个人生产力研究。
公众号：海滨code | 交流请加WX：hbstream（个人主页：https://haibindev.github.io/），转载请注明作者和出处