跳到正文
yPulse
yPulse产品矩阵的中枢

整个矩阵,一个中枢

yPulse 持续采集产品矩阵的全部状态——发布、进度、功能、任务——并把它们收进一个可编排的指挥台。状态是干活的副产品,不是一项额外的工作;而监控,只是这个中枢的第一块能力。

26个项目在中枢监控下增删只改 config/projects.yaml 一行,采集与 webhook 都从它收敛。
1456条功能台账,每晚自动汇总分布在各仓库自己的 .roadmap/features.yaml 里,与代码同仓同评审。
今天矩阵最近一次发布yPulse v0.5.53 —— 发版即触发采集,数分钟内上板。
每日 07:00 JST 自动采集,发版即触发在 GitHub 上看

以下数字由 yPulse 实时读取——这块落地页本身,就是 yPulse 的一个终端。
这套系统的方法论

LIVE FROM THE MATRIX

一块看板,装下整个矩阵首页是可拖拽编排的看板,布局按账号保存。每个项目的发布、活跃度、完成度在同一视野里——不用打开十几个仓库,就知道今天该看哪一个。

看它具体做什么
已落地的能力

采集、汇总,然后让状态自己浮上来。

01

采集全矩阵的状态。

每日 cron 与发版 webhook 双触发,自动收集发布、活跃度与指标;项目增删只改一行配置。

  • GitHub
02

让台账住在仓库里。

每个仓库自带 .roadmap/features.yaml,写完功能顺手记一行;每晚汇总成完成度与发布时间线。

  • GitHub
03

把想法收进一条状态机。

idea / task / todo 统一入口,inbox → triaged → doing → done;成熟的开发任务毕业为 GitHub Issue。

  • Neon Postgres
04

一个数据核,任意多的终端。

网页看板、Discord 斜杠命令(含自然语言捕获 /c)、Claude MCP 六个工具——同一个任务库,加终端不动数据模型。

  • Discord
  • MCP
方法论

三条原则,决定了它长这样

yPulse 不是从「我想要一块 dashboard」开始的,而是从三个判断开始的。

01

状态是副产品。

任何需要专门抽时间去「更新状态」的系统,三周内必然荒废。所以状态必须从工作本身溢出:发版触发采集,提交携带台账,对话即是录入。

02

事实住在仓库里。

功能台账与代码同仓、同 PR、同评审。状态与工作零距离,就不存在「忘了同步」这回事。

03

中枢—终端。

一个数据核,入口可以无限多。网页、Discord、MCP 只是最先长出来的三个;终端是消耗品,数据模型是资产。

这三条原则,比任何一个具体功能都更值得抄走。

路线

监控只是第一步

中枢的职责是替一个人扛起「协调层」——公司里由状态会、运营和 CRM 分摊的那一层。按这个方向,能力在逐块生长:

全状态监控发布、进度、功能、任务,矩阵全量采集已落地
分发监控各内容平台的发布与表现,收进同一块看板规划中
关系维护用户与客户往来的沉淀与跟进规划中
灵感 → 立项从 inbox 里的一个想法,到一个新仓库的完整链路规划中
SHIP LOG

矩阵这周发生了什么

yPulse / 矩阵最近发布
© 2026 CAT FOREST · BUILT IN THE OPENlook: stillnote · yLookbook