⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 古时的风筝 「古时的风筝」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注微信公众号:【芋道源码】有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

前几天刷 GitHub Trending,我被一个数字吓到了。

一个叫 claw-code 的仓库,两小时冲到 5 万 star,现在已经超过 17 万了。这是目前 GitHub 上达到 5 万、10 万 star 最快的仓库,没有之一。

仓库地址:https://github.com/ultraworkers/claw-code

只看名字可能已经看出来了,这个项目和 Claude Code 是有关系的。没错,这就是前几天 Claude Code 在发布 NPM 包时,将source map 源码放出来了,变相也算开源了。

claw-code 的作者Sigrid Jin在得到这个消息后,为了规避版权风险,决定用 Python 重写 Claude Code 源码,虽然功能都没变,但是新项目和 Claude Code 没有一行源码是一样的,这样一来,就不存在侵权的问题了。

Claude Code 意外放出来的源码有 51 万行只多,在一夜之间将这个庞然大物翻译成另一门语言,并且保持功能可用,这可不是手速问题。

在开源后两个小时内就获取了 5 万 star,这其中的一半人是冲着 Claude Code 去的,另一半人则是想看看一晚上干出来的成果质量如何,什么 AI 这么牛掰。

现在不止有 Python 版了,Rust 版本也出来了。

作者也说了,代码只是副产品,真正有价值的是如何在一晚上的时间重写 51 万行代码背后的工程实践。

代码是副产品,系统才是正品

仓库作者写了一篇很长的开发手记。里面有一句话,我反复读了好几遍:

The code is a byproduct. The system that wrote it is the product.

代码不是产品,写代码的那套系统才是真正的产品。

据作者描述,claw-code 的诞生过程是这样的:一个人打开手机上的 Discord,敲了大概十句话,放下手机去睡觉了。

然后 agent 团队接管了一切。它们读到消息,自己拆任务、分角色、写代码、跑测试、互相 review、修 bug、跑通就提交。第二天早上作者醒了,代码已经在仓库里了。

没有终端,没有 IDE,没有 SSH,没有 Vim 分屏,入口就是 Discord,一个聊天框,一个发送按钮。

你在 README 看到的那些跑得飞快的 tmux 终端截图?那是 agent 在用,开发者基本上用不到。

一夜51 万行代码,作者的黑科技

咱们来看看作者用了什么黑科技,能够一夜重写 51 万行代码。

就是下面这 3 个工具,于是我连夜研究了一番,惊呼:这是谁的部将!

OmX(oh-my-codex)

这是套在 OpenAI Codex CLI 上面的一个工具,负责工作流。

它把常用操作做成可复用的关键词:$architect 负责分析,$executor 负责实现,$plan 负责规划。还有两个重模式:$ralph 跑持久执行循环,一直干到任务验证通过为止;$team 协调多个 agent 并行干同一个项目的不同模块。

作者在 Discord 里敲了一句 $team "implement the core runtime",OmX 就把这句话翻译成一整套多步工作流,自动分配出去。

oh-my-codex 仓库地址:https://github.com/Yeachan-Heo/oh-my-codex

clawhip

clawhip 是个后台常驻的事件路由守护进程。它盯着 Git commit、GitHub issue、PR、tmux 会话、agent 生命周期事件,把状态更新推到对应的 Discord 频道。

这里有个很关键的设计决策:clawhip 把所有监控工作放在 agent 的上下文窗口之外。一个正在深度实现任务的 agent,它有限的上下文不应该被通知逻辑和消息格式化塞满。

clawhip 负责送信,agent 只管写代码。

做过 agent 开发的人应该能体会这个设计有多重要,上下文窗口就是 agent 的工作记忆,塞进去的每一条无关信息都在挤占它思考核心问题的空间。

clawhip 仓库地址:https://github.com/Yeachan-Heo/clawhip

oh-my-openagent

oh-my-openagent 是多 agent 协调层。

Architect 的方案和 Executor 建出来的东西冲突了怎么办?信息怎么同步?任务怎么交接?验证怎么做?都归它管。

三个工具拆开看都不算惊艳。拼起来就是一个闭环:人通过 Discord 下指令,Architect 拆方案,Executor 动手,Reviewer 挑毛病,反馈严重就回 Architect 重新规划。

这个循环一直转到所有检查通过。而开发者,可以睡觉了。

真正变贵的东西

作者的推文里有一段话,我也有同感:

当一个系统能在 60 分钟内移植整个代码库,什么变贵了?

知道该建什么?知道为什么?理解各个零件应该怎么拼?有一个清晰的目标架构心智模型,能把它拆成 agent 可以执行的任务,知道怎么设计协调让多个 agent 并行还能保持高产。

坦白讲,”架构能力比编码能力重要”这种话说了好多年,但限于之前写代码这件事确实有很大的门槛,一直表现得不太明显。

agent 越强,清晰思考越值钱。

两种开发者,两种处境

作者在文章结尾分了两类人。

第一类,职业护城河建立在”我能写别人写不出的代码”之上。

大厂一路爬梯子,优化晋升路径。他们的技能是真的,但那技能的定价建立在稀缺之上,现在稀缺正在蒸发。

一个有良好 prompt 直觉和清晰 spec 的初级开发者,一下午就能干出一个高级工程师过去一周的活。

第二类,从一开始就无法融入组织架构的人。

他们从零做东西,不是因为该做,是因为脑子里有一个想法赶不走。对这些人来说,过去最大的约束不是智力不够,是带宽不够,想法永远比执行力多。

现在带宽突然变便宜了,这些人觉得自己拥有了超能力。

如果你的价值是”我能写代码”?那这条护城河正在一点一点地被填平。

如果你的价值是”我知道该写什么、为什么、长什么样”?那这条护城河正在变宽。

最后

如果你也在焦虑 AI 会不会取代开发者,我建议换个问题问自己:

假如明天早上你手上有一支随时待命的 agent 团队,能在你睡觉的时候交付任何代码,你让它去建什么?

文章目录