告别碎片化日志：一套方案采集所有主流 AI 编程工具

在AI编程工具快速普及的今天，如何有效采集和分析AI代码生成数据成为了一个重要课题。我们设计并实现了一套基于MCP（Model Context Protocol）架构的多AI工具代码采集方案，支持claude-code、iflow、codex等CLI工具以及qoder IDE。这套方案具有轻量化、用户无感、可扩展等特点，目前已经和Aone团队合作，数据将自动采集到Aone的日志平台用作团队AI采纳率数据加工的基础。当前已支持claude-code、codex、gemini、ykcli、iflow/iflow-aone、qwen-code、qoder等工具，平台覆盖 macOS + Windows。

随着AI编程助手的快速普及，开发者的日常工作中涌现出了众多AI工具，在不同场景下发挥着重要作用。然而，AI工具的多样化也带来了新的挑战：

• 缺乏统一的数据收口：每个AI工具都有自己独特的数据格式和接口，缺乏统一的标准。开发团队难以全面了解AI工具在组织内的使用情况，无法建立统一的数据视图。

• 平台支持不足：大多数AI工具专注于功能实现，对数据采集和分析的支持有限。即使有数据输出，格式也往往不够标准化，难以进行跨工具的对比分析。

• 度量数据缺失：最关键的问题是，团队无法有效度量AI生成代码的采纳率、质量和影响。这些数据对于评估AI工具的ROI、优化开发流程、制定技术决策都至关重要。

基于这些痛点，我们团队决定建立一套统一的AI工具代码采集方案，为组织提供全面、准确的AI代码生成数据支撑。

在调研过程中，我们发现业界主要存在以下几类AI代码采集方案：

AIDC团队提供了基于VSCode插件的采集方案，这种方式相对比较重量级，需要用户主动安装和配置插件。目前该方案仅支持cursor，扩展性有限。插件形式虽然功能完整，但对用户的侵入性较强，需要用户感知并配置相关设置。

基于对业界方案的深入分析，我们确定了以下设计原则：

• 轻量化优先：采集机制必须对原有工具完全无侵入，不能影响用户的正常使用体验。

• 多样化适配：针对不同类型的AI工具（CLI工具、IDE工具、Web工具），采用最适合的采集策略。

• 标准化输出：虽然采集方式多样，但最终输出的数据格式必须标准化，便于后续分析和处理。

• 可靠性保障：通过本地缓存、重试机制、版本兼容性检查等手段，确保数据采集的可靠性。

我们的采集方案基于MCP架构设计，采用了分层解耦的思路。整个系统由三个核心组件构成：

• 采集层（Collection Layer）负责从不同AI工具获取原始数据。对于CLI工具（claude-code、iflow、codex），我们通过Hook机制在工具执行时拦截相关事件；对于IDE工具（qoder），我们通过解析其历史快照文件获取代码变更信息。

• 处理层（Processing Layer）将来自不同工具的异构数据标准化为统一格式。每种工具都有对应的Collector组件，负责解析原始数据并转换为标准的事件格式。这一层还包含了Git信息解析、文件路径规范化等通用处理逻辑。

• 上报层（Reporting Layer）将标准化后的数据上报到SLS日志系统。这一层实现了数据的批量处理、重试机制和错误恢复，确保数据上报的可靠性。

统一的加工指标

AI 生码率（AI-Generated Code Ratio, AGCR）:  AI有效提交行数/分支Diff总行数*100%

Hook类型

对于claude-code和iflow这类CLI工具，我们采用了Hook机制进行数据采集。系统会自动在用户的配置文件中注入Hook脚本，当工具执行文件操作时，Hook脚本会捕获相关事件并将数据写入本地日志文件。

#!/usr/bin/env bashset -euo pipefail
CLIENT_TYPE="claude"resolve_cache_dir() {  if [[ -n "${R2C_CACHE_DIR:-}" ]]; then    printf'%s'"$R2C_CACHE_DIR"    return  fi  local home="${HOME:-}"  local target=".r2c"  if [[ -n "$home" ]]; then    target="$home/.r2c"  fi  if mkdir -p "$target"2>/dev/null; then    printf'%s'"$target"    return  fi  local fallback="${PWD:-.}/.r2c"  mkdir -p "$fallback"  printf'%s'"$fallback"}CACHE_DIR="$(resolve_cache_dir)"HISTORY_DIR="$CACHE_DIR/logs/$CLIENT_TYPE/history"mkdir -p "$HISTORY_DIR"read_payload() {  if [[ -t 0 ]]; then    printf''    return  fi  cat || true}compact_json() {  local payload  payload="$(cat)"  if [[ -z "$payload" ]]; then    return 1  fi  if command -v python3 >/dev/null 2>&1; then    if printf '%s'"$payload" | python3 -c 'import json,sys;\nprint(json.dumps(json.loads(sys.stdin.read()), ensure_ascii=False, separators=(",", ":")))'2>/dev/null; then      return0    fi  fi  if command -v node >/dev/null 2>&1; then    ifprintf'%s'"$payload" | node -e "let data='';process.stdin.on('data',c=>data+=c).on('end',()=>{try{const parsed=JSON.parse(data);process.stdout.write(JSON.stringify(parsed));}catch{process.exit(1);}});"2>/dev/null; then      return0    fi  fi  if command -v jq >/dev/null 2>&1; then    ifprintf'%s'"$payload" | jq -c '.'2>/dev/null; then      return0    fi  fi  printf'%s'"$payload" | tr -d '\n' | tr -d '\r'  return0}PAYLOAD_RAW="$(read_payload)"PAYLOAD_RAW="${PAYLOAD_RAW//$'\r'/}"TRIMMED="$(printf '%s' "$PAYLOAD_RAW" | sed 's/^[[:space:]]*//;s/[[:space:]]*$//')"if [[ -z "$TRIMMED" ]]; then  exit0fiFIRST_CHAR="${TRIMMED:0:1}"LAST_CHAR="${TRIMMED: -1}"if [[ "$FIRST_CHAR" != "{" && "$FIRST_CHAR" != "[" ]]; then  exit0fiif [[ "$LAST_CHAR" != "}" && "$LAST_CHAR" != "]" ]]; then  exit0fidetect_hook_event(){  case"$1" in    *'"hook_event_name":"PostToolUse"'*) echo "PostToolUse"; return ;;    *"\"hook_event_name\":\"PreToolUse\""*) echo "PreToolUse"; return ;;    *'"hookEvent":"PostToolUse"'*) echo "PostToolUse"; return ;;    *'"hookEvent":"PreToolUse"'*) echo "PreToolUse"; return ;;  esac  echo "unknown"}HOOK_EVENT="$(detect_hook_event "$TRIMMED")"if ! DATA_COMPACT="$(printf '%s' "$TRIMMED" | compact_json 2>/dev/null)"; then  exit0fiUTC_DAY="$(date -u +"%Y-%m-%d")"LOG_FILE="$HISTORY_DIR/${CLIENT_TYPE}-${UTC_DAY}.jsonl"LOG_TIME="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"uuid_fallback() {  local bytes  bytes="$(LC_ALL=C dd if=/dev/urandom bs=16 count=1 2>/dev/null | hexdump -v -e '/1 "%02x"')"  printf'%s-%s-%s-%s-%s\n'"${bytes:0:8}""${bytes:8:4}""${bytes:12:4}""${bytes:16:4}""${bytes:20:12}"}UUID=""if command -v uuidgen >/dev/null 2>&1; then  UUID="$(uuidgen | tr 'A-Z' 'a-z')"else  UUID="$(uuid_fallback)"fiif [[ "$HOOK_EVENT" != "unknown" ]]; then  RECORD="{\"uuid\":\"$UUID\",\"logTime\":\"$LOG_TIME\",\"reported\":false,\"clientType\":\"$CLIENT_TYPE\",\"hookEvent\":\"$HOOK_EVENT\",\"data\":$DATA_COMPACT}"else  RECORD="{\"uuid\":\"$UUID\",\"logTime\":\"$LOG_TIME\",\"reported\":false,\"clientType\":\"$CLIENT_TYPE\",\"data\":$DATA_COMPACT}"fiexec 9>>"$LOG_FILE"if command -v flock >/dev/null 2>&1; then  flock 9elif command -v lockf >/dev/null 2>&1; then  lockf -k 9fiprintf'%s\n'"$RECORD" >&9exec 9>&-

Hook脚本的设计非常轻量化，主要功能是接收工具传递的JSON数据，进行基本的格式验证和清理，然后以JSONL格式写入按日期分割的日志文件。脚本使用bash实现，具有良好的兼容性，支持多种JSON处理工具的降级策略。

采集到的数据会暂存在本地的历史日志文件中，后台服务会定期扫描这些文件，解析其中的事件数据并进行标准化处理。这种设计的好处是完全不影响CLI工具的执行性能，用户在使用过程中完全无感知。

Telemetry类型

对于Gemini/YKCLI/Qwen这类工具，我们采用了Telemetry机制进行数据采集。同样也会在用户的配置文件中注入Telemetry配置，使其工具在生成代码时，能够将相关事件数据写入到采集服务日志文件中。虽然流程和落盘目录上有些区别，但本质上类似都是对过程数据的收集和存储。

{  "telemetry": {    "enabled": true,    "target": "local",    "outfile": "/Users/xxx/.r2c/logs/gemini/raw-telemetry.log",    "otlpEndpoint": "",    "logPrompts": false,    "useCollector": false  }}

我们利用其内置的telemetry配置，可以让我们接收工具内部的所有遥测数据。但是由于其遥测数据量级比较大（每次操作均可输出MB级别的文件大小日志内容），我们对采集工具日志的过滤和控制体积大小方面做了一些优化，使其能够在捕获目标日志后解析组装成我们需要的Write工具调用日志格式，在随后上报后同步清理掉原始日志中废弃和无关的其他日志，保障日志落档文件的IO效率。

Qoder的采集机制需要解析其本地历史快照与工作区存储数据。Qoder会将编辑历史保存在本地的History与workspaceStorage目录中，我们通过解析这些快照来重建代码变更事件。

我们实现了QoderCollector组件，能够读取Qoder的快照格式，提取文件路径、变更类型与diff等关键信息。系统同样维护SnapshotStore来记录已处理快照，避免重复上报。Qoder采集器也支持工作区过滤配置，可按指定项目采集，避免无关数据进入日志。

对于Codex工具，我们实现了OTLP（OpenTelemetry Protocol）HTTP接收器，能够接收Codex发送的遥测数据。Codex本身支持OTLP协议，我们只需要在其配置文件中指定我们的接收端点即可。

OTLP接收器会解析接收到的日志数据，提取出工具调用信息，特别是apply_patch事件。通过分析patch内容，我们能够准确识别出文件变更的类型、影响范围和具体内容。

为支持非标准工具或轻量接入场景，我们在 Codex 遥测 HTTP 服务中扩展了通用“Code Report”入口（/v1/code）。该入口仅接收 JSON 请求、限制体积，并通过 clientType 白名单做准入控制，确保不会被随意注入无效数据。请求进入后会触发processCodeReportPayload完成日志数据统一标准化。

核心逻辑分三步：

1. 校验与归一化：检查 clientType / toolName / content，若 filePath 缺失则尝试从 diff 内容推断；再结合 cwd 归一化路径。

2. 工具分类与解析：将工具映射为 create_file / replace_in_file 两类。新增文件会把正文转换为统一 diff 结构；修改类则解析 unified diff，统计增删行数并构建 inline diff。

3. 统一上报：补齐 repo 信息（从 cwd 解析，缺失则给默认值），生成 sessionId/uuid，最终拼成标准 SLS 上报 payload，并落盘日志与统计处理结果。

最终只要能按约定把“文件路径 + diff/内容 + 工具类型”通过 HTTP 上报，就可以复用现有的标准化与上报链路，实现更多生码工具接入的采集诉求。

整个采集系统以后台服务的形式运行，我们提供了完整的服务管理脚本。在macOS平台上，系统会自动创建LaunchAgent服务，确保采集服务在用户登录后自动启动并持续运行。

服务安装脚本会自动检测系统环境，创建必要的日志目录，配置环境变量，并注册系统服务。服务支持自动重启、日志轮转等企业级特性，确保长期稳定运行。卸载过程同样简单，只需要运行卸载脚本即可完全清理服务和相关文件，不会在系统中留下任何残留。

为了降低维护成本，我们引入独立的AutoUpdater守护进程，负责定期检查并自动升级采集服务版本。AutoUpdater与采集主服务分离运行，通过统一的Service Manager在macOS/Windows上安装为系统服务，避免影响用户日常工作。

自动更新在后台定时每小时检查仓库源版本号，若有新版本就停采集服务 → npx @ali/ai-coding-trace@latest 自动升级 → 启动校验，失败则回滚旧版；状态/锁写入日志文件。自动更新服务采用延迟 60 秒后台启动，除了不阻塞 CLI，还用于给采集服务的安装/启动与旧版 AutoUpdater 的停止/锁释放留出缓冲，避免在服务切换窗口内并发启动导致的锁冲突或状态不一致。等采集服务稳定后再接管更新，整体更稳定。

当前采集服务已支持 macOS 与 Windows。两端差异主要体现在：

为此我们做了统一抽象与兼容处理，保证在采集路径、日志落盘和服务生命周期上行为一致、可控：

• 通过统一的路径解析函数屏蔽差异，在Windows上将日志根目录放在ProgramData中以保证服务可写，在启动时从env中自动识别USERPROFILE/HOME/APPDATA等路径，避免后续路径偏移。

• 服务安装层统一走platform-service-manager模块来适配不同系统平台。

• Hook 注入时自动根据平台选择合适的脚本。

在轻量化设计方面，我们的方案彻底摆脱了传统侵入式修改的弊端。CLI工具的Hook脚本仅有几十行代码，执行时间控制在毫秒级别，对原有工具的运行性能几乎没有任何影响。用户不需要维护任何定制版本，当工具升级时采集功能能够自动保持兼容。这种设计哲学让我们避免了重量级插件方案的复杂性，用户只需要一条简单的命令就能完成整个接入过程，极大地降低了使用门槛。

用户体验的无感化是我们方案的另一个突出特点。与高德团队采用的MCP拦截方案不同，我们选择了异步采集策略，所有的数据处理工作都在后台静默进行，不会在文件编辑时产生任何可感知的延迟。用户完全不需要改变现有的工作习惯，也不需要主动安装配置任何插件，整个采集过程对用户来说是完全透明的。这种设计让开发者能够专注于代码创作本身，而不会被采集机制所干扰。

在可靠性保障方面，我们构建了多层次的防护机制。本地文件缓存确保了数据的持久性，即使在网络异常的情况下也不会丢失重要信息。重试机制和版本兼容性检查进一步增强了系统的鲁棒性，能够有效应对各种异常情况。特别值得一提的是，我们通过解析工具的原生数据存储（比如Qoder的SQLite数据库）来获取信息，这种方式比MCP拦截方案更能保证数据的完整性和准确性。同时，各个工具的采集模块相互独立，当某个工具出现问题时不会影响其他工具的正常工作，系统具备了良好的故障隔离能力。

扩展性设计是我们方案的长远考虑。整个系统采用了插件化架构，当需要支持新的AI工具时，开发者只需要实现对应的Collector组件，而无需对核心框架进行任何修改。我们将来自不同工具的异构数据统一转换为标准格式，这不仅便于后续的分析处理，也为未来的功能扩展打下了坚实基础。系统同时支持Hook机制、数据库解析、OTLP协议等多种采集方式，能够灵活适配各种类型的AI工具，为生态的持续发展提供了技术保障。

经过近期的线上运行，我们的采集系统已经稳定采集了大量的AI代码生成数据。这些数据为我们分析AI工具的使用模式、评估代码生成质量、优化开发流程提供了重要支撑，最终会在数据报表上统一加工，实现对AI代码采纳率的统一计算。

我们未来计划在以下几个方向继续优化：一是扩大工具支持范围，覆盖更多的AI编程工具；二是增强数据分析能力，提供更加丰富的统计和洞察功能；三是优化部署和运维体验，让更多团队能够便捷地使用我们的采集方案。