定义由三部分组成 | 定义产品 | 做产品
定义由三部分组成
给谁、解决什么、做到哪为止。这三句话定不下来，后面每一个决定都会摇摆，而且摇摆的成本会越来越高。
你会遇到的现象
-
讨论一个功能做不做，两边都有道理，最后靠感觉定
-
做了半年，说不清这个产品到底是给谁用的
-
每个版本都在加功能，但没有一版让人觉得「这下好用了」
三块各自的标准
这一块写成什么样才算合格常见的不合格写法
目标用户 具体到你能在脑子里想出一个人：他的职业、设备、熟练度、每天在忙什么 「年轻白领」「小微企业主」——这种描述套谁都行
核心价值 说清楚他现在怎么办，以及你凭什么让他换过来 「提升效率」「更好的体验」——没有对比对象
功能边界 一份要做的清单，加一份明确不做的清单 只有要做的那半份，不做的从来不写
第二行是最容易糊弄过去的。「提升效率」这种话之所以听起来没问题，是因为它对任何产品都成立——对任何产品都成立的话，等于什么都没说。
定义写对了，下一层的东西是「推」出来的，不是「想」出来的
目标用户 接单的自由设计师
核心价值 把散在微信里的需求和改稿 记录按项目归档，对账时说清
功能边界 不做团队协作、不做在线画稿
核心实体 项目 · 改稿记录 · 客户
主任务 归档 · 对账 · 导出
整片不用考虑的 权限 · 通知 · 画布 · 协同编辑
「一个给团队用的效率工具，提升协作效率」推不出右边任何一格——因为它对任何产品都成立。 对任何产品都成立的话，等于什么都没说。
检验一份定义写没写对，最省事的办法就是试着往右边推一次。**推不出实体和任务，说明左边那三块还停留在形容词层面。**而右下角那格——明确不用考虑的东西——恰恰是让后面每个决定都变快的原因。
怎么检验写对了
写完之后拿这三个问题过一遍。任何一个答不上来，就回去改。
没通过
一个给团队用的效率工具 让协作更顺畅，提升工作效率， 支持任务、文档、日程和沟通
谁都能用 = 谁都不会为它换掉现在的工具
通过
给接单的自由设计师 把散在微信里的需求和改稿记录， 按项目自动归档，对账时一次说清
不做团队协作、不做在线画稿
右边这段能直接推出信息架构：核心实体是项目和改稿记录，主任务是归档和对账，团队和画稿相关的一切都不用考虑。
-
**你能说出一个具体的人吗。**说不出，目标用户那一块就还是空的。
-
**他现在用什么？你凭什么让他换？**答案不能是「我们更好用」，要能说出具体差在哪一步。
-
**有什么是你明确不做的？**一个都举不出来，说明边界还没定。
给 AI 的话
把三块写进项目的第一份文档，之后每次让 AI 做功能都带上它。
复制 PROMPT · 产品定义 这个项目的定义如下，之后所有设计和实现都以它为准：
目标用户：[具体的人：职业、设备、熟练度、日常在忙什么] 核心价值：[他现在怎么办 → 我们让这一步变成什么样] 功能边界： 要做：[清单] 明确不做：[清单]
请先做两件事，不要写代码：
- 基于这个定义，列出你认为的核心实体和主任务， 并说明是从定义里的哪一句推出来的。
- 指出这份定义里含糊或自相矛盾的地方， 逐条问我，不要自己替我补全。
之后我每次提功能需求，如果它跟「明确不做」冲突， 请直接指出来，不要闷头实现。
最后那句是这段提示词里最值钱的。它把 AI 从执行者变成了一道边界的看门人，能挡住不少一时兴起的功能。
接着看
一句话产品 三块的压缩版。能压成一句话，说明三块都想清楚了；压不动，说明还有一块是空的。
反面清单 功能边界的下半份。明确不做的那一列该怎么写，以及它为什么比要做的那列更管用。
场景锚点 目标用户那一块的具体写法。锚点写好了，这一块就是现成的。