3 个月烧掉 $20K Token，我们用 AI 重构了 pandas 兼容生态
本文字数：1970；估计阅读时间：5 分钟
作者：Auxten Wang
本文在公众号【ClickHouseInc】首发
我们构建了 chDB DataStore —— 一个覆盖 600+ 方法的 pandas 兼容层，底层由 ClickHouse 驱动。整个项目完全由 AI 驱动完成。以下是我们在实践中总结出的、真正有价值的 AI 辅助开发经验：
1. 把规则写进项目，而不是只存在于你的脑海中
AI 没有跨会话记忆。你今天教会它的一切，明天都会消失。把每一个“AI 反复犯的错误”写进 CLAUDE.md 文件，并提交到代码仓库。
我们明确禁止 AI 编写“伪测试”—— 只用注释描述预期行为却没有断言，只验证 len() 却不检查实际值。对人类来说这显而易见，但对 AI 来说，如果你不明确写清楚，它是意识不到的。
这个文件同时也是团队协作的共享规范。否则，每个人都会在本地各自调教 AI 的行为，而这些经验无法沉淀和共享。
2. 在早期阶段，深度对齐比快速迭代更重要
在项目初期，观察 AI 的推理过程，比让它快速产出代码更有价值。当它的逻辑开始偏离你的预期时，问自己两个问题：是我的判断本身错了？还是我没有把意图表达清楚？这两种情况都会发生，而且需要完全不同的应对方式。而这个不断校准的过程，本身就会沉淀为你的 CLAUDE.md。
3. 刻意引入外部视角
你和每天使用的 agent 会逐渐形成共同的盲区。我们会定期使用一个全新的 agent，在完全没有项目上下文的情况下，让它从外部视角评估 chDB。
这里有两个关键词非常关键：critical —— 明确要求它主动找问题，而不是“帮你优化”（AI 的默认倾向是迎合，你需要刻意打破这种模式）；rational —— 要求结构化的推理，而不是模糊的感觉（问题是什么，为什么是问题，证据在哪里）。对于像 Opus 4.6 这样的模型，你不需要过度设计提示词，只要设定好正确的语境框架即可。
我们使用 claude.ai/code（支持代码执行的网页版 Claude，而不是 Claude Code CLI）来完成这件事。它可以直接 pip install 你的库，运行真实代码，并在同一个会话中给出客观反馈 —— 不会默认接受你的假设。
这些反馈往往刺耳，但极具价值：那些你已经视而不见的报错信息，被你合理化的 API 不一致，以及对任何新用户来说都显而易见的文档缺口。你日常使用的 agent 永远不会指出这些 —— 它已经像你一样学会绕过这些问题。
4. 把 pandas 本身作为测试预言机
我们的目标是实现 pandas 兼容性，因此最好的测试方式就是：在真实项目中找到 pandas 代码（GitHub/Kaggle notebooks），替换一行 import，然后对比输出结果。我们构建了一条由 5 个 AI 智能体组成的流水线来自动化这一过程 —— 包括测试生成、问题修复、架构分析、代码审查和基准测试。
5. 规则比提示词更重要
观察 AI 是如何走捷径的，然后制定明确的禁止规则。比如测试因为行顺序不一致而失败？AI 最常见的做法是直接添加 .sort_values() 让测试通过。但这不是修复 bug —— 而是在掩盖问题。我们明确禁止这种做法。确实无法对齐的情况会被标记为 XFAIL，而绝不会被悄悄跳过。
6. Agent 流水线：filesystem > conversation history
我们在 Cursor 中使用 Python 脚本编排多 AI 智能体工作流。文件系统是共享的上下文层 —— 每个 agent 将结果写入 tracking/ 目录，下一个 agent 读取所需内容。这种方式远比把整段对话历史塞进提示词灵活得多。
核心模式包括：角色分离、结构化决策（以 JSON 形式输出 APPROVE/REJECT/ESCALATE）、以及失败时自动执行 git 回滚。只有真正可用的变更，才会进入 main 分支。
归根结底，AI 擅长的是规模化工作 —— 对齐数百个函数、生成成千上万条测试、发现回归问题。但它无法替你做判断：这是 bug 还是 feature？架构是否合理？这些仍然需要由你来承担。
最后，这是我们在过去三个月里完成的成果，总计消耗超过 $20K 的 Token。https://github.com/chdb-io/chdb
征稿启示
面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com