引子：一个悖论
OpenClaw 是一个重度使用 AI 编程构建的产品–它本身就是 AI 辅助开发的典范。但作为深度用户，我们在日常使用中却发现了一个有趣的现象：几乎每一个版本的升级都会带来一系列严重的问题。
我们当前使用的 2026.6.11 版本，就同时存在多个问题：
- 需要手动打 6 个补丁才能正常工作，涉及会话冲突、文件查看器、路径白名单等多个 bug
- 浏览器 profile 连接失效，内置的
userprofile 无法连接到已启动的 Chrome - PR 审核极其缓慢，bug 修复迟迟无法合并到主线
这不禁让人思考：AI 编程的能力边界到底在哪里？
一、真实案例：看起来修好了，其实没有
最典型的例子是 #99241 这个 bug：当会话上下文累积到 100K+ 时，工具结果会被替换为 (see attached image) 占位符，导致模型无法读取工具输出。
有人提了一个 PR（#99756）声称解决了这个问题。从他的角度来说，他确实测了–图片占位符不出现了，他认为问题解决了。
但实际打上 patch 之后发现：图片占位符确实没了，取而代之的是工具结果直接变成空对象 {}。问题没有解决，只是换了一种形式失败，而且更严重了–原来至少能撑到 180K 上下文，打完 patch 后 120K 就出问题。
这就是 AI 编程的典型问题：局部正确，全局错误。AI 能理解”这个函数该返回什么”，但很难理解”这个改动在 120K 上下文、特定序列化路径下会触发什么连锁反应”。
二、Patch 循环：被逼出来的自助修复
因为 PR 审核慢、合并慢，我们被迫维护了一套 patch 管理机制。目前有 6 个 patch，每个 OpenClaw 升级后都要重新打一遍：
| Patch | 对应 Issue/PR | 等待时间 | 现状 |
|---|---|---|---|
| reply session conflicted | #98416 / PR #100178 | 数周未合并 | 每次升级重新打 |
| 工作区文件查看器后端 | #100615 | feature request，排期未知 | 每次升级重新打 |
| 工作区文件查看器前端 | #100615 | 同上 | 每次升级重新打 |
| Control UI 路径白名单 | #10210240 | issue 提了没人理 | 每次升级重新打 |
| attachment 栈溢出 | 无对应 PR | – | 每次升级重新打 |
| Control UI 服务端路径 | #10210240 | 同上 | 每次升级重新打 |
这个循环本身就说明了一个问题：用户被迫自己修 bug，而每次官方升级又会覆盖掉这些修复。这不是正常的开源软件使用体验。
三、浏览器问题：设计上的死结
2026.6.11 版本引入了 profile="user" 的内置 profile，通过 Chrome MCP transport 连接浏览器。它的 auto-connect 机制依赖在 Chrome 默认用户数据目录下查找 DevToolsActivePort 文件来发现 Chrome 实例。
但我们的 Chrome 必须用非默认的 --user-data-dir 启动（因为登录态都在自定义目录里），所以 auto-connect 找不到文件，连不上。
那能不能用默认目录启动 Chrome？试了，Chrome 146 直接拒绝：
DevTools remote debugging requires a non-default data directory. Specify this using --user-data-dir.
这就形成了一个设计上的死结：
- Chrome 要求：remote debugging 必须用非默认
--user-data-dir userprofile 的 autoConnect 要求：Chrome 必须用默认--user-data-dir
两条规则互相矛盾，在需要 remote debugging 的场景下，profile="user" 设计上就不可用。这种”两个模块各自逻辑正确，组合在一起却完全不工作”的情况，正是复杂系统问题的典型特征。
四、为什么 AI 编程解决不了这些问题
1. 生成容易，验证难
AI 能在几分钟内生成一个看起来正确的 PR，但审核这个 PR 是否安全可能需要几小时–因为复杂系统里，验证成本远高于生成成本。一个改动是否安全，取决于它对整个系统运行时行为的影响，这需要”运行时的体感”，而不仅仅是静态代码分析。
2. 边界条件覆盖不足
CI 跑的都是标准路径，但真实用户的运行环境千差万别：root 用户、非默认 Chrome 目录、自定义 agent workspace、多个补丁共存……这些边缘组合 AI 和 CI 都覆盖不到。只有真正在复杂环境中深度使用的用户才会碰到。
3. PR 质量稀释
AI 降低了提 PR 的门槛，大量”看起来对”的 PR 涌入。维护者审不过来，审核变慢，着急的功能合并慢，不着急的 bug 一直挂着。甚至维护者可能也用 AI 辅助 review–AI 写的代码 AI 审，形成信息茧房。
4. 理解系统 vs 写代码
软件复杂度到一定程度后，理解系统行为比写代码难得多。AI 擅长后者，不擅长前者。它能写出局部正确的代码，但很难预判这个改动在特定上下文大小、特定序列化路径、特定模块组合下会触发什么连锁反应。
五、结论：AI 提效是真的，但别吹过头
我们不否认 AI 编程的价值–它能显著提升开发效率，降低编程门槛，让更多人能参与开源贡献。这些都是真实的。
但把 AI 编程吹成”颠覆式””革命性””取代程序员”，至少在复杂系统工程上，还没有被验证。
我们用 OpenClaw 的实际体验就是最好的反例：一个 AI 编程构建的产品，用户每天都在给它擦屁股。6 个 patch 每次升级重新打，浏览器 profile 设计上不可用，PR 审核慢到用户被迫自己修 bug……这些都是 AI 编程在复杂系统面前的真实局限。
AI 能提效，但复杂系统的边界条件、模块交互、运行时行为–这些地方仍然是人类工程师的领域，至少目前是。
与其说 AI 会取代程序员，不如说 AI 正在倒逼程序员升级：从”写代码的人”变成”理解系统的人”。前者 AI 已经能做，后者才是真正的核心竞争力。