在规划功能、评审范围或构建 MVP 时防止功能蔓延…

当你在做功能规划、范围评审、MVP 构建、待办管理，或听到“再加一个功能”时，用这套决策框架和纪律避免产品臃肿。

适用场景

解决思路

1. 在添加任何功能前，先跑一遍决策清单：1) 验证问题：是否解决真实且已验证的用户痛点？是否和实际用户聊过？有什么证据支持？2) 检查对齐：是否支持核心产品愿景？是否会延迟当前发布？如果做这个，我们就不做什么？3) 衡量影响：如何知道该功能成功？哪些 KPI 会变化？能否量化价值（节省时间、收入、留存）？4) 评估复杂度：真实成本是多少（构建+测试+维护+文档）？是否引入依赖或技术债？能否先发布更简单的版本？5) 最终直觉检查：我们会为这个功能推迟发布一个月吗？这是差异化还是只是基本门槛？去掉它会伤害核心体验吗？如果问题 1-3 不能有证据地回答 YES，就不要做。
2. 定义并捍卫 MVP：开始前写下“完成”的确切含义，并记录你“不做什么”。使用 MVP 范围文档模板：核心问题（一句话）、成功标准、范围内（v1）功能列表、明确范围外（延后到 v2 / 除非某条件否则不做 / 不是我们要解决的问题）、不可协商项（发布日期、预算、核心用户画像）。持续引用它。
3. 像管理代码一样用版本控制管理范围：创建 SCOPE.md 并提交，例如 git add SCOPE.md; git commit -m "Initial MVP scope definition"；任何范围变更都要显式提交，例如 git commit -m "SCOPE CHANGE: Added feature X - approved by [stakeholder] - impact: +2 weeks"。
4. 使用 48 小时规则：当有人请求新功能时，先等 48 小时再放进待办。大多数“紧急”请求在冷静后会变得不那么紧急。
5. 采用基于预算的范围管理：每个功能都有成本。新东西进来时，必须有东西出去。问：“可以加这个，那我们该砍掉这三个功能中的哪一个来腾出空间？”
6. 练习说不，并使用模板：对利益相关者说“这个想法有意思。根据用户研究，它不解决核心用户的前三大问题。先放进 v2 考虑清单，等 MVP 验证后再看。”；对高管说“我理解它可能带来的价值。如果加这个，发布将延迟 [X 周]，并降低 [Y 功能] 的优先级。这些是取舍，我们走哪条路？”；对用户说“感谢反馈。我们目前聚焦 [核心问题]。我已记录供未来考虑。能多说说为什么这会有价值吗？”；对自己说“这是挠我自己的痒，还是解决真实用户问题？我会拿发布日期赌它吗？”；对 AI 代理说“停。在加这个功能前先回答：它是否解决本次会话开始时定义的核心用户问题？如果不是，把它加到 DEFERRED.md，并继续聚焦当前范围。”
7. 与 AI 编码代理协作时：每次会话开始时声明范围约束；代理会建议改进，大多数都超出范围；把代理建议当作利益相关者请求，应用 48 小时规则；如果代理反复推动某功能，连问三次“为什么”找出真实需求。
8. 警惕 AI 功能蔓延红旗：因为“别人都在做”而加 AI；构建 AI 摘要但未验证用户是否想要；多个 AI 功能没有清晰差异化；AI 能力不连接核心用户工作流。
9. 执行 AI 功能纪律：一次只做一个 AI 功能；先用用户验证用例；衡量实际使用量而非仅看是否可用；问“AI 是否让核心任务更快或更好？”
10. 在添加任何 AI 功能前回答：它自动化什么具体任务？它比非 AI 替代方案好在哪里？AI 出错时会发生什么？我们能否不发布这个 AI 功能？
11. 每月做待办审计：对超过 30 天的条目问：1) 自添加以来有人问过吗？2) 它仍符合当前产品愿景吗？3) 如果我们永远不做，会有人注意到吗？如果三个答案都是“否”，删除它。
12. 使用 MoSCoW 优先级框架：Must Have（没有它产品无法工作）、Should Have（重要但发布非关键）、Could Have（不错但可等）、Won't Have（明确范围外）。诚实一点：大多数“Should Have”其实是伪装的“Could Have”。
13. AI 会话开始检查：与任何 AI 助手（Claude、Cursor、OpenCode）编码前，声明：你正在构建的具体功能；本次会话明确范围外的东西；你何时停止并发布。
14. AI 会话中检查：每 30-60 分钟问 AI：“我们今天是在构建正确的东西，还是在增加范围？”如果答案是“增加范围”，停止，提交已有内容，重新开始。
15. AI 会话结束检查：关闭 AI 编码会话前问：我们实际构建了什么 vs 计划构建什么？范围是否扩大？为什么？下次会话应延后什么？
16. 每日 AI 检查：每天与 AI 助手工作结束时记录：1) 今天完成的功能；2) 今天增加的范围；3) 每个增加是否已验证？4) 明天聚焦的单一事项。
17. Sprint 规划护栏：Sprint 中途不加新功能，除非移除某个东西；为 bug 修复和还债预留容量（至少 20%）；每个条目有清晰的完成定义。
18. 创建范围决策日志作为唯一事实来源，表格列：日期、请求、来源、决定、理由、取舍。示例包括：添加 PDF 导出（PM，延后 v2，非 MVP 核心，会延迟发布 2 周）；暗色模式（用户反馈，批准，用户研究显示需求，移除社交分享）；添加缓存层（Claude，延后，过早优化，保持聚焦核心功能）；重构为 hooks（Cursor，拒绝，当前可用，技术范围蔓延）。
19. 把 AI 编码代理当作利益相关者：在范围决策日志中记录代理建议并标注代理名称为来源；对 PM 或高管请求一样严格；代理优化目标（代码质量、模式、完整性）可能与你当前需要不同；“代理建议的”不是添加功能的正当理由。
20. 识别常见代理驱动的范围蔓延模式：“让我也为尚未遇到的边缘情况添加错误处理”“重构一下会更干净”“你应该为此添加测试”“让我为这些额外场景添加 TypeScript 类型”。每个都可能是好主意，但除非你决定，否则都不是当前范围。
21. 如果已经臃肿，执行恢复：1) 审计当前功能：列出每个功能，检查使用数据，找出参与度 <5% 的功能；2) 分类：核心（没有它用户无法完成目标）、支持（让核心更好）、外围（不错但不必要）、臃肿（没人用）；3) 移除或隐藏：带警告期弃用臃肿功能，把外围功能移到高级设置后，清晰沟通变更；4) 防止复发：在 PR/代码评审流程中加入功能蔓延检查，功能从 beta 毕业前要求使用指标，构建功能开关以便轻松移除实验。
22. 评审任何功能请求时问：1) “这解决什么用户问题？”2) “我们能发布的最小版本是什么？”3) “为了腾出空间，我们不做什么？”4) “我们如何衡量成功？”5) “如果我们永远不做会怎样？”如果无法清晰回答，就不要继续。
23. 遵守黄金法则：先发布小而可用的东西，然后基于真实使用数据迭代。用户不记得功能，他们记得你的产品是否解决了他们的问题。你不构建的每个功能都是：你拿回的时间、不必修的 bug、不必写的文档、不必维护的代码、不增加的困惑。最好的产品不是功能最多的，而是把正确的事做得异常好的。

适用边界 · 注意事项

• 当功能是产品核心可用性的必要条件（Must Have）时，不应以“避免功能蔓延”为由砍掉。
• 当已有明确、经过验证的用户需求和证据，且该功能支持核心愿景时，不应机械拒绝。
• 当处于紧急修复或合规/安全必需场景时，不应套用 48 小时规则或常规范围裁剪流程。