反面清单
要做什么的清单是意向，不做什么的清单才是决定。前者不需要放弃任何东西，后者需要。
要做什么的清单是意向，不做什么的清单才是决定。前者不需要放弃任何东西，后者需要。范围失控很少是因为某个决定特别离谱，通常是十几个「顺手加一下」累积的结果。每一次单看都合理，因为没有任何东西挡着。反面清单就是那个挡着的东西。shapeup写这份清单的时间成本很低，收益却很高：每一条都是替未来的讨论提前结了案。
你会遇到的现象：
- 范围一路膨胀，每个功能加进来时都显得挺合理
- 同一个问题反复讨论，因为上次没留下结论
- 让 AI 做功能，它顺手把相关的都补上了，回头你还得删
该写哪些
| 这一类 | 为什么值得专门写下来 |
|---|---|
| 看起来顺理成章的 | 「都做了记录，顺便做个统计吧」——最常见的膨胀来源 |
| 竞品有而你没有的 | 写清楚为什么不跟。不写的话，每次看到对手更新都要重新纠结 |
| 用户提过但你判断是伪需求的 | 连同判断理由一起记。下次有人再提，直接翻记录 |
| 技术上很想做的 | 「正好可以试试这个新框架」，这类动机跟用户价值无关 |
| 未来某天要做的 | 标明「不是这一版」，跟「永远不做」区分开 |
最后一类要跟前四类分开放。混在一起的话，团队会觉得整份清单都是暂时的，约束力就没了。
列清单本身也是一个发现过程。你通常会在列的时候意识到，真正拦路的不是那几个大项，而是一堆小决定——按钮放哪、字段叫什么都算。小决定不写下来，消耗的是每天开会的十分钟；大决定不写下来，消耗的是三个月后的一个周末。
写法的三条规矩
- **每条都带理由。**只写「不做移动端」，三个月后没人记得为什么。写成「不做移动端，因为目标用户对账时都在电脑前」，这条就能一直用。
- **区分「这一版不做」和「永远不做」。**前者是排期问题，后者是定位问题。混着写会让人误以为一切都可以商量。
- **放在需求文档的最前面。**放在末尾等于没写。每次讨论新功能，先扫一眼这份清单。
| 不做 | 为什么 | 类型 |
|---|---|---|
| 团队协作与权限 | 目标用户是单干的自由设计师 | 永远不做 |
| 在线画稿 | 他们已经有专业工具，我们抢不动 | 永远不做 |
| 移动端 | 对账都在电脑前完成 | 这一版不做 |
| 自定义主题 | 只有一个人提过，且是设计师的职业习惯 | 这一版不做 |
三列的格式，写起来只多花几分钟，但它把一次性的判断变成了可以被反复引用的结论。
给 AI 的话
把反面清单放进 CLAUDE.md，AI 就会在你自己都忘了的时候提醒你。
CLAUDE.md · 范围约束
## 这个项目明确不做的
永远不做（属于定位，不要试图说服我）：
- [不做的事] —— 因为 [理由]
- [不做的事] —— 因为 [理由]
这一版不做（以后可能做，但现在不要实现）：
- [不做的事] —— 因为 [理由]
执行要求：
- 我提的需求如果落在上面任何一条里，先指出来并说明
它对应哪一条，等我确认要不要破例，再动手。
- 实现功能时不要「顺手」补上清单里的相关能力，
哪怕它看起来只要几行代码。
- 如果你认为某条约束已经不合理了，可以提出来，
但要给出理由，不要自己绕过去。
第二条最实用。AI 特别爱顺手补全——你让它做一个列表，它会自动加上排序、筛选、分页和导出。这几行能挡住大部分。写完清单，真正花时间的不是写字，是下决心：把「以后可能做」和「永远不做」分清楚，每一类都标好。分不清楚就去找原因，找原因的过程本身就是产品定位的练习。清单一旦开始写，就别急着一次写全，边做边补也来得及。