2.3.5 「不做清单」的魔力
大多数人只列「要做清单」，很少有人列「不做清单」。
但「不做清单」可能比「要做清单」更重要。
为什么需要「不做清单」
原因 1：明确边界
当你告诉 AI「帮我做一个待办清单」，AI 可能会问你：要不要加日历同步？要不要支持团队协作？
如果你没有明确的边界，很容易被这些问题带偏。
「不做清单」让你和 AI 都清楚：这些事情不在范围内。
原因 2：抵抗诱惑
做项目的过程中，你会不断产生新想法：
- 「如果加一个 XX 功能会不会更好？」
- 「竞品都有 XX，我是不是也该有？」
- 「用户反馈说想要 XX……」
这些诱惑会不断膨胀你的项目范围。
「不做清单」是你的防线：这些功能我已经想过了，决定不做，理由在这里。
原因 3：沟通工具
当别人问「为什么你没做 XX 功能」时，你可以清晰回答：
这个功能在我的「不做清单」里。原因是 [理由]。我会在 [条件满足时] 重新考虑。
这比「还没来得及做」或「以后再说」专业得多。
「不做清单」的三个维度
一份完整的「不做清单」应该覆盖三个维度：
维度 1：不做的功能
列出你明确决定不做的功能，以及理由。
维度 2：不考虑的用户群
你的产品不可能服务所有人。明确你不打算服务谁。
维度 3：不追求的指标
MVP 阶段你应该聚焦于验证，而不是增长。明确你暂时不关心什么指标。
「不做清单」完整模板
markdown
# 不做清单（V1 版本明确不做的事情）
## 一、不做的功能
| 功能 | 不做的理由 | 何时重新考虑 |
|-----|----------|-------------|
| [功能名称] | [理由] | [条件] |
## 二、不考虑的用户群
| 用户群 | 不考虑的理由 |
|-------|-------------|
| [用户描述] | [理由] |
## 三、不追求的指标
| 指标 | 不追求的理由 | 替代关注点 |
|-----|-------------|----------|
| [指标名称] | [理由] | [替代指标] |示例 1：待办清单项目的「不做清单」
markdown
# 不做清单（V1 版本）
## 一、不做的功能
| 功能 | 不做的理由 | 何时重新考虑 |
|-----|----------|-------------|
| 多设备同步 | 需要后端开发，大大增加复杂度 | 核心功能验证成功后 |
| 团队协作 | 不是个人工具的核心价值 | 有明确的团队使用需求时 |
| 暗黑模式 | 纯美化功能，不影响核心验证 | 有用户强烈反馈时 |
| 日历视图 | 增加开发工作量，不是极简体验 | P0 功能稳定后 |
| 统计报表 | 对于验证「极简好用」没有帮助 | 用户留存稳定后 |
| 小组件 | 平台特定功能，增加维护成本 | 主产品成熟后 |
## 二、不考虑的用户群
| 用户群 | 不考虑的理由 |
|-------|-------------|
| 专业项目经理 | 他们需要复杂的项目管理功能，不是我们的定位 |
| 团队用户 | V1 只做个人工具 |
| 重度 GTD 用户 | 他们已有成熟工具，不是我们的目标 |
## 三、不追求的指标
| 指标 | 不追求的理由 | 替代关注点 |
|-----|-------------|----------|
| 用户总数 | MVP 阶段关注验证，不关注增长 | 留存率 |
| 功能完整性 | 关注核心功能深度，不关注广度 | 核心功能使用频率 |
| 美观程度 | 功能优先，美化后续迭代 | 可用性 |示例 2：数据分析项目的「不做清单」
markdown
# 不做清单（本次分析项目）
## 一、不做的分析
| 分析内容 | 不做的理由 | 何时重新考虑 |
|---------|----------|-------------|
| 全渠道对比 | 老板只问了 ROI 最高的渠道 | 老板提出新问题时 |
| 年度趋势 | 决策需要的是当前数据 | 季度汇报时 |
| 用户画像分析 | 不是本次问题的核心 | 有用户相关问题时 |
| 竞品对比 | 没有可靠数据来源 | 获得数据后 |
## 二、不考虑的受众
| 受众 | 不考虑的理由 |
|-----|-------------|
| 一线销售 | 本次报告给决策层看 |
| 外部投资人 | 需要不同的呈现方式 |
## 三、不追求的指标
| 指标 | 不追求的理由 | 替代关注点 |
|-----|-------------|----------|
| 图表数量 | 信息密度比数量重要 | 每张图是否回答了问题 |
| 视觉精美 | 清晰比精美重要 | 老板能否一眼看懂 |示例 3：自动化脚本的「不做清单」
markdown
# 不做清单（Excel 自动化脚本 V1）
## 一、不做的功能
| 功能 | 不做的理由 | 何时重新考虑 |
|-----|----------|-------------|
| 图形界面 | 命令行足够，降低开发复杂度 | 非技术同事需要使用时 |
| 自动邮件发送 | 先验证汇总功能 | 汇总功能稳定后 |
| 多格式支持 | 目前只有 xlsx 格式 | 出现其他格式需求时 |
| 错误自动修复 | 先报错提示，人工处理 | 常见错误模式明确后 |
## 二、不考虑的场景
| 场景 | 不考虑的理由 |
|-----|-------------|
| 跨部门数据 | 先搞定本部门 |
| 历史数据迁移 | 只处理增量数据 |
## 三、不追求的指标
| 指标 | 不追求的理由 | 替代关注点 |
|-----|-------------|----------|
| 运行速度 | 每周只跑一次，快慢无所谓 | 正确性 |
| 代码优雅 | 能用就行 | 可维护性 |AI 辅助：让 AI 帮你生成「不做清单」
Prompt 模板
markdown
我正在做一个项目：[项目描述]
目标用户是：[用户描述]
核心假设是：[假设描述]
P0 功能是：[P0 功能列表]
请帮我生成一份「不做清单」，包括：
1. 不做的功能（列出 5-8 个常见但本项目不应该做的功能）
2. 不考虑的用户群（2-3 个）
3. 不追求的指标（2-3 个）
请给出理由和「何时重新考虑」的条件。为什么你忍不住想加功能
了解这些心理障碍，有助于你抵抗它们：
障碍 1：害怕不够好
- 想法：「功能这么少，用户会不会觉得太简陋？」
- 真相：用户在意的是问题有没有被解决，不是功能多不多
- 应对：问自己「核心问题解决了吗？」而不是「功能够不够多？」
障碍 2：害怕错过
- 想法：「竞品都有这个功能，我不做会不会落后？」
- 真相：你不是在和竞品比功能数量，你在验证自己的假设
- 应对：记住你的核心假设是什么，不在验证范围内的功能都可以不做
障碍 3：沉没成本
- 想法：「这个功能我已经想了很久了，不做太可惜」
- 真相：想了很久不代表该做；做了再发现不该做，才是真的可惜
- 应对：把它放进 P2，明确「想过但决定不做」
障碍 4：假装忙碌
- 想法：「多做点功能，显得我很努力」
- 真相：努力的方向错了，再努力也没用
- 应对：用验证结果证明努力，而不是用功能数量
本节要点
你现在理解了「不做清单」的价值：
- 它帮你明确边界、抵抗诱惑、专业沟通
- 应该覆盖三个维度：功能、用户群、指标
- 了解心理障碍有助于你做出更理性的决策
接下来，我们通过一个完整的练习，把本节所学应用到你自己的项目上。