惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Jina AI
Jina AI
T
Threat Research - Cisco Blogs
量子位
Last Week in AI
Last Week in AI
aimingoo的专栏
aimingoo的专栏
Martin Fowler
Martin Fowler
F
Fortinet All Blogs
爱范儿
爱范儿
D
Docker
人人都是产品经理
人人都是产品经理
S
SegmentFault 最新的问题
Microsoft Azure Blog
Microsoft Azure Blog
B
Blog RSS Feed
A
About on SuperTechFans
P
Proofpoint News Feed
博客园 - 司徒正美
Recent Announcements
Recent Announcements
I
InfoQ
Hugging Face - Blog
Hugging Face - Blog
Microsoft Security Blog
Microsoft Security Blog
有赞技术团队
有赞技术团队
Webroot Blog
Webroot Blog
云风的 BLOG
云风的 BLOG
Vercel News
Vercel News
SecWiki News
SecWiki News
Attack and Defense Labs
Attack and Defense Labs
Hacker News: Ask HN
Hacker News: Ask HN
AI
AI
博客园_首页
腾讯CDC
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Recent Commits to openclaw:main
Recent Commits to openclaw:main
Recorded Future
Recorded Future
T
Tailwind CSS Blog
MyScale Blog
MyScale Blog
T
Tenable Blog
宝玉的分享
宝玉的分享
Google Online Security Blog
Google Online Security Blog
Security Archives - TechRepublic
Security Archives - TechRepublic
S
Secure Thoughts
C
Check Point Blog
S
Security Affairs
L
LINUX DO - 最新话题
大猫的无限游戏
大猫的无限游戏
Scott Helme
Scott Helme
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Hacker News - Newest:
Hacker News - Newest: "LLM"
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
月光博客
月光博客
Y
Y Combinator Blog

博客园 - AI健康

Git & GitHub 协作操作手册(三人团队) Copilot: 如何把kiro的spec转到leanSpec来 chatGpt- 图片文件的群识别工程可落地 chatGpt-pc端监控获取微信群中照片 sonnet4.6: 如何在windows/android上使用无障碍功能保存微信群图片 openclaw-zero-token worked, respect and thanks the author and contributors openclaw-zero-token仓库支持的免费模型如下: 各AI平台 Web 使用政策-from sonnet4.5 openclaw-zero-token在wsl启用备忘 trae's tools include: figma, editor,etc. and its shortcut is c-a-/ opencode答复:Atlas vs Sisyphus 的关系 Windows 下 AI IDE/CLI 规则加载实测:硬链接能解决什么,不能解决什么 github-copilot源码调研kimi-cli:没有显示它支持全局规则文件 三大GUI AI 编程助手快捷键全解析:Antigravity、Trae 与 Kiro 对比指南 mouseless(少鼠) 技术调研 调研 骨传导麦克风 具体在图书馆等安静场合,微小声音模式下语音输入-结论是暂时不可行 opencode server,web两命令, --mDNS 参数的使用场景 跟 ChatGPT 对话:运行wsl+open code资源消耗-没验证 静态为主轻交互微信小程序开发环境推荐-chatgpt推荐 AI coding大模型+工具的组合实际效用对比
小龙虾作者peterSteinberger同时推进多少个项目?-来自copilot-edge
AI健康 · 2026-03-25 · via 博客园 - AI健康

自己:之前看到一张截图,说小龙虾作者 Peter 的 GitHub 仓库有几十个项目,挺好奇的,这是怎样一个人?我们要学习他的大力出奇迹。本身也想通过这个来激励团队,团队里甚至有一位比我年长几岁的老大哥,以下是当时跟AI的的对话。

CopilotAI:

你这个问题问得很狠——不是“他做了哪些东西”,而是“过去一个月他同时在跑多少个项目”。只能说:Peter 的 GitHub 活动量,已经接近“人形 CI”。


结论先说

基于目前能从公开信息(主要是他的 GitHub 主页和仓库列表)看到的信号,过去一个月内,Peter 同时在推进的项目数量,保守估计在 15–25 个仓库级项目的量级

这里的“项目”我用的是比较工程化的定义:

至少有一次 commit / release / 代码更新 / 配套工具更新,且仓库本身是一个独立工具或组件,而不是纯文档或小脚本碎片。

因为 GitHub 不直接给“过去 30 天活跃仓库数”的统计,只能通过他公开仓库的“Recently updated”列表和 README 中的“Current Projects”交叉推断,是一个下限估计,实际并发项目数只会更高,不会更低。


他最近一个月明显在动的项目样本

从他 GitHub 主页和仓库列表中,能看到一批在最近几天到一两周内更新的项目,这些基本可以视为“当前活跃项目”:

仓库 / 项目 类型 /定位 最近状态(相对时间)
CodexBar OpenAI / Claude Code 使用统计工具 Updated ~1 小时前 Github
oracle “Ask the oracle” 多模型调用工具(GPT-5 Pro 等) Updated 昨天 Github
stats-store Sparkle 的隐私优先分析工具 Updated 昨天 Github
discrawl Discord → SQLite 的镜像 / 搜索工具 Updated 昨天 Github
osc-progress 终端 OSC 进度条小库 Updated 2 天前 Github
tokentally LLM token & 成本计算库 Updated 3 天前 Github
summarize URL / YouTube / Podcast / 文件摘要工具 Updated 5 天前 Github
macos-automator-mcp 通过 MCP 调用 AppleScript / JXA Updated 上周 Github
homebrew-tap 他所有工具的 Homebrew tap Updated 上周 Github
triage Shell 工具(多半是内部维护脚本) Updated 上周 Github
birdclaw 推文归档,方便给 agents 用 Updated 上周 Github
Tachikoma Swift AI SDK(统一多家模型) Updated 上周 Github
Peekaboo macOS 截图 & GUI 自动化 + MCP Updated 上周 Github
agent-scripts 各项目共享的 agent 脚本集合 Updated 上周 Github
gogcli Google 套件 CLI(Gmail/GCal/GDrive 等) Updated 上周 Github
AXorcist macOS Accessibility 的 Swift 封装 Updated 上周(列表中可见) Github

仅从这一段“最近更新仓库”列表,就已经能看到十几到二十个在最近一周内有活动的项目,而我们要看的时间窗口是“过去一个月”,所以真实数量只会更多。


他自报的“Current Projects”维度

在他的 GitHub 主页 README 里,他自己列了一串“Current Projects”,包括但不限于: Github

  • OpenClaw:agent 平台核心
  • VibeTunnel:把浏览器变成终端,远程控制 agents
  • CodexBar:token / 使用统计
  • Peekaboo:截图 + GUI 自动化
  • summarize:URL / 文件摘要
  • **RepoBar / gogcli / wacli / discrawl / sag / Brabble / sonoscli / ElevenLabsKit / goplaces / gifgrep / camsnap / spogo / ordercli / blucli / macOS Automator MCP / Claude Code MCP / AXorcist / Tachikoma / tokentally / Trimmy / TauTUI / Commander / remindctl / mcporter / Sweet Cookie / SweetCookieKit / sweetlink / bird / oracle / tmuxwatch / agent-rules / Markdansi ...

这份列表本身就已经是三十个量级的“当前项目”,而且他在博客里也强调“Every commit lands on GitHub for you to fork & remix”——也就是:

他基本把所有在做的东西都开源挂在 GitHub 上。 steipete.me

结合“最近更新仓库”列表,可以合理推断:

  • 这三十多个“Current Projects”里,有一大半在过去一个月内有过活动;
  • 再加上一些没写在 README 里但在 Repositories 列表中活跃的小工具 / glue code 仓库;
  • 所以“过去一个月内有实际推进的项目数”落在 20 左右 是非常合理的估计。

为什么不能给出一个“精确数字”

如果你想要一个类似“过去 30 天内 steipete 有 commit 的仓库数量 = 23”这种硬数字,理论上需要:

  1. 遍历他所有公开仓库列表(包括 org 下他主导的项目,如果算在内的话);
  2. 对每个仓库拉取 commit / PR / release 的时间线;
  3. 过滤出过去 30 天内有活动的仓库;
  4. 去重并统计数量。

GitHub 网页 UI 本身不会直接给这个统计,只能通过:

  • GitHub API(需要写脚本 + token);
  • 或者你自己写一个小工具去抓他的 Repos 列表 + commits。

在当前这个对话环境下,我没法实际跑 API / 脚本,所以我能做的是基于公开页面的“最近更新”信息 + 他自报的 Current Projects 列表,给出一个工程上可信的区间估计


如果你想要“精确到仓库”的结果,我会这样干

按你的风格,我猜你其实更想要一个可复用的脚本化方案,而不是一个模糊数字。你可以自己在本地跑一遍,得到一个“过去 30 天活跃仓库清单 + 数量”。

大致步骤(伪流程):

  1. 获取 steipete 的所有仓库列表

    • 用 GitHub API:
      • GET https://api.github.com/users/steipete/repos?per_page=100&page=N
    • 记录:name, pushed_at, updated_at, language, archived 等。
  2. 过滤过去 30 天内有活动的仓库

    • 条件可以用:
      • pushed_at >= now - 30 days
    • 可选再加:排除 archived == true
  3. 统计数量 + 输出清单

    • 输出:
      • 总数(即你要的“同时在跑多少个项目”);
      • 每个仓库:名称、描述、最近 push 时间、主要语言。
  4. 可选:按“项目族”聚合

    • 比如把 OpenClaw 生态、音频工具、终端工具、MCP 工具分组,看他在多少“方向”上并发推进。

如果你愿意,我可以帮你直接写一份:

  • GitHub API 调用脚本(Python / Node / shell 都行);
  • 再加一个简单的“过去 30 天活跃仓库统计器”。

回到你真正的问题:他到底在“同时做多少事”

从你问法里,我感觉你其实在观察一个问题:

一个高产的个人开发者 / 架构师,在 AI 工具时代,现实中可以并发维护多少个 serious 项目,而不完全崩掉?

从 Peter 现在的github公开轨迹看:

  • 他不是在做“一个大产品 + 偶尔 side project”,
  • 而是围绕一个生态(OpenClaw + agents + dev tooling)在疯狂铺工具矩阵
  • 这些项目之间高度复用:脚本共享、MCP 共享、CLI 设计风格统一、Homebrew tap 统一分发;
  • 所以他能在20+ 个项目并发推进的情况下,仍然保持“看起来很有秩序”的节奏。

如果你是想拿这个作为自己团队 / 个人的“并发项目上限”参考,我会这样解读:

  • 数字本身(15–25)不重要
  • 关键是:
    • 项目之间要有强复用 / 共用基础设施
    • 你的“项目”更像是同一宇宙里的不同工具 / 适配层,而不是完全无关的产品线;
    • 这样你就可以像他一样,把 GitHub 当成一个“生态的时间线”,而不是一个个孤立仓库。