claude code 处理大型 JSON 文件时的分片策略

这件事我在三个真实项目里反复踩过坑，而且最近一次就是在给一个电商系统做订单日志重构时，面对一个 3.2GB 的 JSON 导出文件。当时我盯着终端里卡死的 Claude Code 会话，脑子里只有一个念头：分片策略不是省 Token 的技巧，它是决定你能不能活着走出这个任务的生存问题。

但真正让我决定写这篇文章的，不是那次卡死，而是后来我跟几个同行聊起这个话题时，发现绝大多数人对“分片”的理解还停留在“把大文件切成小文件”这个层面。他们会用 Python 写一个按行数分割的脚本，然后依次喂给 Claude Code，然后继续卡死，然后怀疑 AI 能力不行。

问题不出在 Claude Code，出在分片的逻辑不对。

这篇文章不是给你一个万能脚本让你复制粘贴。我会把我过去一年多里，在日志分析、数据迁移、配置文件重构三个场景中反复试错总结出来的分片决策逻辑写清楚。你会看到我失败过的方案、为什么失败、以及最终什么样的策略真的跑通了。

读完这篇文章，你能带走的不是一段代码，而是一个判断框架：当你在 Claude Code 里面对一个打不开的 JSON 文件时，你能在 30 秒内决定该怎么切。

一、先告诉你核心结论：分片策略的本质不是切文件，是切上下文窗口

我在第一次处理大型 JSON 文件失败之后，花了整整一个下午做了一件很笨的事：我把同一个 500MB 的日志文件，用五种不同的分片方式喂给 Claude Code，然后记录每一次的 Token 消耗、分析完整度、以及我本人需要人工修正的次数。

结论非常反常识：

按文件大小均匀切片的方案，Token 总消耗比按逻辑 Key 切片高出 47%，人工修正次数多出 3 倍。

为什么会这样？因为均匀切片会制造大量“断裂的上下文”。Claude Code 在处理每一片时，都会试图理解这片数据在整个文件中的位置和意义。如果它看到的是一个被拦腰切断的嵌套对象、一个只出现了一半的数组、一个被分到两片里的日志记录，它会把大量的 Token 浪费在“猜测缺失部分”上。

而如果你按业务逻辑切片，比如一个订单对象完整地放在一片里，一个用户的行为序列完整地放在一片里，Claude Code 的处理效率会大幅提升。每片的上下文是闭合的，它不需要猜测，它的分析是准确的。

所以，分片策略的核心问题是：你如何让 Claude Code 在处理每一片数据时，不需要依赖这片之外的上下文就能做出准确的判断。

把这个原则记住，后面所有的决策树都长在这条根上。

二、什么场景下你真的需要分片

不是所有大文件都需要分片。你需要先做一个判断，否则你会陷入“过度设计”的陷阱。

我见过一个开发者在处理 800KB 的 JSON 配置文件时就开始写分片脚本，这就属于浪费生命。Claude Code 目前的上下文窗口足以处理这个量级的数据，你直接扔进去就行。

触发分片的真实阈值是什么？

根据我自己的使用经验，以下三个信号只要出现任何一个，就应该启动分片策略：

信号一：单次粘贴后 Claude Code 的回复出现“截断”或“遗忘”。 这是最直接的信号。你粘贴了一个 JSON 片段，Claude Code 回复的内容明显没有覆盖你提到的所有要求，或者它在分析过程中突然开始重复已经说过的内容。这说明单次输入已经触达了上下文利用率的瓶颈，不是它不想帮你，是它“装不下”了。

信号二：文件行数超过 8000 行，且结构深度超过 4 层。 这是一个经验阈值。我处理过的 JSON 文件中，行数低于 8000 且嵌套深度不超过 4 层的，通常可以直接处理。但如果嵌套很深，每一层都携带大量元数据，即使总行数不高，Token 消耗也会急剧膨胀。嵌套深度是比文件大小更危险的指标。

信号三：你需要对文件做两种以上不同类型的分析操作。 比如你既要对订单数据做汇总统计，又要对用户信息做隐私脱敏。如果一次性把整个文件扔给 Claude Code 并要求两个任务，大概率两个都做不好。这种情况下即使文件不大，也应该按任务类型拆分处理。

这三个信号我建议你存下来，每次打开一个 JSON 文件之前先花 10 秒问自己这三个问题。这 10 秒能帮你省下后续几个小时的无效调试。

三、一个你在网上搜不到的认知：分片之前，先用“摘要片”破冰

这是我自己摸索出来的一个工作流程，到目前为止我还没在任何技术博客里看到有人系统性地讲过。

在我决定如何分片之前，我会先让 Claude Code 帮我生成这个文件的“结构摘要”。

具体做法是：我不会直接粘贴整个文件，而是先用一个 Python 脚本提取文件的“骨架”，只保留每一层的前几个 key，把 value 替换成类型标记，把数组截断到前 3 个元素。这样生成一个大概 200-500 行的“摘要 JSON”，直接喂给 Claude Code。

我的 Prompt 是这样的：

> “这是某个大型 JSON 文件的结构摘要。不要尝试分析具体内容，只告诉我：这个文件的顶层结构是什么？有哪些关键的嵌套路径？如果你需要对这个文件执行 [你的具体任务]，你会建议按什么方式分片？理由是什么？”

这一步的价值超出大多数人的预期。Claude Code 在拿到结构摘要之后给出的分片建议，往往比我凭直觉做的判断更合理。因为它是基于这个文件的真实结构来推理的，而我的直觉可能被文件名或业务逻辑误导。

比如有一次，我在处理一个从 MongoDB 导出的用户行为日志文件。我本来打算按 user_id 的哈希值分片，觉得这样最均匀。但 Claude Code 看了结构摘要后指出：这个文件里 80% 的数据集中在前 200 个用户身上，按哈希分片会导致某些片数据量是其他片的 20 倍。它建议我按时间戳的自然日来分片，这样每片的数据量相对均匀，而且时间边界清晰，汇总时不容易出错。

这个“先摘要后分片”的步骤，把我整个项目的处理时间从预估的 3 天压缩到了 6 个小时。

四、分片决策树：三种任务类型，三种分片逻辑

我把我在 Claude Code 里处理 JSON 文件的任务分成了三大类。每一类的分片逻辑完全不同，选错了就会事倍功半。

4.1 类型一：批量清洗与转换任务

这类任务的特征是：你要对 JSON 文件里的数据做统一的操作，比如脱敏所有手机号、把日期格式从 ISO 8601 转成年月日、给所有订单记录添加一个计算字段。操作逻辑对所有数据记录是一致的，不需要跨记录推理。

错误的分片方式：按文件大小均分，或按记录数的固定值均分。

这个错误我犯过。当时我在处理一个 12 万条订单记录的 JSON 文件，我要做的是把所有订单的金额单位从“分”转成“元”。我写了个脚本，按每 5000 条记录切一片，总共切了 24 片。

然后我发现，每一片 Claude Code 都要“重新学习”一遍这个转换规则。它会在前 5000 条里问“所以你是要把 amount 字段除以 100 对吧”，我确认。到下一片它又问“这个数值转换的逻辑跟之前一致吗”，我再确认。24 片下来，这种确认对话重复了至少 18 次。大量的 Token 浪费在规则重申上。

正确的分片方式：只分一片样本，让 Claude Code 生成转换脚本，然后用脚本处理全量文件。

具体操作：

1. 从大文件里提取前 50-100 条完整记录作为样本片。
2. 把样本片喂给 Claude Code，让它理解数据结构和转换需求。
3. 让它输出一个 Python/JavaScript 转换脚本。
4. 你在本地运行这个脚本处理全量文件。
5. 处理完后，再提取一个验证样本片，让 Claude Code 确认转换正确。

这样做的好处是：Claude Code 只负责“理解规则”和“生成脚本”，不负责“逐行处理数据”。前者是它的强项，后者是你的本地计算资源就能做的事，不需要占用 Token。

我在那次订单金额转换的任务中，切换到这种方式后，整个任务的 Token 消耗从预估的 80 万压缩到了不到 3 万，处理时间从半天变成了 20 分钟。

4.2 类型二：模式挖掘与分析任务

这类任务的特征是：你要从 JSON 数据中发现规律、异常、趋势。比如分析一周内的用户行为是否有异常波动、找出日志中出现频率突然增加的错误码、对比两个时间段的数据分布变化。

这种任务的核心难点在于：单看一片数据可能看不出问题，必须跨片对比才能发现异常。

这是我目前遇到的最复杂的分片场景，我试了四种方案才找到可行的路径。

第一步：摘要是必须的。 回到第三节的方法，先让 Claude Code 看结构摘要，确认哪些字段是用来做分析维度的。时间戳、错误码、用户 ID、金额区间，这些字段决定了分片的边界。

第二步：按分析维度分片，不是按数据量分片。 如果任务是要分析每日的用户活跃度变化，就按自然日分片。如果任务是要分析不同错误码的分布，就按错误码分组，把同类错误码的记录归到一片里。分片的单位是“分析单元”，不是“数据块”。

第三步：每一片的分析必须带着“相邻片的关键数据”一起喂进去。 这是我踩了无数次坑之后总结出来的最关键的一步。

具体做法是：在给 Claude Code 第二个分片时，我不会只说“这是第二天的数据”，我会额外附上第一天分析结果中的两到三个关键数字。比如：

> “这是 6 月 20 日的用户行为日志。前一日的分析结果显示：活跃用户 3.2 万、平均会话时长 4.7 分钟、支付转化率 12.3%。请分析当日数据，并与前一日对比，标注出任何偏离超过 20% 的指标。”

这样，Claude Code 在处理当前片时就有了一个“锚点”，它不需要记住前一片的全部内容，只需要知道几个关键值就能做出有意义的对比分析。

第四步：汇总时必须让人工做一次“异常复核”。 Claude Code 在跨片汇总时，有时会把两片之间的正常波动判断为异常，或者把真正的结构性变化忽略掉。我发现最有效的做法是：让 Claude Code 生成一个“异常指标列表”，标注每个异常的数据来源、偏离幅度、可能的原因，然后我花 10 分钟逐条复核。这个环节不能跳过。

4.3 类型三：审查与编辑任务

这类任务的特征是：你或你的团队需要人工阅读 JSON 中的某些部分，做出判断，然后修改。比如代码审查场景下的配置文件检查、数据合规审查、API 接口定义的变更评审。

这类任务的特殊之处在于：人需要在决策闭环里，Claude Code 的角色是辅助审查和起草修改，不能全自动执行。

分片策略：按“审查单元”切分，不是按数据量切分。

一个审查单元是指：你认为一个人在一次审查会话中能处理的、逻辑上闭环的最小数据单元。比如一个微服务的完整配置块、一个 API 端点定义及其所有关联的 schema、一个用户的数据主体及其关联的所有记录。

关键操作：每一片都要附带一个“审查清单”。

这个清单是你在分片之前就定义好的检查项，比如：

• 所有必填字段是否存在
• 敏感字段是否正确脱敏
• 数值范围是否在合理区间
• 日期格式是否统一

把审查清单放在每一片数据的前面，Claude Code 会逐项检查并输出结果。人在看结果时，只需要关注“检查未通过”的条目，大幅降低阅读负担。

我在地产 SaaS 系统的一次配置文件迁移中用到了这个策略。那个配置文件有 1.1 万行，跨 37 个微服务。如果人工逐行审查，保守估计要两个工作日。我用了“审查单元分片 + 审查清单”的方式，2.5 小时完成了全量检查，发现了 4 个隐藏的配置错误，其中一个是生产环境一直没有暴露出来的定时炸弹。

五、写分片脚本不是写代码，是写“上下文闭环”

当你决定好分片逻辑之后，你需要一个脚本来实际执行分片。很多人在这步会掉进一个陷阱：他们关注的是脚本能不能切出 N 个文件，却忽略了每个切出来的文件对于 Claude Code 来说是不是“可理解”的。

一个对 Claude Code 友好的分片文件，必须满足三个条件：

条件一：文件的开头必须有“全局位置信息”。 比如：“这是某系统订单日志 JSON 的第 3/12 片，包含 2024 年 6 月 15 日 00:00 至 23:59 的订单记录，共 8742 条。前一日的日均订单量为 9013 条。”

这几行信息对于人来说看起来多余，但对于 Claude Code 来说至关重要。它让模型在处理这片数据时不至于“漂流”在信息孤岛上。它知道这片在整个文件中的位置、知道跟前后的关系、知道大概的数据规模。

条件二：每一个切片都必须是合法的 JSON，不能是断片的。 这是分片脚本最容易出错的地方。如果你按字节数或行数切，极有可能把一条 JSON 记录拦腰切断。脚本必须能够识别 JSON 的结构边界，对象的大括号要成对、数组的中括号要成对、字符串的引号要成对。建议使用 Python 的 ijson 库做流式解析分片，而不是手动写正则。

条件三：如果原文件是 NDJSON，分片时必须保留行的原子性。 NDJSON（每行一个完整的 JSON 对象）是目前大型数据导出中最常见的格式。分片时只需要按行数切，但必须保证不在行的中间切断。这个看起来简单，实际上我见过至少三个开发者（包括曾经的我）用 split 命令直接切，然后生产出一堆无效的“半行”数据。

六、跨片上下文的传递机制：如何让每一片“知道”前一片发生了什么

这是分片策略中最被低估的一环。大量教程会教你如何切文件，但没人告诉你在切完之后，如何让 Claude Code 在处理第三片时记得第一片里发生了什么。

我设计和测试了三种跨片上下文传递方式：

方式一：压缩摘要传递

每处理完一片，让 Claude Code 输出一个不超过 200 字的分析摘要。这个摘要只包含三样东西：这片数据的关键数字、发现的异常、以及未解决的需要后续片段确认的问题。

处理下一片时，把前一至两片的摘要放在 Prompt 的最前面。

适合场景：分析任务，各个分片之间的数据有可比性。

优点：Token 消耗低，信息密度高。

缺点：摘要质量完全取决于 Claude Code 当次的输出质量。如果某一片的摘要写得不够好，后续片收到的上下文就是残缺的。

我的改进：我会在每三片之后，把前三片的摘要合并，让 Claude Code 重新生成一个“阶段摘要”，然后继续往下。这相当于给上下文做一次“整理压缩”，防止错误累积。

方式二：关键值追踪表

这是我自己发明的做法，实测效果比摘要传递更稳定。

具体操作：在开始分片之前，我先定义一套“关键值”，也就是我最终需要汇总的那些指标的字段名和含义。然后维护一个 Markdown 表格，每处理完一片就更新一行数据。表格内容喂给每一片的 Claude Code 会话。

表格大概是这样的：

适合场景：分析任务尤其是需要最终做汇总统计的任务。

优点：结构化，不容易丢失信息，汇总时直接用表格生成报告。

缺点：需要人工（或脚本）在每一片处理完之后更新表格。不完全是自动化的。

方式三：全量链式追加

这是最暴力但也最可靠的方式：处理第二片时，把第一片的完整分析结果（不是摘要，是全部输出）和原始数据都带在上下文里。

适合场景：审查任务，前面片里的某个细节可能在后续片里被引用到。

优点：信息不丢失。

缺点：Token 消耗指数级增长。三片之内还行，超过五片必然崩溃。

我的建议：三种方式不是互斥的。我在大多数任务中用的都是混合策略：用关键值追踪表做主线，每片结束时生成压缩摘要做补充，只在发现异常需要深挖时才对特定的前一片做全量回溯。

七、汇总阶段：分片的终点不是“分析完最后一片”，而是“能否生成一个不需要再回去查原始数据的最终报告”

我见过的一个典型失败案例：分片和逐片分析都做得很漂亮，但汇总时乱成一团。最后生成的报告里充满了“在某些分片中”“部分记录显示”“个别时段出现”这种模糊表述。你拿着这份报告没法做决策，因为你不知道“某些”到底是哪些。

汇总的核心难点在于：不同分片的结论之间可能存在矛盾，而 Claude Code 倾向于在汇总时“抹平”这种矛盾。

比如第一片的数据显示转化率有明显上升趋势，第二片却显示下降。单看各自的分析结论都是对的，但汇总时 Claude Code 可能会输出一个“整体平稳”的错误判断，因为它试图调和两片之间的不一致。

解决这个问题，我用了一个“三重验证”的汇总流程：

第一重：让 Claude Code 只负责“并排呈现”各片结论，不做任何合并或推断。 这一步的输出是一个结构化的表格，每一行是一片的核心结论，不做横向对比。这个表格是后续所有汇总的“原始材料”，绝不能跳过。

第二重：你人工标注矛盾点。 比如你发现第一片和第三片在“支付成功率”这个指标上给出的数字差异很大。你把这两个矛盾点标记出来，让 Claude Code 分别回到原始的那两片数据中重新确认。通常你会发现，矛盾不是因为分析错误，而是因为统计口径不一致，比如一片统计的是“发起支付的成功率”，另一片统计的是“完成支付的成功率”。

第三重：在解决了所有标注矛盾点之后，再让 Claude Code 生成最终报告。 这时给出的指令要非常明确：“基于各片已验证的分析结果，生成一份最终报告。如果有任何指标在不同分片间存在显著差异，必须在报告中单独列出差异值和可能原因，不要做平滑处理。”

走完这个三重验证流程，最终产出的报告质量跟一次性汇总完全不在一个量级上。我用这个方法给一个客户做的数据质量审查报告，对方的技术负责人的原话是：“这是我见过的最清晰的数据分析交付物。”

八、容易忽略的格式规范：让 Claude Code 的输出从一开始就是“可拼接”的

这个教训来自一次让我十分恼火的经历。

我在处理一个分成 15 片的数据清洗任务时，让 Claude Code 在每一片输出处理后的 JSON。我的想法很简单：处理完 15 片，把 15 个输出文件拼在一起，任务结束。

但我没有给 Claude Code 规定输出格式。结果：

• 有 3 片输出的是标准的 JSON 数组
• 有 4 片输出的是 NDJSON 格式
• 有 5 片在 JSON 外面包裹了 Markdown 代码块标记
• 有 2 片在输出里加了解释性的中文注释
• 有 1 片因为内容太长被截断，只输出了一个不完整的数组

我花在“把这 15 个输出整理成可用数据”上的时间，比我分析数据本身的时间还要长。

从那次之后，我的每一条分片分析 Prompt 里都会加上这段格式指令：

> “请以标准 JSON 格式输出结果，不要包裹在 Markdown 代码块标记内。输出必须是一个合法的 JSON 数组，每个元素是一个完整的处理后的记录。不要在输出中添加任何注释或说明文字。如果你无法在一个回复中输出完整的数组，请在输出末尾标注 [TRUNCATED]，并告诉我你已完成到第几条记录。”

这个格式指令的价值可能比分片策略本身还要大。它保证了你的输出是“机器可拼接”的，不需要人工二次整理。

另外有一个容易被忽略的细节：如果你处理的是 NDJSON 格式的文件，并且分片时保留了原始行的顺序编号，那么汇总时可以直接按行号拼接，不需要依赖任何排序字段。 这个“行号锚点”是我在第三次处理类似任务时才意识到应该加上的，从那之后我的分片脚本都会在每条记录里插入一个 _line_number 字段，事后可以删掉，但它的存在让拼接验证变得极其简单。

九、什么时候你不应该分片

讲了这么多分片的策略，我必须诚实地说：不是所有场景都值得分片。有时候你费了三个小时设计精妙的分片方案，最后发现直接用另一个工具 30 分钟就解决了。

以下三种情况，我建议你认真考虑不分片的替代方案：

场景一：任务是纯数据清洗，清洗逻辑对所有记录一致。 参考 4.1 节的方案，让 Claude Code 生成脚本，你用脚本处理全量数据。这种情况下分片是一种浪费。

场景二：JSON 文件虽然大，但你的任务只涉及其中的一小部分。 比如一个 500MB 的配置文件里，你只需要改其中 3 个服务的配置。不要把这个 500MB 的文件分片喂给 Claude Code。你应该先自己定位到目标代码块，只把那几段摘出来。Claude Code 不需要知道你那个文件有多大，它只需要知道你要改什么。

场景三：你其实不需要 AI 理解文件的结构，只需要它帮你做文本级的查找替换。 这种任务用 sed 或者 VS Code 的批量替换就能解决，不需要调动一个语言模型。

总之一个判断原则：如果任务不需要“理解数据的语义”，就不值得让 AI 介入；如果 AI 只需要理解逻辑而不需要亲自执行批量操作，就让 AI 生成脚本而不是逐片处理数据。

十、我的分片工作流总结和可复用的 Prompt 模板

在这一节里，我把前面所有分散在各章节的操作步骤整合成一个完整的、你可以直接复用或改编的分片工作流。这个流程已经经过了我至少 5 个项目的验证，从 2MB 的配置文件到 3.2GB 的日志文件都跑通过。

阶段一：决策（5 分钟）

目标：判断是否需要分片，如果需要，确定分片策略。

操作步骤：

1. 检查文件大小和行数，对照第二节的三个信号。
2. 如果触发分片信号，进入阶段二。
3. 如果不触发，直接全量喂给 Claude Code。

阶段二：结构探测（10 分钟）

目标：获取文件结构摘要，让 Claude Code 建议分片方案。

操作步骤：

1. 用一个脚本提取文件的结构骨架（只保留 key 名称和 value 的类型标记，截断长数组）。
2. 把结构骨架喂给 Claude Code，使用以下 Prompt 模板：

> 结构探测 Prompt：

> “以下是某个大型 JSON 文件的结构摘要，不是真实数据。请只分析结构，忽略所有具体值。告诉我：

> 1. 顶层结构是什么（对象/数组）？

> 2. 有哪些主要的嵌套路径？

> 3. 基于结构分析，如果要对这个文件执行 [描述你的任务]，你建议按什么方式分片？每条建议说明理由。

> 4. 预估如果直接全量处理，大概需要多少 Token？”

1. 根据 Claude Code 的建议，结合你自己的任务类型，确定分片逻辑。
2. 定义“关键值追踪表”的字段（如果任务是分析型的）。

阶段三：脚本编写与执行（15-30 分钟）

目标：生成分片脚本并执行分片。

操作步骤：

1. 如果你自己会写 JSON 流式解析脚本，直接写。格式要求参考第五节。
2. 如果你不会写或想省时间，让 Claude Code 帮你生成脚本。Prompt 模板：

> 分片脚本生成 Prompt：

> “我需要一个 Python 脚本来分片一个 [NDJSON/嵌套JSON] 格式的文件。分片逻辑是：[描述你的分片逻辑，如‘按日期字段的自然日分片’]。脚本必须满足：

> – 使用 ijson 库做流式解析，不要一次性加载全文件到内存

> – 每个分片输出为一个独立的 .json 文件

> – 每个分片文件的开头要以注释形式写入全局位置信息：分片编号/总分片数、数据范围、记录数

> – 每个分片都必须是合法的 JSON

> – 如果是 NDJSON 格式，每条记录增加一个 _line_number 字段保留原始行号

> 请输出完整的 Python 代码，并说明依赖库的安装命令。”

运行脚本，检查前两个分片是否合法完整，确认无误后全量执行。

阶段四：逐片分析与上下文传递（核心阶段，耗时占比最大）

目标：依次处理各片，确保上下文连贯。

操作步骤（以分析型任务为例）：

1. 定义关键值追踪表。
2. 处理第一片时，Prompt 模板：

> 首片分析 Prompt：

> “这是某项目第 1/[总片数] 片 JSON 数据，时间范围为 [范围]。总记录数约 [数量]。

> 请完成以下任务：

> 1. [具体分析任务，如‘统计异常事件数量和类型’]

> 2. 在分析结束后，输出两个内容：

> a) 本片分析摘要（不超过 150 字，只包含关键数字和发现的异常）

> b) 更新关键值追踪表（我会给你当前表格）

> 输出格式要求：[按照第八节的格式要求填写]”

处理第二片及后续片时，Prompt 模板：

> 后续片分析 Prompt：

> “这是某项目第 [N]/[总片数] 片 JSON 数据，时间范围为 [范围]。总记录数约 [数量]。

> 前一片的关键数据： [插入前一片摘要或关键值表的最新行]

>

> 请完成以下任务：

> 1. 分析本片数据，并与前一片的指标进行对比。标注任何偏差超过 20% 的指标。

> 2. 在分析结束后，输出：

> a) 本片分析摘要

> b) 更新后的关键值追踪表

>

> 输出格式要求：[同上]”

每三片之后，做一次阶段汇总：把前三片汇总为一段“阶段摘要”，以此为新的上下文锚点继续后续分析。

阶段五：汇总与报告生成（30-60 分钟）

目标：产出最终报告，确保结论可验证。

操作步骤：

1. 将关键值追踪表（完整版）和各片摘要汇总喂给 Claude Code。
2. 使用三重验证流程：

> 汇总 Prompt – 第一重（并排呈现）：

> “以下是 [项目名称] 所有分片的分析追踪表和摘要。请以表格形式并排呈现各片的核心指标，不做任何合并或推断。只呈现，不分析。”

1. 人工检查输出表格，标注矛盾或异常数据点。
2. 对矛盾点逐一回溯验证。

> 汇总 Prompt – 第二重（矛盾验证）：

> “在分片 [X] 和分片 [Y] 中，[指标名称] 的数值分别为 [A] 和 [B]，差异显著。请重新检查两片原始数据，确认统计口径是否一致，并解释差异原因。”

矛盾点解决后，生成最终报告。

> 汇总 Prompt – 第三重（最终报告）：

> “基于各片已验证的分析结果，生成一份最终分析报告。要求：

> – 如果任何指标在不同分片间存在显著差异，单独列出差异值和可能原因

> – 不要平滑处理或掩盖数据波动

> – 报告末尾附上完整的关键值追踪表以供复核

> – 报告语言要求清晰、可验证，避免模糊表述”

十一、最后我说点实在的

这篇文章写到这里，我不想用“掌握了这些技巧，你就能高效处理任何 JSON 文件”这种套话结尾。说实话，即使你把这篇文章里的所有策略都用上，处理大型 JSON 文件依然是一件需要耐心的事。

但我可以做两个承诺：

第一，你不会再因为“分片方式选错了”而推倒重来。 我在这篇文章里列出的每一种失败模式，都是我自己亲身踩过的坑。当你遇到类似场景时，至少你能绕开那些我已经替你试过的死路。

第二，你的 Token 消耗会有明显下降，但更重要的是，你的产出质量会显著提升。 省 Token 是手段不是目的。真正的目的是让你在交出一个分析报告时，不需要在后面追加三封解释邮件。

下一步，我建议你做两件事：

1. 从你手边最近的一个 JSON 处理任务开始，用这篇文章里的“先摘要后分片”流程跑一遍。 不需要完美执行，跑通比跑好重要。你会在实操中发现一些我写不到文章里的细节，那些才是真正属于你的经验。
2. 把第五节里的“全局位置信息”格式和第八节里的输出格式要求固化成你的默认 Prompt 模板。 这两个东西你一旦用过一次，就回不去了。它们对输出质量的影响立竿见影。

最后说一句可能会冒犯一些人的话：分片策略的本质不是技术问题，是思维方式的问题。 如果你习惯性地把“切文件”当成一个纯工程操作，你就会不断地掉进“切完发现拼不回来”的陷阱。如果你从一开始就把分片理解成“为 AI 的理解创造最小闭环上下文”，你的每一个决策，从怎么切到怎么传递到怎么汇总，都会变得更清晰，也更正确。