AI参与需求分析时，设计师在设计什么？

最近一直在深入思考一个关键问题：当AI深度参与需求分析工作后，设计师的核心价值究竟应该体现在哪里？我的答案是，设计师的价值不在于生成答案本身，而在于验证逻辑与判断依据。下面，我将分享一段实践中的思考，探讨如何让AI的分析过程更加透明、判断结果更加可靠。

需求文档写的是方案，设计师要看见背后的问题

用户体验设计的工作，往往始于一份需求文档。

文档中通常已经清晰地说明了要增加什么功能、期望达成什么目标，有时甚至会附带用户反馈和初步方案。顺着这个思路去规划用户流程、信息架构和交互界面，似乎是一件顺理成章的事情。但是，其中隐藏着一个容易被忽视的前提：文档所描述的内容，实际上代表的是“团队当前想要做什么”，而非“用户真正遇到了什么问题”。

举个例子。一份需求这样写道：“用户面对的内容过多，希望增加自动摘要功能，以帮助用户更快获取重点信息。”

在这句话中，至少包含了四类不同的信息：

• 事实：用户正在处理大量内容，信息负荷较高
• 目标：旨在降低用户的阅读与理解成本
• 假设：用户需要自动摘要功能来解决该问题
• 方案：在产品中新增自动摘要功能

请注意，“自动摘要”本身已经是一个具体的解决方案。而用户面临的真实困难，可能是难以定位关键信息、无法有效对比多份内容，或者不清楚如何做出决策。如果没有将这些信息进行有效剥离，那么无论后续对摘要长度、按钮位置和纠错机制讨论得多么详尽，也仅仅是围绕一个尚未被确认的问题进行优化。

因此，需求分析不应当被视为设计开始前的一个机械步骤，它本身就是设计工作的核心组成部分。设计师需要持续追问：是谁在什么场景下遇到了什么困难？真正的阻碍是什么？哪些信息已经得到证实，哪些还只是推测？

我们可以将需求拆解看作一座冰山。水面之上是产品背景、产品逻辑、产品目标和功能描述；而水面之下则潜藏着用户场景、真实诉求、约束条件、潜在风险和判断依据等隐藏信息。设计师的任务并非立即将水面之上的内容转化为设计成果，而是首先确认水面之下的问题是否真实存在、是否成立。

然而，即使我们看见了水面之下的信息，也不代表我们就获得了现成的答案。接下来还需要进一步判断：哪些信息足以支撑当前的设计决策？已有的设计原则和经验是否适用于这个特定场景？当用户目标、业务诉求和使用风险发生冲突时，我们应该依据什么来进行取舍？

这意味着，需求分析不仅需要将问题拆解开，还需要建立一套能够被反复调用和核对的判断依据。公开的规范、成熟的设计原则以及积累的历史经验，都是这些判断依据的重要来源。

Apple 的 Human Interface Guidelines 就提供了一种组织这类判断依据的参考框架。它涵盖了设计基础、常见交互模式、系统组件、输入方式以及平台技术，帮助设计师理解平台的行为逻辑与用户的预期，再结合具体情境做出合理选择。HIG 的价值并不在于提供一个可以直接套用的标准答案，而在于阐明一条设计原则为什么成立、通常适用于什么场景，以及在使用时需要注意哪些条件和潜在限制。

同样，用于为AI提供需求分析支持的知识库，也不应该仅仅是罗列设计原则、规范、历史经验或产品价值观。还需要补充说明这些原则成立的支撑依据、具体的适用条件，以及使用时需要注意的边界情况。

为什么 AI 总能给出“看起来合理”的分析？

最初版本的Skill虽然已经包含了提示词、判断知识库资料和基本的流程步骤，但它存在一个致命的缺陷：缺少“约束”。它只告诉AI应该参考什么、输出什么，却没有明确规定它应该如何调用依据、哪些处理步骤不能跳过，以及如何证明其检查过程确实发生过。

AI非常聪明，但也很善于走“捷径”。这里的“偷懒”并非指它故意偷工减料，而是指它倾向于选择最短的路径，尽快生成一个看起来合理、符合要求的结果。在实践中，常见的偏差有以下四种：

1. 无关联性的强行匹配：一旦需求文本与知识库内容出现相似的词语，AI就会将它们强行关联起来，而不去验证关联逻辑是否真正成立。
2. 跳过思考过程：AI能够直接给出结论和理由，但可能无法清晰说明这个结论是针对哪条需求信息得出的，以及它是如何从依据推导而来的。
3. 把总结当成原话：AI会自行总结知识库中的内容，然后在输出结论时加上引号，使其看起来像是来自原文的直接引述。
4. 编造事实来填空：当现有资料未能覆盖某个问题时，AI更倾向于使用常识来继续完成答案，从而将事实、经验和推测混杂在一起。这种看似可信但实际错误的内容，通常被称为“幻觉”。

第一版真正的问题，并非AI不够聪明，恰恰相反，是它太擅长给出答案了。即使缺乏充分的依据，它也能将空白之处填补成完整、合理的结果。

发现问题之后，一个很自然的应对方式是在Skill中不断增加提示指令：要求给出依据、区分事实与推测、禁止编造、列出信息缺口、输出前进行自检。但回顾来看，这些要求就像是一个个补丁，可以修复已经暴露的问题，却难以保证下一个需求不会从其他地方出错。AI可以生成“我已检查”的文字，却不一定真的去读取了资料；它可以列出推理步骤，却可能是在结论形成之后反向补齐的。

因此，真正需要调整的不是提示词的长度，而是将判断依据、执行步骤和检查方式拆分开来，从更系统化、工程化的角度重建Skill的骨架。一次输出看起来正确，只能说明本次结果可用；只有处理过程能够被重复检查和验证，方法本身的可靠性才能得以确立。

如何让 AI 对需求的判断与分析，更可靠？

最初的目标，是希望真正“教会”AI，让它理解我们判断需求的方式。但现实是，AI并不会因为读取了一批资料，就像团队成员一样拥有共同的实践经验和产品价值观。在当前阶段，更可行的方法是让它在明确的依据、清晰的步骤和严格的边界内工作。

随着问题的不断暴露，这个Skill的协作方式逐渐被整理成了三个核心部分：

第一部分：先整理判断依据

如果知识库仅仅按照“来源”进行归档，那么它更适合用于保存，却未必利于进行判断。如果只是将大量材料一股脑地扔给AI，它可能找到相关的观点，却不知道这个观点是在回答什么问题，也不知道它在什么情况下不适用。

因此，除了内容本身之外，还需要对内容进行“解析”处理：明确说明其成立的前提条件、适用的边界范围、与当前需求的具体关联，以及如何回到原始来源进行核对。原始材料与AI生成的摘要也必须严格区分。摘要可以帮助用户快速检索信息，但绝不能取代来源本身。特别是进行引用时，必须能够回溯到原文进行核对，不能将AI的概括伪装成原始表述。

第二部分：再规定分析步骤

如果仅仅要求AI“认真分析”，它会选择自己最擅长且最省力的方式。因此，需要明确指定几个不可跳过的关键动作：

• 将需求中的事实、目标、假设和方案进行拆解与分离
• 寻找相关依据并检查其适用条件是否满足
• 清晰解释需求信息与所引用依据之间的逻辑关系
• 主动暴露潜在的冲突、风险以及信息缺口
• 最终形成结论与下一步的行动建议

这些步骤的目的并非为了把产出物搞得更长更复杂，而是为了避免AI直接从输入跳跃到最终答案。这里，Skill的角色也在从“裁决评审官”逐渐转变为“思辨好伙伴”。它不负责替设计师决定“做”或“不做”，而是帮助设计师看清判断背后的前提条件，以及那些仍然悬而未决的问题。

第三部分：做最终检查

规则、要求、步骤被写入Skill，并不代表它们已经自动生效。真正的检查需要回答：依据仅仅是关键词相似关联，还是适用条件真正成立？是否清晰地解释了该依据为什么适用于当前的需求？引用内容能否方便地回溯到原始来源？对于那些没有找到依据的部分，是否已经明确标记为“未知”？

每次修改规则之后，必须使用历史案例和故意设置的错误样例重新进行测试。因为规则的正确性需要经过验证，而不是写完就算完成了。反复打磨和验证，这与AI应用开发中的评估思路是相近的：首先定义好行为标准，然后用具有代表性的数据来验证输出结果。

所以，Skill的真正价值不在于增加更多的提示词，而在于让判断依据、分析过程和检查方法可以被重复调用。也不是简单地给提示词不断打补丁，而是把依据、步骤和检查组织成一套可以稳定运行的分析流程。

好的需求分析，应该让团队看见什么？

当AI可以快速生成结论时，需求分析反而不应该只留下结论本身。如果只是输出一句“建议推进”或“需要重新考虑”，就会将整个判断过程压缩得扁平。一份高质量的分析，还应该帮助团队清晰地看到四件事：

1. 我们已经知道什么？ 需求材料中可以被确认的事实，例如用户反馈、使用场景、现有流程和明确的约束条件。AI可以帮助整理这些信息，但绝不能将自己的补充内容混入事实之中。
2. 我们正在假设什么？ 那些尚未被验证的判断。很多需求会将问题、目标和方案交织在一起写，分析需要将其中尚未验证的部分单独标识出来。只有先看见了假设，团队才能决定如何去验证它。
3. 我们凭什么得出当前判断？ 设计原则或历史经验不能仅仅因为听起来相关，就自动成为结论的依据。分析需要说明它究竟解决了什么问题、适用的条件是什么，以及为什么能够用于当前的需求。如果存在反面的证据或不同的观点，也应该同时呈现出来，供团队参考。
4. 下一步还要确认什么？ 还需要向谁确认信息、需要补充什么证据、哪个假设的错误成本最高，以及哪些决策在获得更多证据之前暂时不应推进。

需求分析不仅仅要交付结论，还要为团队保留继续验证和深入讨论的入口。AI最自然的动作是补全信息，但需求分析最需要的动作有时恰恰是“停下来”。承认“不知道”并不意味着分析失败。当不确定性被明确地表达出来时，它就从潜在的风险转变成了团队可以着手处理的工作任务。

在这里，设计师的角色也不仅仅是审核AI写得好不好，而是要决定哪些问题值得深入追问、什么证据足以支撑判断、谁的体验可能被遗漏，以及面对不同的价值和风险该如何进行取舍。

设计师真正沉淀下来的，是一种学习循环

这个Skill目前仍在搭建和打磨过程中，我不能确定这套思路就是最终的答案，它也会根据实践反馈继续迭代。但至少可以确认一点：让AI在明确的依据、步骤和边界内工作，比放任它凭借通用能力自由生成，更容易发现偏差和问题。这种约束的目的不是为了让答案变得僵化，而是为了让我们清楚它为什么这样判断，也知道在什么时候不应该完全相信它。

这段实践逐渐形成了一套“做中学”的循环：从真实的业务摩擦出发，选择一个最小的任务进行试验，密切观察输出的偏差，将有效的方法固化下来，再使用新旧案例进行重新验证。

每一次试错最好都能留下资产：一条问题记录、一个失败样例、一份可复用的模板、一张检查清单，或者一条被写进Skill的规则。工具会不断变化，但这些积累下来的经验能让下一次探索不再从零开始。

工具会变化，但从问题出发、用实验验证、把经验保留下来这种能力，是可以在实践中持续积累和增值的。

结语：AI 没有替设计师做判断，而是让判断过程变得清晰

这段实践得到的，并不是一个能够自动评审需求的标准答案。Skill的真正意义，在于将需求分析中那些相对稳定的步骤进行封装，让AI能够按照同一套流程来拆解信息、调用依据和检查结果；而需求分析本身的意义，则是辅助设计师更清晰地看清问题所在，而不是代替设计师去做最终的判断。

当AI越来越擅长生成内容，设计师依然需要深刻理解具体情境和真实用户，发现需求描述之外的问题，在不同目标之间做出有意义的取舍，并为最终的选择承担责任。AI可以快速整理信息，但它不知道哪一种产品体验更值得去做；它可以生成多种解释，却无法代替团队决定什么方向更符合产品的长期发展战略。

因此，在AI时代，设计师更像是一个问题的定义者、情境的解释者和价值的取舍者。不仅要学会使用AI，也要清楚应该向它提供什么依据、在哪些地方应该停下来思考，以及哪些关键的判断必须牢牢掌握在人的手中。

当生成答案逐渐成为一项基础能力时，设计师之间真正的差异，也许不在于谁能够更快地给出结论，而在于谁能够更早地发现：哪些是事实，哪些是假设，以及我们究竟还缺少什么关键信息。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：AI参与需求分析时，设计师在设计什么？要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题