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