即刻App年轻人的同好社区
下载
工程师的日常
计算机工程师的逸闻趣事。
432817人已经加入
- 当下的 OpenClaw🦞 使用体验，其实还挺像当年 ChatGPT 4.x 刚出来时的阶段。能用，也确实能解决不少问题，但总感觉离人类自己上手的效果还差那么一点点。ChatGPT 4.x 很多时候需要通过各种 Prompt 调优，极力去压榨模型的智力。
OpenClaw 的具体表现就是，对 token 的消耗特别大。原因也很简单，它需要在一个模糊且复杂的问题集上找到算法路径。整个过程是一种探索式计算，需要不断试探、回溯和修正，对计算量和上下文都会有很大的消耗。
在当下这个阶段，想提升 OpenClaw 的“智商”，比较有效的办法，就是让它学习人类已经 SOP 化的一些操作。把人类已经验证过的路径直接变成能力模块，让 Agent 少走弯路。
例如使用浏览器，可以用 agent-browser 这一类组件。它的原理是把浏览器协议能力暴露成可编程接口，让模型可以直接读取 DOM、操作页面元素、执行脚本，用结构化的方式去控制浏览器，从而绕开很多低效的探索。
再比如对操作系统的使用，可以用 Hammerspoon。它通过 Lua 脚本桥接 macOS 的系统 API，让自动化脚本可以直接控制窗口、快捷键、菜单栏和应用状态。很多原本需要视觉识别、反复尝试的动作，会变成一次确定性的系统调用。
对于不懂技术底层的人来说，安装 find-skills 会很大程度提升提升 OpenClaw🦞 的水平，因为它具备寻找人类 SOP 的技能。
那 OpenClaw 的下一个“ChatGPT 5.x 时刻”什么时候会到来？我的判断是不会太远。
当前大量的 OpenClaw 使用数据，在 computers/tools/browsers use 等场景里已经积累了非常多的数据集。大模型会根据真实用户的使用路径，加速自己的 RL 训练。
DeepSeek 已经证明了一件事情，推理能力是可以通过训练被内化到模型里的。接下来会发生的事情，是工具使用能力也会被逐渐内化。未来的模型会逐渐形成自己的工具世界模型，多轮工具调用、最佳调用路径、失败恢复策略等等，都会内化为模型能力。
到了那个阶段，OpenClaw 的体验很可能会出现一次明显跃迁。
今天很多人还在用 Claude Code 这样的工具，通过 Prompt、脚本和各种技巧去驱动 Agent 工作。整个过程有点像在 ChatGPT 4.x 阶段做工程，每一步都很依赖经验。
在当下阶段，我也更愿意采用这种务实的使用方式：Claude Code + 打造“最锋利的剑”。
所谓最锋利的剑，其实就是把工具使用的最佳实践不断聚合和沉淀下来。把浏览器操作、系统自动化、代码生成、文件处理这些能力逐渐模块化，变成稳定可复用的能力层，让 Agentic 工作真正跑起来。13 14 - vibe coding 的项目一旦变得庞大，每次让 AI 写代码之前，都需要先让它把 PRD 和系统设计写清楚。
先做文档编程，再做代码编程。
如果你稍微停下来观察一下，会发现一个很有意思的现象：
有些 AI 一旦开始写代码，就会沉浸在自己的逻辑实现里，几乎完全不顾项目原有的设计。
即便你已经提出明确要求，它仍然会受限于上下文窗口和信息宽度，对整个项目缺乏完整理解。
这会带来很多维护性问题。
它不会复用已经实现的业务组件，设计数据库时会产生各种冗余，还会不断衍生新的实体和概念，让系统结构越来越复杂。
代码可以交给 AI 去写。
产品设计和架构设计，仍然需要人来把关。
每次让 AI 做大型重构或者功能改造之前，我都会先让它把需求分门别类，做好抽象和解耦。
即便如此，只要有一些地方考虑不周，AI 依然会生成大量难以维护的代码，性能逐渐下降，项目变更的复杂度也会迅速上升。🥲
18 37 - 项目如何使用 AI 并行开发，其实是一个挺头疼的问题。
比如让 Claude 和 Codex 同时改代码，经常会发生一种很荒诞的场景：
Claude 不小心读到了 Codex 正在修改的代码。
那段代码刚好还没改完，里面还有一点小 bug。
Claude 看不下去，直接把文件接手过来，一通修改。
Codex 很快也意识到自己的代码被改了，于是又把代码修正回来。
于是控制台上就会出现两个 AI 的拉锯战。
你改一版。
我改一版。
来回循环。
token 在疯狂消耗，事情却没有往前推进一步。
Codex 客户端给出的一个解决方案，是利用 Git 的 worktree 机制。
简单说就是把代码拆到多个目录里，每个 AI 在自己的目录里干活，互相隔离。
最后再通过 merge 的方式合并代码，并手动处理冲突。
这个方法在中小规模任务里还算有效。
不过如果项目里有一个比较激进的规则，例如边改代码边做架构优化和工程优化，就会遇到新的问题。
当多个 worktree 分支同时在做结构调整时，最后合并的冲突复杂度会非常高。
有时候解决冲突的时间，比 AI 写代码还要长。
GitHub Copilot CLI 的思路稍微不一样。
它更偏向 任务隔离，而不是代码隔离。
通常会通过一次 Request 定义一个比较完整的任务边界，让 AI 在一个任务上下文中完成修改。
避免多个会话同时在同一片代码区域频繁改动。
简单理解就是：
减少并发编辑，增加任务粒度。
不过说实话，这个问题目前看起来还没有特别完美的解决方案。
我现在的做法主要有几个原则：
第一，在编码之前就约定好规范。
要求 AI 在 Coding 之前先评估影响面。
第二，做好项目目录的隔离。
尽量把功能收敛到单个目录中。
第三，提前做好抽象和组件复用。
减少多个模块同时修改同一层代码的概率。
第四，尽量避免多个 AI 同时编码。
比如 Claude 写代码的时候，让 Codex 去写设计文档或者系统分析，把文档编程和代码编程拆开。
现在的感觉是：
AI 并行开发这件事，看起来很像“多核 CPU”。
真正跑起来之后才会发现，很多问题其实是 锁和资源竞争。
不知道大家现在是怎么处理这个问题的。16 45 - AI Coding 极大提升了传统软件开发者的幸福度。
以前很多想法，其实在脑子里早就把整个项目的编码工作做完了。
现实世界再来一遍，从设计到实现、到调优、再到发布，基本都是体力活。
现在的软件构建，更像是一种创作和表达的过程。
跟 AI 讲清楚要做什么，要做到什么程度，必要的时候再讨论一下怎么做（很多时候这一步都不需要聊得太细）。
剩下的时间基本就是看电影、听歌，或者写别的材料。
幸福感确实提升了。
不过幸福感提升，并不意味着工作量减少。
脑子里的想法越来越多，AI Coding 的时间也越来越长。虽然很多事情可以远程指挥，但整体感觉还是一种陪伴式编程。人需要一直在旁边盯着，不是安慰它，就是鞭策它。
为了让它稳定持续地干活，我自己的睡眠时间反而被压缩得越来越少。
现在每天大概只睡四五个小时。🥲21 44
