当 AI 编码助手成为日常工具，团队真正关心的问题往往不再是“能不能写代码”，而是“它到底做了什么”。近日，一篇来自掘金的技术文章介绍了如何对 Claude Code 的执行过程进行系统化观测与审计，将多次会话、多台机器上的用量数据、工具调用记录以及文件差异集中呈现。
该文章由吴晟撰写，标题为《看清 Claude Code 的用量与文件变更》，发布于 2026 年 9 月 12 日，原文为英文技术博客《Beyond Replay: Metrics and Change Detection for Your Claude Code Sessions》。文章基于 AI Sessionizer 0.3.0、OAP 11.1 和 Horizon UI 1.1 的开发中功能，展示了一套面向 Claude Code 的可观测方案。
从单次回放走向集中统计
单个会话可以解释一次任务的执行细节，但如果要理解几天甚至几周的使用情况，就需要把多次会话、多台机器上的数据放在一起比较。这也是该方案引入指标看板的原因：既可用于个人回顾一周开发，也可用于团队了解整体使用情况。
在“AI Agent Overview”页面中，系统提供按天和按小时展示的 Token 热力图，并汇总用量及上报智能体的用量排名。开发者可以先判断哪些时段使用频繁、哪些智能体上报的 Token 最多，再决定是否深入查看具体任务。
进入具体智能体页面后，用量还可以按 Token 类型、模型，以及主智能体和子智能体分别查看。输入、输出、缓存读取和缓存创建会被分开展示，便于判断较大的 Token 总量由哪些部分构成。同样的指标也可以按运行实例查看，例如单独检查某台机器上运行的采集器所上报的数据。
如果最近用量明显增加，使用者可以先比较各模型的变化，再看主智能体和子智能体分别消耗了多少，以及增长主要来自哪类 Token。若仍需要缩小范围，则可以进入运行实例页面，查看具体机器的情况。
文章同时说明，看板能展示哪些指标，取决于采集的数据来源。已有的 Claude Code 会话记录可以提供部分 Token 指标；配置 Claude Code 自带的遥测导出器后，还能展示按模型统计的费用、活跃时长、新建会话数、增删行数、提交和 PR 数量，以及编辑权限请求的接受或拒绝情况。这些额外图表会在相应指标上报后出现，系统不会根据对话内容估算缺失数值。
在指标采集配置上，文章提到需要选择一条 Token 上报路径，避免同一批活动被重复计数。概览中的服务名称来自实际上报的遥测数据，并不代表会话回放已经支持所有智能体。目前已实现的会话适配器仍是 Claude Code，Codex 和 LangChain/LangGraph 适配器仍在计划中。
会话回放与团队共享
当看板上发现某个时段或智能体值得进一步检查时，用户可以进入“Conversations”页签查找相关工作记录。会话查询支持时间范围、运行实例、标题文字或会话 ID 等筛选条件，找到目标后可在独立页签中打开。
在打开会话之前，页面已经可以显示该会话中的对话轮次、模型调用、子智能体、Bash 执行和文件变更记录数量。进入会话后，对话内容与执行时间线并排展示，用户可以进入子智能体的工作记录，也可以展开某次工具调用，查看请求、结果及对应的来源记录。
这些操作都可以在 SkyWalking 控制台中完成。页面地址还会保留当前选中的对话轮次、步骤和执行流。具备访问权限的同事打开链接后，可以直接查看同一位置，无需到原来的机器上寻找记录。
文章认为，看板帮助发现一段时间内的用量变化，会话则保留一项任务中的具体请求、回复和操作。对于团队来说，这类集中保存的记录减少了追溯成本；对于个人来说，也可以更方便地回顾某次开发过程中的具体决策和执行路径。
文件变更如何被记录与解释
相比用量和对话记录，文件变更更接近实际工程结果。该方案在回放中加入工作区变更记录，将智能体的回复、执行过的工具，以及文件中发生的修改放在同一上下文中查看。
用户点击会话顶部的“Changes”计数后，可以打开整个会话的文件变更列表。文件按工作区根目录分组，每个文件下保留各次变更记录。选择一条记录后，可以跳转到关联的工具执行步骤，并打开变更详情。
文章举例的一次开发会话记录了 93 条变更，涉及 39 个文件。文件列表中既有方案文档，也有看板模板、使用文档和更新日志。同一文件的多次修改会保留在对应路径下，查看它如何随着任务推进而变化，比在整段对话里逐一搜索文件名更方便。
需要注意的是，这里展示的数量表示采集到的变更记录数。一个文件可能被多个工具调用反复修改，同一次调用也可能由不同来源分别记录，因此增删行数可能包含对同一段内容的多次修改。查看过程时可以逐条展开差异；如果要确认工作结束后的最终净变化，仍应以 Git diff 为准。
工具卡片和时间线上的步骤也会显示变更标记。展开卡片后，可以看到文件路径、操作类型和增删行数；继续展开文件，可以阅读逐行差异。较长的内容还可以放入更大的详情面板中，与会话对照查看。
文章提到，一条差异可能记录的是检查代码仓库之后对方案的调整。旁边的对话仍然保留用户的要求和智能体的回复，因此可以一边查看文件改了什么，一边回顾修改之前的讨论，再检查实际执行的工具请求和结果。
这类信息的关键在于保留可检查的依据：变更通过 tool-use ID 与具体执行步骤关联，每条记录也保留采集来源。用户可以从文件差异回到工具请求、结果和来源记录，区分 Claude Code 自身报告的补丁与 Shell 命令执行前后扫描工作区得到的变化。
采集边界与工程限制
与上一篇回放方案类似，采集已有 Claude Code 历史记录无需在 Claude Code 中安装插件或修改配置。成功执行的 Edit、Write 等编辑调用本身可能带有原生补丁，Sessionizer 会在采集时提取这些记录。如果数据由较早版本采集，则需要重新采集才能补充变更记录，仅用新版界面打开旧数据还不够。
如果希望进一步查看脚本执行期间和子智能体任务中的修改，可以安装可选的 asz-changes 插件。该插件会在 Bash、PowerShell、Monitor 等 Shell 工具执行前后扫描工作区，并采集子智能体报告的编辑补丁。这些变化会进入同一套查看界面。
不过，Shell 的前后快照只能在插件安装后、实际观测到相应操作时产生，无法事后为过去的命令补录。记录也会说明采集范围和限制。多个工具的执行时间重叠时，相关变更可能标为 shared；在工具调用之间发现的变化，会单独列在“Changes outside observed tool windows”中。某次扫描被跳过、只完成一部分时，界面也会说明；二进制文件或体积过大的文件，可能只保留路径和哈希值，没有文本差异。
文章强调，这些信息有助于判断记录能说明什么。一次扫描能够确认观测时段内发生了哪些变化；如果期间还有其他并发操作，就不能把所有修改都归因于某一次工具调用。保留来源并明确不确定的范围，才能据此检查执行过程。
本地使用与团队部署
这些能力可以接入现有的终端、编辑器和 Git 工作流程。开发者仍然照常使用 Claude Code、审查和提交代码，Sessionizer 读取保留下来的会话记录，补充用量和执行过程的查看方式。
用户可以先在本机使用；需要更完整的变更记录时，再启用可选插件。asz-changes 在本机写出变更记录，采集过程不依赖 Sessionizer 服务或远端连接；Sessionizer 再读取这些输出。是否把数据导出到中心服务，取决于是否需要跨机器汇总或与团队一起查看。
对于本地体验，文章给出基本路径：按照快速开始指南构建 Sessionizer，然后在项目目录中运行 ./bin/asz server，打开 http://127.0.0.1:8787 即可查看。当前启动命令与之前版本有所不同：asz server 同时运行采集和本地查看服务，asz view 则用于读取已经采集的数据。
如果需要采集 Shell 和子智能体的额外变更，可以在 Sessionizer 项目目录中使用 claude --plugin-dir plugins/claude-code 启动一个新的 Claude Code 会话。
若团队需要集中查看这些数据，则需要在 asz.yaml 中配置 export.otlp.endpoint，并使用兼容的 OAP、Horizon 开发版本。具体步骤见导出指南和后端会话配置指南。再根据看板指南选择指标来源后，即可进入 SkyWalking 的 AI Agents 页面查看。
对越来越多引入 AI 编码工具的团队而言，这类能力的意义不只是“看得见”，而是让智能体的行为可以被审计、被复现、被讨论。用量、会话、工具调用和文件差异被放在同一链路中后，AI 编码助手的工作过程开始从黑盒结果转向可追溯的工程记录。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/shen-ji-claude-code-cong-yong-liang-hui-hua-dao-wen-jian
