目录

  1. 问题
  2. 啰嗦的 chatgpt
  3. 精准的 claude
  4. 结语
  5. END

问题

最近要上一个用到 clickhouse 的服务，我没有这方面经验，之前仅仅在部署 langfuse 时遇到过，但是也只是跟着 chatgpt 设置了一些表的 ttl。所以这次还是高度依赖 chatgpt 帮我设计表、写初步代码、部署和进行其他优化讨论。

刚开始进行挺顺利，帮我简单入门了下 clickhouse，经过一系列讨论，写了 sql 和插入查询代码。终于该部署了。我在本地测试时这一步也很顺利，然后在发布到线上后，容器死活起不来，一直在 restarting，通过日志可以看到如下错误（我手动进行了 wrap 以更方便查看）：

1
2
3
4
5
6
{} <Error> Application: Caught exception while loading metadata:
Code: 722. DB::Exception: Waited job failed: Code: 695.
DB::Exception: Load job 'load table system.latency_log' failed:
Code: 74. DB::ErrnoException: Cannot read from file 28: ,
errno: 1, strerror: Operation not permitted: Cannot attach table
system.latency_log from metadata file ...

后面还有很长我就不贴了，看起来像是 sql 语句。

啰嗦的 chatgpt

没经验的我第一眼看起来像是权限问题，可能是挂载的目录权限有问题，问了 chatgpt 5.4 thinking，也说是这个问题：

后面给我的详细原因也是这个：

解决方案也是删除挂载目录，重新来：

我现在本地复现，复现不了。然后我尝试按照它提供的方向进行调试。我当前的持久化方式是显式挂载到本地目录，类似这样：

1
2
volumes:
  - ./data/clickhouse:/var/lib/clickhouse

于是我进行了如下尝试：

  1. 挂载到 docker 管理的 volume：

    1
    2
    3
    4
    5
    6
    7
    8
    services:
    	...
    	volumes:
    	  - clickhouse_data:/var/lib/clickhouse
    	...
    	
    volumes:
      clickhouse_data:

    这样数据完全由 docker 管理，而且也是全新的 volume，应该不会再存在权限问题。

  2. 删除该目录。

  3. 不再挂载该目录。

以上均无效，仍然报之前的错误。由于我无法登录线上机器，所以哪怕查看 docker 日志这么小的操作也是比较麻烦。再加上其中各种问题，其中还需要找运维帮忙，以及过程中和 chatgpt 的多次交流，昨天一下午都在搞这个事情。

当我尝试完 1 无效后，去把结果丢给 chatgpt，它认为可能是我指定的那个 volume 是一个旧的 volume，里面有残存数据；或者 clickhouse 镜像版本太高；或者镜像的 seccomp 触发了容器内文件异步读取的 Operation not permitted ，由此它推荐我进行如下操作：

从事后诸葛亮来看，其实它在这里已经提到了正确的解决方案：就是这里的 3。只是到这里，我的耐心已经被消耗大半，它的回复每次又非常啰嗦（尽管我已经在个性化中对此进行了限制，比之前有好转，但是仍然不够精炼），导致我没有再进行测试的耐心了。而且由于我无法登录线上机器，所以 1 我实现不了，要实现就得找运维，又得来回好一会儿。对于 2，那也很麻烦，降级就意味着要下载新镜像，还要再推送到我们自己的仓库中，改 compose 文件，鉴于我们的网速和这个流程，我也就放弃了。而且我也不赞成 1 和 2 是潜在的原因。这就导致正确方案被我忽略了，我已经没有耐心听它的意见了。

接下来更是偏离了方向。由于我在配置中禁用了很多系统表，所以我问它是不是这些配置导致的。它回答有可能：

然后建议我先不要挂载配置。我接着问它有无可能是我的挂载方式覆盖了原本的配置导致的：

我对这个完全不懂，所以才会怀疑是不是覆盖了配置文件。然后我又对这个挂载方式进行了一些调试，无果。事后证明这个目录就是用来存放额外的配置的，默认是空的，所以不存在我怀疑的这个问题。理想情况是此时 chatgpt 应该要指出来这点，直接告诉我这个不是原因。

现在来看上面这些，就让我想到了 llm 的“大海捞针” The Needle In a Haystack 测试，这就像 llm 反过来测试我的大海捞针能力一样，测试我能不能在一堆啰嗦的废话中找到那个 needle。关于废话这点，5.3 instant 说是有所改进，当初我的测试也是似乎比之前好点，不过这个改进是不是没用到 5.4 上啊：

5.3 instant 的改进5.3 instant 的改进

然后这个问题我就先搁置了，交给运维，我先下班了，被这玩意儿折腾得不行。哦对了，我后来还想到这个大海捞针的问题，担心 context 可能太大了，模型性能下降了。所以我又开了一个新会话，把报错、当前的 compose 文件、当前的 clickhouse 配置文件给它：

回答的一部分回答的一部分

相对来说要比之前的好点，但是之前那个啰嗦的问题仍在。它的这种表达方式和我当时的心情，成功让我错过了正确方案。

精准的 claude

第二天上班后，我想着用 claude 试一试，虽然我没有 opus 可用，sonnet 试试也可以。于是我把相同的内容发给 sonnet 4.6，结果一针见血，直击要害：

修复 2 无效，1 是正确方案。简明扼要，直击要害。sonnet 4.6 完美诠释了这点。要不是 anthropic 封号和 ip 封的厉害，我也很想开他们家会员。

结语

不过回过头来，chatgpt 大部分时间还是不错的。虽然看起来我是在表扬 sonnet 批评 chatgpt，但是我最后想说的是，当你被一个 bot 气得不行的时候，不要着急，歇一歇，换另一个 bot 试试，众人拾柴火焰高，在座的各位都发表发表意见，头脑风暴一下，说不定解决方案就来了。

但总之，说话不要太啰嗦！

END