一、问题背景：当海量测试日志撞上AI的"有限内存"
假设你接手了一个典型的中大型后端服务项目。它可能是一个微服务集合，也可能是一个单体应用，其特性是：
- 功能模块众多：包含数百个API接口、数据处理函数或算法组件。
- 测试输出冗长：每个功能的测试都会触发框架初始化、依赖调用、数据库操作和业务逻辑日志，一次全量测试运行的输出轻松达到数万甚至数十万行。
你的任务是为这个项目创建一个Claude Code Skill，目标是：一键运行全量测试，并让AI分析结果，给出明确的通过/失败报告以及失败详情。
最初的尝试与直接的失败
你可能会这样设计Skill：让Claude执行 pytest ./tests 或 go test ./... 这样的命令，然后要求它分析控制台输出。然而，你会立刻遇到Claude（以及其他大语言模型）的根本性限制：上下文窗口（Context Window）大小有限。
你可以将上下文窗口理解为Claude的"工作内存"或"思考白板"。所有输入信息------包括你的系统指令、对话历史、被读取的源代码，以及运行测试产生的海量日志------都共享这块固定大小的白板。
当数万行日志瞬间涌入，会发生两件事：
- 内存溢出：可用Token被迅速耗尽，后续的分析指令可能因没有空间而无法执行。
- 注意力失效：即使部分日志被勉强塞入，Transformer模型的注意力机制也难以有效处理序列中间的信息。大量测试结果实际上被AI"视而不见"，导致分析遗漏或错误。
因此，"一次性运行，一次性分析"的传统脚本思维在面对AI协作者时会彻底失效。
二、方案推导：从"硬扛"到"巧治"------分批处理与摘要归档
既然问题出在"数据量（O(n)）大于内存容量（O(1)）"，那么核心思路必然是降低需要同时驻留在"工作内存"中的数据量。
为什么"分批"是突破口？
分批，本质上是"分而治之"。它将一个不可能处理的大任务 T(all)，分解为N个可处理的小任务 T(batch1), T(batch2)...。
但关键在于，如果你简单地将任务分5次运行，并让AI记住全部5次输出的所有日志，那么上下文占用并没有减少，只是从"一次塞入"变成了"分五次塞入"，总量不变。
因此，真正的突破点不在于"分批执行"，而在于"分批处理"中的"处理"二字：即对每一批的输出进行即时消化、压缩，并丢弃原始数据。
核心机制："处理-摘要-归档"循环
这个机制是解决上下文问题的关键，其流程如下：
- 处理当前批次 ：运行第1批测试（如
pytest ./tests/module_group_a）。AI获得本批的原始日志。 - 提炼结构摘要 ：AI不会通读所有日志。相反，它被设计为执行一个快速提取程序 。这通常依赖于：
- 测试框架的总结行 ：几乎所有测试框架在最后都会输出总结，如
"5 passed, 1 failed in 0.12s"。 - 约定的错误信号 ：我们可以在测试中约定，任何失败都以
[FAIL] module_name: error_msg的固定格式打印。AI只需用正则或关键字匹配这些行。 - 进程退出码：最底层的信号。
- AI根据以上信息，生成一行高密度、结构化的摘要 ，例如：
[批次A结果] 总计: 56 | 通过: 55 | 失败: 1 | 失败案例: test_user_login.py::TestLogin::test_invalid_password
- 测试框架的总结行 ：几乎所有测试框架在最后都会输出总结，如
- 上下文归档 ：这是最具技巧性的一步。在Skill的指令中，我们会明确告诉Claude： "此摘要为本批次的最终结论。现在，请将上述摘要添加到'测试结果总表'中。之后关于本批次的所有推理，均应基于此摘要进行。原始的控制台输出可以视为已处理完毕，无需再保留在你的活跃工作记忆中。"
- 循环前进：清空"工作内存"中的原始日志负担，只带着轻盈的"结果总表"（即一系列摘要行），开始处理下一批次。
为什么这能神奇地减少上下文占用？
这利用了LLM的两个关键特性：
- 指令遵循 ：当你在
SKILL.md中强制规定"后续推理仅依据摘要"时，Claude会倾向于遵守，在内部将摘要作为事实来源。 - 注意力权重 ：在Transformer的注意力计算中，与当前任务指令强相关的信息 （刚生成的摘要、处理下一批的指令）会获得高权重。被明确指示"可归档"的旧信息（原始日志）权重会降低。虽然它们在对话历史中依然存在，但在模型计算下一个词时，所消耗的"有效注意力"和"有效工作记忆"已大幅减少。
最终效果 ：在整个长任务中，AI上下文里需要被"认真对待"的数据，从所有批次的全部原始日志（O(n)） ，变成了一个不断增长的摘要列表（O(batch_count)）。由于摘要列表的大小和格式固定，其增长远低于原始日志的线性增长，从而在实践上避免了上下文溢出。
三、方案对比：分批归档 vs. 多开子代理
面对长任务，另一个自然思路是利用Claude Code的子代理（Sub-agent）系统。下表对比了两种范式：
| 特性 | 分批处理 + 摘要归档方案 | 多开子代理 (Sub-agent) 方案 |
|---|---|---|
| 核心比喻 | 一个高效的单线程工作者。自己有一套处理海量资料的流水线：取一份，处理完，记下要点，扔掉原稿，再取下一份。 | 一个项目协调员。把大任务拆成小份，分发给多个临时工（子代理）并行去做，然后等他们各自交回报告。 |
| 上下文管理 | 通过工作流指令，在单一代理内部实现逻辑上的"记忆管理"，用摘要替换细节。 | 依赖系统级的上下文隔离，每个子代理在独立沙箱中运行，物理上互不干扰。 |
| 实现复杂度 | 较低 。逻辑集中在一个SKILL.md文件中，流程是线性的，状态自己管理。 |
较高。需要主代理协调子代理的创建、任务分配、结果收集和错误处理，架构更分布式。 |
| 数据连贯性 | 好。主代理经历了全过程，对整体进度、失败模式有连贯的、渐进的理解。 | 差。主代理只看到最终的结果片段，失去了对过程的感知和中间状态的把控。 |
| 资源开销 | 主要是一个主代理的持续开销。 | 并行时会瞬时创建多个子代理，系统资源占用较高。 |
| 最佳场景 | 任务同质、输出数据量大、串行可接受 。（本文讨论的自动化测试是典型场景） | 任务异构、单个任务耗时极长、需强隔离或真并行。例如：同时运行前端构建、后端测试和数据库迁移。 |
结论 ：对于"大型工程功能测试"这种任务高度同质、单个执行快、但总输出数据量爆炸 的场景，分批摘要方案凭借其简洁性、可控性和对上下文的极致利用，是更优、更实用的选择。
四、实战：Demo Skill 写法示例
以下是一个概念性的 SKILL.md 示例，展示了如何将上述思想落地。
shell
# 技能：大型工程分批测试运行器
## 技能描述
本技能用于安全、高效地运行大型代码库的全量测试。它会自动将测试套件分批执行，避免上下文溢出，并生成清晰的最终报告。
## 工作流与规则
### 1. 准备工作
- 用户需指定测试命令模版（如 `pytest {test_path}`）和项目根目录。
- 技能将自动探索 `tests/` 目录，或根据配置文件，将测试用例智能分成若干个批次（如每批50个测试）。
### 2. 核心循环指令（关键）
对于每一个测试批次：
1. **执行**：运行当前批次的测试命令。
2. **提取**：分析输出，**严格按以下优先级提取信息**：
a. **第一优先级：进程退出码**。非零则本批次标记为失败。
b. **第二优先级：结构化总结行**。从输出末尾查找如 `X passed, Y failed, Z skipped in ... seconds` 的框架总结行。
c. **第三优先级：失败用例行**。搜索如 `FAILED`, `ERROR`, `[FAIL]` 等关键字，提取失败的测试用例全名（如 `tests/feature_a/test_api.py::TestClass::test_method`）。
3. **归档**：
a. 生成批次摘要
b. **重要**：将此摘要添加到下方的"测试结果总表"章节中。
c. **上下文管理声明**：*"此批次处理完毕。以上摘要是其权威记录。原始输出已不再需要，思考应集中于总表和下一批次。"*
### 3. 结果汇总
- 所有批次完成后，分析"测试结果总表"。
- 计算总通过率，列出所有失败用例。
- 提供最终结论和建议。
---
## 测试结果总表
（此区域由技能在运行过程中动态填充）
[批次 1] 文件数: 50 | 通过: 48 | 失败: 2 | 失败列表: [test_a.py::test_x, test_b.py::test_y]
[批次 2] 文件数: 50 | 通过: 50 | 失败: 0 | 失败列表: []
...
---这个Demo展示了如何通过严格的指令，将"分批、处理、归档"的循环固化到技能的工作流中，从而实现对海量测试任务的安全处理。
五、总结
为大型工程构建AI驱动的测试自动化，其挑战不在于AI的分析能力，而在于我们如何设计出适应AI约束的工作流程。
分批处理与摘要归档方案的精髓在于：
- 承认限制：正视上下文窗口的物理限制，不与之蛮力对抗。
- 转换思路：从"让AI记忆所有过程"转变为"让AI产出并记住所有结论"。
- 利用特性：通过明确的指令，引导AI的注意力机制，将高密度的摘要作为思考的基石，而非低密度的原始日志。
这套模式不仅适用于测试，任何需要AI处理输出量远大于输入量 的批处理任务（如日志分析、代码审查、数据清洗报告生成）都可以借鉴此思想。其本质是一种与大型语言模型高效协作的、新的软件工程模式。