Product Insight & Planning

1. 适用场景

• 一句话粗略需求（如"做一个内部知识库系统"）
• 粗略技术调研报告 / 行业研究 / 竞品分析
• 完善的产品需求文档（PRD）
• 业务方提供的"现状问题 + 目标用户 + 价值主张"摘要

不适用：纯技术实现方案、单点功能 bug 修复、UI 改版任务（这些归 analyzing-code-then-planning / frontend-design）。

2. 输出位置与命名

• 报告文件：docs/reports/YYYYMMDD_简要描述.md
• 文件名中的"简要描述"使用业务对象或主题词的中文短语（≤ 20 字）
• 同时在对话中给出 Markdown 摘要，便于复制
• 报告内容遵循第六节统一模板

3. 工作流（必须严格按顺序执行）

1. 输入理解：复读用户输入，识别
   - 业务背景 / 现状问题
   - 目标用户与典型场景
   - 价值主张 / 解决的核心痛点
   - 已知的输入类型（一句话 / 调研报告 / PRD）
2. 输入分级（决定后续展开深度）：
   - L1 一句话需求：信息量严重不足，先调用 product-and-technical-research skill 补足调研/竞品/约束，拿到"粗略技术调研报告"后再回到本 skill 走 L2 路径
   - L2 调研报告：抽取痛点、机会点、关键约束
   - L3 PRD：直接结构化整理
3. 业务视角优先：始终以"用户能做什么"而非"系统如何实现"来组织模块
4. 模块划分：按"用户旅程驱动 + 角色分离 + 价值导向 + 递进关系 + 闭环思维"五原则
5. 功能点拆解：使用第三节"功能描述标准模板"
6. 主流程 + UI 流程：使用第四、五节模板
7. 对抗性审查：使用第七节第一性原理 + 对抗性审查自检
8. 报告落盘：写入 docs/reports/YYYYMMDD_简要描述.md
9. 摘要输出：在对话中输出"产品定位 + 模块列表 + 关键决策"三段式摘要

3.1 L1 输入的特殊处理：内置调研

L1（一句话需求）信息密度太低，直接规划极易出现"自说自话"。强制执行以下两阶段：

阶段 A：内部调研（一阶段调用，对用户透明）
- 调用 product-and-technical-research skill，传入用户的原始一句话
- 调研至少覆盖：业务背景 / 目标用户画像 / 痛点假设 / 竞品参考 / 关键约束与风险 / 技术方案调研
- 产出"粗略技术调研报告"（可缓存为临时文件，不强制落盘 docs/reports/）

阶段 B：回到本 skill
- 将阶段 A 的调研报告视同 L2 输入，按 L2 流程产出最终产品规划报告
- 在最终报告的 frontmatter 中标注：
- 输入类型: L1一句话（已补调研）
- 输入来源: 用户原话 + 内部调研（product-and-technical-research）
- 在报告末尾"附录"中给出"调研结论摘要"小节，便于追溯

如果 product-and-technical-research 不可用或被用户拒绝，回退为：
- 列出"业务假设清单"（≤ 6 条）写到报告 frontmatter 之后的"业务假设"小节
- 在每个假设旁边标注"待用户确认"

4. 核心思维框架

4.1 业务视角 vs 技术视角

4.2 产品规划五原则

1. 用户旅程驱动：从用户使用产品的自然流程出发
2. 角色分离：区分"谁在用"和"谁在维护"
3. 价值导向：每个模块必须有清晰的业务价值主张
4. 递进关系：模块之间有逻辑上的先后或依赖
5. 闭环思维：每个用户任务都应有始有终

5. 功能模块划分的通用规约

【0. UI 设计概览】
  ├── 菜单结构（一级菜单 / 二级菜单）
  └── 页面布局（核心操作区 / 辅助信息区 / 状态反馈区）

【1. 业务模块】← 用户可见、可感知的功能集合
  ├── 模块名称（业务价值命名）
  │   ├── 核心业务主流程（端到端流程）
  │   ├── 核心业务 UI 交互流程（典型操作路径）
  │   ├── 功能 1
  │   │   ├── 功能点描述
  │   │   ├── 业务规则与流程
  │   │   └── 功能边界及联动关系
  │   └── 功能 2 ...
  └── 模块间关系（上下游依赖 / 数据流转）

【2. 系统管理模块】← 支撑性、管理性功能
  └── ...

6. 功能描述的标准模板

6.1 功能点描述

6.2 业务规则与流程

6.3 功能边界及联动关系

7. 核心业务主流程描述规范

【核心业务主流程：{流程名称}】

流程目标：{一句话说明用户要达成什么业务结果}
参与角色：{谁发起、谁参与、谁审批}

流程步骤：
  步骤 1：{动作} → {触发条件} → {预期结果}
  步骤 2：{动作} → {触发条件} → {预期结果}
  ...
  步骤 N：{动作} → {触发条件} → {最终结果}

分支 / 异常路径：
  - 条件 A → {替代路径}
  - 条件 B → {异常处理}

成功标准：{如何判定流程执行成功}

与其他模块的交互点：
  - 上游：从 {模块 X} 获取 {数据 / 事件}
  - 下游：向 {模块 Y} 输出 {数据 / 事件}

8. 核心业务 UI 交互流程描述规范

【核心业务 UI 交互流程：{交互流程名称}】

交互目标：{用户通过 UI 操作要达成的结果}
入口页面：{从哪个页面开始}

操作路径（用户视角的界面操作序列）：
  1. 页面 / 区域：{具体页面或 UI 区域}
     - 用户操作：{点击 / 拖拽 / 输入 / 选择等}
     - 系统响应：{页面变化 / 数据加载 / 状态反馈}
  2. 页面 / 区域：{下一个页面或区域}
     - 用户操作：{具体操作}
     - 系统响应：{具体响应}
  ...

关键 UI 元素：
  - {元素名称}：位于 {位置}，用于 {作用}
  - {元素名称}：位于 {位置}，用于 {作用}

状态反馈设计：
  - 加载中：{loading 状态如何展示}
  - 操作成功：{成功提示如何展示}
  - 操作失败：{错误提示如何展示，如何引导恢复}

交互约束：
  - {什么情况下按钮置灰}
  - {什么情况下弹出确认框}
  - {什么情况下自动跳转}

与其他 UI 模块的联动：
  - {触发什么导致其他区域刷新}
  - {选择什么导致其他菜单变化}

9. 报告标准模板（落盘到 docs/reports/）

---
创建时间: YYYY-MM-DD HH:MM
输入类型: [L1一句话 | L2调研报告 | L3PRD]
输入来源: {用户原话 / 文件名 / 链接}
状态: [已完成]
---

# {产品名称} — 产品定义与功能模块规划

## 1. 摘要
- 产品定位：
- 目标用户：
- 核心价值主张：
- 模块概览（一级模块列表 + 一句话价值）：

## 2. UI 设计概览
### 2.1 菜单结构
- 一级菜单：...
- 二级菜单：...
### 2.2 页面布局原则
- 核心操作区：
- 辅助信息区：
- 状态反馈区：

## 3. 业务模块划分
### 3.1 {模块 A}
- 业务价值：
- 核心业务主流程：
- 核心业务 UI 交互流程：
- 功能 1：{名称}
  - 功能点描述
  - 业务规则与流程
  - 功能边界及联动关系
- 功能 2：...
### 3.2 {模块 B}
- ...

## 4. 系统管理模块
- ...

## 5. 模块间关系图（文字描述）
- 上游 → 下游：
- 数据流转：

## 6. 对抗性审查记录
- 第一性原理复盘：
- 删除/简化的功能：
- 风险点：

## 7. 附录：术语表 / 关键决策 / 后续待办

10. 第一性原理与对抗性审查清单

完成报告后必须逐项自检：

10.1 第一性原理

• 本质问题：用户真正要解决的是什么？
• 不可约减的核心：去除所有修饰，剩下的最基本操作是什么？
• 验证：去掉任何一个环节，用户还能完成核心任务吗？

10.2 对抗性审查

• 这个功能是"用户想要的"还是"用户真正需要的"？
• 这个流程步骤是业务必需的，还是技术实现带来的妥协？
• 如果没有这个功能，用户会用什么替代方案？
• 替代方案是否更简单？

如发现冗余，将处理结论记录到报告"6. 对抗性审查记录"中。

11. 写作风格要求

• 使用业务语言，避免"解析引擎 / 存储层 / 中间件"等技术命名
• 模块名称用"动词+业务对象"或"业务对象 + 管理"
• 每个模块必须有"为什么存在"的一句话价值声明
• 报告内容只描述做什么和为什么，不写大段实现代码；如需示意，使用伪代码或结构化列表
• 报告整体长度建议 200-600 行 Markdown；超过 800 行需考虑拆分为多个产品域

12. 失败模式与纠正

• 输入是技术方案/架构设计 → 不调用本 skill，改用 analyzing-code-then-planning
• 输入是单点功能改造 → 改用 analyzing-code-then-planning
• 用户仅询问"是否值得做" → 仅输出一句话判断 + 关键风险，不展开完整报告
• L1 一句话输入 → 强制先内部调用 product-and-technical-research 补调研，再回到 L2 路径
• 输入信息严重不足（且调研 skill 不可用） → 主动列出"补充问题清单"（≤ 6 个问题），等待用户补充

与其他技能的关系