news 2026/10/29 14:55:12

Clawdbot之父:我从不读自己的代码

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Clawdbot之父:我从不读自己的代码

Clawdbot之父:我从不读自己的代码

本文共 2979 字,阅读预计需要 4 分钟。

Hi,你好,我是Carl,一个本科进大厂做了2年+AI研发后,裸辞的AI创业者。

一个退休3年的开发者,同时操控10个AI工具,用AI Agent实现一天600个Commit,甚至发布自己没读过的代码。

他的项目Clawdbot(现在改名OpenClaw了)两周暴涨到几万星,现在已超9万星。

这是Clawdbot之父Peter Steinberger给所有程序员上的一课:

问题从来不是"AI会不会取代我",而是"我怎么和AI一起干活"。

一天600个Commit?他是认真的

说实话,当我第一次看到这个数字,我以为是标题党。

一天600个Commit,还发布自己没读过的代码。这不是草率,这是疯了吧...

但Peter Steinberger就是这么干的。

这哥们的工作方式像极了国际象棋大师的车轮战:同时开着5到10个AI Agent,在任务之间不停切换。设计一个新子系统?他知道Codex需要40分钟到1小时来完成构建,所以先把规划敲定、启动任务,然后立刻跳到下一件事。

他就像个厨神一样,等这边"炖着",他去处理那边。那边"炖着",他又去处理另一件。转一圈回来,第一个任务刚好出锅。

这种并行工作的节奏,让他凌晨5点还在跟Claude较劲。在他看来,Claude的输出像老虎机——你投入一个prompt,要么开出一堆废铁,要么中个头彩。

问题来了:这种看起来疯狂的工作方式,为什么能跑通?

闭环才是秘诀:让AI自己验证自己

Peter能"不读代码就发布",靠的不是运气,是一套完整的验证闭环。

在他的工作流里,AI必须能"自证清白"——代码写完只是开始,能编译、能通过代码规范检查、能执行、能验证输出,这四道关卡缺一不可。

这就像工厂的质检流水线。原材料进来,不是直接出厂,而是经过层层检测:尺寸对不对、颜色对不对、功能对不对。每一道工序都有自己的验收标准。

AI写代码也一样。

代码写完不是终点,compile通过才算第一关,lint检查是第二关,单元测试是第三关,集成测试是第四关。

Peter的逻辑很简单:只要验证循环跑通了,测试全部通过,他就选择信任AI的输出。

为什么不呢?规范的检查,规范的测试流程,最后的稳定性也许能胜过90%以上的人写的代码。

有一次Peter在摩洛哥旅行,用WhatsApp给他的Agent发了条语音消息——完全是下意识的动作,因为他压根没给Agent开发过语音识别功能。

半分钟后,Agent居然回复了。

Peter懵了,追问它怎么做到的。Agent的回答让他目瞪口呆:它自己检测到文件头是OGG音频格式,主动调用FFmpeg做格式转换,然后翻出电脑里存着的OpenAI API密钥,把音频发到OpenAI的语音转文字服务,最后才给出回复。

没有人教它这么做。它自己把整个链路串起来了。

这就是闭环的力量:你不需要告诉AI每一步怎么做,只需要给它目标和验证标准,它会自己找到路径。

Pull Request已死,Prompt Request当道

Peter的工作流里,传统代码审查已经成了历史。

他给代码提交起了个新名字:不叫Pull Request,叫Prompt Request。

理由很直接:别人提交代码时,他最想看的不是代码本身,而是生成这段代码的prompt长什么样。

这个观点值得仔细考虑,如同我常说现在spec规格说明才是代码,而代码本身是编译产物一样。

传统开发里,代码是核心交付物。你写代码,我审代码,我们讨论代码。

但在AI时代,prompt才是核心资产。

好的prompt可以让AI生成无数版本的代码;而代码本身,反而是可以随时重新生成的"易耗品"。

Peter甚至会直接拒绝一些只修了几个小bug的PR。他的理由是:

人工审查这种小修小补的代码,花的时间可能是让Codex直接修复的10倍。

与其浪费时间审代码,不如把问题描述清楚,让AI重新生成。

这对程序员意味着什么?

技能重心正在发生位移。从"写代码"转向"写需求",从"实现细节"转向"架构设计",从"逐行审查"转向"验收结果"。

三类程序员,谁最适合AI时代?

Peter观察到一个有趣的规律:那些痴迷于算法难题的工程师,反而很难适应AI驱动的开发。

道理不难理解:如果你最享受的是Leetcode式的解题快感,那AI时代会让你很痛苦——你不再需要亲手推导动态规划、手写红黑树,AI几秒钟就搞定了。那种"我亲手攻克难题"的成就感,被彻底剥夺了。

反过来,如果你真正在乎的是把产品交付出去,关心的是最终结果而非实现路径,那AI时代简直是如鱼得水。

第三类人更有意思:带过团队的人。

管理者天然具备一种能力:放下完美主义,接受"足够好"的交付物。

Peter认为,这恰恰是和AI协作的核心心态。你要先保证完整性,再考虑是否完美。

管理者习惯了"委托"与"验收":你不需要亲自写每一行代码,只需要把需求讲清楚、把验收标准定好、然后检查交付物。这恰恰是和AI协作的核心能力。

还有一个反直觉的观察:新人可能有逆袭机会。

Peter的解释是:新人没有被过往经验"污染"。老程序员会下意识觉得"这个方法行不通",但新人不知道这些禁忌,反而会用老鸟想不到的方式驱动Agent——而在AI快速进化的当下,很多"行不通"的事情,可能已经行得通了。

从CEO到单人军队:Peter的燃尽与重生

Peter Steinberger不是什么"野生程序员"。

他来自奥地利农村,14岁入坑编程。后来花了13年打造PSPDFKit,这是一个最终用在超过10亿台设备上的PDF渲染框架,。公司从他一个人,发展到70多人,全球远程办公。

但CEO不好当。

用Peter自己的话说,CEO本质上就是个"兜底的人",团队搞不定的、搞砸的,最后全得创始人来收拾。

这种压力持续太久,Peter彻底燃尽了。他卖掉股份,从科技圈消失了整整三年。

那三年,他需要很长时间来解压。他参加了大量派对,过上了完全远离科技的生活——有好几个月,他甚至没有打开过电脑。

2025年4月,Peter重新打开电脑。

他想做一个Twitter分析工具,但发现自己根本不会Web开发。然后他发现了AI。

他把一个1.3MB的GitHub仓库Markdown文件拖进Gemini,输入"写个说明",AI输出400行规格说明。然后他把规格说明拖进Claude Code,输入"build"。然后不停地点continue、continue、continue...

最后AI信心满满地宣布:100%生产就绪。

Peter一启动程序,直接崩了。

但这次失败反而点燃了他。程序虽然崩了,但AI展现出的潜力已经足够震撼。它确确实实地,在几分钟内完成了一个他可能需要几周才能写出的原型。

从那一刻起,Peter开始失眠。他意识到一场革命正在发生,而他不想错过。

OpenClaw爆红:未来Siri该有的样子

Clawdbot(现已更名OpenClaw)最初只是Peter给自己搭的一个私人助手,通过WhatsApp跟他对话。

他在摩洛哥旅行时,用它导航、听笑话、甚至代发消息给朋友——那时候它还只是个"玩具"。

后来他做了一个疯狂的决定:把自己的Agent放到了公开的Discord里,让任何人都能体验。

结果完全超出预期——几乎所有试用过几分钟的人都上瘾了。更夸张的是,在这几天,它的谷歌搜索量一度超过了Claude Code和Codex的总和。

现在star数已破9万,还在涨,极为罕见的增长速度。

这个项目支持WhatsApp、Telegram、Slack、Discord、Signal、iMessage等十几个渠道,能语音唤醒,能实时画布,能多Agent路由。它不是"半吊子Siri",而是一个真正理解上下文、能自主解决问题的个人AI助手。

这才是未来个人助手该有的样子。

写在最后:给AI时代开发者的3个建议

Peter用自己的经历证明了一件事:问题从来不是"AI取代程序员",而是"程序员如何与AI融合"。

代码本身不重要,闭环才重要。

实现细节不重要,系统设计才重要。

Pull Request不重要,Prompt Request才重要。

这是一个单人开发者展现出团队级产出的时代。超级个体的时代。

建议1:构建你的验证闭环

无论用什么AI工具,都要建立compile/lint/test/deploy的自动化流水线。闭环是信任AI的前提。

建议2:保持架构敏感度

代码可以交给AI,但模块划分、技术选型、扩展性设计必须自己把控。这是AI时代程序员的核心竞争力。

建议3:学会写需求,而不只是写代码

Prompt质量决定输出质量。花时间学习如何把需求讲清楚、把验收标准定精确,这比学习新框架更重要。

这个时代,才刚刚开始。

既然看到这了,如果觉得不错,随手点个赞、收藏、转发三连吧~

我是Carl,大厂研发裸辞的AI创业者,只讲能落地的AI干货。

关注我,更多AI趋势与实战,我们下期再见!

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/23 0:05:01

IntelliJ IDEA:无法读取**.properties

目录 问题 解决方案 效果 问题 IntelliJ IDEA:无法读取**.properties,reports all properties not referenced from outside of the propertie file 解决方案 Settings - Editor - Inspections - Properties files - Unused property - disable 效果…

作者头像 李华
网站建设 2026/10/28 13:23:46

2026年02月03日热门github项目

GitHub 趋势总结 本期 GitHub 趋势榜呈现出“AI 原生工具主导、多智能体协作爆发、实用场景深度渗透”的鲜明特征。上榜的 11 个项目中,8 个聚焦 AI 辅助开发、多智能体 orchestration 或 LLM 训练领域,彰显了“智能工具链重构开发流程”的行业浪潮&…

作者头像 李华
网站建设 2026/10/29 5:16:11

Go进阶之异常处理error

1.error接口:erorr是一种内建的接口类型.内建意味着不需要"import".任何包都可以直接使用,使用起来就像int string一样自然.源码位置:src/builtin/builtin.go// The error built-in interface type is the conventional interface for // representing an error cond…

作者头像 李华
网站建设 2026/10/27 4:08:20

全网最强汉字游戏:汉字加一笔耶

游戏介绍 《汉字加一笔》、 游戏是一种富有创意和趣味性的文字游戏,通过给汉字增加一笔,形成新的、有意义的汉字。 比如:“十”字,加一笔可以变成的字:土、士、千、干、卂等,还有很多意想不到的哦&#xf…

作者头像 李华
网站建设 2026/10/20 9:49:02

在单片机串口接收程序中,通常每接收完一条报文就添加一条接收时间,而不是每接收一个字节。这是因为报文是逻辑单元,添加时间戳到完整报文更合理和高效。

从这些信息中,我可以推导出添加时间戳的常见做法:在串口接收中,数据通常以字节为单位接收,每个字节接收时触发中断(、)。但是,添加时间戳的粒度取决于应用需求:如果每字节添加时间戳…

作者头像 李华
网站建设 2026/10/29 13:57:22

电脑端串口助手一个时间戳后面跟几条完整报文,而不是每条报文添加一个时间戳,这是依据什么确定添加接收时间戳

电脑端串口助手采用“‌超时机制‌”确定时间戳的添加规则,核心依据是‌相邻报文接收的时间间隔‌。具体逻辑如下:⚙️ 时间戳分组机制 ‌时间阈值设定‌ 通过用户配置的 ‌"时间值"参数‌(如 100ms)作为分组阈值&#…

作者头像 李华