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