第 4 章 · 把范围砍到一个流程
砍到什么程度，它还成立？
范围不是越大越安全，而是越大越做不完；砍到不成流程为止，再退回一步。
- 这一章回答
- 砍到什么程度，它还成立？
- 你会做出来
- 一条步骤可数、砍无可砍的核心流程
现在你有一个真实的问题和几条站得住的证据。下一步最容易出事：决定做多少。
几乎所有人第一次都会做多，而且察觉不到——因为每一个加进来的东西单独看都合理。
机制
功能不断累加，核心流程始终没跑通。
它难防是因为没有「出错的时刻」。你只是在第 3 天想到「应该能保存一下」，第 6 天想到「那得有列表页」，第 9 天想到「列表多了要能搜索」。三条都对，合起来核心流程推迟两周。
直觉做法是「把重要的留下」。这行不通——所有功能在你眼里都有点重要，否则你不会想到它。
有效的做法反过来：一条一条砍，砍到流程断掉为止，再退回一步。 它不要求你判断「重不重要」（主观，你会放水），只要求判断「砍掉之后用户还能不能走到结果」（客观，只有能和不能）。
裁剪时要同时盯住两个判断，它们不能合成一个分数：
- 时间是加法。 留下的越多，加起来越做不完。
- 流程是一条链。 链断了，再省时间也没有意义。
用户为了拿到结果必须走的那条路。只有一条，不是功能列表。每一步要能回答：用户看到什么？需要给出什么？拿到什么？
第二条最容易错。砍掉「粘贴输入」却留着「结果页」，剩下的条目看起来还有四个功能、工期也降了，但用户走不到结果——省下的时间一分价值都没有。这在清单上看不出来，只有把条目排成一条链才看得见。
现实案例
初始提交一次性落了 75 个文件、8,251 行：产品页、thesis 页、about 页、多语言路由、sitemap、robots、manifest、opengraph 图片生成，全都有了。
两天后改了一次 logo（7 个文件，+14/-24）。
然后停了两个月。
10 月 10 日才有下一次提交。此后一周内连续四次：加学习系统（+955/-304）、扩语言（+1,240/-55）、加 profile（+78）、落品牌文档（+1,233）。
两个月的空窗不是因为忙。第一次提交就把范围铺到了六个产品、七个学习系统、六种语言——这个体量下，任何一次改动都要同时动很多地方，于是每次打开仓库都要先想「从哪开始」。
对照 10 月那一周：每次提交只动一件事，四次改动加起来比初始提交还小，但推进速度完全不同。
动手试
一开始所有条目都是「留着」。逐条决定砍还是留，右边同时给两个判断：剩下的要多久，以及剩下的还构不构成一条路径。
「做一个 AI 学习平台：用户登录后可以选课程，和 AI 聊天答疑，系统根据表现推荐下一步学什么，答题拿积分上排行榜，社区里互相提问，高级功能按月订阅。」
原始范围 14 条，加起来约 33 周。你的预算是 4 周。
还有 14 条没决定。
试试砍掉流程链上的第一步，看判定变成什么。那就是「砍断了」——总工期很好看，但没有价值。
你的行动
把你的项目拆成条目，每条标一个粗略工期（半周为单位，不要假装精确），标出依赖关系。
逐条砍，每砍一条检查剩下的还能不能从入口走到结果。砍到断为止，退回一步。
产出：一条步骤可数、砍无可砍的核心流程。
检查标准
- 剩下的条目构成一条从入口到结果的完整路径
- 总工期落在我真实可投入的时间内
- 我能说出每一条被砍掉的东西为什么第一版不必要
- 核心流程不超过五步
- 我没有把「以后要加」的东西偷偷留在清单里
容易搞错的地方
单看确实简单，但它从不单独出现：加了保存就要有列表，有了列表就要能删除。
判断标准不是「这条难不难」，而是「核心流程跑通之前它是不是必须的」。不是就砍，哪怕只要十分钟。
被砍的十条不是坏主意，只是不属于这一轮。把它们写进明确不做的清单：一是你不会在第三周又捡回来，二是有人问起时你说得出「我知道它不在，这是有意的」。
本章自测
- 为什么「挑重要的留下」行不通？
- 时间和流程这两个判断，为什么不能合成一个分数？
- 工期从 33 周降到 18 周，为什么那是一次失败的裁剪？
- 第 6 章 · 先画流程，不要先画界面 — 核心流程