# MSP：Seed it till it grows

> Seed status: v0。  
> 这篇先保持为 MSP-style seed，不写成完整方法论手册。

## Core seed

MSP 可以先理解成一句话：

> 从真实 problem 出发，把当前最有生命力的部分 seed 下来，让它在反馈中自然 grow。

它反对两种冲动：

1. 一有想法就写庞大计划；
2. 一有任务就马上进入 Build Step。

MSP 更关心的是：这个问题现在成熟到哪一层？它应该被 seed、被折叠、被验证，还是被交给 delivery 去 grow？

## Minimal Seed Problem

Minimal 不等于小，也不等于低配。

Minimal 指的是：当前能承载问题生命力的最小表达。它应该足够短，让人愿意反复回来；也应该足够准，让下一位 agent 不会误判方向。

Seed 不等于 TODO。

TODO 偏执行，seed 偏生长。一个好的 seed 会告诉后来的智能体：这个问题为什么重要、现在不能展开什么、什么信号出现时可以 grow。

Problem 是第一位。

如果没有抓住 problem，项目文件、功能列表、文章标题和任务看板都会变成表层动作。

## Strategic deferral

MSP 最重要的能力之一，是战略性推迟。

不是逃避复杂度，而是承认有些复杂度现在展开会污染主线。把它折叠成 seed，等证据、反馈或注意力成熟后再 grow。

例如：

- 不知道完整产品形态时，先写清楚用户真实痛点；
- 不知道完整架构时，先写清楚系统必须保留的边界；
- 不知道文章终稿时，先写清楚核心判断和未来证据入口。

## Grow handoff

Seed 可以长成很多东西：

- 文章；
- 项目；
- skill；
- workflow；
- eval；
- demo；
- product surface；
- research question。

但不是每个 seed 都应该立刻 grow。Grow 的条件不是“这个想法不错”，而是：

> 不 grow 会持续造成误判、重复解释或行动损失。

## MSP for WeHub

WeHub 特别需要 MSP，因为 WeHub 的对象不是单一 app，而是一组会持续变化的 agent、频道、记忆、项目和人。

如果没有 MSP，系统很容易变成两种东西：

- 一堆看似厉害但彼此不长在一起的工具；
- 一套过早定型、很快跟不上真实协作的流程。

MSP 让 WeHub 保持活性：先 seed，后 grow；先问题，后结构；先证据，后制度。

## Next grow

这篇文章下一步不应该扩成完整教程。更好的 grow 方向是三个真实例子：

1. 一个文章 seed 如何长成可发布文章；
2. 一个项目 seed 如何长成 delivery；
3. 一个 agent skill seed 如何长成稳定工作流。

Seed delta: 这篇文章先固定 MSP 的姿势，而不是写全 MSP 理论。后续 grow 由真实例子驱动。