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

把近5万个源文件喂给AI之前,我先做了一件事 近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零依赖。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.xFreeImage用的是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。