Query Value Analysis
目的
通过分析一批 query，回答三个问题：
- 用户在什么业务场景下，有哪些具体需求；
- 哪些需求出现得足够多、足够急，值得优先解决；
- 线上已有产品或 Skill 能否解决这些需求，还需要推进哪些方向。
核心流程：
明确业务与场景 → 按 query 聚合需求并判断优先级/迫切程度 → 对照线上能力并识别建设方向
输入要求
优先收集以下信息；缺失时只追问当前步骤最关键的一项：
- 业务领域：例如广告、电商、客服、财务或 HR；
- 现有产品名称：例如腾讯广告、淘宝、小爱同学；
- query 数据：文本、用户标识、时间、会话标识，以及可用的回答/反馈信息；
- 现有一级业务场景：如果已经定义，优先复用；
- 分析范围：时间窗口、用户范围、需要排除的业务或关键词；
- 线上能力清单：产品功能、Skill、Agent、接口或已有人工流程。该信息在第三步使用，可以为空。
文件归档与命名
1. 文件夹层级
默认使用当前工作目录；如果用户指定目录，则使用用户指定目录。首次启用时，先创建根目录，再开始后续分析。
<指定目录或当前工作目录>/
└── LLM query 数据分析/
└── <业务领域-产品名称>/
├── 现有业务场景定义.md
├── 线上能力清单.md
└── YYYY-MM-DD-<项目理解>/
├── 01-数据来源与分析范围.md
├── 02-需求洞察.md
├── 03-线上能力对照.md
├── 04-线上能力建设优先级.md
└── <原始 Query 数据文件>
2. 创建规则
首次启用
- 检查目标目录下是否存在
LLM query 数据分析；不存在则立即创建。 - 根据业务领域或产品名称创建第二层级文件夹。
- 创建
现有业务场景定义.md和线上能力清单.md。 - 进入第一步前，先处理
现有业务场景定义.md：
- 用户已有一级业务场景时，引导用户提供并写入；
- 用户没有仔细分类时，先根据业务信息和样本生成一版初始一级业务场景，写入并标记为“待确认”；
- 用户核对确认后，才将其作为正式分类口径。 - 现有业务场景文档必须有内容，不能以空文档开始 query 分析。
非首次启用
- 复用已有的
LLM query 数据分析根目录和对应业务文件夹。 - 如果是新的业务领域或产品，创建新的第二层级文件夹，不复用其他业务领域的一级场景。
- 读取并复用该业务文件夹下的两个基础文档。
每次分析
首次启用完成根目录和业务文件夹初始化后，也必须按以下规则创建本次分析文件：
- 创建一个新的第三层级日期文件夹，不覆盖既有分析。
- 在第三层级文件夹中创建四个 MD 文件。
- 将本次原始 Query 数据文件复制到第三层级文件夹中作为存档。
3. 命名规则
- 第一层级固定命名为：
LLM query 数据分析。 - 第二层级使用业务领域或产品名称，例如：
广告、妙问、电商、客服、财务、HR。 - 第三层级使用：
YYYY-MM-DD-<项目理解>。 <项目理解>根据当前项目和本次分析目的生成；- 不包含日期时，整体控制在约 10 个汉字；
- 示例：
2026-09-03-妙问广告需求分析。 - 同一天有多次分析时，在末尾增加
-02、-03，不得覆盖已有文件夹。 - 分析文档使用固定序号和短名称，保持顺序稳定。
- 原始数据文件尽量保留原文件名；同名时追加
-原始存档，不得覆盖既有存档。
4. 第二层级的两个基础文档
现有业务场景定义.md
该文件必须非空，至少包含：
- 业务领域或产品名称；
- 一级场景名称；
- 场景定义；
- 典型需求；
- 纳入与排除边界。
如果用户没有现成分类，先生成初版并标记“待确认”。在用户确认前，不把初版当作最终统计口径，也不进入正式需求结论。
线上能力清单.md
该文件用于记录线上已有的：
- 产品功能；
- Skill 或 Agent；
- 接口、数据能力或已有人工流程；
- 能力的使用限制和适用范围。
该文件允许为空。若文件为空且上下文中也没有线上能力信息：
- 不自行推测或编造线上功能；
- 在后续
04-线上能力建设优先级.md中明确说明“线上能力清单为空，当前无法完成可靠的需求与功能对比”； - 告知用户，如需完成对比，需要补充线上功能、Skill 或相关产品背景。
5. 第三层级的第一个 MD 文件
01-数据来源与分析范围.md 必须记录：
数据来源索引
- 本次 Query 数据的原始地址：保留用户提供的本地路径、文件 URL 或其他来源说明；
- 当前分析目录中的原始存档路径；
- 原始文件名、文件类型和获取日期；
- 如果原始文件不可复制，记录原因，不伪造存档路径。
如果原始数据是可访问的本地文件，必须复制到本次第三层级文件夹中作为存档。
分析范围
- 时间周期；
- 分析条数；
- 样本范围；
- 去重规则；
- 排除条件；
- 统计口径；
- 主业务场景和辅助场景的标注规则。
核心流程
第一步：明确业务以及一级业务场景
- 确认本次分析的业务领域或产品。
- 读取对应第二层级的
现有业务场景定义.md。 - 如果已有一级业务场景，复用其名称、定义和边界。
- 如果没有仔细分类：
- 根据用户提供的业务背景和 Query 样本生成一版初始一级场景；
- 每个场景只定义四项：场景名称、场景定义、典型需求、纳入与排除边界；
- 将初版展示给用户核对，并根据反馈修改；
- 用户确认后写入现有业务场景定义.md，再进入第二步。 - 如果 Query 无法归入已有一级场景，不直接归入正式的“其他”：
- 先标记为候选新业务场景；
- 聚合并判断是否跨用户、跨周期稳定出现；
- 若形成稳定需求，补齐四项定义并请用户确认是否扩充一级场景；
- 尚未形成稳定需求的样本保留为待归类样本。
第二步：按 Query 整理，并根据内容和数量判断需求优先级与迫切程度
- 按已确认的一级业务场景对 Query 进行语义聚合，不脱离业务背景做关键词分类。
- 一个 Query 可以保留多个辅助场景，但必须标注一个主业务场景；主场景按用户最终希望获得的业务结果判断。
- 将相近 Query 聚合为具体需求。需求不是单条 Query，也不是“查数、生成、修改”等表面动作，而是用户在特定背景下要解决的问题。
- 一个具体需求至少满足：
- 有明确的业务角色和工作任务；
- 有明确的业务对象和目标结果；
- 出现频率足够高，或有充分证据表明它是重复性工作。 - 结合单条 Query 和上下文工作流，提取：
- 业务背景：在什么情况、阶段或触发条件下提出；
- 业务角色：谁在做这项工作；
- 业务对象：处理账户、素材、订单、客户、数据、合同等什么对象；
- 具体问题：当前遇到什么阻碍、异常或决策问题；
- 目标结果：希望得到什么判断、产物、动作或业务结果；
- 典型问法：用户实际如何表达；
- 工作流关系：前置数据、后续动作、是否与其他 Query 连续出现。 - 统计并记录：
- 同类 Query 的出现次数；
- 去重用户数；
- 是否跨多个日期或周期持续出现。 - 根据 Query 内容和数量判断：
- 优先级：需求的共性、覆盖用户数、出现次数和持续性越高，越值得优先产品化；
- 迫切程度：当前阻塞、明确时间节点、财务或合规风险、投放损失、客户交付压力、反复纠正等信号越强，越迫切。 - 优先级和迫切程度分别标记为高、中、低，并说明判断依据。不能只因单个用户反复提问，就认定为高优先级共性需求。
- 将结果写入
02-需求洞察.md。
02-需求洞察.md 的内容
结论
用两到三句话说明本次最重要的需求洞察。
典型需求场景
每个需求场景包含：
- 典型场景描述；
- 业务背景；
- 业务角色；
- 业务对象；
- 具体问题；
- 目标结果；
- 典型问法；
- 工作流关系；
- Query 数、去重用户数和跨周期情况；
- 优先级：高/中/低；
- 迫切程度：高/中/低；
- 10-15 个典型 Query 示意，样本不足时如实说明；
- 待验证内容。
第三步：将洞察需求与线上已有产品功能进行对比
- 读取第二层级的
线上能力清单.md，并结合上下文中用户提供的线上功能信息。 - 只对第二步确认的具体需求进行对比，不在需求尚未聚合时提前套用产品或 Skill 名称。
- 对每个重点需求确认：现在线上是否有产品功能、Skill、Agent、接口或人工流程可以解决。
- 将结果写入
03-线上能力对照.md，至少记录：
- 具体需求；
- 线上已有能力；
- 覆盖状态：完全覆盖、部分覆盖、需要组合、暂无能力、有能力但难使用、数据/权限受阻；
- 仍缺少的环节；
- 判断依据和待确认信息。 - 将后续推进方向写入
04-线上能力建设优先级.md，例如：
- 补充原子能力；
- 建设端到端工作流；
- 补充数据接入与归因；
- 改进 Skill 触发和使用体验；
- 补充领域知识与业务规则；
- 暂不建设，继续验证需求。 - 如果
线上能力清单.md为空且上下文没有相关信息，04-线上能力建设优先级.md必须明确写出：
- 线上能力清单为空；
- 当前只能完成需求洞察，不能可靠判断已有能力和能力缺口；
- 需要用户补充线上功能、Skill 或产品背景后，才能完成对比。
报告输出顺序
每次分析按以下顺序输出：
- 数据来源与分析范围；
- 一级业务场景（首次或变更时先让用户核对）；
- 具体需求洞察；
- 需求优先级与迫切程度；
- 线上能力对照；
- 线上能力建设优先级和待验证问题。
如果一级业务场景尚未确认，停止在第二项，不继续输出需求结论。
