反面清单 | 定义产品 | 做产品

反面清单

要做什么的清单是意向，不做什么的清单才是决定。前者不需要放弃任何东西，后者需要。

你会遇到的现象

• 范围一路膨胀，每个功能加进来时都显得挺合理

• 同一个问题反复讨论，因为上次没留下结论

• 让 AI 做功能，它顺手把相关的都补上了，回头你还得删

范围失控很少是因为某个决定特别离谱，通常是十几个「顺手加一下」累积的结果。每一次单看都合理，因为没有任何东西挡着。反面清单就是那个挡着的东西。

该写哪些

这一类为什么值得专门写下来 看起来顺理成章的「都做了记录，顺便做个统计吧」——最常见的膨胀来源 竞品有而你没有的写清楚为什么不跟。不写的话，每次看到对手更新都要重新纠结 用户提过但你判断是伪需求的连同判断理由一起记。下次有人再提，直接翻记录 技术上很想做的「正好可以试试这个新框架」，这类动机跟用户价值无关 未来某天要做的标明「不是这一版」，跟「永远不做」区分开

最后一类要跟前四类分开放。混在一起的话，团队会觉得整份清单都是暂时的，约束力就没了。

范围失控很少是因为某个决定特别离谱

原定范围

顺手加

顺手加

顺手加

顺手加

顺手加

顺手加 范围失控

每一次单看都合理——因为没有任何东西挡着。

反面清单，就是那个挡着的东西。要做什么的清单是意向，不做什么的清单才是决定。

而这两类必须分开放

永远不做 定位问题。团队协作、在线画稿

这一版不做 排期问题。移动端、自定义主题

混在一起写，团队会觉得整份清单都是暂时的，约束力就没了。

每条都要带理由。只写「不做移动端」，三个月后没人记得为什么；写成「不做移动端，因为目标用户对账时都在电脑前」，这条就能一直用下去。放在需求文档最前面，放末尾等于没写。

写法的三条规矩

• **每条都带理由。**只写「不做移动端」，三个月后没人记得为什么。写成「不做移动端，因为目标用户对账时都在电脑前」，这条就能一直用。

• **区分「这一版不做」和「永远不做」。**前者是排期问题，后者是定位问题。混着写会让人误以为一切都可以商量。

• **放在需求文档的最前面。**放在末尾等于没写。每次讨论新功能，先扫一眼这份清单。

反面清单

不做为什么类型 团队协作与权限目标用户是单干的自由设计师永远不做 在线画稿他们已经有专业工具，我们抢不动永远不做 移动端对账都在电脑前完成这一版不做 自定义主题只有一个人提过，且是设计师的职业习惯这一版不做

三列的格式，写起来只多花几分钟，但它把一次性的判断变成了可以被反复引用的结论。

给 AI 的话

把反面清单放进 CLAUDE.md，AI 就会在你自己都忘了的时候提醒你。

复制 CLAUDE.md · 范围约束

这个项目明确不做的

永远不做（属于定位，不要试图说服我）：

• [不做的事] —— 因为 [理由]
• [不做的事] —— 因为 [理由]

这一版不做（以后可能做，但现在不要实现）：

• [不做的事] —— 因为 [理由]

执行要求：

• 我提的需求如果落在上面任何一条里，先指出来并说明 它对应哪一条，等我确认要不要破例，再动手。
• 实现功能时不要「顺手」补上清单里的相关能力， 哪怕它看起来只要几行代码。
• 如果你认为某条约束已经不合理了，可以提出来， 但要给出理由，不要自己绕过去。

第二条最实用。AI 特别爱顺手补全——你让它做一个列表，它会自动加上排序、筛选、分页和导出。这几行能挡住大部分。

接着看

唯一主线 反面清单是守主线的具体手段。凡是稀释主线的，写进清单比每次现场判断省力得多。

定义由三部分组成 功能边界那一块的下半份。只有要做的那半份，边界是划不出来的。

约束沉淀 反面清单是沉淀到 CLAUDE.md 里最值钱的内容之一，那一篇讲还有哪些该沉淀。