Self-hosted development自举开发指南

How to build the tool you run every day without blowing up your daily driver — the dual-track workflow, plus how Linux, Karpathy, and the OpenClaw author handle eating their own dogfood.如何开发「自己每天都在用」的工具而不把日常环境玩坏——双轨工作流,以及 Linux、Karpathy、OpenClaw 作者各自的自举实践。

The trap: repo as production directory陷阱:仓库即生产目录

This harness itself was born inside ~/.pi/agent/extensions/ — the git repo was the live extension. Three risks showed up immediately:本 harness 最初就诞生在 ~/.pi/agent/extensions/ 里——git 仓库就是正在运行的扩展。三个风险立刻显现:

The dual-track workflow双轨工作流

Daily use = your published stable. Remove the in-place pointer and eat the same bowl as your users:日常使用 = 你发布的稳定版。卸掉原位指针,和用户吃同一碗饭:

pi remove  local:~/.pi/agent/extensions/pi-muselinn-harness   # avoid double-loading
pi install npm:pi-muselinn-harness                            # same bits as everyone else

Development = project-scoped loading. Move the repo to your normal project area, and load the dev version only where you test it — a scratch project with .pi/extensions/ symlinked back. The global npm install stays untouched; a broken experiment only breaks the scratch project.开发 = 项目级加载。仓库挪到正常项目区,开发版只在试验项目里加载——scratch 项目里放 .pi/extensions/ 软链回仓库。全局 npm 稳定版不受影响,玩砸了也只是那个项目的事。

Release = a conscious cut. feature branch → full test suite green → merge to main → bump → publish → tag → pi update on your machine. Publishing stops being "push whatever" and becomes a deliberate act with a version anchor.发布 = 有意识的 cut。feature 分支 → 测试全绿 → 合 main → bump → publish → tag → 本机 pi update。发布从「顺手一推」变成带版本锚点的刻意动作。

How the masters do it名家怎么做

Linux & GCC: bootstrap with a trusted stage0Linux 与 GCC:可信 stage0 的自举

GCC compiles itself in three stages: the system compiler builds stage1, stage1 builds stage2, stage2 builds stage3 — then stage2 and stage3 are compared bit-for-bit. Self-hosting is only trusted when the final artifact can reproduce itself. Git followed the same arc: Linus wrote it in about two weeks in April 2005 and immediately moved git's own history onto it — but the initial import came from a trusted external state. Lesson: keep a known-good fallback you can always rebuild from, and make "rebuild from scratch" a routine, verified path.GCC 用三阶段编译自己:系统编译器产出 stage1,stage1 产出 stage2,stage2 产出 stage3——然后逐字节对比 stage2 与 stage3。自举只有在产物能复现自身时才被信任。git 也走过同样的路:2005 年 4 月 Linus 用约两周写出 git,随即将 git 自己的历史导入自托管——但初始导入来自可信的外部状态。教训:永远保留一个已知良好的可回退版本,并把「从零重建」变成例行的、被验证的路径。

Karpathy: small surface, evals before agentsKarpathy:小表面积,评估先行

Andrej Karpathy's self-hosting tools (micrograd, nanoGPT, llm.c) are deliberately tiny — small enough that one person can read every line, which is exactly what makes them safe to modify with AI assistance. His public guidance on agentic coding is consistent: write the evals first, then let the agent iterate against them. The harness equivalent: our 269 pure-node assertions run without model quota, so every change is gated by a cheap, deterministic check before it ever reaches a session.Karpathy 的自举工具(micrograd、nanoGPT、llm.c)都刻意做小——小到一个人能读完每一行,而这正是敢让 AI 参与修改的前提。他关于 agentic coding 的公开建议始终如一:先写评估,再让 agent 迭代。对应到本 harness:269 项纯 node 断言不烧模型额度,任何改动先过一道便宜、确定性的门禁,才轮到真实会话。

steipete (OpenClaw): the agent fixes itself, the human reviewssteipete(OpenClaw,社区称「龙虾之父」):agent 修自己,人来把关

Peter Steinberger built OpenClaw largely with the agent itself — it patches its own code, opens its own PRs, restarts into its own new builds. The reason this doesn't collapse is the scaffolding around it: heavy CI on every change, fast rollback habits, and a human who owns architecture decisions and reviews what lands. Dogfooding at that intensity works because the safety rails are built first, not after the first fire.Peter Steinberger 用 OpenClaw 自身完成了它大部分的开发——自己改代码、自己提 PR、重启进自己的新构建。这套玩法不塌的原因是周围的脚手架:每次改动都有重 CI、快速回滚的习惯、以及一个始终掌握架构决策和 review 的人类。这种强度的自举能成立,是因为安全栏杆先于事故建好,而不是等第一次着火。

The checklist落地清单

Links链接