AI-Native 系列 · 超级仓库
我把 17 个 Repo 接进一个前门，没跑通闸门，谁都别想变绿
一分钟速览——你能带走什么
我用一天的时间把 17 个 repo 接进一个超级仓库——灵感来自一款我在法律上不能抄的手写画布应用。让这套东西真正跑起来的规则是：任何卫星仓库若不先跑通自己的闸门，就不能变绿。链条 01：一张手绘草图，最终变成一份通过五项建筑检查、退出码 0 的平面图。
一个超级仓库，一天之内诞生即为绿色——灵感来自一款我在法律上不能抄的手写画布应用。整套设计只有一条规则：没有证据，就没有徽章。约 6 分钟读完。
问题所在：24 个仓库，却没有一个前门
我建 repo 的方式，就跟有些人记笔记一样——是一种强迫症。设计工具、研究工具、一个理财系统、一个职业系统、一个战略系统。每一个都能用。但放在一起，它们就是一个杂物抽屉：连 I 自己都未必记得哪个 repo 该答哪个问题。如果连自己的工具都需要人工索引才能用得上，那你手上的就不是一个产品家族，而是一堆东西。
解决办法是一场为期一天的构建，名叫 allin-anything：一个超级仓库，它唯一的产品是一份已验证覆盖度 ——一份涵盖 17 个卫星仓库的登记表，每一项都标注了它能做什么，更重要的是，标注了这句承诺里，有多少已经被机器实际核实过.
灵感来自一支笔（和它的双重身份）
触发这一切的是 penecho——一个开源画布应用，你可以在上面手写内容给 AI：公式、图表、空间草图。墨迹输入进去，结构化的草稿输出回来，草稿会一直和你已确认的成果分开存放，直到你亲自确认。物理动作进去，数字智能出来，中间隔着一道人类闸门。这就是别人已经做出来的一个应用，替我把我整个仓库家族的论点全说完了。
只有一个问题：penecho 用的是 AGPL 许可证。把它的代码抄进我的仓库，既是法律上的雷区，也是架构上的偷懒。于是它反倒成了这套设计的第一块试金石：一个卫星仓库，说到底就是一个指针、一个钉死的 commit SHA，加一份已确认事实的摘要——绝不是一份内嵌复制的代码。 我借用做法、注明来源，然后让他们的代码留在原地运行：上游。
一个 15 岁小孩也能看懂的心智模型
想象一家门禁极严的俱乐部。每个想进门的卫星仓库都会拿到一条腕带，颜色只有三种：
- ⚪ 候选 ——你上了名单。有名字，有分工，但什么都还没验证过。仅此而已。
- 🟡 已消化 ——真的有人查过你的身份证：存在一份摘要文件，事实都钉在某个具体 commit 上，未经确认的内容会标注为 unconfirmed.
- 🟢 已集成 ——你现场表演过：你自己的闸门在这台机器上跑过，并且 exit 0，前门会把流量导向你。
把门的是代码，不是感觉。校验规则的逻辑很简单：证据文件若不在磁盘上，任何状态升级都别想过关。README 里的表格是自动生成的，来自这份登记表本身，一旦二者出现偏差，CI 就会失败。第一天，9 个卫星仓库里有 7 个老老实实还是白色——README 上也如实写着，因为一张自我美化的表格，是一张你没法信任的表格。
链条 01：一张手绘草图，最后变成通得过审查的平面图
整个项目的承诺，是「与数字和物理世界的全方位交互」，所以里程碑 3 必须是一条能跨越边界的链条。目标很明确：「手绘一张房间布局图，然后验证它是否可建造。」
一个确定性路由器——每一条路由声明本身都是一个 pytest，包括那条必须拒绝内嵌 penecho 的声明——负责宣告这条链条：手绘部分交给 penecho，物理验证交给 design-anything。接着，物理这一半真的跑了起来：
$ python3 pipeline/construction_gate.py studio.json
PASS C1_topology: 4 rooms, 4 openings, all resolve
PASS C2_clearances: all openings meet table minima
PASS C3_habitability: areas, dimensions, daylight, ceiling OK
PASS C4_egress: all rooms reachable; entry door present
PASS C5_module_grid: 100% of coordinates on the 100mm module
READY: studio-flat (design-sanity gate, not a permit or PE stamp)退出码 0。一个 4 个房间、28.5 平方米的布局，通过了拓扑结构、间距、可居住性、疏散通道和网格检查——这正是那个仓库用来判定任何东西「可用」的同一道人类闸门。正是这次运行，把 design-anything 提升为 🟢。penecho 则刻意保持 🟡：手绘草图这一步由人类完成、且发生在上游，若假装机器验证过这一步，就会毁掉这张表格真正在卖的东西——信任。
这个仓库会审查自己——也会审查我
如果登记规范全凭我的心情维持，一周之内就会烂掉，所以这个仓库会给自己的运作打分：九条原则（spec-as-data、no-evidence-means-no、maker-is-not-checker、satellites-never-vendored……），每一条背后都有一个可执行的检查，在 CI 中以 90/100 为门槛把关。一条没有被量度的原则，不算通过——它会直接挡在闸门外。目前跑分是 100/100，哪天有个「捷径」让某条原则退步了，构建就会在我这里失败。
这份诚实是双向的：构建过程中，GitHub 的 CI 队列有一天状态很差——任务莫名死掉，没有日志、没有步骤、没有任何注解。我刚好升级了两个 action 的版本，所以现有证据没法分清究竟是「他们的基础设施出了问题」，还是「我的改动出了问题」。修复方式很朴素也很诚实——回退到上一个确认可用的确切配置，交由下一次运行判断——在变更日志里记为一次回滚，而非一次诊断。在书面记录里写下「我暂时还不知道」，本身就是一种本事。
何苦要搭一个超级仓库
因为不这么做的替代方案，正是这个行业的默认操作：一个宣称自己集成了各种能力的落地页。而一个设有人类闸门的登记表，恰恰是反过来的。新增一项能力，成本只是一条 YAML 记录；这道梯级会告诉每一位用户——包括未来的我自己——每一行到底能被信任到什么程度。这张表目前还很小：2 个绿、10 个黄、5 个白——发布之后的第二天，仓库自己的章程闸门就抓到我在这一段里把绿色的数量多算了。闸门说了算，文字要被更正。但表上每一种颜色，都是由一次真实运行挣来的，也只有这样的表格才能持续增值。
可以推广到别处的规则是： 如果你的系统在聚合其他系统，别聚合它们的说法——聚合它们的退出码。
AI-Native 系列更多文章
这些内容全都在首页的 Writing 板块里。
本文属于 AI-Native 系列。基于 goal-10x 循环打造：研究 → 吸收 → 教练式打磨 → 推到全绿 → 自我迭代。相信实物，别相信标签。发布按钮，握在你自己手里。