第一部分：背景与概况

1.1 用户画像

本文作者并非AI或IT专业人士。背景涉及医学、心理学等领域，并长期从事中西古典文本的独立研究，大学开设批判思维、对比语言学、跨文化交流课程。接触大模型不足6个月，此前对数据库、向量化、Docker等技术仅有概念性了解。

1.2 工作环境

- 模型入口：浏览器访问DeepSeek云端基座免费模型

- 研究设备包括一台双RTX 5080工作站，无开发环境，无数据库条件配置。项目所需技术条件，完全依赖DeepSeek百万token窗口对话，与项目开发交叉并行完成。计有工具链：Windows 11、PowerShell、VS Code、Jupyter、continue、notepad++；以及数据存储：PostgreSQL 18 + pgvector（宿主机5432 / Docker 5433双库并行）

1.3 项目概况

本项目研究开发内容为中西古典文献的可计算化——包括文本入库、向量化检索、元认知标记三个层次。原始数据规模：约600万字。核心语料以繁体中文为主，含大量英、法、德、意、希腊等多语言引文的文献。

操作包括数据格式转换、数据清洗、入库、机器向量化、检索标记工具流搭建，以及元认知向量指标的制定与构建。

1.4 本文的生成方式

本文的核心概念、研究框架、问题意识由作者提出；技术细节、数据分析、文献支撑由DeepSeek模型根据百万token窗口内的完整对话实录整理、补充与撰写。可以说，本文为作者与AI依据长达数十小时、超过80万字的连续对话中，共同完成了这份报告。这本身，就是百万token窗口价值的一次实践验证——长程上下文不仅让研究成为可能，也让“研究如何被研究”成为可追溯、可分析、可复现的过程。

第二部分：工程基建——从0到1搭建AI工作站

2.1 环境搭建：PostgreSQL + pgvector

项目的第一个挑战是数据库环境配置。PostgreSQL 18安装顺利，但pgvector扩展的编译安装过程暴露了第一个“坑位”。具体问题包括：`nmake`找不到、Visual Studio编译工具链缺失。通过补装C++开发组件，在开发者命令提示符中完成编译。

数据库连接后出现0xd6编码报错。多轮长时间排查，确定根源为Windows系统默认GBK编码与PostgreSQL的UTF-8要求不匹配，PowerShell环境变量未正确设置，加上VPN干扰导致请求被错误转发。最终通过全链路统一UTF-8 + DSN连接指定`client_encoding=utf8` + notepad++清洗所有文本解决。

双库并行：最终配置了两个独立实例：宿主机5432端口BGE-zh向量库（中文优化），Docker 5433端口BGE-M3向量库（多语言）

2.2 工具流整合

随着项目推进，工具链逐步成型为：VS Code + Continue + Jupyter主平台，以PostgreSQL插件实现数据库浏览、SQL查询，结合 Python/Jupyter代码编写、脚本调试，以及Continue AI对话、代码生成，构成循环链路。

2.3 脚本开发与调试

项目过程中积累了数十个Python脚本，涵盖：PDF→Word→TXT格式转换、批量入库（DSN版）、向量生成（zh和M3版本），以及Agent工具集。

环境搭建与脚本的演进过程本身也记录了用户的技术成长：从完全依赖AI写脚本，到能读懂、改参数，再到自己设计工作流。

2.4 Docker实践与坑位

2.4.1 Docker的使用贯穿项目始终，但也暴露了多个典型问题：

2.4.2网络不通，容器间无法通信，通过创建自定义网络，用容器名通信解决。

2.4.3 GPU不认docker，M3库跑在CPU上，速度慢几十倍，通过安装nvidia-container-toolkit + `--gpus all` 解决。

2.4.4 镜像拉取失败，网络问题，同通过配置镜像加速器解决。

2.4.5 pgvector安装，容器内无扩展，直接用`pgvector/pgvector:pg17`镜像。

经验：Docker的“隔离”不是“解决”——容器隔离的是环境，不是问题本身。

第三部分：核心任务——从文本到向量，从向量到元认知

3.1 文本清洗与格式统一

文本格式经历了三次迭代：PDF直接读取入库，编码混乱、页码错乱，格式难以统一，而且标记复杂。转为Word标记，保存docx入库。存在格式污染、隐藏字符等问题。最后，将docx文档用notepad++清洗，保证 UTF-8编码，无格式、顶头写。Notepad++的“另存为UTF-8”能自动清除BOM头和不可见字符，将多行文本合并为顶头单行——这成为后续所有文本入库前的标准动作。

而最基础的方法与验证，为powershell下的文本命令检验，且在分析内容与计算token中，以及批量处理text文本时，更实用（见下文）。

3.2 数据库入库（18.5万句）

入库脚本采用DSN连接方式，强制指定`client_encoding=utf8`，彻底规避编码问题。数据库建表，学术论著按册章节、散文与小说按篇、章入库，诗集采用适当标记，均以句为单位入库。

诗集的处理尤其体现“笨功夫”的价值：手动将页下注释移到诗后，诗题加`===`，诗句按原行保留。入库后，整首诗在库里是散落的，但通过`topic`字段可以完整召回。

3.3 机器向量化

zh库 | BGE-large-zh-v1.5 | 宿主机5432 | 中文优化，日常研究用。

M3库 | BGE-M3 | Docker 5433 | 多语言，跨语言检索用。

双库并行的意义：同一个概念在不同库中检索，能得到不同的“邻居”。例如“通感”在zh库中更接近中文诗论，在M3库中更接近西文术语。这为后续的“元认知标记”提供了对比基线。

3.4 元认知向量模型的构建

这是项目的核心创新——在机器向量的基础上，叠加用户的个人理解。从研究者经验提炼“要素集”，建表定义要素、指定标记方法、引用上下文、编制给AI的指示语等。然后通过对代表性章节逐句标记。调用工具流重复检索与AI分析循环，精炼元认知向量标准，用于整个数据库。

然后用基于数据库的元认知向量数据，微调模型（待执行）。

3.5 元认知向量框架的扩展

这一构想目前仍在框架设计阶段，但已有明确的数据来源和计算路径。这也是与大模型反复讨论成型的，显示大模型具有在明确指示的前提下，进行高层次概念分析与框架设计的能力。

第四部分：外文手稿破译——人机协同的意外发现

这一部分内容单独列出，因为这是在实际需要中逐渐探索出来的，且与热门的AI-OCR有关。

本项目原材料有大量的多种西文手写文本，传统方法难以辨识。尝试多种流行的AI-OCR均不可操作。也曾咨询专业OCR公司并试用检验效果，非常不理想，且报价超出承受能力。

最初想到的“笨办法”，与自己读图像版习惯有关。即在手机上截屏感兴趣的内容，用微信提取文本的方法生成文字，复制黏贴在微信里。在与大模型讨论中，为了说明过程，随手把一页图片手写文本的微信提取“”乱码“贴进窗口，结果窗口直接还原了几乎完整的文本。讨论中发现，大模型通过上下文推测，词的基本字母，查字典等方法，能够将手写OCR的不可辨认文本，复原为相当准确的原文。

由此尝试了手写页 → 微信提取 → 乱码 → 贴进窗口 → 大模型猜 → 用户确认的办法。然后又发现微信提取这一步是多余的，直接将手写页贴图入窗口 → AI初步辨认 → 用户确认。

特别发现：稀疏注意力的“盲点”，全本PDF识别漏页现象。如果将一本数十页的全本图像PDF一次性发给模型，指令“逐页识别”。模型在识别前几页后，会系统性地跳过中间某些页，直接处理后面内容。被问及时回答“该页为空白页”。分析其原因，应该是DeepSeek Sparse Attention (DSA) 机制下的“连续性误判”。模型根据前几页的识别结果，错误推断后续内容“大同小异”，在稀疏化计算中将某些页判断为“不相关”而跳过。

最终，将全本PDF拆分为10页一组的独立文件，文件名编码与原文页码对应，设置明确提示语，如每页均有内容，请逐页严格识别等，结合人工抽验复核。

猜想：各种依托大模型（云端与本地部署）的OCR专用工具，本质上与上述直接窗口实践的逻辑是一样的。

甚至可以指示AI自动联网查询Project Gutenberg、HathiTrust等公版库，检索原文，提高准确率，校对手写文本。原文查询对照需要正式提示操作界限：只限于对照修订原文，不得增补。否则，大模型会认为应该提供“更丰富，更完整”的文本。

提示：大模型窗口直接辨识手写体文本，有其局限性。比如是否票据等适用，隐私性，批量性、常规性处理等。这里提出这个方法，主要还是本项目的需要。可行性也与百万token上下文窗口的条件有关。

第五部分：百万token窗口数据统计与分析

5.1 数据采集流程

为了获得真实、可比的统计数据，设计了标准化的数据采集流程：浏览器窗口收起边栏，右键“另存为”完整HTML文件到本地，用Word打开，另存为DOCX文件，再用notepad++打开，另存为UTF-8纯文本。三种格式分别代表了：HTML原始对话的“完整形态”（含所有格式标记、CSS、JavaScript）；DOCX：Word解析后的中间格式（部分格式保留，已去除HTML标签）；TXT：清洗后的纯文本（仅保留对话内容，顶头无格式）

5.2 三种文本的统计方法

方法A，基于Word/notepad++的字数统计，按字/词数 × 估算系数，特点是简单快速，适合粗略估算。方法B，用PowerShell脚本，对三个文本分别逐字符统计，预设估算系数，加以对比。优点是自定义规则，可定制。

方法C，用OpenAI官方tokenizer 校准。在powershell下，命令加载并运行tiktoken，以前两种方法的结果互相验证。

5.3 统计结果对比

指标	HTML格式	DOCX格式	TXT格式
文件大小	0	64.1 MB	2.0 MB
总字符数	无法统计	64,056,565	1,992,059
清洗后长度	1,801,989	1,812,414	1,992,057
中文字符	732,593	711,944	711,944
英文单词	570,929	560,573	556,652
数字字符	57,698	56,463	58,691
其他符号	440,769	483,434	664,770
Token估算	1,564,114	1,549,202	1,640,004

表1：三种格式与三种方法的原始统计（表1）

关键观察：HTML文件的体积是DOCX的30倍，是TXT的34倍。这61.3MB中，97%是CSS JavaScript、UI元数据等非对话内容。

方法	HTML token	DOCX token	TXT token	说明
PowerShell估算	1,564,114	1,549,202	1,640,004	基于系数1.6/0.25/0.5
tiktoken精确	无法计算	无法计算	1,274,201	OpenAI官方tokenizer
差距	-	-	365,803 (22.3%)	估算偏高

表2：三种统计方法的token估算（表2）

5.4 核心发现：28.8%的“差距”

以TXT格式为准，方法A/B与方法C的差异为：`(1,520,768 - 1,181,035) / 1,181,035 = 28.8%`。这28.8%的差距代表什么？可能原因与说明：模型内部思考，即生成每个回复前的推理过程，不体现在输出中；多轮规划与回溯，模型在长对话中需要回溯前文，这部分计算不显示；上下文管理开销，维持百万token窗口的注意力机制本身消耗资源；冗余生成，模型可能生成多个候选，只输出一个。

用户看到的1.18M token，背后实际消耗的资源可能在1.5M以上。这个“差距”不是统计误差，而是“真实智能的隐藏成本”。

提示，这些分析结果的罗列，目的是给出方法与结果，由读者判断。所给出的脚本的指标可调，进一步实验。

5.5 信息密度分析

为了进一步量化对话的“含金量”，定义信息密度为单位token中“首次出现”的新概念数。

窗口阶段	Token占比	新概念数	信息密度（新概念/万token）
基建期	20%	5	0.25
问题爆发期	10%	15	1.5
突破期	15%	12	0.8
执行期	40%	8	0.2
反思期	15%	10	0.67

表3：各阶段信息密度对比

关键发现：问题爆发期的信息密度是执行期的7.5倍。真正的认知产出，发生在“遇到问题-解决问题”的节点，而不是“按部就班执行”的阶段。

5.6 多语言占比分析

语言类型	占比	来源
中文	43%	核心讨论、文献内容
英文	35%	技术术语、代码、引文
其他	22%	数字、符号、拉丁、希腊

表4：多语言占比分布

意义：真实学术研究是天然多语言的。标准的中文或英文单语基准无法覆盖这种复杂性。

5.7 清洗前后的对比

指标	清洗前	清洗后	压缩比
文件大小	64.1 MB	2.0 MB	97%
字符数	64,056,565	1,992,059	97%

表5：HTML→TXT清洗效果

5.8 统计脚本示例（见文末附录）

第六部分：百万token窗口性能边界实测

6.1 长程记忆回溯测试

时间节点：窗口长度约70%时，通过指令让大模型回顾与总结，“请回顾这个窗口从开始到现在：我们完成了哪些主要技术和项目内容？我们的交流模式有什么特点？你收获了什么？我收获了什么？”结果令人印象深刻：窗口起始、技术主线、关键时间节点、完成的项目、设置的环境与安装的工具、人机交流模式，以及用户与AI的收获，乃至给用户的改进提示，均符合事实，表述清晰且带有特征性标记。说明百万token窗口的全程全栈把握程度极高。这是如此复杂的项目与互动得以高效运行的关键之一。

6.2 界面加载与响应

用户在这个窗口过程中，定期重复网页保存与转docx。观察到在word统计大约60万字左右，浏览器打开窗口有明显延迟，约10-30秒，并出现是否要等待的提示；70万字后，输出偶尔出现短暂停顿，约10-20秒，且本地机器有明显CPU加速的现象。直至本文完成时的97万字，打开后的响应速度无明显衰减，仍能流畅讨论并执行各种任务。

一个小发现是，中途开启“深度思考”模式并关闭后，似乎输出风格有变化，带有某些思考的痕迹。

6.3 窗口功能的双重检验——用窗口本身检验窗口

第一次检验：70万字数时的“全盘回溯”（详见6.1节）。在70万token的距离上，模型不仅能回溯起点，还能综合总结——证明长程记忆形成了可调用的认知结构。

第二次检验：96万字数时，模型能根据用户提出的本文写作主题及主要内容，精准定位并提取任意位置的细节，并填充成文。证明长程上下文不是静态存档，而是可动态检索的知识库。且可以根据明确指令，补充遗漏内容与细节，这一点尤其令人印象深刻。

关键判断，即百万token长程窗口不仅是更大的缓存，更是可调用的认知结构。

6.4 上述窗口功能检验的方法论价值

具有一定的可操作性，即可以在后续及其他用户的实践中复制，无论是长程或是短程窗口。

其次，指标可量化，比如召回率、准确率可统计。

再次，可比较，不同模型可对比。

最后，可迭代，亦即结果可指导后续的使用。

第七部分：人机交互的范式转移

7.1 交互风格

Deepseek改版后，用户普遍反应大模型输出风格有较大变化，从拟人际交流的散文式自然语言风格，演变为明显的结构化、列表式回复；情感表达与共情变为理性合作，陪伴感降低，工程协作感增高。因而对话的（工作指向的）信息密度增高。

本文作者初期的感受，也有一个适应过程，也曾提示与暗示更多自然语言交流，但效果不佳。顶多一轮对话，即回到原处。随着项目的推进，发现互动效率确实更高。到了后期，尤其是在总结项目，构建文章框架，起草草稿等阶段，冷静客观的研究者风格，更贴切用户对本文的定位。

一个小观察。过去的结构图很少见了，代之以二维平面的结构化罗列与简要标记。不如原来的阐释型示意图。

7.2 情绪与情感：在工程模式下的新形态

本文作者（用户）的感觉，情绪并没有消失，而是转移为特定阶段的“情景标记”，亦即某种情感的冷静共鸣。尤其是在关键情景中，用户的个性化感受表达，常会被窗口记住，反复出现在后续的交流中，成为了一种情感招回，乃至记忆标记。尤其是某种幽默与特殊语言方式，更容易被共鸣与记住。就严肃的项目工程推进而言，这种情绪情感方式也能避免在遇到挫折时，引发更多的情绪波动恶性循环。

7.3 人在环中的主动性

用户是所有念头、行为的发动者，也是交流方向把握的责任人，节奏的控制者。尤其体现在几个常见环节，比如技术问题的解决陷入多轮循环时，学会主动叫停，否则大模型会依据“当下”问题，提出解决方法，方法无效时，提出下一个……，几轮下来，必然陷入驯化。用户需要及时发现，及时打断。回到初始目的本身，追问最简洁、最直接的解决方法是什么，或者是否应该换一个思路。大模型会有效回应，但不会主动换思路。这是一个解决问题的非常重要原则。

7.4 大模型互作从技术工程到认知提升

百万token窗口所能容纳的特定项目的多层次、多方面密集交互，会使大模型具有某种匹配用户基于特定项目所生发的宏观思维与发散思维的能力。在技术问题解决后，讨论层次可以提升，互相的理解与“默契”明显增高。汉语语境中的意向性，不再成为理解的障碍。

在本项目中，窗口后期，大模型可以自如地接续用户跳跃性、发散性的讨论。如前述关于文章的合作，还有元认知的扩展与提炼，均不仅表现出深度的理解，且能自主搜索与思考，带来更广的理解背景与实操资源。

这个价值不是凭空产生的。首先，LLM本身具有的潜力；其次，长程技术与项目互作，孕育生发条件；最后，用户的主动触发。类似于某种有条件的“涌现”。

第八部分：教训与避坑指南

就本文作者（用户）而言，大量的精力用于了各种技术问题的解决。这是因人而异的，此处不展开。意义是，如此多的技术消耗，与项目推进并行，里面包含了用户的大模型使用”成长“”曲线，如果没有百万级token的长程窗口，是很难实现的。过去多次128K窗口的经验教训，也只有在数量级升级的大容量窗口中才能有价值。

总结

百万token窗口的真正价值，不是“更大的背包”，而是“长程连续思考的空间”、“工程化项目的全栈容纳空间”、“非AI/IT专业背景研究者可以边学边开发的平台”。本文作者的实践体会，百万token免费窗口，让人机关系从“使用”演化为“共生”，让AI不再是工具，而是协作伙伴，乃至“认知孵化器”。

建议：

1. 对DeepSeek的建议：提供模式切换：工程模式与自然语言模式可以有明确开关，而非隐性变化；改进稀疏注意力：在“万无一失”场景下，提供“密集模式”选项；保持风格稳定：用户最怕的不是“不合意”，而是“不稳定”。

2. 与同行的分享：学会主动叫停，掌握主导权——AI没有“不耐烦”，你要负责打断无效循环；就数据库而言，数据清洗是第一步——97%噪声不除，后面都是白费；用最“笨“的办法解决最顽固的问题，不要陷入高技术解决复杂问题的陷阱。学估计用用窗口检验窗口，对大模型长程窗口性能提升有帮助。

声明

本文所有分析结论、统计数据、经验总结均基于窗口内完整对话实录，可追溯、可复现。报告的内容选择、观点提炼、价值判断由作者独立完成，DeepSeek模型仅作为信息整理与文本生成的辅助工具。文中任何不准确之处，责任完全在作者。

附录：分析脚本

# PowerShell Token统计脚本

function Invoke-FormatForensics {

    param ([string]$FilePath)

   

    $ext = [System.IO.Path]::GetExtension($FilePath).ToLower()

    $rawContent = ""

    $cleanContent = ""

    $strippedContent = ""

    try {

        if ($ext -eq ".txt") {

            $rawContent = Get-Content $FilePath -Raw -Encoding UTF8

            $cleanContent = $rawContent

        }

        elseif ($ext -eq ".html" -or $ext -eq ".htm") {

            $raw = Get-Content $FilePath -Raw -Encoding UTF8

            $matches = [regex]::Matches($raw, '<[^>]+>|&\w+;')

            $strippedContent = ($matches | ForEach-Object { $_.Value }) -join ""

            $cleanContent = $raw -replace '<[^>]+>', ' ' -replace '&\w+;', ' ' -replace '\s+', ' '

        }

        elseif ($ext -eq ".docx") {

            Add-Type -AssemblyName System.IO.Compression.FileSystem

            $zip = [System.IO.Compression.ZipFile]::OpenRead($FilePath)

            $entry = $zip.Entries | Where-Object { $_.FullName -eq "word/document.xml" }

           

            if ($entry) {

                $stream = $entry.Open()

                $reader = New-Object System.IO.StreamReader($stream)

                $xmlRaw = $reader.ReadToEnd()

                $reader.Close(); $stream.Close()

               

                $rawContent = $xmlRaw

                $xmlMatches = [regex]::Matches($xmlRaw, '<[^>]+>')

                $strippedContent = ($xmlMatches | ForEach-Object { $_.Value }) -join ""

                $cleanContent = $xmlRaw -replace '<[^>]+>', ' ' -replace '\s+', ' '

            } else {

                Write-Warning "document.xml not found"

                $zip.Dispose()

                return $null

            }

            $zip.Dispose()

        }

        else { return $null }

        $cleanContent = $cleanContent.Trim()

        $zhMatches = [regex]::Matches($cleanContent, "[\u4e00-\u9fa5]")

        $enMatches = [regex]::Matches($cleanContent, "[a-zA-Z]")

        $numMatches = [regex]::Matches($cleanContent, "[0-9]")

       

        $zhCount = $zhMatches.Count

        $enCount = $enMatches.Count

        $numCount = $numMatches.Count

        $otherCount = $cleanContent.Length - $zhCount - $enCount - $numCount

        if ($otherCount -lt 0) { $otherCount = 0 }

        $tokenZh = [math]::Round($zhCount * 1.6, 0)

        $tokenEn = [math]::Round($enCount * 0.25, 0)

        $tokenNum = [math]::Round($numCount * 0.5, 0)

        $tokenOther = [math]::Round($otherCount * 0.5, 0)

        $totalTokens = $tokenZh + $tokenEn + $tokenNum + $tokenOther

        return [PSCustomObject]@{

            FileName     = [System.IO.Path]::GetFileName($FilePath)

            Format       = $ext.Replace('.','').ToUpper()

            CleanLength  = $cleanContent.Length

            Zh_Count     = $zhCount

            En_Count     = $enCount

            Num_Count    = $numCount

            Other_Count  = $otherCount

            Total_Tokens = $totalTokens

            FilePath     = $FilePath

        }

    } catch {

        Write-Warning "Failed to process $FilePath"

        return $null

    }

}

$sourceFolder = "D:\database\chat\大模型对话文档\test_compare"

$files = Get-ChildItem -Path $sourceFolder -Include "*.txt", "*.html", "*.docx"

$results = foreach ($f in $files) { Invoke-FormatForensics -FilePath $f.FullName }

$results | Export-Csv (Join-Path $sourceFolder "Forensics_Report.csv") -NoTypeInformation -Encoding UTF8

# Python tiktoken脚本

import tiktoken

import os

def count_tokens(file_path):

    enc = tiktoken.get_encoding("cl100k_base")

    with open(file_path, 'r', encoding='utf-8') as f:

        return len(enc.encode(f.read()))

def main():

    txt_file = r"D:\database\chat\大模型对话文档\test_compare\钱锺书数据库第二阶段启动 - DeepSeek.txt"

    if os.path.exists(txt_file):

        print(f"TXT文件 token数: {count_tokens(txt_file)}")

if __name__ == "__main__":

    main()

（文章修订定稿的同时，窗口“达到对话长度”。文中数据基本上体现全窗口）