需求分析

一句话提醒

有人提出、听起来合理或局部有帮助，都不足以证明一个需求值得当前投入。

为什么今天看它

• 面对‘做出来看起来更高级’这类诉求时，先追问使用者、场景、频率、痛点和不做的损失，才能区分低优先级真需求与当前阶段的伪需求。

留一个问题

你正在考虑的一条需求，真实使用场景、发生频率、稳定痛点和业务价值分别是什么？如果说不清，是否还不该进入开发？

参考思路

1. 1.确认是谁在什么场景下使用，以及具体要完成什么任务。
2. 2.追问痛点是否稳定发生，频率和影响是否足够明确。
3. 3.拆掉‘看起来更高级’等感受性表达，寻找可验证的业务结果。
4. 4.判断不做会造成什么损失，并与开发成本和替代方案比较。
5. 5.证据不足时先降级、补验证或驳回，不要因为有人提出就直接立项。

03_知识库/问题/什么是伪需求，为什么有些需求看起来合理却不值得做.md

一句话提醒

还没把问题和目标分析清楚，就跳到具体功能，会把实现方式误当成需求本身。

为什么今天看它

• 面对‘加一个功能’或‘改一个按钮’的表达时，先把问题层和解法层拆开，才能看见流程、规则或协作方式等其他可能路径。

留一个问题

你正在讨论的一条需求，描述的是用户要解决的问题，还是已经预设了某个功能解法？还有哪些不同路径没有被比较？

参考思路

1. 1.先明确用户、场景、目标和当前真正受阻的环节。
2. 2.标记原始表达中已经带有的功能、流程或技术方案。
3. 3.把问题层与解法层分开，避免直接把方案当成需求。
4. 4.至少列出功能、流程、规则或协作方式等不同解决路径。
5. 5.比较各路径对目标、成本、边界和后续链路的影响后再定方案。

03_知识库/问题/什么叫需求滑向方案.md

一句话提醒

伪需求识别判断它是否值得认真对待，需求验证判断它是否强到值得现在投入。

为什么今天看它

• 团队容易把所有需求都直接带入方案讨论。先做第一轮伪需求筛查，再用频率、影响、稳定性和替代成本验证强度，可以减少对表面合理诉求的过度投入。

留一个问题

你手上的一个需求，是从根上就不成立，还是确实存在但证据还不够强？下一步应是排除，还是补充验证？

参考思路

1. 1.先看业务场景、价值和提出者的真实问题。
2. 2.做伪需求识别，检查它是否只是情绪、方案偏好或看起来高级。
3. 3.若有成立可能，再验证发生频率、影响范围、稳定性和业务损失。
4. 4.比较替代成本与当前投入价值，判断需求强度而非只判断存在与否。
5. 5.验证通过后再进入优先级排序和方案讨论。

03_知识库/问题/伪需求识别和需求验证有什么区别.md

一句话提醒

功能回答做什么，数据需求回答靠什么信息去做、去记录、去判断。

为什么今天看它

• 产品讨论很容易先看到页面、按钮和流程，但报表、搜索、推荐和运营判断能否成立，往往取决于字段、口径、来源、流转和权限是否先被定义。

留一个问题

你正在设计的一个功能，依赖哪些数据字段和指标口径？这些数据从哪里来、谁能看、最终支持什么判断？

参考思路

1. 1.先明确功能要支持的业务判断或行动，而不是只描述页面结果。
2. 2.列出需要记录的字段、事件、状态和时间维度。
3. 3.统一指标定义，明确数据来源、计算口径和更新频率。
4. 4.梳理数据如何流转、展示和被不同角色使用，并补上权限边界。
5. 5.在功能开发前确认数据是否可采集、可验证、可持续维护。

03_知识库/问题/什么是数据需求，为什么它容易被忽略.md

一句话提醒

用户需求能提示问题存在，但是否值得做仍要结合业务目标、成本收益、优先级和整体影响。

为什么今天看它

• 用户提出的内容常已带有具体方案，也受其角色视角限制。直接照做会把局部最优误当整体最优；需求分析要把声音翻译为问题，再做业务取舍。

留一个问题

你正在接收的一条用户需求中，用户真正遇到的问题是什么？原话里的方案成分、局部视角和业务约束分别是什么？

参考思路

1. 1.先记录用户原话与使用场景，确认它提示的真实问题。
2. 2.拆出其中已经预设的功能或解决方案，不把它直接当需求本体。
3. 3.比较局部角色收益与整体系统、其他角色和长期目标的影响。
4. 4.评估成本、预期收益、资源占用与当前优先级。
5. 5.形成业务判断：做、暂缓、拒绝或换一种更合适的解法。

03_知识库/问题/为什么用户提了需求还不够.md

一句话提醒

需求真实且重要，不等于它就是当前最该做的；还要看频率、平台阶段、资源与更深层链路。

为什么今天看它

• 面对具体解法时，团队容易直接讨论怎么做。先拆开“问题是否存在”“表面解法是否触及根因”“当前是否值得投入”，能避免把有限资源压在阶段不对的方案上。

留一个问题

你当前的一个需求，真实问题与提出的解法分别是什么？如果暂不做，平台更根本的链路问题是哪一条？

参考思路

1. 1.确认问题是否真实存在、发生频率是否稳定、影响是否足够大。
2. 2.把用户提出的功能解法与平台真正想控制的深层问题分开。
3. 3.结合平台阶段、资源限制、替代方案和基础链路判断当前优先级。
4. 4.识别更根本但暂时过重的投入，避免把理想路径误当立即路径。
5. 5.选择本阶段能收住关键链路的行动，并说明暂不做的原因。

03_知识库/问题/如何判断一个需求是真需求但不一定先做.md

一句话提醒

不完美方案的取舍不是默认选最彻底的，而是选当前阶段更轻、更快、更可控的解。

为什么今天看它

• 面对风险或体验问题时，团队容易直接追求根治方案。先比较副作用、落地性与解决力度，才能避免把未来更适合的重方案过早压到当前阶段。

留一个问题

你当前正在比较的方案里，哪一个更彻底，哪一个更适合当前资源、链路成熟度和体验约束？两者是否被混成同一个判断？

参考思路

1. 1.先明确要控制的深层问题，而不是只复述表面功能诉求。
2. 2.列出不同路径分别是在做功能限制、流程限制还是更底层的机制调整。
3. 3.比较每条路径对体验、流程和现有系统的副作用。
4. 4.评估开发成本、改动范围、时间与当前资源条件。
5. 5.结合解决力度与平台阶段，选择当前最适合先上的方案，并保留后续升级路径。

03_知识库/问题/如何在不完美方案里做阶段性取舍.md

一句话提醒

需求边界明确这次做到哪里、暂时不做什么，目的是保护当前阶段聚焦核心问题。

为什么今天看它

• “顺手加一下”的扩展最容易让最小需求膨胀成大系统。写清本期不做什么，才能让范围、资源和后续版本保持一致。

留一个问题

你正在推进的一项需求，能否明确写出本期做到哪里、暂不做什么，以及哪些扩展只是当前阶段不必要而非没有价值？

参考思路

1. 1.先明确本期唯一要解决的核心问题。
2. 2.定义最小可用流程和最常用的资料、角色或场景。
3. 3.列出本期不覆盖的扩展能力，例如编辑、下载、分类或外链协同。
4. 4.说明暂不做的阶段原因，而不是把它们判成没有价值。
5. 5.把扩展项保留为后续版本条件，避免在交付中不断顺手加入。

03_知识库/问题/什么是需求边界，为什么边界不清需求就会失控.md

一句话提醒

需求验证先确认场景、频次、影响和投入价值；需求成立不等于它现在必须排第一。

为什么今天看它

• 团队一旦直接讨论功能做法，就容易跳过需求强度判断。把验证问题问完整，才能分清真需求、伪需求和虽成立但暂不优先的事项。

留一个问题

你正在讨论的一项需求，目标用户、真实场景、使用频次、当前替代方式和不做影响是否都有证据？

参考思路

1. 1.确认目标用户与具体业务场景。
2. 2.观察问题是否稳定、高频地发生。
3. 3.了解当前替代方案及其时间、出错或协作成本。
4. 4.判断不做的影响和做成后的实际价值。
5. 5.先得出需求是否成立及其强度，再单独进入优先级排序。

03_知识库/问题/如何验证一个需求是否真的成立.md

一句话提醒

需求边界明确这次做到哪里、暂时不做什么，目的是保护当前阶段聚焦核心问题。

为什么今天看它

• “顺手加一下”的扩展最容易把一个核心问题膨胀成大系统。把本期不做的内容写清，才能让价值判断、交付范围和后续版本保持一致。

留一个问题

你正在推进的一项需求，能否清楚写出本期做到哪里、暂不做什么，以及哪些扩展不是没价值而是当前阶段不必要？

参考思路

1. 1.先明确本期要解决的单一核心问题。
2. 2.定义最小可用流程和最常用的资料、角色或场景。
3. 3.列出本期不覆盖的扩展能力，例如编辑、下载、分类或外链协同。
4. 4.说明暂不做的阶段原因，而不是把它们判成没有价值。
5. 5.把扩展项保留为后续版本条件，避免在交付中不断顺手加入。

03_知识库/问题/什么是需求边界，为什么边界不清需求就会失控.md

一句话提醒

一个需求真实且重要，仍要结合发生频率、平台阶段、资源限制和更深层链路判断是否当前先做。

为什么今天看它

• 需求验证通过后直接排进计划，容易忽略基础链路和阶段约束。把“需求是否成立”与“现在是否优先”分开，才能避免把局部解法抢成最高优先级。

留一个问题

你正在推进的一项真需求，发生频率和影响是否足以支持当前投入？是否还有更根本的链路问题需要先收稳？

参考思路

1. 1.先确认是否有真实场景、明确风险或价值，而不是表面偏好。
2. 2.验证发生频率、影响范围和当前问题强度。
3. 3.把功能或方案表达拆回深层业务链路问题。
4. 4.评估平台阶段、资源限制和可替代路径。
5. 5.把真需求判断和当前优先级排序分开，选择本阶段最该先收的链路。

03_知识库/问题/如何判断一个需求是真需求但不一定先做.md

一句话提醒

功能回答做什么，数据需求回答靠什么信息去做、去记录、去判断。

为什么今天看它

• 指标口径、字段、来源和权限若没有在功能设计前定义清楚，页面即使做完也可能无法支撑正确记录、统计和决策。

留一个问题

你正在推进的一项功能，是否已明确记录哪些字段、指标怎么定义、数据从哪里来、如何流转，以及谁能按什么维度使用？

参考思路

1. 1.列出功能判断和记录需要的数据对象与字段。
2. 2.明确关键指标的业务口径，而不是只写页面展示名称。
3. 3.说明数据来源、状态流转与保留规则。
4. 4.定义数据如何统计、展示和被不同角色使用。
5. 5.补查权限、质量与时效约束，避免把数据定义问题误判为功能问题。

03_知识库/问题/什么是数据需求，为什么它容易被忽略.md

一句话提醒

问题值得解决，不等于当前提出的做法就是最合适、最划算、最贴近本质的解。

为什么今天看它

• 团队常把功能表达直接当成需求结论。把方案拆回深层问题，再比较解决力度、副作用和阶段适配，才能避免只堵表面入口。

留一个问题

你正在讨论的一项方案，真正想控制或改善的深层问题是什么？它覆盖了主要入口，还是只处理了一个显眼表象？

参考思路

1. 1.先区分问题是否成立，与当前方案是否合适这两个判断。
2. 2.把功能表达还原为深层目标和主要问题入口。
3. 3.检查该方案的覆盖范围与实际解决力度。
4. 4.比较它对体验、流程与现有系统的副作用。
5. 5.结合平台阶段、资源和成本，选择当前最适合的解而非理论最彻底的解。

03_知识库/问题/如何判断一个方案是不是当前最优解.md

一句话提醒

用户诉求能提示问题存在，但是否值得做还要结合目标、成本收益、优先级和整体影响判断。

为什么今天看它

• 把用户的一句功能要求直接排进计划，容易把局部角色的方案误当成整体最优；分析的任务是把声音转回问题、价值与取舍。

留一个问题

你最近收到的一项用户需求，背后实际痛点是什么？它服务的局部目标是否与整体业务目标、成本和优先级一致？

参考思路

1. 1.把用户说出的功能或做法还原为真实场景与待解决问题。
2. 2.区分该诉求代表的是局部角色利益，还是整体系统价值。
3. 3.核对业务目标、预期收益、投入成本和潜在副作用。
4. 4.评估替代路径，不把用户提出的方案视为唯一解。
5. 5.再依据当前资源与优先级，决定推进、调整、延后或拒绝。

03_知识库/问题/为什么用户提了需求还不够.md

一句话提醒

不完美方案的取舍不是默认选最彻底的，而是选当前阶段更轻、更快、更可控的解。

为什么今天看它

• 面对风险或体验问题时，团队容易直接追求根治方案。先比较副作用、落地性与解决力度，才能避免把未来更适合的重方案过早压到当前阶段。

留一个问题

你当前正在比较的方案里，哪一个更彻底，哪一个更适合当前资源、链路成熟度和体验约束？两者是否被混成同一个判断？

参考思路

1. 1.先明确要控制的深层问题，而不是只复述表面功能诉求。
2. 2.列出不同路径分别是在做功能限制、流程限制还是更底层的机制调整。
3. 3.比较每条路径对体验、流程和现有系统的副作用。
4. 4.评估开发成本、改动范围、时间与当前资源条件。
5. 5.结合解决力度与平台阶段，选择当前最适合先上的方案，并保留后续升级路径。

03_知识库/问题/如何在不完美方案里做阶段性取舍.md

一句话提醒

没想清问题和目标就锁定功能做法，会把一种解法误当成需求本身。

为什么今天看它

• 讨论一旦从“我们该解决什么”直接跳到“做一个什么功能”，可选路径会被提前关掉，团队也容易错过流程、规则或协作层的更优解。

留一个问题

你当前收到的一句功能诉求，能否先改写成用户、场景、目标和痛点，而不出现任何具体功能名？

参考思路

1. 1.先还原客观问题、目标用户和发生场景。
2. 2.把具体功能或实现说法暂时拿掉，确认真正要改变的结果。
3. 3.列出功能、流程、业务规则和协作方式等多条可能路径。
4. 4.比较各路径解决核心问题的力度、代价和副作用。
5. 5.确定需求后再进入方案选择，而不是反过来为既定方案找理由。

03_知识库/问题/什么叫需求滑向方案.md

一句话提醒

功能回答做什么，数据需求回答靠什么信息去做、去记录、去判断。

为什么今天看它

• 很多项目在页面和流程已定后才发现指标口径、字段或权限没有定义，返工的根源通常不是实现，而是早期遗漏了数据需求。

留一个问题

你正在讨论的一个功能，是否已明确需要记录哪些字段、指标如何定义、数据从哪里来，以及谁能按什么维度使用？

参考思路

1. 1.先列出支持功能判断与记录所需的数据对象和字段。
2. 2.为关键指标写清业务口径，例如什么算有效订单或活跃用户。
3. 3.说明数据来源、流转方式和需要保留的状态。
4. 4.明确数据如何统计、展示和被不同角色使用。
5. 5.再检查权限、质量、时效等约束，避免把数据问题误当页面问题。

03_知识库/问题/什么是数据需求，为什么它容易被忽略.md

一句话提醒

伪需求识别先判断值不值得认真对待，需求验证再确认它是否强到值得当前投入。

为什么今天看它

• 把两步混为一谈时，团队不是过早排除潜在需求，就是在证据不足的事项上直接讨论优先级和方案。

留一个问题

你手里的一个功能诉求，是连真实场景和价值都说不清，还是已像需求但还缺频率、影响和替代成本的证据？

参考思路

1. 1.先回到业务场景与价值，识别它是否只是方案、情绪或“看起来高级”的表达。
2. 2.明显不成立的伪需求直接排除或降级。
3. 3.对仍可能成立的需求，再查频率、影响范围、稳定性、业务损失和替代成本。
4. 4.验证通过后才进入优先级判断。
5. 5.优先级明确后，再讨论当前方案是否合适。

03_知识库/问题/伪需求识别和需求验证有什么区别.md

一句话提醒

先看场景和边界，再拆需求、验真假、排优先级，最后才谈方案。

为什么今天看它

• 需求讨论很容易从一句功能诉求直接跳到实现方案。把判断顺序固定下来，能让评审从“谁的方案更好”回到“到底要解决什么问题”。

留一个问题

你现在在推进的一项需求，能否用一句话说清它的场景、边界和价值目标？如果不能，当前讨论可能还停在方案层。

参考思路

1. 1.先描述真实场景：谁在什么条件下，为了什么目标做什么事。
2. 2.收清边界：这次做到哪里，明确不做什么。
3. 3.拆价值、功能、数据、非功能四层，避免把解法当需求。
4. 4.用频次、影响、替代方案或用户证据判断真伪，再排当前优先级。
5. 5.最后比较方案的副作用、落地性和解决力度。

03_知识库/综合/有效需求分析一页速查卡.md

一句话提醒

验证需求成立，不是继续讨论怎么做，而是先确认它是不是真的存在、是否稳定发生、影响够不够大、当前值不值得投入。

为什么今天看它

• 如果在需求还没验证成立前就开始讨论实现方案，团队很容易在一个看似合理、但未必值得做的问题上消耗资源。

留一个问题

你当前一个正在讨论的需求，如果回到“给谁用、什么场景、频次多高、不做影响多大”这几个问题，它还成立吗？

参考思路

1. 1.先问目标用户、真实场景和使用频次。
2. 2.再看当前怎么处理、不做会有什么影响、做了价值是什么。
3. 3.最后把“真需求判断”和“优先级判断”分开处理。

03_知识库/问题/如何验证一个需求是否真的成立.md

一句话提醒

功能回答“做什么”，数据需求回答“靠什么信息去做、去记录、去判断”。

为什么今天看它

• 如果只盯页面、按钮和流程，项目很容易把关键的数据定义、口径和流转漏掉，结果是界面做出来了，业务判断却立不住。

留一个问题

你最近一个看起来是功能问题的需求，背后真正缺的是功能，还是数据定义和数据口径？

参考思路

1. 1.先明确系统需要哪些数据、字段怎么定义、从哪里来。
2. 2.再补数据怎么流转、记录、统计、展示和使用。
3. 3.对关键指标先问业务定义，再谈技术实现。

03_知识库/问题/什么是数据需求，为什么它容易被忽略.md

一句话提醒

真需求成立，只代表问题值得解决；方案判断还要继续确认，这个做法是不是当前最合适、最划算、最贴近问题本质的解。

为什么今天看它

• 很多工作里的“需求”其实已经偷偷带着方案，如果不把问题层和解法层拆开，就很容易把一个可行方案误判成当前最优解。

留一个问题

你手上正在推进的一个方案，如果把深层问题重新翻出来，它还一定是当前最优解吗？

参考思路

1. 1.先区分当前在判断需求成立，还是在判断方案优劣。
2. 2.把表面方案和深层问题拆开，别直接接受提案里的做法。
3. 3.优先看副作用、阶段适配和解决力度，再看覆盖范围与成本。

03_知识库/问题/如何判断一个方案是不是当前最优解.md

一句话提醒

业务场景是需求成立的上下文；一旦脱离场景，需求就会退化成抽象功能名词。

为什么今天看它

• 如果需求里只有“要一个功能”，没有人物、时机、目标和痛点，后面的优先级和方案判断都会失真。

留一个问题

你最近写过的一条需求，如果把场景补完整，它的优先级和方案还会保持不变吗？

参考思路

1. 1.先补齐什么人、在什么条件下、为了什么目标做什么事。
2. 2.把抽象功能名词改写成具体业务场景表达。
3. 3.再回头判断这个需求为什么成立、为什么现在该做。

03_知识库/问题/什么是业务场景，为什么脱离场景写需求很危险.md

一句话提醒

用户提了需求，只能说明问题可能存在；值不值得做，还要再过业务目标、成本收益、优先级和整体影响这一关。

为什么今天看它

• 如果把用户声音直接等同于应该立刻做的需求，团队很容易被局部视角牵着走，忽略整体系统最优。

留一个问题

你最近收到的一个用户需求，如果不看“是谁提的”，单看业务目标和 ROI，它还成立吗？

参考思路

1. 1.先把用户表达里的问题和方案拆开，别直接接受表层做法。
2. 2.再看这个需求和业务目标、资源、优先级是否一致。
3. 3.最后判断它是局部角色最优，还是整体系统也值得做。

03_知识库/问题/为什么用户提了需求还不够.md

一句话提醒

还没把问题和目标分析清楚，就先锁定某个功能做法，需求就已经滑向方案了。

为什么今天看它

• 很多需求讨论的问题，不是大家没想到方案，而是太早把某个方案当成了需求本身。

留一个问题

你最近讨论过的一个“需求”，到底是在说问题，还是已经偷偷在说某种方案了？

参考思路

1. 1.先把一句需求拆开看：它是在描述问题、目标，还是已经在描述功能做法。
2. 2.如果已经锁定了解法，回头追问还有没有其他路径能解决同一个问题。
3. 3.把流程、规则、协作方式也放进候选解，而不是只盯功能层。

03_知识库/问题/什么叫需求滑向方案.md

一句话提醒

把需求记下来，只是防止遗漏；把需求分析清楚，才是在判断哪些问题成立、哪些值得做、哪些只是表层方案。

为什么今天看它

• 如果把收集清单误当成完成分析，后续设计、优先级和资源判断都会建立在一堆未分层的原始输入上。

留一个问题

你现在手上最近一份“需求列表”，里面哪些只是记录，哪些已经完成了结构化判断？

参考思路

1. 1.先把原始输入和分析结论分开，不要把会议纪要直接当需求分析结果。
2. 2.对每条需求补三个判断：它解决什么问题、背后价值是什么、当前值不值得先做。
3. 3.把零散点整合成结构，再决定后续设计与优先级。

03_知识库/问题/为什么记录需求不等于分析需求.md

一句话提醒

一个需求即使是真的，也不代表现在最该先做；成立性判断和当前阶段的优先级判断，是两步不同的问题。

为什么今天看它

• 它能把‘这是不是问题’和‘这要不要现在做’拆开，减少真需求一成立就直接冲优先级的常见误判。
• 它适合在平台早期、资源有限、链路没收稳的时候，提醒你继续往更深层的核心链路看。

留一个问题

我现在面对的这条真需求，是当前最该先补的那一层，还是只是方向重要、但还没到现在最优先投入的阶段？

参考思路

1. 1.先确认它是不是伪需求。先过真实场景、平台风险和问题存在性这一关。
2. 2.再看平台阶段和发生强度。偶发问题、可替代方案和早期野蛮生长阶段，都会影响当前是否先做。
3. 3.最后追到更深链路。表面解法很可能只是某个具体方案，真正该先补的可能是更底层的控制力问题。

03_知识库/问题/如何判断一个需求是真需求但不一定先做.md

一句话提醒

没有业务场景，需求就会退化成抽象功能名词；同一句需求放进不同场景里，含义和优先级可能完全不同。

为什么今天看它

• 它能把需求分析从抽象功能名词拉回真实上下文，减少‘要一个功能’但其实没想清楚谁在用、何时用、为何用的偏差。
• 它适合在需求讨论已经开始围着功能转时，逼着大家先补人物、时机、目标和痛点。

留一个问题

我现在说的这条需求，已经有清楚的业务场景了吗，还是只是一个脱离上下文的功能名词？

参考思路

1. 1.先补人物和时机。明确是谁在什么条件下发起这个需求，而不是只写功能动作。
2. 2.再补目标和痛点。说清楚为什么要做、当前怎么处理、哪里真的在痛。
3. 3.最后再判断功能形态。同一个功能放进不同场景，意义和优先级都会变，所以场景先于方案。

03_知识库/问题/什么是业务场景，为什么脱离场景写需求很危险.md

一句话提醒

有人提了、听起来合理、局部上有帮助，不等于它就值得当前投入；关键看场景、痛点、频次和价值是否够强。

为什么今天看它

• 它能把‘听起来像需求’和‘真的值得做’拆开，减少被表面合理性带着走的判断偏差。
• 它适合在需求讨论里出现感受型表达或好看型表达时，帮你继续往下追场景、频次和业务价值。

留一个问题

我现在面对的这条需求，是已经足够强到值得推进，还是只是带着合理外衣、但还支撑不起当前投入？

参考思路

1. 1.先别被表面表达带走。有人明确提了、态度很坚定，不等于需求就成立。
2. 2.再追四件事。有没有明确场景、稳定痛点、足够频次和业务价值，这四件事决定它是不是伪需求。
3. 3.最后用强度收口。不是完全没价值，但如果不够强，就该降级、延后，甚至直接驳回。

03_知识库/问题/什么是伪需求，为什么有些需求看起来合理却不值得做.md

一句话提醒

验证需求不是继续讨论怎么做，而是先确认它是否真的存在、是否稳定发生、影响够不够大、当前值不值得投。

为什么今天看它

• 它能把讨论从方案层拉回成立性判断，减少还没确认问题就先堆功能的常见偏差。
• 它适合在需求一开口就像是合理要求时，帮你先过一遍用户、场景、频次、替代方案和影响强度。

留一个问题

我现在面对的这条需求，是真的稳定存在的问题，还是只是看起来合理、但还没有足够证据支撑投入？

参考思路

1. 1.先问给谁用、在什么场景用。没有明确用户和真实业务场景，需求很难算成立。
2. 2.再看频次、替代方案和不做的影响。能不能手工替代、问题是不是稳定高频、影响是不是足够强，这些决定需求强度。
3. 3.最后把验证和优先级拆开。需求即使是真的，也不代表现在一定先做；成立性和排序是两步判断。

03_知识库/问题/如何验证一个需求是否真的成立.md

一句话提醒

优先级不是否定价值，而是在资源有限的前提下，把当前最该先成立的闭环排到前面。

为什么今天看它

• 它能把‘都重要’这种看似公平的说法拆穿，逼着我们真的做阶段性排序。
• 它适合在需求会上已经开始什么都想保留时，帮助我们重新回到当前最小闭环。

留一个问题

我现在说的‘都重要’，是真的都要现在做，还是其实还没把当前阶段最关键的闭环排出来？

参考思路

1. 1.先承认资源有限。只要时间、人力、预算有限，就一定要排先后，不存在所有项同时推进。
2. 2.再回到最小闭环。优先把最核心问题对应的 MVP 能力排到前面，效率优化类项往后放。
3. 3.最后把排序说完整。不要只说重要，要明确这期先做什么、后做什么，以及为什么这样排。

03_知识库/问题/什么是需求优先级，为什么都重要其实等于没有判断.md

一句话提醒

页面和按钮只是表面，很多需求真正的难点不在界面，而在字段、口径、来源、流转和可用范围这些数据定义上。

为什么今天看它

• 它能把需求讨论从显眼的功能层，往更底下的数据定义层再压一层，减少做完界面才发现基础没定清。
• 它适合在报表、搜索、推荐、统计这类场景里提醒自己，先把数据问题说清楚，再谈功能实现。

留一个问题

我现在讨论的这个需求，卡住的到底是功能没想清楚，还是数据字段、口径和流转规则根本还没定义好？

参考思路

1. 1.先问要什么数据。把字段、指标、状态、来源和使用对象先列清，不要直接跳页面。
2. 2.再问定义是否一致。像活跃用户、转化率、有效订单这类词，先统一业务口径，再谈开发实现。
3. 3.最后检查数据如何流转。谁记录、谁看、按什么维度统计、权限怎么分，这些没定清，功能通常也站不住。

03_知识库/问题/什么是数据需求，为什么它容易被忽略.md

一句话提醒

需求别一上来就谈方案，先按场景、边界、四层、真伪、验证、优先级、方案、取舍这条链往下走。

为什么今天看它

• 它把零散的需求判断点收成一条可复用顺序，适合在真实讨论里防止思路乱跳。
• 它适合做开场校准，让你先看问题本身，再决定要不要继续往方案层推进。

留一个问题

我现在讨论的这条需求，卡在判断链的哪一步，是场景不清、边界没收，还是已经提前滑进方案了？

参考思路

1. 1.先看场景和边界。先把真实发生场景讲清楚，再收这次做到哪里、不做到哪里。
2. 2.再拆四层并验真假。把价值、功能、数据、非功能拆开，再判断这是不是成立的真需求。
3. 3.最后再谈优先级、方案和取舍。只有前面的判断站住了，后面的先后次序和解法选择才不会跑偏。

03_知识库/综合/有效需求分析一页速查卡.md

一句话提醒

按钮、页面和流程通常只是功能表达，真正该先确认的是它到底想解决什么问题、带来什么结果。

为什么今天看它

• 它能把‘怎么做’和‘为什么做’拆开，减少把方案误当需求的常见偏差。
• 它适合在别人一开口就在说按钮、导出、页面时，帮你把讨论拉回价值目标。

留一个问题

我现在记下来的这条需求，表达的是价值目标，还是已经滑进了某个具体功能解法？

参考思路

1. 1.先改写成结果句。把原始表达从按钮、页面、动作改写成效率提升、风险降低、结果改善这类目标句。
2. 2.再分层记录。价值需求写为什么值得做，功能需求再写系统具体做什么，不要混成一句。
3. 3.最后检查是否跑偏。凡是讨论已经只剩控件和流程时，都要回问这件事到底在解决什么问题。

03_知识库/问题/价值需求和功能需求有什么区别.md

一句话提醒

边界不是否定价值，而是明确这次只解决到哪里，保护团队先聚焦在当前核心问题上。

为什么今天看它

• 它能把‘这些以后也要做’和‘这次先做到哪里’拆开，减少范围失控。
• 它适合在需求讨论里开始出现一连串‘顺手再加一下’时及时收口。

留一个问题

我现在加进去的这些扩展项，是当前闭环必需，还是只是因为它们看起来也有价值？

参考思路

1. 1.先定义这次解决到哪里。明确当前版本的核心问题、核心流程和最小闭环。
2. 2.再把暂不做写清楚。边界不是否定价值，而是把后续扩展留到更合适的阶段。
3. 3.最后检查蔓延点。凡是‘顺便加下载/编辑/分类/外链’这类扩展，都要先问是不是当前必须。

03_知识库/问题/什么是需求边界，为什么边界不清需求就会失控.md

一句话提醒

一句需求表达看起来完整，不代表它只在说一件事；先拆价值、功能、数据、非功能四层，判断才会稳。

为什么今天看它

• 它能把混在一起的目标、能力、信息和质量要求重新拉开，减少误判。
• 它适合在需求一开口就夹着方案、字段和约束时做第一轮整理。

留一个问题

我现在听到的这句需求，主要是在说目标、动作、数据定义，还是质量约束？

参考思路

1. 1.先按四层拆。价值看为什么做，功能看系统做什么，数据看口径和字段，非功能看质量和约束。
2. 2.再找混淆点。很多表达把价值和功能、数据和非功能、问题和方案混在一起，要先拆开再谈。
3. 3.最后再进入后续判断。四层没拉开前，真假、优先级和方案讨论都容易跑偏。

03_知识库/综合/需求分析四层拆解法.md

一句话提醒

真实工作里很少有完美方案，当前更重要的是选一个在这个阶段最轻、最快、最可控的解。

为什么今天看它

• 它能提醒你别把‘更彻底’自动等同于‘现在就该做’。
• 它适合在方案讨论开始变重、范围和成本不断上浮时拿来收束。

留一个问题

我现在倾向的方案，是因为它理论上更完整，还是因为它真的更适合当前阶段的资源和节奏？

参考思路

1. 1.先看副作用。更强的控制方案，往往也会带来更重的体验和理解成本。
2. 2.再看落地性。开发范围、改动链路和上线速度，决定它是不是现在能先推的方案。
3. 3.最后看阶段目标。先堵住最明显的问题入口，不等于放弃更彻底的解，只是把它放到更合适的时机。

03_知识库/问题/如何在不完美方案里做阶段性取舍.md

一句话提醒

验证需求不是继续讨论怎么做，而是先确认它是不是真的存在、稳定发生、影响够不够大。

为什么今天看它

• 它能在方案讨论之前先拦住‘先做了再说’的惯性。
• 它适合在任何新需求冒出来时，先做一轮成立性和强度检查。

留一个问题

我现在讨论的这个需求，已经有明确用户、真实场景、稳定频次和足够影响了吗？

参考思路

1. 1.先看用户和场景。没有明确对象和真实发生情境，后面的讨论很容易漂。
2. 2.再看频次和替代方案。稳定高频、替代成本高，才更像值得认真投入的需求。
3. 3.最后看影响强度。需求验证回答的是‘真不真、强不强’，不是直接跳去‘怎么做’。

03_知识库/问题/如何验证一个需求是否真的成立.md

一句话提醒

记录需求只是防止信息漏掉，分析需求才是在做整合、分层、判断和取舍。

为什么今天看它

• 它能把‘我已经把需求记下来了’和‘我已经把需求分析清楚了’这两件事拆开。
• 它适合在需求清单越记越长、但决策还是推进不动时做纠偏。

留一个问题

我现在手上的这份需求列表，是只是把输入记全了，还是已经真的走到了业务价值和优先级判断？

参考思路

1. 1.先分清动作。记录解决的是不遗漏，分析解决的是哪些值得做、哪些只是表层方案。
2. 2.再做结构化整理。把孤立输入整合成分层判断，而不是继续堆成一张清单。
3. 3.最后回到业务。分析需求必须结合价值、取舍和后续决策，而不只是把话记下来。

03_知识库/问题/为什么记录需求不等于分析需求.md

一句话提醒

真需求判断解决的是成不成立，高优先级判断解决的是现在先不先做，这两步不能混在一起。

为什么今天看它

• 它能把需求成立判断和资源排序判断拆开，减少‘都重要’式混乱。
• 它适合在一件事看起来确实该做、但团队资源明显不够时做收束。

留一个问题

我现在是在证明这个需求是真的，还是已经该进入当前阶段的先后顺序判断了？

参考思路

1. 1.先判真需求。先看业务场景、稳定痛点和需求验证，别跳过成立性判断。
2. 2.再判高优先级。成立之后，再结合资源、收益和阶段目标决定是否现在先做。
3. 3.最后分清输出。真需求的结论是‘成不成立’，高优先级的结论才是‘当前先不先做’。

03_知识库/问题/真需求和高优先级需求有什么区别.md

一句话提醒

先看场景，再收边界；再拆四层，再验真假；再排优先级，最后再看方案和取舍。

为什么今天看它

• 它能把零散判断动作压回一条完整链路，适合在真实工作里快速校准分析顺序。
• 它适合在需求讨论开始发散、大家跳着讲时，拿来做一页式收束。

留一个问题

我现在讨论的这件事，是还停在场景和边界，还是已经可以进入真假、优先级和方案判断了？

参考思路

1. 1.先走判断链。按场景、边界、四层、真伪、验证、优先级、方案、取舍这条顺序推进，别跳步。
2. 2.再拆四层。把价值、功能、数据、非功能分开，减少不同层次混在一起导致的误判。
3. 3.最后看三件事。方案判断时优先比较副作用、落地性和解决力度，而不是只看能不能做。

03_知识库/综合/有效需求分析一页速查卡.md

一句话提醒

真需求成立只说明问题值得解决，不说明你手上的这个解法就是当前最合适的解。

为什么今天看它

• 它能把讨论从‘这个方案能不能做’拉回到‘它是不是现在最合适’。
• 它适合在业务方直接给出解法、团队准备默认照做时先补一轮判断。

留一个问题

我现在拿着的这个方案，解决问题的力度、副作用和阶段适配，真的比其他可选解更合适吗？

参考思路

1. 1.先把方案和问题拆开。别把‘虚拟电话’‘数据大屏’这类表面解法直接等同于真实需求。
2. 2.再看三件事。优先评估解决力度、副作用和阶段适配，而不是只看能不能做出来。
3. 3.最后比较覆盖范围和成本。当前最优解通常不是最彻底的，而是当前最划算、最贴近问题本质的。

03_知识库/问题/如何判断一个方案是不是当前最优解.md

一句话提醒

价值需求回答的是为什么做、要换来什么结果；功能需求回答的是系统具体做什么，这两层不能混着说。

为什么今天看它

• 它能把需求讨论从按钮、页面和流程，往更上层的目标和结果拉回去。
• 它适合在一看到功能提议就想开做时，先补一轮价值层判断。

留一个问题

我现在拿到的是一个功能层解法，还是已经说清楚了它要换来的真实价值和目标结果？

参考思路

1. 1.先问为什么做。先说清问题本质、业务目标和用户结果，不要一上来就落到功能名词。
2. 2.再区分目标和解法。效率提升、风险降低、体验改善是价值层，按钮、页面、流程是功能层。
3. 3.最后再谈功能实现。先把价值需求钉住，功能需求才不容易滑向表面解。

03_知识库/问题/价值需求和功能需求有什么区别.md

一句话提醒

验证需求不是继续讨论怎么做，而是先确认它是不是真的存在、是不是稳定发生、值不值得现在投入。

为什么今天看它

• 它能在方案讨论之前先拦住‘先做了再说’的惯性。
• 它适合在新需求冒出来时，快速做一轮成立性和强度检查。

留一个问题

我现在讨论的这个需求，已经有明确用户、真实场景、稳定频次和足够影响了吗？

参考思路

1. 1.先看给谁用。目标用户不清，后面的讨论基本都会漂。
2. 2.再看场景、频次和替代方案。稳定高频、替代成本高，才更像值得认真投入的需求。
3. 3.最后看影响强度。真需求不等于最高优先级，但至少要先证明它是真的、强度够不够。

03_知识库/问题/如何验证一个需求是否真的成立.md

一句话提醒

伪需求识别是在挡掉不值得认真对待的东西，需求验证是在确认一个看起来成立的需求到底强不强。

为什么今天看它

• 它能把‘不要太快相信需求’拆成前后两步，减少分析时的混乱。
• 它适合在接到一个听起来合理的新需求时，先明确自己现在到底在做哪一轮判断。

留一个问题

我现在面对的这个需求，是还在第一轮筛查里，还是已经值得进入第二轮证据确认了？

参考思路

1. 1.先做伪需求识别。先看场景、价值和是不是只是情绪化或方案化表达。
2. 2.再做需求验证。对看起来可能成立的需求，继续查频率、影响、范围和替代成本。
3. 3.最后再排优先级。别把前两轮没做完的需求，直接推进到方案和资源讨论。

03_知识库/问题/伪需求识别和需求验证有什么区别.md

一句话提醒

真需求判断解决的是成不成立，高优先级判断解决的是现在先不先做，这两步不能混成一步。

为什么今天看它

• 它能防止把‘需求是真的’直接误判成‘这件事现在就该做’。
• 它适合在需求成立后、资源开始拉扯时拿来做阶段排序。

留一个问题

我现在推动的这件事，是还停留在证明它是不是真需求，还是已经该进入当前阶段的优先级判断了？

参考思路

1. 1.先判成立性。先看业务场景、痛点和需求验证，别跳过真需求判断。
2. 2.再判排序性。成立之后，再结合资源、收益和阶段目标决定先后顺序。
3. 3.最后分清输出。真需求的结论是成不成立，优先级的结论才是当前先做还是后做。

03_知识库/问题/真需求和高优先级需求有什么区别.md

一句话提醒

一旦脱离业务场景，需求就会退化成抽象功能名词，判断会开始失真。

为什么今天看它

• 它能把讨论从“要不要这个功能”拉回到“谁在什么情况下为什么要它”。
• 它适合在需求刚被提出、还没滑向方案讨论前先收住问题定义。

留一个问题

我现在讨论的这个需求，具体是谁在什么条件下、为了什么目标、遇到了什么痛点？

参考思路

1. 1.先补角色和时机。没有人物和发生时点，需求很容易只剩一个空名字。
2. 2.再补目标和痛点。说明为什么现在要做，以及当前阻力到底在哪里。
3. 3.最后再谈功能。先把场景说实，再判断这个功能是不是当前真正需要的解。

03_知识库/问题/什么是业务场景，为什么脱离场景写需求很危险.md

一句话提醒

真实工作里很少有完美方案，当前更重要的是选一个在这个阶段最轻、最快、最可控的解。

为什么今天看它

• 它能提醒你别把“更彻底”误当成“现在就该做”。
• 它适合在方案讨论开始变重、范围开始失控时拿来收口。

留一个问题

我现在倾向的方案，是因为它理论上更完整，还是因为它真的更适合当前阶段的资源和节奏？

参考思路

1. 1.先看副作用。更强的控制方案，往往也会带来更重的体验和理解成本。
2. 2.再看落地性。开发范围、改动链路和上线速度，决定它是不是现在能先推的方案。
3. 3.最后看阶段目标。先堵住最明显的问题入口，不等于放弃更彻底的解，只是把它放到更合适的时机。

03_知识库/问题/如何在不完美方案里做阶段性取舍.md

一句话提醒

真需求不是靠感觉成立的，要能说清它是否存在、是否高频、是否有足够影响。

为什么今天看它

• 它能帮你把“先讨论怎么做”的惯性往回拽，先做需求成立判断。
• 它适合在需求刚冒出来、还没进入方案讨论前先做一轮核查。

留一个问题

我正在讨论的这个需求，到底是一个真实稳定的问题，还是一个只在表面上看起来合理的提议？

参考思路

1. 1.先问场景和角色。用户是谁、在什么情境下遇到问题，这一步不清，后面都容易漂。
2. 2.再问频次和替代。稳定高频、且现有替代成本高，才更像值得投入的需求。
3. 3.最后问影响强度。真需求不等于最高优先级，还要看不做的代价到底有多大。

03_知识库/问题/如何验证一个需求是否真的成立.md

一句话提醒

把需求记下来只是防止遗漏，真正的分析还要继续做整合、判断和取舍。

为什么今天看它

• 它能帮你重新拉开“收集信息”和“形成判断”这两个动作，避免误以为记完就等于做完。
• 它适合放在任何需求讨论开始变多、但结论仍然模糊的时候回看。

留一个问题

我现在手上的这份需求清单，哪些只是被记下来了，哪些已经真的被分析过了？

参考思路

1. 1.先看是不是只有罗列。只有原始输入，没有结构和归类，通常还停留在记录层。
2. 2.再看有没有判断。分析不是复述需求，而是判断真假、轻重和优先级。
3. 3.最后看是否接到业务。不能回到业务价值和后续决策的内容，还不能算真正分析完成。

03_知识库/问题/为什么记录需求不等于分析需求.md

一句话提醒

先判断需求是不是真的成立，再讨论怎么做；顺序反了，后面全会偏。

为什么今天看它

• 它把“需求成立”拆成可核对的问题，能帮你少掉很多凭感觉推进的讨论。
• 它适合放在任何新需求刚冒出来的时刻，先做一轮低成本筛查。

留一个问题

我现在正在讨论的这个需求，是真的稳定存在，还是只是一次性的声音、情绪或表面动作？

参考思路

1. 1.先问给谁用。用户角色不清，后面的场景和价值判断都会漂。
2. 2.再问场景和频次。只有稳定发生的问题，才值得进入正式投入判断。
3. 3.最后看影响和替代。有痛点不等于要立刻做，还要看不做的代价和现有替代成本。

03_知识库/问题/如何验证一个需求是否真的成立.md

一句话提醒

阶段性最优，往往不是最彻底的方案，而是当下更轻、更稳、更能落地的那一个。

为什么今天看它

• 它能帮你把“更根本”与“更适合现在”这两个判断拆开。
• 它适合放在任何需要权衡副作用、成本和节奏的场景里反复回看。

留一个问题

我眼前更想推进的那个方案，是因为它真的更适合当前阶段，还是只是因为它听起来更完整？

参考思路

1. 1.先看副作用。不要只比较解决力度，也要看它会对体验和理解成本带来什么扰动。
2. 2.再看落地性。当前阶段能不能快上、稳上，往往比理论上更彻底更重要。
3. 3.最后判断节奏。更根本的方案不一定该现在做，先上轻量收口也可能是更好的阶段性判断。

03_知识库/问题/如何在不完美方案里做阶段性取舍.md

一句话提醒

记录只是把输入留住，分析才是在做整合、分层、判断和取舍。

为什么今天看它

• 这张卡能提醒你别把勤奋收集误当成已经形成判断。
• 它适合今天任何在整理需求、开会记录或梳理输入的场景。

留一个问题

我现在手上的这份需求清单，是真的已经形成结构和判断了，还是还停留在原始输入汇总？

参考思路

1. 1.先区分收集和分析。 记下来只能防漏，不能直接指导决策。
2. 2.再做结构化整理。 把表层表达、真实问题和业务价值拆开。
3. 3.最后补判断和取舍。 没有优先级和价值判断，就还不是分析结果。

03_知识库/问题/为什么记录需求不等于分析需求.md

一句话提醒

优先级不是决定做不做，而是在有限资源下决定什么先做、什么后做。

为什么今天看它

• 这张卡能提醒你，公平地说“都重要”并不等于完成了判断。
• 它适合今天任何需要在价值、资源和节奏之间做取舍的场景。

留一个问题

我现在说“都重要”，到底是在尊重需求，还是在回避当前阶段必须做出的排序？

参考思路

1. 1.先承认资源有限。 只要时间和资源有限，就一定要有先后顺序。
2. 2.先找最小闭环。 优先让当前阶段最核心的问题先被解决。
3. 3.把优化项往后排。 不是否定价值，而是把效率提升和扩展项留给下一轮。

03_知识库/问题/什么是需求优先级，为什么都重要其实等于没有判断.md

一句话提醒

功能回答做什么，数据需求回答靠什么信息去做、去记录、去判断。

为什么今天看它

• 这张卡能提醒你别只盯页面和流程，而忽略功能背后的数据口径。
• 它适合今天任何需要定义指标、字段或统计逻辑的判断场景。

留一个问题

我现在讨论的这个需求，真正卡住它的是功能实现，还是数据定义还没说清楚？

参考思路

1. 1.先拆功能和数据。 不要把页面、按钮和数据定义混成同一个问题。
2. 2.先问字段和口径。 先明确要记录什么、怎么定义、从哪里来。
3. 3.再看展示和使用。 只有数据基础清楚，统计、推荐、报表这些功能才站得住。

03_知识库/问题/什么是数据需求，为什么它容易被忽略.md

一句话提醒

一个按钮、页面或流程通常只是功能层表达，真正的需求判断要先回到它想解决的结果。

为什么今天看它

• 它能提醒你在讨论需求时，不要被现成功能名词直接带进方案层。
• 它适合今天任何需要判断目标、价值和实现是否错位的场景。

留一个问题

我今天正在讨论的需求里，哪些表述其实是在讲功能，而没有说明真正想达成的价值？

参考思路

1. 1.先问为什么做。 先说清这件事想改善什么结果，而不是先说做什么功能。
2. 2.再拆目标和解法。 把价值需求和功能表达分开，避免把按钮当需求本身。
3. 3.最后校验结果。 判断这个功能是否真的对应效率提升、风险降低或体验改善。

03_知识库/问题/价值需求和功能需求有什么区别.md

一句话提醒

有人提、听起来顺、局部有帮助，都还不够支撑它进入当前投入序列。

为什么今天看它

• 这张卡能帮你在需求沟通里把“看起来合理”与“值得现在做”分开。
• 它适合今天所有需要做取舍、驳回或降级的讨论场景。

留一个问题

我今天接到的需求里，哪一个只是看起来有道理，但没有真实场景、稳定痛点或足够价值支撑？

参考思路

1. 1.先追使用场景。 没有明确谁在什么时刻高频使用，就先别急着接。
2. 2.再追痛点强度。 不是有一点帮助就值得排进当前开发序列。
3. 3.最后看投入回报。 价值不足以支撑当前资源时，要敢于降级或驳回。

03_知识库/问题/什么是伪需求，为什么有些需求看起来合理却不值得做.md

一句话提醒

还没把问题和目标分析清楚就跳到解法，会过早缩窄选择空间。

为什么今天看它

• 这张卡能提醒你在需求沟通里先停在问题层，不要急着接功能方案。
• 它适合今天任何需要做取舍和判断的场景。

留一个问题

我今天讨论的需求里，有哪些表述其实已经偷偷从问题滑向了方案？

参考思路

1. 1.先把问题层和解法层拆开。 不要把具体功能直接当需求本身。
2. 2.补足目标与约束。 先搞清真正要解决什么，再谈实现形式。
3. 3.保留多条路径。 在锁定方案前，至少比较两种以上可能解法。

03_知识库/问题/什么叫需求滑向方案.md

一句话提醒

记录只是收集输入，分析才是在业务里做结构化判断、分层和取舍。

为什么今天看它

• 这张卡能防止你把需求清单误当成需求判断。
• 它适合在今天的沟通里提醒自己多问价值和优先级，而不是只做搬运。

留一个问题

我今天接到的需求里，哪些只是被记录下来了，但还没有真正被分析？

参考思路

1. 1.先把原始输入和判断动作分开。 记录不等于已经得出结论。
2. 2.补业务价值这一层。 先问这件事为什么重要，而不是直接接方案。
3. 3.做结构化取舍。 把需求放进优先级、真假需求和边界里重新看。

03_知识库/问题/为什么记录需求不等于分析需求.md

一句话提醒

需求一旦脱离场景，就容易退化成抽象功能名词。

为什么今天看它

• 适合开会前提醒自己先补上下文。
• 能避免把记录需求误当成分析需求。

留一个问题

这个需求发生在什么具体场景里，是谁在什么条件下、为了什么目标，遇到了什么真实阻力？

参考思路

1. 1.先补场景中的人物、时机和目标。
2. 2.再补当前做法和痛点。
3. 3.最后才谈功能表达。

03_知识库/问题/什么是业务场景，为什么脱离场景写需求很危险.md