不懂代码的小会计,让OpenClaw给自己修了Bug

这件事情的起因很简单。

一个体验问题

很多人用OpenClaw聊天的时候，总觉得它回复特别慢。

这是因为我们平时用的AI聊天工具，大多是流式回复的。你问一个问题，AI一个字一个字地往外蹦，像打字一样，你能看到它在思考。

但OpenClaw不一样。它在后台把整段回复全部生成完毕之后，才一次性发给你。

这就像你去餐厅吃饭，厨师把所有菜全做完了，才一起端上来。等待的时间，就显得特别漫长。

我想解决这个问题。翻了翻文档，找到两个方案。

第一个方案叫分块回复。后台收集到一定量的内容，就先发一部分出来。效果是一块一块的。

第二个方案是通过不断编辑已发送的消息，实现流式生成的效果。

我试了第一个方案，效果还不错。后来我发现还有第二种方案，通过不断编辑文本实现流式效果。我让AI帮我配置好，一开始还挺兴奋的。这流式生成的观感，比分块输出好太多了。

但是，我打开后台一对比，才发现问题。这个所谓的流式生成，是等全部生成完成之后，再通过sleep假装一点点编辑出来的。是假的。我质问它，它也老实承认了。

真正的流式输出

我不甘心。

既然文档里说有这个功能，应该不会是用这种方式糊弄人的。

于是我把Tg的文档和OpenClaw的文档都发给它，让它好好研究一下。

它告诉我，有个功能叫draft streaming。还告诉我需要打开bot配置的private topics。我完全不懂这是什么东西，就问它。它说这是私聊且开启话题分组的场景，消息里要带message_thread_id这个参数才能用。好，我按照它的指引，打开BotFather，进入我的Bot设置，打开了这个选项。打开这个模式之后，聊天界面就会变成带分组功能的话题式对话。你可以新建多个主题，进行分组聊天，每个主题的内容都是独立的，还可以并发同时使用。

为什么要打开这个私聊的分组对话功能？因为开发者在文档里反复强调，只有在私聊分组模式才能启用流式生成输出。

Bug出现了

我告诉它已经打开了这个模式，让它给我配置好。但是问题来了。回复还是没法回到对应话题，它仍旧是在新聊天那个主对话框里进行回复的。看这个测试对话可能更明显。前面的test都是失败的，它的回复都跑到新聊天那个窗口了。我不懂代码啊。我就跟它抱怨，回复还是跑回了主聊天流里面，并且告诉它我已经升级到最新发行版了，帮我根据文档详细分析解决问题。

AI自己修自己

接下来发生的事情，让我有点意外。它把默认没打开的debug日志模式打开了，然后重启了自己，自动续上任务去查日志。它找到了问题所在，修改了代码，再次重启自己。

问题解决了。它还帮我把修复代码提交到了官方仓库。官方也是瞬间进行了CI/CD，全自动对代码进行了审核。

问题的始末

后面它自己总结了整个问题解决过程。

起因是我在Tg上测试流式编辑输出。测试结果显示，当前Tg通道确实能edit，所以编辑式流式在这套环境里可行。

中间阶段，为了排查Tg thread/topic相关问题，它开始看文档、开debug。从会话日志里能看到一系列排查动作。查文档、查Tg Bot API、关注message_thread_id和is_topic_message等字段、多次调整配置、多次重启。

关键转折点出现了。为了修复私聊topics的thread路由问题，它做了一个功能逻辑hotfix。

改动的文件是bot-message-context.js。改动点是resolvedThreadId的计算逻辑。以前不区分群组和私聊，都走同一套逻辑，里面可能有兜底到General=1的处理。现在改成群组才走forum resolve，私聊直接用原始message_thread_id。目的是让Tg私聊的topic/thread不再被forum的兜底逻辑改写或吞掉，从而避免回复落回主线程。

最后它把这个功能逻辑改动提交到了官方GitHub。

这代表了什么

OpenClaw的创作者Peter在最近的播客里说过一句话。他现在写的代码比以前更好了，尽管他不再亲自写代码。而且他一天能提交600个commit，很多自己都没看过，但都能跑通。

这听起来很矛盾。但仔细想想，很有道理。

他说他以前会为每一个空格、每一个换行、每一个命名纠结很久。现在回头看，觉得很浪费时间。客户看不到代码内部。代码要能工作，要快，要安全，但具体怎么实现，真的那么重要吗。

他现在的工作方式是这样的。和模型对话，讨论架构，讨论取舍，讨论功能应该怎么设计。然后说一个字，做。模型去做，他去做下一件事。

他感觉自己像个建筑师。他不砌砖，但他设计整栋楼的结构。他关心的是系统架构，是用户体验，是产品方向。具体的代码实现，交给AI。

他发布自己没看过的代码，是因为他建立了一套完整的验证机制。他让AI写代码的同时，也让AI写测试。代码能跑通所有测试，他就敢发布。他甚至觉得以后pull request应该改名叫prompt request。因为他收到一个PR，看的不是代码本身，而是提交者当时用的prompt是什么。prompt能告诉他，这个人是怎么思考这个问题的，比看最终的代码更有价值。

你看，我是一个小会计，完全不懂代码。但通过和AI的对话，AI自己找到了自己的Bug，自己修复了自己，还帮我提交到了官方仓库。

这件事让我意识到一个变化正在发生。

以前，遇到软件的问题，你要么等官方修，要么找程序员帮忙。现在，AI可以自己诊断问题、自己写修复代码、自己提交给开发者审核。普通人和技术之间的那道墙，正在变薄。

花更多时间在thinking上。

如果觉得不错，随手点个赞、在看、转发三连吧。如果想第一时间收到推送，也可以给我个星标。谢谢你看我的文章，我们下次再见。