把整个项目交给 Agent，听起来像最高程度的自动化。

“做一个 SaaS。”

“把这个产品从开发做到上线。”

“帮我把增长做起来。”

一句话发出去，Agent 立刻开始拆需求、写代码、补文档、改页面。几个小时后，文件越来越多，待办越来越长，你却更难回答一个最基本的问题：

**项目现在到底往前走了一步，还是只是发生了很多活动？**

任务越大，Agent 越需要替你决定什么更重要、先做什么、做到什么程度、什么时候停。结果不是更自动，而是更多关键判断被藏进执行过程。

另一种极端也没有更好。

你把工作切成“改一个按钮”“加一个字段”“补一个测试”“换一句文案”。每一项都能很快完成，可一个星期过去，用户仍然不能顺利使用产品，市场也没有给你任何新反馈。

任务太大，会失去边界。任务太小，只会积累动作。

真正能让项目推进的单位，不是最大任务，也不是最小改动，而是一个能闭环的环节。

闭环不是“做完一串事情”

一个环节闭环，至少要发生三件事：

1. 它改变了一个真实状态； 2. 你能观察到结果； 3. 结果会告诉你下一步该继续、调整还是停止。

例如，“优化新用户体验”不是闭环。它没有说明哪一种体验、服务哪个动作，也没有共同的停止条件。

“让第一次安装的用户成功生成路线图，并在真实 VS Code 窗口里完成一次环节启动”更接近闭环。

它有明确的状态变化：用户从刚安装，走到第一次成功运行。 它有可观察结果：安装、生成、启动这条路径是否真的走通。 它会产生下一步：如果成功，继续观察首次使用；如果失败，修复最先阻断用户的地方。

这比“完成整个产品”小得多，又比“改一个按钮”完整得多。

环节要足够小，也要足够完整

“足够小”不是代码行数少，也不是一天内一定能做完。

它意味着边界清楚：

  • • 只有一个主要结果；
  • • 知道哪些东西本轮不改；
  • • 出现相邻问题时，不会悄悄换掉目标。

“足够完整”则意味着它能独立接受现实检验：

  • • 用户可以完成一个动作；
  • • 产品状态真的发生变化；
  • • 你拿到了能影响下一步的证据。

如果一个任务结束后只能说“我们改了五个文件”，它可能很小，却没有闭环。

如果一个任务需要同时完成产品开发、官网、定价、获客和用户研究，它看起来完整，却大到没有可守住的边界。

好的环节位于两者之间：**小到可以负责，完整到值得验证。**

用 Build、Sell、Learn、Improve 找到最近的结果

面对一个大目标时，不要先问“可以拆成多少任务”。先问：

> 现在最需要发生的，是构建、销售、学习，还是改进？

这四类动作不是部门，也不是固定流程。它们帮助你判断，项目距离下一个真实结果还缺什么。

Build：先让一个关键动作成立

当产品还不能完成核心动作时，最近的结果通常属于 Build。

不是“把产品做完”，而是：

> 让第一次使用的人可以创建项目、看到路线图，并启动一个环节。

完成后，你得到的是可使用的路径，而不是更多半成品模块。

Sell：先验证别人是否理解价值

当产品能用，却没人知道为什么需要它，最近的结果可能属于 Sell。

不是“做增长”，而是：

> 用一个清楚的页面向五位目标用户解释价值，并记录他们是否愿意继续了解。

这里的结果不是虚构转化率，而是真实表达是否被理解。

Learn：先减少一个关键未知

当你不知道问题出在哪里，继续开发往往只是扩大赌注。

最近的结果可以是：

> 观察三次首次使用，找出最早出现、重复最多的阻断点。

Learn 不是收集一堆意见，而是让一个会改变决策的未知变得更清楚。

Improve：先修复最影响结果的一处

当真实证据已经指出主要摩擦，最近的结果属于 Improve。

不是“全面优化体验”，而是：

> 修复首次启动中最常见的阻断，并重新完成同一条真实路径。

改进只有回到原来的用户动作上复验，才算闭环。

不要把四类动作一次全塞进一轮

很多项目烂尾，不是因为没有路线图，而是每一轮都想同时完成 Build、Sell、Learn、Improve。

开发一个功能，顺便重做官网； 写官网时，顺便确定定价； 讨论定价时，又决定先做用户访谈； 访谈还没开始，又回头重构产品。

每个决定单独看都合理，放在同一轮里却会互相抢夺终点。

闭环环节的关键不是把世界切得越碎越好，而是让一轮只对一个主要状态变化负责。

其他发现可以进入后续路线图，但不能在没有判断的情况下接管当前环节。

一个大目标，如何收束成下一环节

假设你的目标是：

> 发布一个可以帮助独立开发者管理 AI 项目的产品。

不要立刻把“发布产品”整体交给 Agent。先写四行：

  • • 当前事实：产品能安装，但首次使用路径尚未完整验证；
  • • 最近结果：一位新用户能生成路线图并启动一个环节；
  • • 本轮边界：不改定价，不扩渠道，不新增第二套入口；
  • • 验证证据：在全新环境中完成安装、生成和启动，并保存结果。

这就是一个可以开始的 Build 环节。

它完成以后，再由证据决定下一步。可能进入 Learn，观察用户在哪里犹豫；可能进入 Improve，修复首个阻断；也可能进入 Sell，把已经成立的价值讲给目标用户。

路线图不是提前猜完所有任务。它让每一次闭环都为下一次判断提供依据。

SoloMap 让路线图环节成为真实执行单位

SoloMap 把 Build、Sell、Learn、Improve 放在同一条项目推进路线里。你可以从当前最需要的结果建立环节，让它带着目标、完成标准、边界与交接进入 Agent 对话。

Agent 负责调查、实现和验证。你仍然决定本轮值得改变的状态，以及哪些事情不该顺手扩进来。

这样做不是把 Agent 管得更细，而是把项目责任放回一个可观察结果上。

现在花 15 分钟，找出你的下一个闭环

拿出你当前最大的目标，完成下面四句话：

1. 现在最重要的是 Build、Sell、Learn 还是 Improve？ 2. 这一轮结束时，哪个真实状态必须发生变化？ 3. 哪些相邻问题明确不属于本轮？ 4. 你会亲自查看什么证据，决定继续、调整还是停止？

如果答案仍然包含“做完整个产品”“全面优化”“把增长跑通”，再缩小一次。

如果答案只剩“改一个文件”“加一个按钮”，再补上它要改变的用户结果。

直到这个环节足够小，可以守住边界；又足够完整，能让现实给出反馈。

**一次只推进一个能闭环的环节，不是放慢项目。它是让每一次 Agent 执行，都真正把项目带到一个新的位置。**