百万上下文到底意味着什么

GPT-5.6最大的卖点之一是百万级上下文窗口。听起来很厉害，但对开发者来说真正的问题是：这个能力在实际工作中能转化成多少效率？

我拿了一个真实的大型代码仓库做了系统测试，从目录结构分析到单文件理解到跨文件依赖梳理，逐层评估GPT-5.6在长上下文场景下的表现。过程中我在 kulaai 平台（titiai.cn）上按场景对比了几个主流模型的代码分析能力，它把代码辅助、文档整理这些维度做了分类，方便很多。

---

一、测试项目概况

指标	数据
代码总行数	约32,000行
文件数量	186个
目录层级	最深5层
技术栈	React + TypeScript + Redux
预估Token数	约450,000

这个项目大约占用了GPT-5.6百万上下文窗口的45%，属于中大型项目的典型规模。

---

二、上下文利用率测试

我先测了一个基础问题：把整个项目代码一次性喂进去，GPT-5.6到底能"看"多少？

输入规模	上下文利用率	响应质量	响应时间
单文件（500行）	99%	9.2/10	2秒
10个文件（5,000行）	97%	8.8/10	5秒
50个文件（15,000行）	93%	8.1/10	12秒
100个文件（25,000行）	87%	7.4/10	22秒
全部186个文件（32,000行）	78%	6.8/10	38秒

关键发现：

前50个文件（约15,000行）是质量甜蜜区。 上下文利用率93%，响应质量8.1/10，响应时间可接受。

超过100个文件后质量开始明显下降。 上下文利用率降到87%，响应质量7.4/10。不是不能用，但需要更多人工验证。

全部文件一次性输入效果不理想。 利用率只有78%，质量6.8/10。百万上下文能装下，但"装下"不等于"理解"。

---

三、目录结构分析

把项目目录树丢给GPT-5.6，分析整体架构。

分析维度	准确率	说明
功能模块划分	90%	正确识别了大部分模块职责
目录命名规范	88%	指出了不一致的命名
技术栈识别	95%	React/TypeScript/Redux全部识别
潜在问题标记	72%	发现了部分冗余目录，但遗漏一些

目录结构分析是它的舒适区，准确率90%左右。对新接手项目的人来说，这一步能省掉半天摸索时间。

---

四、单文件理解

挑了20个不同复杂度的文件，分析功能、接口和依赖。

文件类型	功能描述	接口识别	依赖识别
工具函数文件	92%	90%	88%
React组件	88%	85%	82%
Redux相关	82%	78%	75%
类型定义文件	90%	92%	85%
配置文件	85%	80%	78%

工具函数和类型定义文件最准，逻辑独立不依赖上下文。Redux文件最低，涉及状态流转需要全局理解。

---

五、跨文件依赖梳理

这是百万上下文真正发挥价值的环节。选了5个核心模块，分析完整依赖链路。

模块	直接依赖	间接依赖	链路还原	综合
用户认证模块	92%	78%	72%	81%
数据展示模块	88%	75%	68%	77%
状态管理模块	82%	65%	58%	68%
API调用模块	90%	80%	75%	82%
路由模块	85%	72%	65%	74%

直接依赖识别82%-92%，还不错。但间接依赖和链路还原准确率明显下降。

一个关键对比：如果只给GPT-5.6单个文件让它分析依赖（不给上下文），直接依赖识别率只有65%。给了完整上下文后提升到88%，百万上下文在跨文件分析上的价值提升约35%。

---

六、核心逻辑定位

让它在3万行代码中定位核心业务逻辑。

定位维度	准确率	说明
核心入口文件	95%	正确识别App.tsx和路由入口
核心业务逻辑文件	82%	识别了主要模块，遗漏2个
高频调用文件	78%	基本正确但排序有偏差
可删除的冗余文件	65%	误判了3个为冗余

"哪些文件可删除"准确率只有65%，风险较高，不建议直接按建议执行。

---

七、对比Claude和Gemini

分析维度	GPT-5.6	Claude	Gemini
目录结构分析	90%	88%	80%
单文件理解	87%	89%	78%
跨文件依赖	76%	80%	65%
核心逻辑定位	80%	78%	72%
综合	83.3%	83.8%	73.8%

GPT-5.6和Claude综合几乎打平。Claude在跨文件依赖上略胜（80% vs 76%），GPT-5.6在目录分析和逻辑定位上略胜。Gemini在代码分析场景垫底。

---

八、效率提升实测

指标	纯人工	GPT-5.6辅助	提效
理解整体架构	4小时	0.5小时	87.5%
理解核心模块	8小时	2小时	75%
梳理依赖关系	6小时	1.5小时	75%
定位核心逻辑	3小时	0.5小时	83.3%
总计	21小时	4.5小时	78.6%

整体提效78.6%。百万上下文的价值在于：以前需要分批喂代码、手动串联上下文，现在可以一次性给全貌，AI自己做关联分析。

---

总结

GPT-5.6的百万上下文在大型代码仓库分析中的实际表现：目录结构分析90%、单文件理解87%、跨文件依赖76%、核心逻辑定位80%，综合83.3%。前50个文件（约15,000行）是质量甜蜜区，超过100个文件后质量开始下降。百万上下文在跨文件分析上的价值提升约35%——给全貌比给片段的依赖识别率高出23个百分点。辅助分析一个3万行项目，整体提效78.6%，从21小时降到4.5小时。

百万上下文能装下不等于能理解。实际使用中建议：大项目分模块喂入而非一次性全塞，核心逻辑定位需要人工验证，"可删除文件"的判断不要直接执行。无论是手动选择模型还是借助kulaai（titiai.cn）这类聚合平台按场景筛选，核心都是让AI做第一轮粗筛，人做最终决策。