AI（人工智能）编程工具正在产生一种新的数据：开发者和模型之间的真实协作记录。
这些记录不只是普通聊天。它们包含需求拆解、代码生成、报错排查、上下文补充、反复修改、最终收敛等过程。相比只看 Git 仓库里的最终代码，AI 编程对话更接近开发过程本身，也更能反映模型在真实任务中应该如何协助人类完成工作。
DataClaw 要解决的问题很直接：把本地 AI 编程终端里的对话记录导出来，经过脱敏处理后，整理成可以长期保存、分析或共享的数据集。
它支持的典型来源包括：
- Claude Code
- Codex
- Gemini CLI
导出的数据可以保存在本地，也可以上传到 Hugging Face。上传后的数据集会带有统一的 dataclaw 标签，方便后续检索和聚合。
DataClaw 解决的核心问题
使用 AI 编程终端时，对话通常散落在不同工具自己的本地目录里。开发者想复盘某次调试过程、整理高质量样本，或者把自己的数据贡献给开源社区，都会遇到几个麻烦：
| 问题 | 具体表现 | DataClaw 的处理方式 |
|---|---|---|
| 数据分散 | 不同 AI 终端有不同的存储位置和格式 | 统一读取 Claude Code、Codex、Gemini CLI 等来源 |
| 数据不适合直接公开 | 路径、用户名、密钥、令牌、数据库密码可能混在对话里 | 导出前执行隐私扫描和脱敏 |
| 缺少标准格式 | 原始记录不方便训练、检索和共享 | 整理成结构化文本记录 |
| 上传过程容易误操作 | 一旦把敏感信息传到公开平台，风险很难完全消除 | 每个关键步骤都需要用户确认 |
| 数据集难以被发现 | 零散上传后缺少统一标识 | Hugging Face 数据集统一打上 dataclaw 标签 |
它不是一个训练框架，也不是一个模型微调工具。DataClaw 更像是 AI 编程数据的采集、清洗和发布管道。
为什么 AI 编程对话记录有价值
模型蒸馏是一种常见训练方式。简单说，就是让一个模型学习另一个模型的输出行为：输入同样的问题，观察强模型怎么回答，再用这些输入输出样本训练另一个模型，使后者获得一部分能力。
在编程场景里，真实对话数据的价值尤其高，因为它不只包含“问题”和“答案”，还包含中间过程：
flowchart LR
A[开发者提出需求] --> B[AI 给出初始方案]
B --> C[开发者补充约束]
C --> D[AI 修改代码]
D --> E[运行后出现报错]
E --> F[开发者贴出日志]
F --> G[AI 定位问题]
G --> H[形成可用实现]
公开代码库只能看到结果，很难看到“为什么这么改”。而 AI 编程对话能保留这些过程信息：
- 需求如何被拆成小任务；
- 模型第一次回答哪里不够准确；
- 开发者如何补充上下文；
- 报错信息如何影响后续修改；
- 最终代码是怎样一步步收敛出来的。
这类数据对训练下一代编程模型、评估模型调试能力、研究人机协作方式都有用。但它也天然包含隐私风险，所以不能把原始日志直接公开。DataClaw 的价值就在于给开发者一个可控的出口：导出之前先清洗，上传之前再确认。
DataClaw 的整体工作流
DataClaw 的导出流程可以理解为五步：选择来源、限定范围、预览数据、隐私扫描、确认发布。
flowchart TD
A[启动 DataClaw] --> B[选择数据来源]
B --> C[确认项目范围]
C --> D[本地预览导出内容]
D --> E[执行隐私扫描与脱敏]
E --> F{是否上传到 Hugging Face}
F -- 否 --> G[保存在本地]
F -- 是 --> H[用户确认]
H --> I[推送数据集]
I --> J[添加 dataclaw 标签]
这里最重要的一点是：上传不是默认动作。数据会先在本地完成扫描和预览，用户确认之后才会推送到 Hugging Face。
这种设计能降低误传风险。尤其是开发者的对话里经常会出现本地路径、仓库名称、内部接口、测试账号、环境变量名，甚至直接粘贴过密钥或日志。把确认点放在上传前，是必要的安全边界。
隐私清洗做了哪些事
DataClaw 在导出过程中内置了多层脱敏处理，目标是尽量去掉不应该进入公开数据集的信息。
| 信息类型 | 风险 | 处理方式 |
|---|---|---|
| 绝对文件路径 | 暴露本机用户名、项目目录、组织命名习惯 | 转成相对路径或进行归一化 |
| 用户名 | 暴露个人身份或机器信息 | 替换成匿名编码 |
| API Key | 可能被他人调用付费服务或内部系统 | 扫描后删除或打码 |
| Token | 可能获得仓库、云服务、平台账号权限 | 扫描后删除或打码 |
| 数据库密码 | 可能导致数据库被访问 | 扫描后删除或打码 |
| 项目内部信息 | 可能涉及商业秘密或未公开实现 | 需要人工复查 |
自动脱敏只能覆盖常见模式。比如 sk-... 这类密钥格式容易被识别，但一些内部系统的自定义令牌、业务参数、客户名称、私有域名，并不一定能被工具准确判断。
公开前最好再做一次人工检查。可以用正则命令辅助扫一遍导出目录：
grep -RInE "(password|passwd|token|secret|api[_-]?key|access[_-]?key|private[_-]?key)" exported/
如果项目里可能出现云厂商密钥，也可以增加更具体的规则：
grep -RInE "(AKIA[0-9A-Z]{16}|AIza[0-9A-Za-z_-]{35}|ghp_[0-9A-Za-z]{36}|sk-[A-Za-z0-9_-]+)" exported/
这些命令不能替代人工审查，但能帮助快速发现高风险片段。
导出的数据长什么样
DataClaw 会把对话整理成结构化文本。资料中描述的是“每行是一条完整的对话记录”，这类设计通常接近 JSONL（JSON Lines，一行一个 JSON 对象）的组织方式。
一个合理的数据记录大概会包含这些信息：
{
"source": "claude_code",
"project": "example-project",
"messages": [
{
"role": "user",
"content": "这个函数在空数组输入时会报错，帮我看一下。"
},
{
"role": "assistant",
"content": "问题出在没有处理 length 为 0 的情况，可以先增加边界判断。"
}
],
"metadata": {
"created_at": "2026-02-28T10:00:00Z",
"sanitized": true
}
}
实际字段应以 DataClaw 的导出结果为准。关键不在字段名，而在它把多轮对话、来源信息、清洗状态放进了统一结构里。这样后续无论是做搜索、统计，还是转成训练样本，都会比直接处理各工具的原始日志更方便。
安装和上手
DataClaw 可以通过 pip 安装：
pip install dataclaw
安装完成后，通过命令行进入交互式流程：
dataclaw
典型操作顺序如下：
sequenceDiagram
participant Dev as 开发者
participant CLI as DataClaw CLI
participant Local as 本地 AI 工具记录
participant Scan as 隐私扫描器
participant HF as Hugging Face
Dev->>CLI: 启动导出流程
CLI->>Dev: 选择 Claude Code / Codex / Gemini CLI
CLI->>Local: 读取本地对话记录
CLI->>Dev: 确认项目范围
CLI->>Dev: 展示本地预览
CLI->>Scan: 执行脱敏扫描
Scan-->>CLI: 返回清洗后的数据
CLI->>Dev: 请求最终确认
Dev->>CLI: 确认上传或仅本地保存
CLI->>HF: 推送数据集并添加 dataclaw 标签
如果选择上传到 Hugging Face，需要准备可写入数据集的账号权限。更稳妥的做法是先只导出到本地，检查无误后再上传。
推荐流程是：
# 1. 安装工具
pip install dataclaw
# 2. 启动交互式导出
dataclaw
# 3. 先选择本地保存，完成后人工检查
grep -RInE "(password|token|secret|api[_-]?key)" exported/
# 4. 确认无敏感信息后，再选择上传到 Hugging Face
哪些场景适合用 DataClaw
DataClaw 适合“开发者主动管理自己的 AI 编程数据”的场景，但并不适合所有项目。
| 场景 | 是否适合 | 原因 |
|---|---|---|
| 个人开源项目的 AI 编程记录 | 适合 | 代码和讨论本身可以公开，清洗后风险较低 |
| 想长期保存自己的 AI 协作过程 | 适合 | 即使不上传，也可以把对话沉淀成本地资料 |
| 构建编程模型评测样本 | 适合 | 真实调试和修改过程比单轮问答更有分析价值 |
| 公司内部闭源项目 | 谨慎 | 可能包含商业秘密、内部接口和客户信息 |
| 医疗、金融、政务等强合规项目 | 不建议直接公开 | 数据合规要求高，自动脱敏不够 |
| 未经审查的大规模上传 | 不适合 | 一旦公开敏感信息，后续补救成本很高 |
判断能不能公开，不只看工具能不能脱敏，还要看数据本身有没有共享资格。比如公司代码、客户需求、内部日志，即使去掉了用户名和密钥，也可能仍然不能公开。
使用时容易忽略的坑
自动脱敏不是安全承诺
DataClaw 的清洗流程能处理常见敏感信息，但不能保证百分百覆盖。项目 README 中也明确提醒过：这不是万无一失的方案。
比较危险的内容包括：
- 内部域名；
- 客户名称；
- 业务编号；
- 私有仓库地址；
- 只在公司内部使用的环境变量；
- 日志里夹带的用户数据；
- 模型回答中复述出来的敏感内容。
这些信息不一定符合常见密钥格式，自动扫描可能不会拦下来。
上传前要确认服务条款
AI 编程工具生成的内容，可能受到对应服务条款约束。不同平台对输出内容、使用限制、再训练、商业用途的规定不一样。
公开数据前至少要检查三类约束：
| 约束来源 | 需要确认什么 |
|---|---|
| AI 工具服务条款 | 是否允许导出、公开、用于训练或再分发 |
| 项目代码许可证 | 代码片段是否允许作为数据集发布 |
| 公司或组织制度 | 内部项目对日志、代码、需求文档是否有保密要求 |
如果数据来自工作项目，不能只按个人意愿决定公开范围。
对话记录可能泄露思考路径
即使没有密钥，对话本身也可能暴露很多信息。比如你让模型排查一个支付接口的漏洞，哪怕接口地址被替换了，问题描述和修复方式仍然可能透露系统设计。
脱敏处理的是显性敏感字段，不能自动判断“业务语义是否敏感”。
数据质量需要额外整理
把对话上传到 Hugging Face，并不等于它马上能用于训练。高质量数据集通常还需要：
- 去掉失败或无意义对话；
- 标注任务类型；
- 标记最终答案是否可用；
- 删除重复样本；
- 过滤过长上下文；
- 统一许可证和数据说明。
DataClaw 解决的是导出和清洗的入口问题，不负责完成全部数据治理工作。
DataClaw 的意义：把选择权放回开发者手里
AI 编程对话正在变成一种新的数字资产。它既有复盘价值，也有训练价值；既可能推动开源模型进步，也可能带来隐私和合规风险。
DataClaw 的关键点不是“鼓励所有人公开对话”，而是提供一个可控流程：
flowchart LR
A[本地对话记录] --> B[开发者选择范围]
B --> C[脱敏与预览]
C --> D{开发者决定}
D -- 私有保存 --> E[本地归档]
D -- 公开共享 --> F[Hugging Face 数据集]
公开、私藏、删除、归档，都应该由数据持有人主动决定。DataClaw 给出的路径是：先把数据从各个 AI 终端里取出来，再通过清洗和确认流程降低风险，最终由开发者决定它的去向。
项目地址：
https://github.com/peteromallet/dataclaw