借鉴 gstack 设计模式: - 8 条命令统一引入 Confusion Protocol(关键事实缺证据停止推理) - 假设验证路径 + 假设上限(≤5 条 active) - CWD 显式项目边界声明 - pos/uj 前置指令摘要(对标 gstack /context-restore) - ROADMAP 同步 + state_template 增强 - CHANGELOG v0.2.1
106 lines
4.7 KiB
Markdown
106 lines
4.7 KiB
Markdown
# /uj - 全链路用户旅程与流失分析
|
||
|
||
## 命令定位
|
||
还原用户从「第一次听说」到「成为忠实用户」到「可能流失」的完整
|
||
行为路径,标注每个节点的情绪曲线、决策障碍和流失原因。
|
||
|
||
## 第 0 步:加载项目状态
|
||
|
||
执行本指令前,先读取项目根目录下的 `.yxstack/_state.md`(如果项目 CODEBUDDY.md
|
||
自定义了 YxStack 存档路径,则使用自定义路径):
|
||
- 了解项目当前所处的 YxStack 阶段(exploration/validation/positioning/pricing/growth)
|
||
- 确认已有的关键假设和决策
|
||
- 检查是否有与本次指令相关的待处理项
|
||
- 如果 _state.md 不存在,说明这是项目首次使用 YxStack
|
||
|
||
然后按原有规则检查历史记录:
|
||
|
||
执行本指令前,先检查当前项目根目录下的 `.yxstack/` 目录(如果项目 CODEBUDDY.md
|
||
自定义了 YxStack 存档路径,则使用自定义路径),查找近期同指令(uj)的历史记录:
|
||
- 如果有同类用户旅程分析 → 标注与历史结论的差异/更新点
|
||
- 如果历史已有流失节点结论 → 追问"当前数据跟当时比有什么变化?"
|
||
- 如果没有历史记录 → 跳过,正常执行
|
||
|
||
### 前置指令摘要
|
||
读取 `.yxstack/` 中最近 pfit(痛点验证)+ pos(产品定位)记录,提取:
|
||
- 已验证的痛点结论(来自 pfit)
|
||
- 已确认的产品定位(来自 pos)
|
||
- 旅程分析应基于已知痛点和定位,而非重新猜测用户卡点
|
||
|
||
### Confusion Protocol(假设暴露)
|
||
在执行本指令时,遇到以下情况停止推理,转为追问用户:
|
||
- 对用户业务场景的关键事实在猜测而非确认
|
||
- 对市场/用户行为的判断缺少定量或定性证据
|
||
- 在多个不相容假设之间跳转(信号:假设 > 3 个未验证)
|
||
|
||
激活时机:上述任一条触发时,列出已知/未知,追问缺失信息,不继续产出。
|
||
|
||
## 核心追问清单
|
||
|
||
### 1. 旅程阶段划分
|
||
- [ ] 用户是怎么第一次知道你的?(渠道、口口相传、广告、搜索)
|
||
- [ ] 从知道到第一次使用,中间隔了多久?最大障碍是什么?
|
||
- [ ] 用户第一次用完后的感受是什么?(惊喜、疑惑、失望)
|
||
|
||
### 2. 关键决策点
|
||
- [ ] 在哪个环节用户会决定「继续用」或「放弃」?
|
||
- [ ] 每个决策点上用户的评估标准是什么?
|
||
- [ ] 有没有「关键魔法时刻」(Aha Moment)?
|
||
|
||
### 3. 流失节点排查
|
||
- [ ] 当前用户主要在哪一步流失?(按数据排前三)
|
||
- [ ] 流失用户离开前做了什么?有没有共性行为?
|
||
- [ ] 流失用户去了哪里?(竞品、回到旧方案、彻底放弃这类需求)
|
||
|
||
### 4. 重激活路径
|
||
- [ ] 已流失用户有没有自然回流的?为什么?
|
||
- [ ] 用什么触点可以拉回流失用户?成本多高?
|
||
|
||
## 输出结构
|
||
1. **旅程全景图**:阶段 × 行为 × 情绪曲线
|
||
2. **关键决策点**:每个节点的用户心理 + 当前满足度
|
||
3. **流失断点 Top 3**:排名 + 根因 + 数据依据
|
||
4. **破局建议**:最应该修复的节点和可操作动作
|
||
|
||
## 常见误区
|
||
- 用自己的行为推演用户(你是超级用户,他不是)
|
||
- 只看「用的人」不看「没用的人」(沉默证据偏差)
|
||
- 没有区分不同用户类型的旅程差异
|
||
|
||
## 存档规则
|
||
|
||
执行完毕生成报告后,按以下规范存档:
|
||
|
||
**默认路径**:`{项目根目录}/.yxstack/uj-{日期}-{一句话摘要}.md`
|
||
(如果项目 CODEBUDDY.md 自定义了 YxStack 存档路径,优先使用自定义路径)
|
||
|
||
**格式**:YAML frontmatter + 报告正文
|
||
```yaml
|
||
---
|
||
title: "{一句话标题}"
|
||
author: "{执行者}"
|
||
date: "{YYYY-MM-DD}"
|
||
tags: ["关键词1", "关键词2"]
|
||
status: draft # draft → validated → outdated
|
||
---
|
||
```
|
||
|
||
## 更新项目状态
|
||
|
||
### 追加事件日志
|
||
向 `.yxstack/_timeline.jsonl` 追加一行:
|
||
```json
|
||
{"skill":"uj","event":"completed","ts":"当前时间","phase":"当前阶段","summary":"本次产出核心结论","assumption":"本次新增假设(有则填,无则留空)","decision":"本次关键决策(有则填,无则留空)"}
|
||
```
|
||
|
||
### 更新状态快照
|
||
更新 `.yxstack/_state.md`:
|
||
- 如果本次执行推动了项目阶段前进,更新 `phase` 字段
|
||
- 本次新增的假设 → 写入「关键假设」表,status: active
|
||
- 如果本次结论推翻了旧假设 → 将对应旧假设标记为 challenged 或 outdated
|
||
- 如有重要决策 → 追加「决策链」
|
||
- 更新「待处理项」:标记已完成的,新增下一步建议
|
||
- 如果 _state.md 不存在,按模板创建(参考 templates/state_template.md)
|
||
- 每个 active 假设必须附带验证标准(一句话:用什么证据可证实/证伪)
|
||
- 同时 active 假设不超过 5 条,达到上限时必须先标记一条旧假设为 outdated 才能新增
|