用户意图解析器Skill 用法详解

用户意图解析器Skill：把模糊需求变成可执行的结构化需求文档

• 一句话概括：它把「我想让用户能导出数据」这类口语化、碎片化的需求，解析成包含动作、对象、隐式假设、模糊点和接受标准的结构化需求文档。
• 核心能力：四步解析流程（提取明确语句 → 识别隐式需求 → 标记模糊之处 → 生成结构化格式），并为每条需求标注高/中/低置信度。
• 产出物：一份保存到 docs/specs/parsed-intent-{session}.md 的「解析意图文档」，可直接作为需求评审、开发排期和测试用例的输入。
• 最适合谁：产品经理、需求分析师、独立开发者、与 AI 协作写代码的工程师，以及经常接收非技术同事口头需求的团队成员。
• 最大差异点：不只是「总结需求」，而是主动暴露「没说的话」——隐式假设、模糊术语、缺失的量化指标，从源头减少返工。

该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能中文名：用户意图解析器Skill 技能英文名：user-intent-parser 技能ID：11832

它要解决的问题非常具体：需求的「入口」通常是模糊的。用户说「搜索太慢了」「让仪表板更好」，这些表达里包含动作、对象，也包含了用户没有说出口的期望（比如要快多少、在什么设备上、出错时怎么办）。传统做法是产品经理靠经验反复追问，或者在文档里写下带歧义的需求，等到开发阶段才发现理解偏差。用户意图解析器Skill 把这个「追问 + formalize」的过程标准化、可复现：它按照固定的四步流程拆解请求，并明确标注哪些是用户说的、哪些是它推断的、哪些必须回去澄清。

一键安装的思路与步骤（具体命令与入口请以官方说明为准）：

1. 确认前提：你需要一个支持 AI 技能（Skill）机制的环境，比如具备技能市场/技能库的 AI 编程助手或智能体客户端；同时本地项目具备写入 docs/specs/ 目录的权限，因为该技能的产物默认保存到该路径。
2. 找到技能：在技能市场或技能库中，通过中文名「用户意图解析器」、英文名 user-intent-parser 或技能ID 11832 检索（检索入口与字段支持情况以官方说明为准）。
3. 一键安装/启用：点击安装或启用按钮，将技能加入当前工作区或会话的技能列表。多数环境支持按项目启用，建议在需求梳理类项目中开启，避免无关会话被触发。
4. 验证是否生效：新建一个会话，输入一句模糊需求，例如「让用户能导出他们的数据」，观察返回结果是否包含「动作 / 对象 / 隐式需求 / 模糊之处 / 置信度」这些结构化字段，并检查是否生成了 docs/specs/parsed-intent-*.md 文件。若没有触发，通常是技能未在当前会话启用，或触发描述未匹配，具体排查方式以官方说明为准。

该技能的主要功能和特点

• 四步标准化解析流程：从「提取明确语句」到「生成结构化格式」，每一步都有明确检查项，避免解析过程随人（或随模型）漂移。
• 显式语句拆解：按「动作（动词）/ 对象（名词）/ 条件（何时、如果）/ 结果（以便）」四要素提取用户直接说出的内容，让需求从一段话变成可枚举的条目。
• 隐式需求识别：主动追问那些「假定但未陈述」的内容，包括是否需要身份验证、错误处理期望、性能期望、平台与设备支持、数据验证需求。这是它相对普通总结工具最关键的差异。
• 模糊之处标记：专门捕捉模糊术语（「快速」「良好」「简单」）、缺失的具体信息（数量、限制）、范围不清的边界、未定义的参与者，把「看起来很清楚其实没说清」的地方挖出来。
• 置信度分级：为每条需求分配高/中/低置信度——高=用户直接陈述（可进行）、中=强烈暗示（需确认）、低=推断假定（必须澄清）。这让下游团队知道哪条需求可以立刻开工、哪条必须等回复。
• 草拟接受标准：输出中直接包含接受标准的草稿，需求到验收之间不再是空白地带。
• 标准化产出与落盘：统一保存到 docs/specs/parsed-intent-{session}.md，按会话区分文件，天然形成需求变更的历史痕迹。
• 可集成的中间层：技能说明中明确了三个集成点——研究结果可以用于补全隐式需求、生成的模糊点可以直接喂给后续的提问/澄清环节、结构化输出可以作为需求验证的输入。

和普通「帮我总结一下这段话」的工具相比，它强在不给模糊需求打圆场：普通工具倾向于把模糊的地方用更漂亮的措辞掩盖过去，而这个技能的价值恰在于把模糊点逐条列出来并要求澄清。

如何使用该技能？

1. 准备输入：直接把用户的原始表述贴进来，不需要事先润色。可以是一句聊天记录、一段会议纪要、一条工单。例如：

   「用户反馈搜索太慢了，希望优化一下，最好在下个版本上线。」

2. 触发解析：在启用技能的会话中发出请求，明确说明希望做意图解析，例如「用用户意图解析技能处理下面的需求：……」。
3. 阅读四步解析结果：
   • 明确语句：动作=「优化搜索性能」；对象=「搜索结果页」；条件=「下个版本上线」；结果=「用户不再抱怨慢」。
   • 隐式需求：当前性能不可接受、需要设定目标响应时间、需要覆盖移动端。
   • 模糊之处：多慢算慢？目标速度是多少？数据量级多大？在什么网络环境下衡量？
   • 置信度：「需要提速」为高；「目标 1 秒内」为低（推断），必须澄清。
4. 处理低置信度条目：把标记为「低」的条目整理成澄清问题，回到需求提出方确认。技能说明中的常见模式已经给出了参考问法，例如针对错误报告型需求会追问「多慢？目标速度？」。
5. 确认文件产出：检查 docs/specs/parsed-intent-{session}.md 是否生成，内容是否覆盖原始语句、功能性需求、非功能性需求、假设及理由、待澄清模糊点、草拟接受标准。
6. 对照质量检查清单自检：所有明确动作是否已识别、对象/实体是否已命名、隐式需求是否已记录、模糊之处是否已标记、置信度是否已分配、草拟接受标准是否已创建。
7. 移交下游：把这份文档作为需求评审材料、任务拆分依据或测试用例编写输入。

输入示例（功能请求型）：

「我需要用户能够导出他们的数据。」

预期输出要点：动作=导出；对象=用户数据；参与者=用户（已认证）；隐式=导出格式未指定、需要权限校验；模糊之处=哪些数据？什么格式？导出量级上限？——这正是技能说明中给出的标准示例，可以直接用来验证技能是否工作正常。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
用户意图解析器Skill（user-intent-parser）	需求入口的结构化解析层	四步解析、隐式需求识别、模糊点标记、置信度分级、草拟接受标准、落盘为 Markdown	需在支持技能机制的环境安装启用，产物需 docs/specs/ 写入权限	模糊需求初筛、口头需求形式化、AI 协作前置澄清	优势：流程固定、输出可归档、主动暴露未说出口的假设；不足：仍需人工完成澄清与最终确认
通用大模型对话（直接提问）	通用问答	可总结、可改写、可追问	门槛最低，打开即用	临时性需求梳理	优势：灵活、零配置；不足：输出格式不稳定，容易「圆滑地」略过模糊点，不产生可归档的标准文档
需求管理工具内置模板（如工单/看板系统）	需求记录与流转	字段化表单、状态流转、协作评论	需要团队账号与流程配置	需求已相对明确后的管理与追踪	优势：协作与追溯能力强；不足：不负责「把模糊说法变清楚」，输入的模糊会被原样保留
人工需求评审会议	组织流程	面对面澄清、当场决策	需要协调多方时间	重大需求决策	优势：决策权威；不足：耗时、依赖主持者经验、结论若不落文档难以复用

选择建议：需求已明确，用工单/看板系统；需要权威决策，开评审会；需求还很模糊、需要先把话问清楚，用用户意图解析器Skill 做前置解析，再进入上述任一流程。

该技能的典型应用场景与实际体验情况

场景一：产品经理接收业务方的口头需求 业务方在群里说「让仪表板更好」。痛点是这种表述无法排期。使用技能后，输出会明确指出动作是「改进仪表板」，模糊点在于「哪些方面？视觉？功能？性能？」，并给出低置信度提示、需要大量澄清。实际体验：这类极模糊请求的解析结果价值最大——它把「无法执行」变成了一份可发给业务方逐条确认的问题清单。

场景二：独立开发者用 AI 写代码前的前置澄清 直接让 AI 写代码，常常得到「看起来对但不符合预期」的结果。先用本技能解析需求，把隐式需求（鉴权、错误处理、平台支持）显式写进文档，再交给编码环节。实际体验：上手几乎零成本，因为输入就是一句大白话；收益主要体现在减少返工，而不是加速单次生成。

场景三：把错误报告转化为功能需求 「搜索太慢了」本质是性能投诉，但需要变成可验收的需求。技能会把它解析为「提高搜索性能」，并识别出隐式前提「当前性能不可接受」，同时标记「多慢？目标速度？」两处必答项。实际体验：这类转化的关键提醒是——目标数值必须由人给出，技能只负责指出「这里缺一个数字」。

场景四：团队需求评审前的标准化准备 会前用技能批量解析一批原始需求，生成多份 parsed-intent-{session}.md。评审会上直接围绕「高置信度条目是否通过、低置信度条目由谁澄清」推进。实际体验：会议时长通常下降，但前提是团队接受「先看文档再讨论」的节奏。

注意事项：技能的产出是「解析结果 + 待澄清清单」，不是最终需求定稿；低置信度条目必须由人确认，不能直接当作结论使用。

该技能能为用户带来的价值

• 把隐性认知成本显性化：需求中最贵的从来不是写下来的部分，而是「双方都以为自己懂了」的部分。技能通过隐式需求识别和模糊点标记，把这类风险在动工前就摊开。
• 降低沟通门槛：非技术用户不需要学会写规范需求文档，只要正常说话；形式化的工作由技能完成。
• 缩短需求到开发的距离：输出中直接包含草拟接受标准，省去「需求写完还要再写一遍验收标准」的重复劳动。
• 标准化与可复用：固定的四步流程与统一的文件路径约定，让不同人、不同时间产出的需求文档结构一致，便于横向比较与历史追溯。
• 决策有依据：高/中/低置信度分级，让团队清楚哪些可以立刻开工、哪些必须等回复，避免「带着猜测开工」造成的返工。
• 长期价值：docs/specs/ 下按会话沉淀的解析文档，会逐渐形成一份可检索的需求决策档案，新人接手项目时能看懂「当初为什么这么定」。

常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ 在支持 AI 技能机制的环境里，通过中文名「用户意图解析器」、英文名 user-intent-parser 或技能ID 11832 检索并一键启用即可。安装入口、是否收费以及具体计费方式，以官方说明为准。

Q2：它会不会替我做决定、自己臆想出需求？ 不会直接当结论用。技能的设计是为每条需求分配置信度：用户直接陈述的标为「高」（可进行），强烈暗示的标为「中」（需确认），推断假定的标为「低」（必须澄清）。凡属推断的内容都会连同理由一起写进文档，由人来拍板。

Q3：适合谁用？技术人员用得上吗？ 产品经理、需求分析师用它做需求初筛和评审准备；开发者用它把模糊的用户反馈转成可实现的条目；独立开发者用它作为让 AI 写代码前的澄清步骤。只要你会收到「不太正式的需求描述」，它就有用。

Q4：和直接让大模型总结需求有什么区别？ 普通总结倾向于让文本更通顺，可能把模糊处一并「润色」掉；本技能的产出重点是标记不确定性——模糊术语、缺失的数量与限制、不清的范围、未定义的参与者都会被单独列出，并附上草拟接受标准，最终落盘为固定路径的文档。

Q5：输出保存在哪里？会不会覆盖之前的内容？ 默认保存到 docs/specs/parsed-intent-{session}.md，文件名按会话区分，不同会话产生不同文件。具体命名与覆盖行为以官方说明为准，建议纳入版本管理以便追溯需求变化。