一句话
MSP 工作法，是一套以 seed 为中心、面向开放式问题的 AI-native 项目推进方法。
它的核心口号不是 fake it till you make it，而是：
Seed it till it grows.
意思是：从一个足够好的问题种子出发，在恰当的时机做恰当的事；遇到卡点或不该现在展开的复杂度，先把它折叠成 seed，保证主线继续极速推进。
它要解决什么问题
开放式问题有一个基本事实：你不可能一开始就知道完整答案。
传统软件开发里，MVP 很有用，先做一个最小可用产品，去验证市场。但在 Agent 时代，生成代码的成本变低了，真正稀缺的不再是“能不能快速做出来”，而是：
- 注意力放在哪里
- 什么现在该展开，什么现在不该展开
- 人类真正关心的问题，有没有被项目记住
MSP 工作法就是为这件事而生的。
它默认：项目不是一次性交付物，而是一个会生长的结构。人类负责注入问题、边界和启发式；Agent 负责沿着这些种子推进、构建、验证。两者协作，而不是一方替代另一方。
和 MVP 的关系
可以这样记：
| MVP | MSP | |
|---|---|---|
| 口号 | Fake it till you make it | Seed it till it grows |
| 核心动作 | 先做出最小可用产品 | 先种下最小可生长的问题/结构 |
| 主要担心 | 做太多没用的功能 | 展开太多不该现在展开的复杂度 |
| 时代语境 | 软件验证时代 | 人机协作、开放式问题时代 |
MSP 不取代 MVP。MVP 仍然负责真实功能闭环和反馈；MSP 负责让这些推进过程不变成一次性 demo，也不变成过早锁死未来的重架构。过去我们需要 MVP；现在，面对越来越多开放式问题，我们更需要 MSP。
工作法的两个核心动作
1. Problem-first：先把问题种好
MSP 相信：
Everything starts with a research question.
很多时候，交付一个高质量问题，本身就已经很有价值。我们完全可以接受当下没有好答案；但不能接受问题本身质量很低。
所以 MSP 项目通常从一个 hello_agent.md 开始。它不是操作手册，而是项目灵魂入口：人类此刻真正关心什么、长期方向是什么、哪些约束不能丢。
2. Strategic Deferral：战略性推迟，主动折叠
这是 MSP 最重要的执行纪律。
当你遇到当下不属于主线高杠杆的子问题、太复杂或信息不够的问题、已经写得过细过重并开始锁死未来的设计，不要硬刚。
正确动作是：把它 seed 化。也就是把一团复杂思绪，压缩成一条简短启发式，例如：
<!-- seed: 未来需要处理极端并发下的状态一致性；当下先绕过 -->然后继续推进主线。这不是偷懒，而是主动管理复杂度。MSP 允许你“想象卡点已被解决”，从而立刻开发依赖它的下游逻辑。
反过来也成立：如果某个文档或设计已经过度展开，你也应该有能力把它 prune / fold 回 seed。
日常怎么用：Seed Step 与 Build Step
可以把 MSP 的日常迭代理解成两步交替。
Seed Step：慢思考
人机一起看项目，问：
- 当下时机，什么该做、可做、适合做？
- 哪些地方信息过载了？
- 哪些卡点应该先折叠成 seed？
- 哪些 seed 已经到了该生长的时候？
这一步的产出，主要是增 / 删 / 改 seed，而不是立刻大改实现。
Build Step：高杠杆生长
从众多 seed 里，选出少数高杠杆、高 ROI 的点，去做开发、构建、验证、交付。
判断标准很朴素：它是不是当前真正的注意力高点？grow 它会不会显著推进主线？如果不 grow，会不会阻塞太多下游？
除非判断它是高杠杆注意力点，否则保持折叠，不要轻易擅自展开。
这有点像项目推进里的“梯度下降”：反馈给方向，seed 保存状态，高杠杆 grow 控制步长，Strategic Deferral 避免在低价值维度上浪费更新。
Seed 分层：注意力怎么分配
MSP 不只是“多写几个注释”。它把 seed 当成注意力分配机制：
| 层级 | 常见形态 | 注意力 | 作用 |
|---|---|---|---|
| System | founder_seed.md 等 |
极高 | 系统基石、偏好、协议 |
| Project | hello_agent.md |
高 | 项目灵魂、核心问题、长期方向 |
| Folder | seed.md |
中 | 模块边界、局部目标、演化方向 |
| File | inline seed | 极低 | 局部 TODO、未来线索、实现启发 |
越靠近上层，越需要人类投入注意力维护，AI 越不该轻易擅自改。越靠近具体文件，越适合用轻量 comment seed 承载局部启发。
该细处真实详写，该粗处 seed 折叠。
什么叫“用 MSP 工作法推进一个项目”
如果你说某个项目是 MSP project / Seed Project，通常意味着：
- 有一个清晰的问题入口，而不是只有功能清单
- 项目里到处有 seed，用来折叠当下不该展开的复杂度
- 迭代时会区分：先改 seed，还是先 grow 某个高杠杆点
- 评测优先发生在真实工作现场，而不是一开始就追求完整 benchmark
- 项目面向人机协作，允许演化，而不是一次定稿
所以，MSP 不只是一种文档写法，更是一种推进开放式问题的工作方式。
一个容易误解的点
MSP 不是一套越来越重的流程拐杖。
模型越强，那些为弱模型准备的固定模板，“先分析再计划再执行再复盘”，越应该退场。否则 MSP 会变成反智能的束缚。
会消失的是流程拐杖，不会消失的是 seed 本身。
因为 seed 代表的是人类真实需求和注意力锚点，什么现在不该展开，什么未来还值得接回来。这些不会因为模型变强而贬值。模型越强，反而越需要被清楚告知：此刻人类关心什么，什么不该展开。
先记住这四句就够了
MSP 工作法 = 以 seed 为中心，推进开放式问题。
口号是 Seed it till it grows，不是 Fake it till you make it。
核心动作是 Strategic Deferral：该展开就展开，不该展开就折叠成 seed。
日常循环是 Seed Step 与 Build Step：先慢思考整理种子，再挑高杠杆点生长。
结尾
MSP 工作法想回答的，其实是一个很朴素的问题：
在 Agent 越来越强的时代，人类怎样继续把真正重要的问题种进项目里，并让项目沿着这些问题长出来？
我们还没有把所有细节写清楚，也不需要一次写清楚。先把这颗种子交出去。后续再根据真实反馈，继续 seed、prune、grow。
后续可补：一个最小可操作的一周工作样例；与 gstack / msp-stack 的关系；与 nano-work 的边界；英文版。