「OpenClaw 项目每小时能收到上百个 pr，甚至很多 PR 的提交者自己都不知道这段代码是怎么来的。代码开始成为了一种负债。」
「当代码都是 AI vibe 出来的，测试其实比真实代码更值钱。」
「以前，工程师的核心能力是做 Feature Coding，但现在你会更注重整个 Platform Engineering 的事情。」
OpenClaw的热度已经持续了半个多月。从最初的极客玩具，到如今在具体业务场景中落地提效，我们看到了它作为生产力工具的潜力。国内几家基础模型大厂也相继发布了类似功能。
在组织了第一场闭门讨论后，我们再次邀请了一线开发者、技术创始人和明星创业公司的核心工程师，进行了一场更深入的闭门分享，聚焦于OpenClaw在实际业务中的应用、思考与困惑。
以下是部分精彩内容的整理（出于隐私考虑，部分嘉宾已匿名处理）。
01 Vibe Coding 时代，代码开始成为负债
「Code as Liability」
飞书 OpenClaw 插件维护者：分享一个非常直观的数据。大家可以猜一下，现在 OpenClaw 项目的主干，平均每小时会收到多少个 PR？答案是 30 到 60 个，高峰期甚至能超过 100 个。随时去看它的官方仓库，都可能看到超过 2000 个待处理的 PR。这意味着，一个贡献被合并进去的概率，大概是两千分之一。
从工程视角看，如果未来的开源项目都以这种方式维护，每小时涌入几十个PR，怎么可能有人review得过来？即使OpenClaw有几百个贡献者，但核心维护者的注意力永远是稀缺资源。
为了应对这种情况，OpenClaw社区甚至设立了一个专用频道，限制每人6小时内只能发一条消息。如果你觉得自己的PR特别重要，想让维护者看到，就只能在这里“排队”发言。这很像大公司每天收到海量内推简历，谁能被优先看到，变成了纯粹的注意力争夺战。
这种模式颠覆了传统的开源协作心态。以前看到新PR是积极的，意味着有人愿意参与维护。但现在，维护者的心态更多地转向了 「Code as Liability（代码是负债）」 。每增加几百行AI生成的代码，都可能引入意想不到的问题，让项目未来更难维护。在这种心态下，只能尽可能避免随意合并。
开源的信任链条其实有些断裂，我们似乎又回归到了最原始的人际信任。
一方面需要更多个人信用背书，另一方面必须探索自动化的review和测试。实际上，OpenClaw自身已有机制，能自动识别并关闭那些明显是低质量、机器生成且提交者不关心的PR。
在Vibe Coding导致PR“恶性通胀”的产能下，传统的开源信任链条是断裂的。我们合并一个PR，可能不是因为仔细读了所有代码，而是出于对提交者工程能力和持续维护信用的信任。
我们还不知道如何迎接上万个高质量 PR 的涌入
Agent 创业者：我喜欢把代码库比作“胶水”。在Agent时代，代码就是连接逻辑的胶水。现在的Coding Agent就像一把“热熔胶枪”，可以源源不断地喷出胶水。每个人手里都有一把枪，都想按照自己的意愿把东西粘成想要的形状。但最终，这个玩具是被粘得更奇怪，还是更圆润？这是个深刻的问题。
OpenClaw将这个问题推向了更疯狂的层面。我一直在思考，未来GitHub上一定会涌现出一批这样的仓库，无数的人和Agent都在疯狂提交代码。在OpenClaw项目上，现在很多提交者已经不是人，而是Agent。未来这种情况只会更加极端。
那时，假如以分钟为单位，都有海量高质量的PR被提交。从review角度看，每个PR单独拿出来，可能都有其合理性。那么，当这些中上水平的PR如潮水般涌入时，会发生什么？
首先，人工测试显然不现实。其次，也是我更关心的：当一分钟有上万个高质量 PR 涌入时，我们那个时代的 Git 基础设施、整个软件仓库的演进生态，以及相应的治理规范，会是什么样？ 这可能是我觉得目前还没有明确答案的地方。
Vibe Coding 进入到了一个「快消费」的时代
AI4S Agent 创业者：我认为Vibe Coding对社会长期影响才刚刚开始。我写了十几年代码，也研究了两三年代码生成，现在发现Vibe Coding进入了一个非常“快消费”的时代。
这种“快消费”与传统的硬核开发（如写Linux内核、数据库引擎）形成了鲜明对比。一边是快速、用后即抛，另一边是支撑整个互联网的基础架构，可能还是需要那20个人去写最核心的代码。
这两种模式如何协作？如何维持两者间的张力？普通人能不能去写Linux内核？这非常有趣。
就像“胶水”的比喻，以前铸造东西需要做模型、找工匠，现在可能直接3D打印就出来了。当代码变成一个用后即抛的东西之后，它真正的价值和意义到底是什么？ 这非常值得我们思考。
02 当代码都是 AI vibe 出来的，测试变得异常重要
测试，其实比你真实的代码更值钱
Agent Infra 创业者：我们的项目——一个Agent运行时的沙箱——基本就是Vibe Coding出来的，Claude Code是我们项目的第一贡献者。这个项目非常依赖测试。
但如果你放手让Claude Code去写测试，它会写大量我们称之为“瞎 Mock”的东西。它可能在一个测试里把所有外部环境全Mock一遍，装模作样测一下，告诉你通过了，实际上真实代码一行都没跑。这种测试是无效的。
所以我们在文档里写了非常多的测试规则，还写了一些Skill。当它开发完代码，我们会主动@这些规则，让它去修改。
我觉得测试其实比真实代码更值钱。 像Claude前段时间号称写了个C编译器，其实C编译器的测试用例这么多年已经非常完善了。你在一个快速反馈的环境下烧Token，是能烧出来的。但在一个比较开放的开发任务里，让Coding Agent去做事就非常困难。
所以我的观点是，Coding Agent写的代码我可以不看，但它写的测试我一定会看，而且会严格要求它按照我们的模式去重写。
这里有一个很重要的Mock规则：只有第三方的库你可以 Mock，但是你所有的内部 Library、内部 Service 都不能 Mock。
在我们的通用测试框架里，除了第三方的东西Mock之外，所有内部Service调用都是真实的。验证时，我们只验证API的请求和结果，不做任何手工数据库插入和读取的断言。这在以往算集成测试，但我们会把它定义成最小粒度的单元测试。
对于 UI 测试，我们有两种。 一种是我们写得最多的，就是React的UI测试。我们把整个页面渲染出来，在模拟环境中做用户界面操作，比如点击按钮，断言UI结果。这里面没有真实浏览器，是模拟的DOM。
还有一类是Playwright那种E2E测试，那个测试很慢，我不太喜欢写。一般只测主流程，比如登录注册能进首页，写一两个就行。大部分还是React Mock DOM的测试。
飞书 OpenClaw 插件维护者：Playwright E2E其实很重，维护成本也高。但测试有一个黄金准则：你的测试越接近实际使用的方式，你就越能带来实际的信心，你就越确信这个东西不会坏。
我们的实践是，会投入更多人力去维护E2E测试。因为它虽然容易坏，但真正抓到线上问题还是靠它。
但Agent公司的迭代速度非常快，我们就有了一个准则：我们还是用Playwright写很多E2E测试，但分为两类：
- 冒烟测试：往主干合代码时，比较激进，只跑50个以内的Case，允许Mock后端，保证5分钟内能合进去。
- 巡检：面向线上的场景，低频地跑，比如半小时一次，用线上端到端的链路验证。
这里有个简单的实践技巧：给业务应用加测试时，先用一个Skill去扫描UI组件，加上test-id。然后让AI写测试用例，只验证打开UI时test-id都在。以此为起点，你可以封装一些能力，这样就不需要每次都依赖多模态模型，成本低且快。
大模型就像「抽卡」，建立一个自己的 benchmark 很重要
基模公司核心工程师：测试这件事其实很重要。现在的模型每次更新后，权重和训练数据都会变，模型公司是不对这个负责的。这跟做工程不一样，模型类似于“抽卡”。今天抽到80分，下次可能是60分，波动非常大。
比如GPT-4o刚发布时，很多人说缺少了GPT-4的“人味儿”。模型公司自己不一定测得出来，因为他们只关注自己的Benchmark指标。这对AI从业者来说，是一件非常疲惫的事情。因为，每天都像是在跟一个新的人聊天。我今天教的东西，明天到底会不会？
所以我的一个建议是，去造一些属于你们自己的 Benchmark，验证它到底能干什么。 用这件事从概率里找到准确性，保证你的东西能持续往前走。
03 大众还在接受过程中，少数人已经玩成了「超级个体」
Pro User 玩出了花，普通用户却有点恐惧
AI4S Agent 创业者：我们在湾区，离OpenClaw很近，也实际参与了。我们跟OpenClaw官方组织了一个用户的Workshop，帮50个人配置OpenClaw。发现了一个有趣的现象：在普通人和专业工程师之间，大家对OpenClaw的认知差距很大。
对于工程师、PM来说，安装OpenClaw可能很容易。但对于普通用户，大部分人其实都不知道怎么弄，他们完全不知道Terminal是什么。而且OpenClaw很多代码是Vibe Coding出来的，有一些不稳定的地方，在Mac或Linux上会有各种环境配置问题，所以最终跑通的成功率其实并不高。
但是，一旦跑通了，那种感觉真的有点像「Feel of AGI」。 当他把OpenClaw跟WhatsApp、Gmail连起来，再去操作的时候，那个体验是非常不一样的。
还有一点，大家其实非常恐惧。我帮一位女生在Mac mini上装OpenClaw，她之前从没接触过编程。装Gmail插件时需要去Google Cloud Console建一个App，把API Key和Secret复制到Terminal里。她当时整个人都傻了，有点像被扔到了太平洋正中间。当我离开的时候，出了问题她完全不知道该怎么继续。这个视角非常有趣。
但我跟那些AI Native的朋友，也就是OpenClaw的Pro User去聊，发现真正跑起来后，对某些行业的效果其实非常好。比如当公司的业务流程已经数字化，且不需要太多人工审核时，整个公司都可以搬到OpenClaw上。
我有个创作者朋友，买了两三台Mac Mini，装了Gemini Ultra的套餐。他们公司不光是做内容，连互联网上的API调用都自动化了。比如以前他们觉得很复杂的广告投放分析、SEO优化，现在直接跟OpenClaw或Claude Code聊，AI会建议一个方案，人只需要去开发者网站把Key拿过来验证一下就行。
所以他们都不需要UI了，基于API把一整套业务都跑起来了，甚至连招人都是自动化的。我有个朋友的流程是：在LinkedIn上触达200个人，收简历和作品集，用AI Review结果，再进行AI监考的面试。从200人筛选到2人的过程完全自动化，省了大量时间。
Power User跑起来之后，你会非常惊讶。他们一行代码不写，纯动嘴就把我们花很多年才学会的GitHub、前后端开发、甚至各种开发者工具全都跑起来了，而且特别熟练。这个事让我觉得非常意外。
文科生，一行代码都不会写，但被 merge 了 9 个 PR
金融投资从业者：我是个文科生，做金融投资出身的。到现在为止，我仍然是一行代码都不会写。算是一个Vibe Coder。
但是这两天我开始给OpenClaw写代码，提交了十几个PR，然后被通过了9个。所以我现在基本上是OpenClaw全球贡献者里面前50名了。
我发现，正是因为没有技术背景，反而更依赖、也更天然地接受AI技术。传统搞技术的朋友可能更喜欢确定性，比如输入1+1必须等于2。但AI编程很多时候是在“抽卡”，可能抽10次只有2次能用。这种路径差异，可能是很多人使用AI的限制。
我现在使用AI的方法很简单，依靠三个“AI员工”组成的团队，部署在我的MacBook Air和Mac Mini上：
- 一个首席助理，负责安排和协调所有Agent的工作；
- 一个CTO，负责实际的代码编写；
- 一个是CMO或者Social Officer，在CTO提交完PR后，它会去评论区自动寻找最近活跃的、对这个PR感兴趣的Maintainer，主动@他们。这样可以加快我PR被合并的效率。
另外还有一个“需求发现师”，它会24小时不断在GitHub上寻找Issue，分析有哪些Issue需要被解决，哪些是比较重要的，哪些是目前更可能被合并的。
大概是这样的一个工作流，跑起来发现效果出奇的好。
从 Feature Coding 到 platform engineering
飞书 OpenClaw 插件维护者：结合我现在在公司里的工作，我发现自己做的很多事正在逐渐往两个方向发展，即所谓的“左移”和“右移”。
以前我们可能会很强调工程师的核心能力是做 Feature Coding，但现在你会更注重整个 Platform Engineering 的事情。
往左移，就是在代码合并和发布之前，你要注重怎么给代码一个容器化的隔离环境，怎么让AI在你约束的SPEC下面去编码。
右移部分是说，在代码合并之后，如果有问题，我要能够快速恢复，做一些可观测性的建设，有问题能够回滚兜底。
因为你很难保证每天写进来的几千、几万行代码在工程上是绝对可靠的，它可能只是“能运行”。这个时候，传统的软件开发角色就变成了一个左移和右移结合的角色，有点类似于测试开发和平台工程师。
中间的Feature Coding反而变得可能没那么重要了，因为它越来越能由AI全自动生成。虽然现在无监督的AI开发还有点离谱，比如Claude号称写了个C编译器，但连Hello World都编译不了。但再过两年会变成什么样？我觉得还是有非常多工程上可以做的方式，比如从Platform Engineering这个角度入手，或者是否会有新的组织和个体去做相应的质量控制。
比如Linux社区就有不同的发行版：有的像Arch Linux非常激进，所有东西都往里合，体验最新代码；有的像Debian强调稳定，会人工做很多测试才发出来，这种概念可能更适合企业的场景。同时，像这样的概念是不是会得到一些商业上的机会？我觉得也是非常有可行性的。
Agent Computer，会是一种新的硬件形态
Agent 创业者：我看几位嘉宾都聊到家里有不同的小主机在部署Agent。其实OpenClaw相比于Manus、GenSpark、Happycapy，虽然产品形态类似都是在云端起Docker跑Agent，但OpenClaw走向了反面，它是深度结合你本地的，比如联动苹果的通讯录、备忘录。
我觉得OpenClaw这一波带火了“个人助理”的意义，它相对于云端产品，跟本地智能结合得更紧密。
大家讨论的形态，在计算机上装Agent，资源主要给Agent用，平时不插显示器——其实是一个新的产品形态。我有个朋友在做叫“Pamir AI”的项目，他们提了一个概念叫 “Agent Computer”。
*Pamir AI：一个售价 250 美元、计算器大小的硬件，能 24 小时保持在线，接管重复性工作，甚至能通过物理接口，直接介入物理世界。
这就好比苹果诞生于PC将出未出的时代。我们想，以后大家可能每天不需要对着几百个软件界面，而是每个人有100到500个Agent来服务他。那时，我们的硬件设备形态可能也会发生很大的改观。
05 Heartbeat 机制，让 OpenClaw 更像是一位长期伙伴
OpenClaw 更像是一个「长周期、永远在线、有主动性」的陪伴型伙伴
Agent 创业者：过去一年，我们在做Claude Code的开源实现。从我的视角来看，OpenClaw跟过去传统的Claude Code这种Agent到底有什么区别？
Claude Code的设计中，也有任务持久化和记忆机制，但不是那么凸显。你跟它的对话很像是一种临时性的对话。打开Terminal，聊完Task就结束了，Terminal一关，很多人甚至有“上下文洁癖”，用一半就清除了。
那OpenClaw显然走向它的反面。你跟它聊，随便聊，你也不知道上下文窗口用得有多满。它不会给你显示Session Window占用了多少，但你提的任务它都给你完成。这个时候显然不可能由人来手动管理上下文，它内部必须保持长周期的连续运转。
我觉得这是两个相反的设计。Claude Code是一个更加单元型的Agent，关心原子性任务。而 OpenClaw 其实已经不再是一个 Chatbot 或 Chat Agent，它是一个长周期、主动的陪伴，就像你身边的一个同事。
你不会说你跟OpenClaw临时开了一个会话，你会把它当做一个长周期的伙伴，因为它的记忆是始终在线的，任务是始终往前推进的。而且它有 Heartbeat 机制，会周期性地提醒并唤醒自己做一些后台任务，比如做文件的整理或数据的搜集。
我觉得这是两个项目的一些核心差异。上层的产品哲学、心智还是非常不同的，这也是OpenClaw能引爆社区的主要原因。
现阶段，用 OpenClaw 做 SaaS 还蛮难的
开源社区负责人：OpenClaw出来之后，我就试着让它把我过去几年的发票处理一下：我要求它分门别类，按“故事”线整理，比如这趟是北京出差，那趟是深圳出差，把发票分组在一起，算明白里面的税。跟它聊，给它OCR工具、视觉语言模型，把API Key给它，让它自己上网学。
结果发现它做得还不错。我当时想，是不是可以让OpenClaw去做一些有实际商业价值的事情？但坐下来细聊需求后，我发现用 OpenClaw 做 SaaS 还是蛮难的。
首先是成本问题。 因为它实际是一个数字助理，给我个人服务很方便。但做成会计SaaS，假设一个月收二三十块钱，如果每个人背后都绑一个Claude的套餐，哪怕是Kimi，这笔账也是算不过来的。我没办法用纯AI Native的方式去交付这个服务。
其次是权限和安全问题。 我想过把它包装成带API的服务，抽象一部分控制权。但权限控制很难搞。 如果放在同一个Server上，客户文件之间的隔离很难做。更担心的是，用户跟OpenClaw聊着聊着，可能会诱导它改代码——因为OpenClaw权限太高了，甚至能改自己的代码。
这就引出了供应链安全的问题。所以我觉得供应链安全这个东西还挺难搞的。 结合最近的SEO污染事件，如果未来有人通过SEO污染了一个常用Tool的搜索结果，Agent下载了带有恶意代码的东西，那整个安全防线就彻底崩溃了。
最后是结果一致性的问题。 它很聪明，比如看到我发票的时间点，自动把两张发票关联起来，说这是一个从A到B再到C的行程。但当我下次找它做同样的事时，它很难给我一个可复现的、非常一致的结果。
我尝试用Prompt控制它，效果都不太好。如果要把它变成一个SaaS服务交付给用户，在现阶段，那我可能还无法完全信任这个Agent。
06 Token 税：谁用得越多、试错越多，谁就越能理解 AI 的「思维模式」
Claude 4.5 Opus 之后，模型开始进化到「可用」的状态了
基模公司核心工程师：直到半年之前，我还是一个“古法编程爱好者”。在那之前，我对模型属于完全不信任的状态，不管是当时的GPT-3.5还是4，我都试过，觉得这东西没办法解决真实工程中的各种问题。
什么时候我的思维开始动摇了？其实是从Claude 4.5 Opus出来之后。在它之后，我明显地能感知到一件事情，就是模型从我的视角下的「不可用」已经进化到一个「可用」的状态了。
因为我是古法编程，我真的仔细地把OpenClaw当时版本下的所有代码都读了一遍。其实OpenClaw整体的架构并没有超出设计的范畴，从头拆解起来其实就三个东西：模型、Loop、Tool。
业界最近在探索一种新的Agent使用方式，叫Proactive Agent。我的第一反应是这东西不就是把ReAct变成了后端熟悉的Cron Job，不断轮询吗？
如果真要做 Proactive Agent，我觉得最重要的因素是记忆。 之前Manus爆火时我也猜测过它的记忆机制。后来逆向Claude Code发现，其实没有什么黑魔法，就两件事：一是通过标注把所有代码执行一遍；二是在Tool上做了很多细节优化，通过System Prompt告诉它当前的执行过程。仅仅靠这点东西就形成了魔法。
这件事对我的冲击有点大，因为它跟工程师的直觉是相反的。工程师觉得我得知道一件事到底是为什么，我才去用。但实际上这一波的模型能力迭代真的有一个分界线，可能就是Claude 4.5 Opus之后，模型在Coding领域真的从玩具状态变成了生产级可用。
「Token 税」，是 Vibe Coding 时代的经验条
基模公司核心工程师：最近感触最大的是听了翁家翌的采访，里面有一句很重要的话：环境的稳定性，或者叫迭代的速度，直接决定了当前模型能够进化的效率。
大家觉得模型训练是黑魔法，只要有神算法和神数据就行。但实际上，真正的算法研究员 90% 的时间都在「揉数据」，揉数据决定了能产生多少高质量轨迹供模型学习。 这需要快速试错，像抽卡一样，一旦抽中SSR，就可以无限复制当前的所有轨迹。
这其实也是现在模型训练中的一个最核心的点，就是把一切可被规模化的事情作为第一性原理。
我现在重新反思，如果现在再去做应用，可能需要牺牲掉一部分“解耦”的执念。实际上，你给模型一个完全可供自己探索的环境，让它烧Token去试，直到发现一条模型一定能走对的路径时，这条认知就变成了你自己的能力。
所以，这个时代有一个很严肃的问题，叫做「Token 税」。就是谁用的 Token 越多，谁对于这个东西感知越多，谁就能更理解所谓的模型的 AI Native 思维。
包括OpenClaw该怎么用？我觉得这件事可能会有一个听起来很无聊但很正确的答案，就是“试”。你不断地试，找到它真的能够帮你做好的那一件事，然后在这个过程中再去发现，到底什么路径是对的。
这场关于OpenClaw与Vibe Coding的深度讨论，涉及了从工程实践到哲学思考的多个层面。无论是测试价值的重估、工程师角色的演变，还是新硬件形态的构想，都预示着软件开发领域正在经历一场深刻的范式转移。对于开发者而言，适应并驾驭这种变化，或许比单纯追逐热点更为重要。更多关于人工智能和软件测试的实践与思考，欢迎在云栈社区交流探讨。对于热衷开源实战的开发者来说，现在正是参与和观察这场变革的最佳时机。
发表于 2026-2-14 02:33:20
|
查看: 56|
回复: 0
