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.Wangclickhouse.com