2026-02-13 20:22
扫码打开虎嗅APP
本文来自微信公众号： Founder Park ，作者：Founder Park
「OpenClaw项目每小时能收到上百个pr，甚至很多PR的提交者自己都不知道这段代码是怎么来的。代码开始成为了一种负债。」
「当代码都是AI vibe出来的，测试其实比真实代码更值钱。」
「以前，工程师的核心能力是做Feature Coding，但现在你会更注重整个Platform Engineering的事情。」
......
OpenClaw已经持续发酵了半个多月。
在这段时间里，我们看到的一个趋势是，OpenClaw正在从一个单纯的极客「玩具」，逐渐在各种具体业务中被实际用起来、作为一个可落地的生产力工具来提效。国内的几家基模大厂，也陆续发布了类似产品或功能。
于是，在组织了第一场闭门之后，我们决定找离OpenClaw最近的一群人：一线开发者、技术founder、明星创企的核心工程师，聊聊在概念、热度之外，他们在各种实际业务中是怎么用OpenClaw的，以及一些真实的思考与困惑。
这场闭门分享，很硬核，我们整理了部分精彩内容。
PS：考虑到是闭门分享交流，我们对一些嘉宾进行了匿名化处理。
⬆️关注Founder Park，最及时最干货的创业分享
超19000人的「AI产品市集」社群！不错过每一款有价值的AI应用。
邀请从业者、开发人员和创业者，飞书扫码加群：
进群后，你有机会得到：
最新、最值得关注的AI新品资讯；
不定期赠送热门新品的邀请码、会员码；
最精准的AI产品曝光渠道
01
Vibe Coding时代，
代码开始成为负债
「Code as Liability」
飞书OpenClaw插件维护者：先分享一个非常夸张的数据。大家可以想一下，现在的OpenClaw项目主干，平均每小时会收到多少个PR？这个数字现在是30到60个，高峰期甚至能超过100个。现在随时去看它官方仓库，都可能看到2000多个待处理的PR。这意味着，你的贡献能被合并进去的概率，大概是两千分之一。
回到工程视角来看。如果未来的开源项目都以这种方式维护，一个小时涌入几十个PR，怎么可能有人review得过来？即使OpenClaw现在有几百个contributor，但最终的maintainer数量也是极其有限的，这些maintainer的注意力非常稀缺。
为了应对这种情况，OpenClaw社区甚至搞了一个专门的频道，限制每个人6小时内只能发一条消息。如果你觉得自己的PR特别重要，想让维护者看到，就只能在这里「排队」发言，才可能更优先地获得注意力。
整个状态，就好像一个大企业每天收到几千份内推简历，最终谁的简历能被优先看到，已经变成了一个纯粹的注意力争夺问题。
这带来了一个非常大的转变。之前的开源项目里，如果看到一个新的PR，第一反应是积极的：有人愿意读我的代码，有人愿意参与维护，那我可以降低一点这个项目的「公交车指数」，就是万一我出门被公交车撞了，还有人能维护这个项目。
但现在，这个模式可以说被完全颠覆了。因为所有人都可以随便提交，甚至很多PR的提交者自己都不知道这段代码是怎么来的。维护者的心态更多地转向了「Code as Liability（代码是负债）」的角度。你每增加几百行代码，都可能引入一些意想不到的问题，让项目在未来更难维护。在这种心态下，只能尽可能避免随意合并。
开源的信任链条其实有些断裂，我们似乎又回归到了最原始的人际信任。
一方面是需要更多的人际信任来做背书，另一方面，我们需要探索自动化的review和测试。实际上，OpenClaw自己已经有了一套机制，它会自己识别出来那些很低质量的、机器生成且你根本不care的PR，关掉。
我的感觉是，在OpenClaw这种大家用Vibe Coding写PR的「恶性通胀」产能下，传统的开源信任链条是断裂的。我们合并一个PR，不是因为我读了你所有代码，可能是信任你作为一个engineer的工程能力，和你对这个东西持续维护的credit。
我们还不知道如何迎接上万个高质量PR的涌入
Agent创业者：我很喜欢把代码库比作「胶水」。在Agent时代，我们可以重新审视代码的本质：它不就是连接逻辑的胶水吗？现在的Coding Agent就像手里的一把「热熔胶枪」，它可以源源不断地喷出胶水。每个人手里都拿着一把热熔胶枪，对着一个「泡泡玛特」玩具说，「诶，这个不错，我也来喷点胶水」。每个人都想按照自己的意愿把它粘成合适的形状。但最终，这个玩具是被粘得更奇怪，还是更圆润？我觉得这是一个很深的问题。
OpenClaw这个项目其实让我看到了这个问题被推向了一个更疯狂的层面。
所以我一直在思考一个问题：未来如果过了半年或一年，GitHub上一定会涌现出一批这样的仓库，无数的人和Agent都在疯狂地往里提交代码。在OpenClaw这个项目上，现在很多提交代码的已经不是人了，而是Agent。未来这个情况只会推演得更加疯狂。
到了那时候，假如以小时甚至分钟为单位，都有海量高质量的PR被提交进来。从review的角度看，每一个PR单独拿出来，可能都有在某个角度上的合理性。那么，当这些中上水平的PR涌入时，会发生什么？
首先，人工测试显然已经是不太现实了。其次，也是我更关心的问题：当一分钟有上万个高质量PR涌入时，我们那个时代的Git基础设施、整个软件仓库的演进生态，以及相应的治理规范，会是什么样？这可能是我觉得目前还没有明确答案的地方。
Vibe Coding进入到了一个「快消费」的时代
AI4S Agent创业者：我觉得Vibe Coding的Impact我们才刚刚感知到一部分，但它对社会的长期Impact才刚刚开始。我写了十几年代码，也研究了两三年代码生成，现在发现Vibe Coding进入到了一个非常「快消费」的时代。
这种「快消费」跟传统的硬核开发，比如写Linux Kernel、数据库Planning，形成了鲜明对比。一边是非常快速、用后即抛的使用方式，另一边是支撑整个互联网的最基础架构，可能还是需要那20个人去写最核心的维护代码。
这两种情况下如何协作？如何维持两者之间的Tension？普通人能不能去写Linux Kernel？我觉得这非常有趣。
就像前边提到的「胶水」比喻，很早以前铸造一个东西需要做模型、找工匠，现在可能直接3D打印就出来了。当代码变成一个用后即抛的东西之后，它真正的价值和意义到底是什么？非常需要我们思考。
02
当代码都是AI vibe出来的，
测试变得异常重要
测试，其实比你真实的代码更值钱
Agent Infra创业者：我们的项目——Agent运行时的Sandbox基本就是Vibe Coding出来的，Claude Code是我们项目的第一贡献者，它的Commit数量是我们剩下4个人加起来的总和。这个项目非常依赖测试。
但如果你放手让Claude Code去写测试的话，你会发现他写大量那种我们叫「瞎Mock」的东西。他可能在一个测试里把所有外部环境全Mock一遍，装模作样测一下，告诉你通过了，实际上真实代码一行都没跑。这种测试是无效的。
所以我们在文档里写了非常多的Testing规则，还写了一些Skill。当它开发完代码，我们会主动@这些规则，让他去修改代码。
我觉得测试其实比真实代码更值钱。像Claude前段时间号称写了个C编译器，其实C编译器的Test Case这么多年已经非常完善了。你在一个快速反馈的环境下去烧Token，是能烧出来的。但在一个比较开放的开发任务里，让Coding Agent去做事就非常困难。
所以我的观点是，Coding Agent写的代码我可以不看，但他写的测试我一定会看，而且一定会严格要求他按照我们的Pattern去重写。
这里有一个很重要的Mock规则，只有第三方的库你可以Mock，但是你所有的内部Library、内部Service都不能Mock。
在我们的通用测试框架里，除了三方的东西Mock之外，所有内部Service调用都是真实的。验证的时候，我们只验证API的请求和结果，不做任何手工数据库插入和读取的断言。这在以往算集成测试，但我们会把它定义成最小粒度的单元测试。
对于UI测试，我们有两种。一种是我们写的最多的，就是React的UI测试。我们会把整个页面渲染出来，在模拟环境中做用户界面操作，比如点击按钮，断言UI结果。这里面没有真实浏览器，是模拟的DOM。
还有一类是Playwright那种E2E测试，那个测试很慢，我不太喜欢写。一般只测Happy Pass（主流程），比如登录注册能进首页，写一两个就行。大部分还是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去聊，发现真正跑起来后，对某些行业的效果其实是非常好。比如当公司的Workflow已经数字化，且不需要太多人工审核时，整个公司都可以搬到OpenClaw上。
我有个Creator朋友，买了两三台Mac Mini，装了Gemini Ultra的Plan。他们公司不光是做内容，连互联网上的API调用都自动化了。比如以前他们觉得很复杂的广告投放分析、SEO优化，现在直接跟OpenClaw或Claude Code聊，AI会建议一个方案，人只需要去Developer网站把Key拿过来验证一下就行。
所以他们都不需要UI了，基于API把一整套业务都跑起来了，甚至连招人都是自动化的。我有个朋友的Stack是：在LinkedIn上Reach 200个人，收简历和Portfolio，用AI Review结果，再进行AI Monitor的面试。从200人筛选到2人的过程完全自动化，省了大量时间。
Power User跑起来之后，你会非常Surprise。他们一行代码不写，纯动嘴就把我们花很多年才学会的GitHub、前后端开发、甚至各种Developer Tool全都跑起来了，而且特别熟练。这个事让我觉得非常Surprising。
文科生，一行代码都不会写，但被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需要被解决，有哪些是比较重要的，有哪些是目前更可能被合并的。
大概是这样的一个工作流，Run起来发现效果是出奇的好。
04
Platform Engineering，
正在成为人类工程师的核心
从Feature Coding到platform engineering
飞书OpenClaw插件维护者：结合我现在在公司里面的角度，我发现自己做的很多工作正在逐渐往两个方向发展，所谓的「左移」和「右移」。
以前我们可能会很强调工程师的核心能力是做Feature Coding，但现在你会更注重整个Platform Engineering的事情。
往左移，就是在代码合并和发布之前，你要注重比如怎么给代码一个容器化的隔离环境，怎么让AI在你约束的SPEC下面去编码。
右移部分是说，在代码合并之后，如果有问题，我要能够Resilience，做一些可观测性的建设，有问题能够回退兜底。
因为你很难保证每天写进来的几千、几万行代码在工程上是可靠的，它可能只是「It works」。那这个时候，传统的软件开发角色就变成了一个左移和右移结合的角色，有点类似于测试开发和平台工程师。
中间的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一关，很多人甚至有「上下文洁癖」，用一半就Clear了。
那OpenClaw显然走向它的反面。你跟它聊，随便聊，你也不知道上下文窗口用得有多满。它不会给你显示Session Window占用了多少，但你提的任务它都给你完成。这个时候显然不可能由人来手动管理上下文，它内部必须保持长周期的连续运转。
我觉得这是两个相反的设计。Claude Code是一个更加单元型的Agent，关心原子性任务。而OpenClaw其实已经不再是一个Chatbot或Chat Agent，它是一个长周期、主动的陪伴，就像你身边的一个同事。
你不会说你跟OpenClaw临时开了一个会话，你会把它当做一个长周期的伙伴，因为它的记忆是始终Online的，任务是始终往前推进的。而且它有Heartbeat机制，会周期性地提醒并唤醒自己做一些后台任务，比如做文件的整理或数据的搜集。
我觉得这是两个项目的一些核心差异。上层的产品哲学、心智还是非常不同的，我觉得这也是OpenClaw能引爆社区的主要原因。
现阶段，用OpenClaw做SaaS还蛮难的
开源社区负责人：OpenClaw出来之后，我就试着让它把我过去几年的发票处理一下：我要求它分门别类，按「故事」线整理，比如这趟是北京出差，那趟是深圳出差，把发票Group在一起，算明白里面的税。跟它聊，给它OCR工具、Vision Language Model，把API Key给它，让它自己上网学。
结果发现它做得还不错。我当时想，是不是可以让OpenClaw去做一些有实际商业价值的事情？但坐下来细聊需求后，我发现用OpenClaw做SaaS还是蛮难的。
首先是成本问题。因为它实际是一个数字助理，给我个人服务很方便。但做成会计SaaS，假设一个月收二三十块钱，如果每个人背后都绑一个Claude的套餐，哪怕是Kimi，这笔账也是算不过来的。我没办法用纯AI Native的方式去交付这个服务。
其次是权限和安全问题。我想过把它包装成带API的服务，抽象一部分控制权。但权限控制很难搞。如果放在同一个Server上，客户文件之间的隔离很难做。更担心的是，用户跟OpenClaw聊着聊着，可能会诱导它改代码——因为OpenClaw权限太高了，甚至能改自己的代码。
这就引出了供应链安全的问题。所以我觉得供应链安全这个东西还挺难搞的。结合最近的SEO，如果未来有人通过SEO污染了一个常用Tool的搜索结果，Agent下载了带有恶意代码的东西，那整个安全防线就彻底崩溃了。
最后是Consistent的问题。它很聪明，比如说它看到我这个发票的时间点，自动把两张发票关联起来，说这是一个从A到B再到C的Trip。但当我下次找它做同样的事时，它很难给我一个可复现的、非常Consistent的结果。
我尝试用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，就可以无限复制当前的所有轨迹。
这其实也是现在模型训练中的一个最核心的点，就是把一切可被Scalable的事情作为第一性原理。
我现在重新反思，如果现在再去做应用的话，可能需要牺牲掉一部分「解耦」的执念。实际上，你给模型一个完全可供自己探索的环境，让它烧Token去试，直到发现一条路径是模型一定能走对的时候，这条认知就变成了你自己的能力。
所以，这个时代有一个很严肃的问题，叫做「Token税」。就是谁用的Token越多，谁对于这个东西感知越多，谁能更理解所谓的模型的AI Native思维。
包括OpenClaw该怎么用？我觉得这件事情其实可能会有一个无聊的废话，但是很正确的答案就是「试」，你不断地试，找到一个它真的能够帮你做哪一件事情，然后在这个过程中再去找那个轨迹，到底什么东西是对的。
