当 AI 参与需求分析：设计师在设计什么？
当AI深度参与需求分析，设计师的工作重心从生成答案转向验证逻辑与依据。本文探讨如何让AI的分析过程更透明、判断更可靠，从而真正赋能设计决策。核心内容：1. 设计师如何区分需求文档中的事实、假设与方案2. AI生成“看似合理”分析的内在逻辑与潜在陷阱3. 构建可检查、可验证的AI辅助需求分析方法论
Sharing
AI 可以快速拆解需求、调用资料并生成结论，但一份完整的分析并不等于可靠的判断。本文从一次需求分析 Skill 的迭代出发，讨论设计师如何区分事实与假设，组织判断依据，并让 AI 的分析过程能够被检查和持续验证。
本期提纲：
• 需求文档写的是方案，设计师要看见背后的问题
• 为什么 AI 总能给出“看起来合理”的分析？
• 如何让 AI 对需求的判断与分析，更可靠？
• 好的需求分析，应该让团队看见什么？
• 设计师真正沉淀下来的，是一种学习循环
• 结语
最近在搭建一个需求分析 Skill，这个skill的运行逻辑是：我把一份需求文档交给 AI，希望它结合我提前整理设计理论和产品价值观等材料搭建出来的知识库内容，判断这个需求解决了什么问题、是否值得做、还存在哪些风险。很快，一份有用户、有场景、有结论的分析生成了。只看结果的话，似乎方法已经跑通。但当遇到一些较为棘手的问题时，继续追问AI，例如“这条判断用了哪项依据”、“为什么这项原则适用于当前需求”时，问题出现了：
有些结论来自 AI 自身的通用推理；
有些观点虽然来自资料，却忽略了适用条件；
还有些表达过于绝对，仿佛一条经验能够覆盖所有需求。
这些答案不一定是错的。真正值得警惕的问题是：这一次看起来正确，究竟是方法可靠，还是 AI 恰好猜对了？这成为我持续思考迭代这个 Skill 的起点。比起让 AI 给出更多答案，更重要的是让判断的依据、过程和边界变得清晰。
1需求文档写的是方案，设计师要看见背后的问题体验设计经常从一份需求文档开始：文档通常已经写明要增加什么功能、希望达到什么目标，有时还附带用户反馈和初步方案。我们很容易顺着它继续思考用户流程、信息架构和交互界面等等设计工作的开展，却忽略了一个前提：文档描述的往往是：“团队目前想做什么，不一定等于用户真正遇到了什么问题”。
假设，一份需求写着：
“用户面对的内容太多，希望增加自动摘要功能，帮助用户更快获取重点。”这句话至少混合了四类信息：- 事实： 用户正在处理较多内容；
- 目标： 希望降低阅读和理解成本；
- 假设： 用户需要自动摘要；
- 方案： 在产品中增加摘要功能。
“自动摘要”已经是一个方案。用户真正的困难可能是找不到关键信息、无法比较多份内容，或者不知道怎样做决定。
如果没有拆开这些信息，我们很容易把尚未验证的方案当成需求本身。后面无论把摘要长度、按钮位置和纠错机制讨论得多完整，都可能只是在认真解决一个没有被确认的问题。
把需求拆解看成一座冰山，水面上是产品背景、产品逻辑、产品目标、功能描述；水面下还有用户场景、真实诉求、约束、风险、判断依据等等隐藏信息。设计师的工作不是立刻把水面上的内容做出来，而是先确认水面下的问题是否成立。
不过，看见水面下的信息，并不代表我们已经得到了答案。
接下来还需要判断：哪些信息足以支撑当前选择？已有的设计原则和经验是否适用于这个场景？当用户目标、业务诉求和使用风险发生冲突时，应该依据什么做出取舍？
这意味着，需求分析不仅需要把问题拆开，还需要一套能够被调用和核对的判断依据。公开规范、设计原则和历史经验，都是这些依据的重要来源。
Apple 的 Human Interface Guidelines，就提供了一种组织这类判断依据的参考。它覆盖设计基础、常见模式、系统组件、输入方式和平台技术，帮助设计师理解平台行为与用户预期，再结合具体情境做出选择。
HIG 的价值不在于提供一个可以直接套用的标准答案，而在于说明一项设计原则为什么成立、通常适用于什么场景，以及使用时需要注意哪些条件。
同样，用于提供给AI进行需求分析的知识库，不仅仅只是单纯给出设计原则、规范或历史经验、产品价值观。还需要补充说明它们成立的支撑依据是什么、适用条件有哪些、使用的边界情况，等等额外信息。
2为什么 AI 总能给出“看起来合理”的分析？
第一版 Skill 已经包含提示词、判断的知识库资料和基本流程步骤，但没有太多的“约束”。告诉 AI 应该参考什么、输出什么，却没有规定怎样使用依据、哪些过程不能跳过，以及怎样证明检查真正发生过。AI 很聪明，但也很会“偷懒和欺骗”。
这里的“偷懒和欺骗”，是指它擅长选择最短路径，尽快生成一个符合要求、看起来合理的结果。实践中，常见的偏差有四种：
1. 无关联性的强行匹配
需求和知识库内容一旦出现相似词语，AI 就把两者强关联起来。结果是不太关联的内容却被关联了起来，且没有确认原则、关联逻辑成立的条件。
2. 无视思考，直接跳过
AI 可以直接给出结论和理由，但未必说得清结论对应哪条需求信息，又是怎样从依据推导出来的。
3. 把“总结”“篡改”原话
AI 自行总结知识库里的内容，在后续输出结论的时候加上引号“”，变成仿佛是来自原文的直接表达。
4. 捏造事实，只为补满空白
当资料没有覆盖某个问题时，AI 更自然的选择是用常识继续完成答案，事实、经验和模型推测也因此混到了一起。这种看似可信但实际错误的内容通常被称为幻觉。OpenAI 的相关研究也指出，只奖励正确率的评测方式可能鼓励模型猜测，而不是承认不确定性。
AI 的捷径不一定让答案显得粗糙，反而可能让缺失的过程更难被发现。
第一版真正的问题不是 AI 不够聪明，恰恰是它太会给答案。即使缺少依据，也能把空白补成完整、合理的结果。后来发现这些问题之后，我采取的一个处理方式是不断在 Skill 中增加提示：给出依据、区分事实和推测、不要编造、列出信息缺口、输出前自检。
但回想后发现，这些要求像一个个补丁，可以修复已经出现的问题，却很难保证下一个需求不会从别处出错。AI 也可以生成“我已检查”的文字，却不一定真的读取了资料；可以列出推理步骤，却可能是在结论之后反向补齐。
因此，真正需要调整的不是提示词长度，而是把判断依据、执行步骤和检查方式拆开，更系统性工程化的角度来重新构建 skill 的骨架。一次输出看起来正确，只能说明这次结果可用；只有过程能够被重复检查，方法才开始变得可靠。3
如何让 AI 对需求的判断与分析，更可靠？
最初的目标，是想真正“教会”AI，让它理解我们判断需求的方式。但 AI 不会因为读过一批资料，就像团队成员一样拥有共同经验和产品观。当前更现实的方式，是让它在明确的依据、步骤和边界内工作。
随着问题不断暴露，这个 Skill 的协作方式逐渐被整理成三个部分：
1. 先整理判断依据：AI 根据什么做判断
这个阶段聚焦在知识库里，知识库的内容如果按“来源”进行归档，适合保存，却未必适合判断。如果只把大量材料交给 AI，它可能找到相关观点，却不知道这条观点在回答什么问题、何时不适用。
因此，除了内容本身以外，还需要对内容进行“解析”处理：说明成立前提、适用边界、与当前需求的关系，以及如何回到原始来源核对。
原始材料与 AI 生成的摘要也需要分开。摘要可以帮助检索，却不能代替来源。尤其是引用，必须能够回到原文核对，不能把 AI 的概括伪装成原话。
2. 再规定分析步骤：哪些过程不能跳过
如果只要求“认真分析”，AI 会选择自己最擅长也最省力的方式。所以，需要明确几个不能跳过的动作：
拆开需求中的事实、目标、假设和方案；
寻找依据并检查适用条件；
解释需求信息与依据之间的关系；
暴露冲突、风险和信息缺口；
最后形成结论与下一步建议。
这些步骤不是为了让产出物变长变复杂，而是避免 AI 直接从输入跳到答案。
Skill 的角色也从“判决评审官”逐渐转向“思辨好伙伴”。只告诉设计师“不要做”并不会提高设计质量，团队还需要知道问题在哪里、原始诉求是否成立，以及还能怎样重新理解。
它不负责替设计师说“做”或“不做”，而是帮助设计师看见判断的前提和仍未回答的问题。
3. 做最后检查动作：规则是否真的生效
规则、要求、步骤写进 Skill，并不代表已经生效。真正的检查需要回答：
依据只是关键词相似关联，还是适用条件真的成立？
是否解释了它为什么适用于当前需求？
引用能否回到原始来源？
没有依据的部分是否明确标成未知？
每次修改规则后，还要用历史案例和故意设置的错误样例重新运行。因为规则需要经过测试，而不是写完就算完成。反复打磨和验证，这也与 AI 应用中的评测思路相近：先定义行为标准，再用代表性数据验证输出。
Skill 的价值不是增加提示词，而是让依据、过程和检查可以被重复调用。也不是给提示词不断增加补丁，而是把依据、步骤和检查组织成一套可以重复运行的分析流程。4好的需求分析，应该让团队看见什么？
当 AI 可以很快生成结论时，需求分析反而不应该只留下结论。如果仅只是输出一句“建议推进”或“需要重新考虑”会把判断过程压平。好的分析还应帮助团队看清四件事：
1. 我们已经知道什么？
需求材料中能够确认的事实，例如用户反馈、使用场景、现有流程和明确约束。AI 可以帮助整理这些信息，但不能把自己的补充混进事实。
2. 我们正在假设什么？
尚未被验证的判断，很多需求会把问题、目标和方案写在一起。分析需要把尚未验证的部分单独标出来。只有先看见假设，团队才能决定怎样验证。
3. 我们凭什么得出当前判断？
一条条设计原则或历史经验不能只因为听起来相关，就成为结论依据。分析需要说明它解决的是什么问题、适用条件是什么，以及为什么能用于当前需求。
存在反面证据或不同观点时，也应该同时呈现。
4. 下一步还要确认什么？
还要向谁确认、补充什么证据、哪个假设的错误成本最高，以及哪些决策暂时不应推进。
需求分析不只交付结论，还要保留团队继续验证和讨论的入口。AI 最自然的动作是补全，但需求分析有时最需要的动作恰恰是停下来。
“不知道”并不意味着分析失败。当不确定性被明确表达，它就从隐藏风险变成了团队可以处理的工作。
设计师在这里也不只是审核 AI 写得好不好，而是决定哪些问题值得追问、什么证据足以支撑判断、谁的体验被遗漏，以及不同价值与风险该如何取舍。
5设计师真正沉淀下来的，是一种学习循环
虽然，目前的skill还在搭建和打磨当中，仍不能确定这套基建思路是不是最终答案，它也会继续迭代。
但至少可以确认：让 AI 在明确的依据、步骤和边界内工作，比放任它凭通用能力自由生成，更容易发现偏差。这种约束不是为了让答案僵硬，而是让我们知道它为什么这样判断，也知道什么时候不该相信它。
这段实践逐渐形成了一套“做中学”的循环：从真实摩擦出发，选择一个最小任务试验，观察输出偏差，把有效方法固化下来，再用新旧案例重新验证。
这也符合当前常见的 AI 工程实践：先从简单方案开始，通过评测优化，只有在无法满足需求时，再增加系统复杂度。而且不同工具各有所长，重点不是寻找一个包办所有事情的工具，而是先判断当前环节需要什么能力，再用真实任务验证它。
每次试错也最好留下资产：一条问题记录、一个失败样例、一份模板、一张检查表，或一条被写进 Skill 的规则。工具会变化，但这些经验能让下一次探索不再从零开始。
工具会变化，但从问题出发、用实验验证、把经验留下来的能力可以持续积累。
6结语：AI 没有替设计师做判断，而是让判断过程变得清晰
这段实践得到的，不是一个能够自动评审需求的标准答案。
Skill 的意义，是把需求分析中相对稳定的步骤封装起来，让 AI 按同一套流程拆解信息、调用依据和检查结果；需求分析本身的意义，则是辅助设计师看清问题，而不是代替设计师下判断。
当 AI 越来越擅长生成内容，设计师仍然需要理解具体情境和真实的人，发现需求描述之外的问题，在不同目标之间做出取舍，并为最终选择承担责任。
AI 可以快速整理信息，却不知道哪一种产品体验更值得做；可以生成多种解释，却无法代替团队决定什么符合产品的长期方向。
因此，AI 时代的设计师更像问题的定义者、情境的解释者和价值的取舍者。我们不仅要会使用 AI，也要知道应该给它什么依据、在哪些地方停下来，以及哪些判断必须留在人手里。
当生成答案成为基础能力，设计师之间真正的差异，也许不在谁更快给出结论，而在谁能更早发现：哪些是事实，哪些是假设，我们究竟还缺少什么。登录查看剩余 70% 内容
