夜雨聆风昨天飞书里我的 OpenClaw 机器人明月跟我说有新版本 OpenClaw 发布：
检测到有新版本可用。
当前版本：2026.4.2 最新版本：2026.4.11
看了一下，好些特性都还不错，也没想那么多，就去进行升级三部曲。
openclaw gateway stopnpm install -g openclaw@latestopenclaw gateway
意想不到的是 OpenClaw 的 gateway 又起不来。这个也不是破坏性升级啊。
看了一下报错日志，倒是有很明显的报错：Invalid config at C:\Users\ivan4.000.openclaw\openclaw.json:\n- channels.feishu.accounts.main: invalid config: must NOT have additional properties
后面还让运行 openclaw doctor --fix
运行了 doctor 之后，gateway 仍然起不来。
老老实实让 Codex 来救 OpenClaw：
OpenClaw升级到2026.4.11版本启动Gateway失败，提示
Restarted Scheduled Task: OpenClaw Gateway
Error: Config validation failed: channels.feishu.accounts.main: invalid config: must NOT have additional properties
Codex 一顿折腾（54条消息）后很快找到了问题：
很坑啊，botName 改成了 name，但是无论是升级过程还是 doctor 的修复，都完全没考虑这个。
Peter 当初将龙虾从 ClawdBot 改成 MoltBot 随即又改成 OpenClaw，应该是看出了这个产品的潜力，努力地把 bot 的名称去掉。
然而这些升级仍然做得那么毛糙，还好不是商业产品，不然还不被骂死。
光吐槽问题并不能自动让这个世界变得更好，我觉得这个坑可以让 doctor 自动修复，就让 Codex 写了一份 issue 准备去提交。
然而去打开那个 New Issue 的表单，看到一个又一个字段，感觉有点无语。我只想提个简单的bug，界面却那么复杂，像什么正式申请一样繁琐。
想了一下，继续让 Codex 出手：你能打开 https://github.com/openclaw/openclaw/issues 去提issue吗？那个表单内容有点多。
这时候有点惊喜，Codex 直接提示可以安装 GitHub 插件来操作，于是又折腾把 GitHub 插件装了。然而高兴得太早，Codex 的这个插件有 create_pull_request 功能，却没有 create_issue 功能。这个就很有问题，现在已经有说法 Code is cheap， 所以 pull request 没那么重要了，可以变成 prompt request。那么应该让更多的人来提 issue ，提出了合理的 bug，修复是很简单的事情。
我还是不想手动填写 New Issue 的表单，就提醒 Codex 可以使用一泽的 web-access skill 来填写。
Codex 调用 Skill 很顺滑，37 条消息就处理好了。一泽的 web-access skill 非常好用，不过如果是用于大量抓取小红书评论之类，保险起见，建议使用小号操作。
今天去看， https://github.com/openclaw/openclaw/issues/65177 这个issue已经有一个开发者提交了修复。
所以如果你在养虾，并且还想让它变得更好的话，就努力去提 Issue 或者 PR 吧。
Codex 的 GitHub 插件不能创建 Issue，我也去提了个 Issue，然后有位仁兄写了下面这段话，感觉非常有道理，也在此分享：
This is a good observation about the API surface gap. When an AI agent can read issues and create PRs but cannot create issues, it creates an awkward workflow where the agent has to ask the human to perform a manual step that is structurally identical to something it can already do programmatically.
这是一个关于 API 接口覆盖范围缺失的很好的观察。当一个智能体能够读取 Issue 并创建 PR，却无法创建 Issue 时，就会产生一种尴尬的工作流：智能体必须请求人类去执行一个手动步骤，而这个步骤在结构上与它已经能够通过编程完成的操作完全相同。
More broadly, we see this pattern frequently with AI-generated API integrations: the generated code covers the happy path for the operations the developer thought of, but misses operations that exist in the same API namespace. The agent can fetch_issue, search_issues, and create_pull_request, but creating an issue — the most basic write operation — is absent.
更广泛地说，我们在生成式 AI 生成的 API 集成中经常看到这种模式：生成的代码涵盖了开发者所想到的操作的“快乐路径”（happy path），但却遗漏了同一 API 命名空间中存在的其他操作。智能体可以 fetch_issue 、 search_issues 和 create_pull_request ，但创建 Issue——这一最基本的写入操作——却缺失了。
This type of API surface gap is hard to catch in code review because the code that exists is correct. The problem is the code that is missing. SonarQube and traditional linters do not check “does this integration cover all available operations?” — they validate what is there, not what is absent.
这种类型的 API 接口缺失在代码审查中很难被发现，因为现有的代码本身是正确的。问题在于缺失的代码。SonarQube 和传统的代码检查工具（linter）不会检查“此集成是否涵盖了所有可用操作？”——它们验证的是已有的内容，而不是缺失的内容。
We have found it useful to run an API coverage comparison that checks the operations an integration actually implements against the full API surface documented by the provider. It catches exactly this kind of gap — missing endpoints that belong to the same resource family.
我们发现运行 API 覆盖率对比非常有用，它可以将集成实际实现的操作与提供商记录的完整 API 接口进行比对。它正好可以捕捉到这类缺失——即属于同一资源系列但被遗漏的端点。
npx @opencodereview/cli scan . --sla L1 includes API coverage analysis for common integrations.
npx @opencodereview/cli scan . --sla L1 包含针对常见集成的 API 覆盖率分析。
