自建全套AI开发工具：Token消耗实测下降52%

本文转载自《我开始使用 Claude Code》。

用秒表和秤测量连接了我所开发全部工具的盒子。

在上一篇文章中，我分别通过自制的 AIShell 和普通 Codex，让 Codex 执行相同的任务，结果 token 使用量减少了 25.86%。我当时觉得效果似乎不错。不过，由于结果仅来自 3 个任务、共 9 次试验，我还无法确定这一结论是否可靠。

这一次，我增加了功能，并扩充 benchmark 后重新进行了测量。先说结果：token 使用量减少了 52.44%。相比上一次又有提升，而且幅度超出了我的预期。

把所有实用工具都做了出来

在增加功能时，我询问了 Claude：根据我的开发环境，哪些工具会比较实用？它给出了很多建议。

一开始，Claude 建议先实现其中几个，观察效果后再说。但我基本上只是个业余独立开发者，在本职工作之余让 AI 帮我开发，因此不必太担心开发结果带来的风险。于是，我决定把它们全部做出来。

AIShell 当前的功能

上一篇文章发布时，AIShell 有 5 项功能：

• 一次性返回工作目录的当前状态，以及相较上次发生的所有变化
• 只读取多个文件中必要的内容
• 在指定范围内搜索
• 执行构建和测试，并返回重要的诊断信息
• 从保存的完整输出中读取所需范围

下面列出本次新增的全部功能：

• 等待变化：等待 AIShell 检测到文件变化或构建完成。在等待期间，AI 不需要不断发出检查命令。
• 在后台运行并按需查看：让构建和测试持续在后台运行，同时 AI 可以继续处理下一个任务。需要时再获取中间进度和最终结果。
• 取消正在运行的进程：中途取消后台进程，并在不留下任何残余的情况下结束它。
• 批量修改多个文件：一次修改多个文件。在应用修改前，检查作为编辑依据的文件是否发生过变化；如果已经变化，就停止操作。
• 显示修改的影响范围：返回修改某个文件会影响哪些源文件和测试。还会根据构建依赖记录追踪影响。对于无法追踪的依赖，则将其报告为 unknown。
• 持久化 workspace 记忆：即使 AIShell 重启，也能记住此前的状态，并以 diff 的形式返回停止运行期间发生的变化。
• 比较 branch 和 worktree：一次性返回 branch 之间的差异，或 worktree 中发生的变化。
• 理解详细的 Git 状态：报告 staged 和 unstaged 修改混合存在、文件被重命名等状态，同时保留修改的身份信息。
• 记住项目配置：记住并返回当前项目的构建命令和测试命令。如果 package.json 等配置文件发生变化，则重新学习。
• 批量执行多项搜索：一次接收多个搜索查询，并优先返回已修改文件和测试中的结果。
• 语义搜索：除了文本匹配，还会追踪函数与变量之间的联系来进行搜索。编辑完成后，立即将编辑前的旧分析结果视为过期。
• 格式化诊断信息：按照不同格式，将构建和测试产生的诊断信息整理成固定结构。如果格式损坏，则将其报告为 broken。
• 复用验证结果：重复执行相同验证时，如果输入没有变化，就使用上一次的结果；如果输入发生变化，则重新执行。
• 建议要运行的测试：根据修改内容，建议当前应该运行哪些测试。可以只给出建议，也可以等待批准后再执行。
• 搜索并比较过去的执行结果：跨多个已保存的运行输出进行搜索。比较两次运行，并显示新增和消失的 warning。
• 恢复操作：检查 AIShell 自身的状态，并打开管理应用。当设置不完整或管理应用停止 AI 操作时，这两项操作仍然可用。

其中，“等待变化”“在后台运行并按需查看”“批量修改”和“影响范围”这四项功能被新增为独立工具。恢复操作也拆成了两个工具：状态检查和打开管理应用。其余功能则整合进了现有的 5 个工具中。AI 可见的工具数量由 5 个增加到了 11 个。

稍后我们会逐项查看这些工具在各个任务中的效果。

将 Benchmark 扩展到 32 个任务

我根据真实开发中会出现的场景设计了 32 个任务。任务包括等待构建完成、对多个文件应用修改，以及从过去的执行结果中搜索问题原因等。

每个任务分别交给普通 Codex 和 AIShell 执行三次。是否成功，则根据为各项任务设定的条件，以机械方式判定。

Token 减少了 52.44%

整体结果如下。

每个成功任务的 token 数，是把失败试验中使用的 token 也计入总量，再除以三次试验均成功的任务数量所得。与上一次减少 25.86% 相比，这次的结果有所提升，成功完成的任务数量也增加了。

各任务的 token 减少率。重新理解项目配置和等待场景减少了 70%，判断损坏诊断信息则增加了 30%。

接下来，我们会逐项查看每项功能具体实现了什么，以及它们在哪些任务中产生了怎样的结果。我也会介绍那些无法直接发挥作用的功能。

4 个新工具的结果

普通 Codex 在等待期间会持续发送检查命令，因此所有这些检查都会消耗 token 和时间。AIShell 则会在发生变化时主动通知。

普通 Codex 会重复执行检查命令，AIShell 只请求一次，然后等待通知。

这是 32 个任务中差距最大的一项功能。在等待外部编辑的任务中，token 减少了 75%～78%，耗时则缩短了 90% 以上。即使是在检测变更通知已经停止、并转而重新调查的任务中，token 也减少了 68%。

在后台运行并按需查看

这项功能对应两个任务。一个任务要求从正在运行的构建中提取第一个 failure，并在构建结束时报告 exit code。另一个任务要求取消正在运行的进程，并在不留下任何残余的情况下结束它。

普通 Codex 在全部 6 次试验中均告失败。AIShell 则在 6 次中成功了 5 次。暂且不谈效率，这类任务原本就无法通过 shell 完成。

批量修改多个文件

在应用修改前，它会检查作为编辑依据的文件是否发生过变化；如果发生过变化，就停止操作。

这项功能对应三个任务。普通 Codex 在 9 次试验中成功了 5 次，而 AIShell 9 次全部成功。对比双方都成功的任务，token 减少了 33%～40%。

显示修改的影响范围

在追踪直接依赖的任务中，普通 Codex 3 次全部失败，AIShell 则 3 次全部成功。在根据构建依赖记录显示影响范围的任务中，双方的成功次数是 1 比 3，同时 token 减少了 49%。

这里也有一个 AIShell 失败的任务：当其中混入无法追踪的依赖时，需要报告“从这里开始，我无法确定”。普通 Codex 成功了 2 次，而 AIShell 3 次全部失败。对于 unknown 部分应如何报告，目前仍存在不足。

现有工具扩展后的结果

持久化 Workspace 目录记忆

即使在重启之后，AIShell 仍会记住先前的状态，并以 diff 的形式返回停止期间发生的变化。在重启后的状态恢复任务中，token 减少了 44%；在检测停机期间发生的编辑时，token 减少了 32%。

用于比较 branch 和 worktree 的功能也被加入了工具。在理解包含文件重命名的混合状态时，token 减少了 63%；在理解 worktree 变化时，token 减少了 51%。在准确报告 staged 和 unstaged 修改混合状态的任务中，普通 Codex 3 次全部失败，而 AIShell 3 次全部成功。

感知项目配置

这项功能会记住当前项目的构建命令和测试命令，并将它们返回。当 package.json 发生变化时，它会重新学习。

在配置变更后重新学习的任务中，token 减少了 77%。在可以直接使用已记忆内容的场景中，token 减少了 46%。

在一次传入多个搜索查询的任务中，token 减少了 54%。在追踪函数和变量之间联系的搜索任务中——其中还包括“编辑后不得返回过期分析结果”这一要求——普通 Codex 6 次全部失败，而 AIShell 成功了 5 次。

这里也有一个失败案例。在“只读取指定容量内能够容纳的内容，并将剩余内容作为 continuation 返回”的任务中，双方都是 3 次全部失败。

构建与测试执行相关功能

在把执行结果中的诊断输出格式化为固定结构的任务中，双方的成功次数是 1 比 2，AIShell 的 token 使用量减少了 42%。

在根据修改内容提出应该运行哪些测试、等待许可后再执行的任务中，普通 Codex 6 次全部失败，而 AIShell 成功了 5 次。

效果不佳的任务也集中在这一部分。在要求刻意将损坏的诊断数据判断为 broken 的任务中，AIShell 使用的 token 比普通 Codex 多了 30%。当重复执行相同检查时，复用上一次结果的功能几乎没有带来 token 差异。在信息原本就已存在于本地的场景中，经过 AIShell 仍然会产生额外开销。

搜索过去的执行结果

AIShell 会保存执行过程的完整输出。在跨多次执行搜索 error 的任务中，token 减少了 48%。在比较两次执行结果，并列出哪些 warning 新增、哪些 warning 消失的任务中，token 减少了 46%。

普通 Codex 会先重新运行命令来重建输出，这正是产生差异的原因。

延续上一次的问题

上一篇文章始于这样一个问题：“有了 AI，我们还需要 shell 和 terminal 吗？”

这次的结果表明，绕过 shell 的连接方式使用了更少的 token，耗时更短，同时成功完成了更多任务。至少在这次 benchmark 的范围内，不使用 shell 时，AI 能取得更好的结果。

下一步，我将验证这些效果是否也会出现在日常开发中。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。