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