范围蔓延是 vibe 项目的头号杀手：需求冻结与变更治理实战

先说一个反直觉的判断：2026 年 vibe 项目的烂尾，第一死因不是 AI 写不出代码，而是 AI 把"加个功能"的成本压得太低了。当你凌晨两点对着屏幕说"加个深色模式吧，也就一句话的事"，项目就离烂尾又近了一步。

AI 编程把单点功能的边际成本压到了趋零，但项目的总成本从来不是单点功能相加——是功能之间的交互、回归、决策和心智负担相乘。需求不设防的 vibe 项目，死法千奇百怪，墓碑上刻的字都一样："就差这一个功能。"

这篇不讲开工之前的需求澄清（那是另一门手艺），也不讲上线之后的功能下线，只管一件事：开工之后，怎么守住需求。一套可以直接抄的机制：范围基线、变更评审漏斗、停车场清单、说"不"的话术、里程碑门禁。

一、范围基线：开工前先把"不做"写下来

范围蔓延最难防的形态，不是别人塞需求进来，是你自己都不知道当初承诺了什么。三个月前的需求文档躺在某个 Notion 页面里吃灰，谁也想不起来第一版到底要做多少功能。这时候任何"加一个"都显得无害——因为没有基线可以对照。

基线的标准写法是 MoSCoW 分级 + 一条冻结线：

• Must（必须有）：没有这些，产品就不成立。上限 5 条，超过 5 条说明你还没想清楚。
• Should（应该有）：重要但可以晚一点，不影响第一版上线。
• Could（可以有）：有了更好，但第一版没有也完全 OK。
• Won't（这次不做）：明确写出"这次不做"，比写 100 条要做更重要。

冻结线画在 Must 和 Should 之间：冻结线以上（Must）是开工后的法律，任何变更走评审；冻结线以下（Should/Could）是待定区，可以讨论但默认不做；Won't 是禁区，提都不要提，除非下个版本。

直接抄的模板（保存成项目根目录的 SCOPE.md，每次加需求前先打开看一眼）：

# 范围基线 v1.0 ｜ 冻结日期：____
## Must（冻结线以上，开工后变更需评审）
1. ___
2. ___
## Should（默认不做，评审通过才进）
1. ___
## Could（想法池，不承诺）
1. ___
## Won't（本版明确不做）
1. ___
2. ___
---
冻结规则：Must 变更需走变更评审漏斗；Should 进入 Must 必须有至少一项 Must 移出或里程碑延期。

注意最后一条规则，它是整套机制的灵魂：接受一个新需求，必须指明代价——要么某项旧需求让位，要么里程碑延期。"加一个"从来不是加一个，是"加一个并砍一个"或"加一个并晚一周"。

二、变更评审漏斗：给变更一个正规入口

需求守卫最大的误区是"靠意志力说不"。意志力在凌晨两点不工作，在客户说"很简单"的时候不工作，在合伙人兴奋地转发竞品截图的时候不工作。靠得住的是流程：把变更的决策从"情绪现场"搬到"固定仪式"。

漏斗有三个阶段：

• ① 提交：任何变更请求必须用固定格式提单，不接受口头/微信语音/灵光一闪。提单格式是"问题 / 价值 / 成本"三段式：这个问题真实存在吗（谁遇到了、频率多高）？解决它带来什么价值（能量化最好）？预估成本是什么（工时、风险、回归面）？写不满三段，说明这个需求还没想清楚，不配进入下一环节。
• ② 影响评估：48 小时内给出书面评估，核心是回答"它会碰坏什么"。AI 生成的代码耦合度经常被低估：一个"加个导出 PDF"可能牵动权限、样式、分页、移动端四处。评估人必须是真正写代码的人，不能是拍脑袋的人。
• ③ 批次评审：每周固定时间（比如每周五下午 4 点）集中评审一批，不随到随做。这是整套机制里最反人性、也最有效的一条：把"即时满足"变成"延迟决策"，一半以上的"紧急需求"在等到周五之前就自己消失了。

评审的决策人必须唯一。一个人项目，决策人就是你；小团队，决策人只能是一个。评审会可以讨论，但拍板的那个人有且仅有一个——"集体负责"在范围治理里等于"没人负责"。

三个出口：接受（排入里程碑，冻结线内生效）、停车场（记录但不做，见下一节）、拒绝（说明理由，并且说清楚"这个版本不再讨论"）。拒绝一定要给理由，不给理由的拒绝会在两周后以另一个名字的形式回来。

三、"停车场"清单：记录但不做的艺术

大部分需求管理失败，不是因为拒绝得不够狠，而是因为拒绝得没有出口。人（包括你自己）最怕的不是"不做"，是"被遗忘"。一个好想法被当场毙掉，提议者会记仇；但如果它被郑重地记进"停车场"清单，注明"v2.0 候选"，提议者立刻就舒服了——他的想法被尊重了，只是时机未到。

停车场清单的写法：每条记录四个字段——想法一句话、提出人、提出日期、重估条件（比如"等日活过 1000 再看"或"等支付跑通后再议"）。重估条件是关键：没有重估条件的停车场就是垃圾场，三个月后谁也不敢打开。

配套一个仪式：每个里程碑结束时，花 30 分钟重估停车场。绝大多数条目在重估时会自然死亡——"当时觉得很重要的那个功能，现在看完全不重要了"。这 30 分钟是整套机制里性价比最高的 30 分钟：它让团队（和你自己）亲眼看到"不做"是对的，从而在下一个里程碑里更敢于说不。

对独立开发者还有一个私人用法：把"你自己的灵感"也扔进停车场。vibe 编程最大的敌人经常是开发者本人——写着写着冒出个新点子，手痒就想让 AI 顺手做了。先记下来，继续写当前的。你的点子不会跑，但你的里程碑会。

四、说"不"的话术：三段可以直接抄的模板

道理都懂，但"不"字说出口需要肌肉记忆。准备三段话术，分别对应你最常面对的三种压力源。提前写好存在备忘录里，真到用的时候直接复制粘贴改关键词——现场组织语言必输。

对客户版（礼貌、专业、给台阶）：

"这个想法我记下来了，确实有价值。为了不影响咱们约定的 [日期] 上线，我建议把它放进下一版的候选清单。如果这版非要加，咱们得一起决定：是把 [某个已承诺功能] 往后放，还是把上线时间延后 [X] 天？您看怎么选？"

这段话的精髓是"把代价摆上台面 + 把选择权交还"。客户通常不是不讲理，是没意识到有代价。一旦代价可见，80% 的客户会自己说"算了，下版再说"。

对合伙人/朋友版（直接、不绕弯）：

"可以加，但咱们先过一下漏斗：你写个三段式提单（问题/价值/成本），周五评审会一起定。如果它真值得进 Must，咱们就砍掉 [某个 Should] 给它让位。你先写，我等你。"

对熟人不用客气，但要给流程。"你先写提单"这五个字能过滤掉 90% 的随口一说——随口说的灵感，经不起三段式的拷问。

对自己版（贴在显示器边框上）：

"这个功能上线第一天会有用户用吗？如果答案是'可能'、'以后'、'万一'，先记进停车场，写完当前这版再说。你现在手痒，三个月后你会恨现在的自己。"

对自己要狠一点，因为你对自己最没有议价能力。vibe 时代的独立开发者，需求方、产品经理、工程师是同一个人——你必须学会跟自己谈判。

五、里程碑门禁：开工前的打勾清单

冻结线不是画一次就完事的。每个里程碑开始前，过一遍门禁检查，逐项打勾，缺一项不开工：

• □ 本里程碑的 Must 清单已冻结，SCOPE.md 版本号已更新
• □ 上个里程碑的停车场已重估，死掉的条目标记归档
• □ 本周期的变更评审时间已定（固定星期、固定时间）
• □ 决策人明确（一个人项目：就是你，不要假装有委员会）
• □ 上个里程碑接受的变更，其代价已兑现（砍掉的功能真砍了？延期的日期真改了？）

最后一条最容易被跳过，也最重要。如果上次"加一个"的代价最后不了了之（功能加上了，该砍的没砍，该延期的没延），整个机制的信用就破产了。范围治理是信用货币：每一次"说到做到"，都是在为下一次说"不"充值。

门禁会议不需要长，15 分钟标准议程就够：5 分钟过 Must 清单（有没有含糊条目，含糊的当场改写或移出）；5 分钟重估停车场（每条 30 秒，活着还是归档）；5 分钟确认评审 slot 和决策人。如果超时，说明某个条目有争议——有争议的条目不配进 Must，先扔回 Should。门禁的本质不是"开会"，是"开工前强制对齐一次现实"。

六、三个反模式：vibe 项目特有的死法

反模式一："就差这一个功能"陷阱。这是范围蔓延的经典台词，在 vibe 时代变本加厉，因为 AI 让"一个功能"看起来真的只要 10 分钟。但"一个功能"的真实成本 = 实现 + 联调 + 回归测试 + 文档 + 用户教育 + 后续维护。独立开发者尤其要警惕"演示前夜综合征"：为了给朋友演示，加个"看起来很酷"的功能，结果演示用的分支合不回主干，项目从此分叉烂尾。

反模式二：AI 顺手加料。你让 AI "给登录页加个记住我"，它顺手把整个认证体系重构了，还加了你没要求的社交登录按钮。AI 没有范围意识——它的目标函数是"让你满意"，而"多做一点"在它的训练数据里约等于"更让你满意"。对策：prompt 里明确写"只做 X，不碰 Y，不新增任何未要求的功能"；review AI 的 diff 时，第一眼先看"有没有我没要求的东西"，有就 revert。把"AI 多做了"当成 bug，而不是惊喜。

反模式三：演示驱动膨胀。发了个 demo 视频，有人评论"要是能导出 Excel 就好了"，你连夜加上；又有人说"加个暗黑模式吧"，你又加上。公开 demo 的反馈是范围蔓延的加速器，因为每条反馈都带着社交压力。记住：评论区要的是"被回应"，不是"被实现"。回一句"好想法，已记进 v2 清单"——停车场话术在这里同样适用。

七、成本账：一个中途加塞的功能到底有多贵

感性上都知道范围蔓延贵，但"贵多少"需要一笔账。下面这张示意图用了一个简化模型：每个新功能除了自身工作量，还会和已有功能产生交互成本（联调、回归、心智负担），交互成本随功能数量平方增长。

看两个数字：中途加塞 20 个功能，上线多耗约 7 天；加塞到 50 个，多耗约 24 天。功能数量是 2.5 倍，延期是 3 倍多——而且这还没算维护期：每个加塞的功能在未来每一次重构、每一次升级依赖时都会回来收一次税。

给你一个可以直接用的测算表，评估任何一个加塞需求时填一下：

• 实现成本：___ 人天（让 AI 写也算 0.5 天起，review 和联调省不掉）
• 交互成本：会碰到 ___ 个已有模块，每个模块回归测试 ___ 小时
• 决策成本：评审、讨论、返工，___ 小时
• 维护税：未来 6 个月，预计为它修 ___ 次 bug，每次 ___ 小时
• 总成本 = 以上相加 × 1.5（1.5 是乐观偏差系数，独立开发者实测基本都低估一半）

填完这张表，再问自己：这个功能值得吗？大多数"就差这一个"在表格面前会现原形。

八、把机制装进 AI 工作流：让 AI 也遵守冻结线

前面都是"人"的机制，但 vibe 项目的特殊之处在于：一半的代码是 AI 写的，一半的"加一个"冲动是 AI 勾起来的。所以范围治理必须进 AI 的工作流，否则你白天定的规矩，晚上 AI 就帮你破了。

第一，把 SCOPE.md 喂进每一次会话。AI 没有长期记忆，你的冻结线在它那里不存在。对策：项目根目录的 SCOPE.md 就是 AI 的"宪法"。每个新会话的第一条指令固定为："开始前先读 SCOPE.md，本次任务只能动 Must 清单里的条目；任何超出范围的想法，先记下来问我，不直接做。"用 Cursor / Claude Code 的话，把这条写进项目 rules 文件，一次配置，永久生效。

第二，给 AI 的 prompt 加"范围条款"。直接抄这段，贴进你的常用 prompt 模板：

范围约束：
1. 只做本次明确要求的 X，不碰 SCOPE.md 之外的任何功能；
2. 如实现中发现"顺手可以做"的改进，先停下来，用一句话描述它并问我，不自行实现；
3. 输出 diff 摘要时，第一项必须声明"本次未新增任何未要求的功能"。

第三条是点睛之笔：让 AI 自己先做"范围自检"，把"顺手加料"从默认行为变成需要申报的行为。AI 很听话——只要你把"不做什么"说得和"做什么"一样清楚。

第三，让 AI 当评审漏斗的书记员。每周五评审前，让 AI 做三件事：汇总本周所有被记进停车场的想法（去重、按主题归类）；对每条生成三段式提单初稿（问题/价值/成本，成本部分标"待人工确认"）；检查本周的 commit 里有没有"没走评审就进来的功能"——AI 扫 diff 比人仔细，这正是它擅长的。用 AI 来执行流程，而不是绕过流程。

第四，演示前夜给 AI 上锁。"演示驱动膨胀"的高发期是 demo 前 48 小时。这时候把 AI 的指令收紧为"只修 bug，不加功能；任何新功能提议自动记入停车场"。你可以把它写成一条 slash command（比如 /demo-lock），演示前夜一键切换。技术上只是一句话，心理上是一道闸。

一句话总结：AI 是范围蔓延的放大器，也可以是范围治理的执行者，区别只在于你有没有把规则写进它的工作流。SCOPE.md 不只是给人看的，更是给 AI 读的。

九、收尾：产能过剩时代，说"不"才是核心竞争力

AI 编程解决的是"做出来"的问题，但 2026 年的现实是：做出来已经不稀缺了。GitHub 上每天诞生的 vibe 项目成千上万，能活下来的不是功能最多的，而是最先上线的——而最先上线的，永远是范围管得最死的。

vibe 时代稀缺的不是产能，是说"不"的能力。产能可以外包给 AI，但"不做什么"的判断，只能你自己做。把 SCOPE.md 建起来，把评审会定下来，把停车场用起来——这三件事今天就能做，不需要任何新工具。

最后送一句可以贴在墙上的话：你的项目不是被做死的，是被加死的。守住范围，就是守住上线那一天。

范围治理不需要天赋，只需要三件套：开工前一张基线表、每周一次评审会、一个敢说不的你。今晚就能开始。