Zero-Friction Scope Creep（零摩擦范围蔓延）
定义
AI 将新增功能、项目和内容的边际成本降得很低，使每个扩张动作都显得合理，最终导致方向漂移、维护负债和注意力污染。
核心机制
传统范围蔓延会被预算、排期、人力和疲劳拦住。AI 时代的变化是：每一个新增功能、边界案例、脚本、原型或自动化都可以用几句提示词生成，因此它在局部看起来“当然值得做”。
问题不是某个功能错误，而是系统失去筛选压力：
- 生成成本下降：想法可以快速变成代码、页面、脚本或内容。
- 承诺感下降：因为投入很少，用户没有被迫确认自己是否真的需要它。
- 维护成本滞后：代码、内容、用户、合规和运营责任在生成之后才出现。
- 方向漂移：局部合理的扩张累积后，产品或个人注意力偏离原始目标。
20260531-thoughts-hmmz 给出个人层面的版本：作者从“写个快速脚本”开始，最后产生大量不想维护、没有真实用途的项目。The-Founders-Playbook-05062026_v3 给出创业层面的版本：当开发近乎免费时，创始人容易不断加入“看起来合理”的功能，反而伤害方向和动量。
与摩擦的关系
Zero-Friction Scope Creep 不是说摩擦越多越好，而是说某些摩擦承担筛选功能。
| 摩擦类型 | 是否应保留 | 原因 |
|---|---|---|
| 样板代码、格式转换、查参数 | 通常不保留 | 属于偶然摩擦，可自动化 |
| 维护责任、市场路径、用户承诺 | 应保留或显式化 | 决定项目是否值得继续 |
| 架构边界、测试难度、命名困难 | 应读取 | 可能暴露本质复杂性 |
| token 预算、时间盒、发布门槛 | 应设计 | 用外部约束抵消无限生成冲动 |
因此它与 Friction-as-Design-Signal 互补：后者提醒工程师读取摩擦，前者解释摩擦消失后为什么会失控。
失败信号
- 项目从“小脚本”扩张成完整产品，但原问题仍未解决。
- 每个新增功能都有理由，但整体产品越来越难解释。
- 作者、创始人或团队无法说明谁会维护、谁会使用、谁会付费。
- AI 生成速度超过测试、审查、用户验证和运营能力。
- 团队把“能做出来”误认为“值得做出来”。
关键数据点
- The-Founders-Playbook-05062026_v3 明确提出 Zero-friction scope creep：当构建几乎免费时，创始人会不断加入“看起来合理”的功能，导致产品偏离原始边界。
- 20260531-thoughts-hmmz 提供个人层面证据：作者列出十几类 AI 生成项目，并指出除一个 SaaS 外，大多没有真实用途或维护意愿。
- 该现象常从“快速脚本”开始，但生成过程本身会把任务扩张成更大软件。
- 风险不在单个新增项明显错误，而在每个新增项都局部可辩护，整体却损害方向、维护和注意力。
应对方式
- 时间盒：限制探索会话长度，防止一小时脚本变成无边界产品。
- 删除预算：每新增一个功能，要求删除或推迟另一个功能。
- 维护声明：在生成前写清楚 owner、维护周期、用户和停止条件。
- 发布门槛：要求测试、用户验证或真实使用证据，而不是只看 demo。
- YAGNI 化：将“以后可能需要”改写成“有证据再做”。
前提与局限性
- 前提: 使用者缺少强约束，且 AI 生成物会产生后续维护、运营或注意力成本。
- 局限: 对一次性、可删除、可自动验证的小任务，低摩擦生成仍然是净收益。
- 局限: 高摩擦不自动等于高价值；很多工具噪音应被消除。
- 误用风险: 把范围控制变成保守主义，阻止必要探索。正确做法是给探索设边界，而不是禁止探索。
关联概念
- Friction-as-Design-Signal — 被消除的摩擦中有一部分是设计和承诺信号。
- Vibe-Coding — 原型生成容易扩张为未审查、无人维护的软件。
- AI-Restraint — 克制不是慢，而是知道何时停止生成。
- Cognitive-Surrender — 用户放弃筛选判断时，范围蔓延会自我强化。
- Constraint-Driven-Engineering — 外部约束可以抵消无限生成冲动。
- YAGNI — “现在不做”是 AI 时代更重要的工程动作。