back
loading skill details...
帮助 PM 在需求启动阶段,通过三步对话法(苏格拉底→第一性→奥卡姆)拆清问题本质, 产出可进 review 的 PRD v3.x 终稿。支持按需裁剪章节、按需启用场景定位/Agent 设计/学习循环等可选阶段。 输出优先飞书文档,降级本地 MD。
---
name: pm-requirement-sharpening-stone
name_zh: 需求磨刀石
version: 2.0.0
description: |
帮助 PM 在需求启动阶段,通过三步对话法(苏格拉底→第一性→奥卡姆)拆清问题本质,
产出可进 review 的 PRD v3.x 终稿。支持按需裁剪章节、按需启用场景定位/Agent 设计/学习循环等可选阶段。
输出优先飞书文档,降级本地 MD。
scope: cn,international
not_for:
- 不直接写代码或技术方案
- 不做 UI 设计或原型图
- 不处理已有明确规范的执行型任务(如"按设计稿写前端")
- 不替代人工拍板业务决策
examples:
- 帮我写一份 PRD
- 启动一个新项目的需求,帮我从头梳理
- 帮我跑完整流程,从场景定位到分期规划
- 写个迭代 PRD,我有上期版本
---
# 操作说明
## 操作一：三步对话拆解
- **功能**：用苏格拉底→第一性→奥卡姆三步,把模糊需求拆成清晰骨架
- **输入**：用户的项目背景(一句话或一段描述均可)
- **输出**：真实目标一句话 + 1-3 个必要条件 + 精简后的功能清单 + 不做清单
## 操作二：PRD 产出
- **功能**：按章节裁剪表产出 PRD v1.0,迭代到 v3.x 终稿
- **输入**：三步对话产出 + 物料(参照物料/数据分析/继承清单)
- **输出**：飞书文档格式的 PRD v3.x(章节按需裁剪)
## 操作三：多角色 Review
- **功能**：四端(服务端/客户端/测试/设计)并行 review,分级反馈闭环
- **输入**：PRD v2.x
- **输出**：review 反馈汇总 + PRD v3.x 终稿 + 决策记录
## 操作四：场景定位(Agent 产品专用)
- **功能**：交互模型选型 + 核心场景设计 + PageContext 协议
- **输入**：产品方向描述
- **输出**：交互模型决策 + 场景故事线 + PageContext 字段清单
## 操作五：Agent 交互设计(Agent 产品专用)
- **功能**：三步确认链路 + 交互状态机 + 快捷工具设计
- **输入**：PRD v3.x
- **输出**：交互设计文档 + 状态机 Mermaid 图
## 操作六：学习循环 + 分期(Agent 产品专用)
- **功能**：日志架构 + 经验库三层设计 + P0-P3 分期规划
- **输入**：PRD v3.x + 交互设计
- **输出**：日志规范 + 经验库设计 + 分期规划文档
# 工具定义
本 Skill 为**纯流程编排型**,不直接调用 MCP 工具。依赖以下内置能力：
| 能力 | 用途 | 来源 |
|------|------|------|
| 飞书文档创建 | PRD 输出载体 | feishu_lark_cli |
| WebSearch | 竞品信息抓取(物料补全) | web_access_tool |
| 本地文件读写 | 降级输出 + 经验沉淀 | 内置 |
---
# 需求磨刀石 v2
> **一句话**:让 PM 的第一版 PRD 少返工 50%。从命题到可交付的 PRD 终稿,6 个 Stage 按需裁剪。
## 使用方式
**按需启用 Stage**,不用全跑。默认启用 Stage 1-3(三步对话 → PRD 产出 → Review),其余按需叠加:
| Stage | 名称 | 何时启用 |
|-------|------|----------|
| 0 | 场景定位 | 做 Agent 产品时必须;非 Agent 项目可跳过 |
| 1 | 三步对话 | **默认启用**,任何 0→1 产出的起点 |
| 2 | PRD 产出 | **默认启用**,三步对话产出后接续 |
| 3 | 多角色 Review | **默认启用**,PRD 写完必走 |
| 4 | Agent 交互设计 | 做 Agent/Copilot 产品时启用 |
| 5 | 学习循环 + 分期 | Agent 产品需要长期迭代时启用 |
**快速启动**:跟用户说"帮你写 PRD"→ 自动启用 Stage 1-2-3。
**完整流程**:跟用户说"帮我跑完整流程"→ 全部启用。
**输出格式**:所有文档产出**优先飞书文档**,降级写本地 MD。PRD 文档章节支持按需裁剪(Phase 2.3 会先让你勾选需要的章节)。
---
## 输入参数
本 Skill 接受以下可选输入(不提供则在运行中追问):
| 参数 | 说明 | 默认值 |
|------|------|--------|
| project_name | 项目名称 | 运行中追问 |
| project_type | new(0→1) / iteration(迭代) / hotfix(修复) | 运行中判断 |
| stages | 启用哪些 Stage,如 `1,2,3` | `1,2,3` |
| output_format | feishu(飞书文档) / local(本地 MD) | feishu |
| prd_chapters | PRD 章节裁剪列表,如 `0,1,2,3,7,14,15` | 默认全选必选章节 |
| existing_prd | 已有 PRD 链接(迭代场景) | 无 |
**触发示例**:
- `帮我写 PRD` → 自动走 Stage 1-2-3
- `跑完整流程` → 全部 Stage
- `写个迭代 PRD` → Stage 1-2-3 + 自动识别为迭代模式
---
## 错误处理与边界情况
| 异常场景 | 处理方式 |
|----------|----------|
| 用户说“你先列一个吧”(不愿回答三步对话) | 不替用户答,给出候选选项让用户拍板,不能跳过 |
| 物料严重不足(3 类全缺) | 列补料清单 + 责任人 + deadline,不强行推进 PRD |
| 三步对话拆不出必要条件(目标本身模糊) | 退回,建议用户先找业务方对齐目标 |
| Review 反馈 > 20 条 | PRD 还没稳定,拆成多次小 review |
| “待确认”连续 2 轮清不掉 | 强制升级:列出未决项 + 责任人 + deadline,推业务方 |
| 用户中途要跳阶段 | 允许,但记录跳过项,后续阶段提醒补 |
| 飞书文档创建失败 | 降级写本地 `knowledge-base/product/` |
---
## 前置条件
- ✅ 用户能描述项目背景(哪怕是模糊的一句话)
- ✅ 有基本的飞书文档权限(如选飞书输出)
- ❌ 不需要已有代码/设计稿/技术方案
- ❌ 不需要特定工具或环境
## 全景流程图
```
┌──────────────────────────────────────────────────────────────────────┐
│ 需求磨刀石 · 按需裁剪 │
├──────────┬──────────┬──────────┬──────────┬──────────┬──────────────┤
│ Stage 0 │ Stage 1 │ Stage 2 │ Stage 3 │ Stage 4 │ Stage 5 │
│ 场景定位 │ 三步对话 │ PRD 产出 │ 多角色 │ Agent │ 学习循环 │
│ (可选) │ (默认) │ (默认) │ Review │ 交互设计 │ + 分期 │
│ │ │ │ (默认) │ (可选) │ (可选) │
├──────────┼──────────┼──────────┼──────────┼──────────┼──────────────┤
│ 交互模型 │ 苏格拉底 │ 物料准备 │ 四端并行 │ 三步确认 │ 日志→AI汇总 │
│ 核心场景 │ →第一性 │ 4步推进 │ 反馈闭环 │ 状态机 │ →人工标注 │
│ 上下文 │ →奥卡姆 │ 门禁控制 │ 角色Agent │ 快捷工具 │ →经验沉淀 │
│ 设计 │ │ 产出PRD │ 人工定稿 │ │ P0-P3分期 │
└──────────┴──────────┴──────────┴──────────┴──────────┴──────────────┘
↓ ↓ ↓ ↓
G0 通过 G1 通过 G2 通过 G3 通过
```
**门禁依赖图**:
```
G0 场景定位(可选) → G1 三步对话 → G2 PRD v1.0 → G3 四端 Review → G4 PRD v3.x 终稿
↓
G5 Agent 交互设计(可选)
↓
G6 学习循环设计(可选)
↓
G7 P0-P3 分期规划(可选)
```
---
## 通用机制
### 门禁原则(Gate-based)
本流水线所有 Stage 采用 **Phase + 门禁** 机制:不过闸不下一步。每步有明确产出和通过标准。
- ✅ = 通过条件满足
- ❌ = 不满足,停下补或重做
- 不接受"后面补"--后面补 = 永远不补
### 日志规范
每个 Stage 完成后写入 `experience-base/raw/` 目录:
```json
{
"timestamp": "ISO 8601",
"stage": "stage-0/1/2/3/4/5",
"project": "...",
"mode": "new | iteration | hotfix",
"outcome": "...",
"gate_passed": true
}
```
---
## Stage 0: 场景定位（可选）
> 来源：agent-scenario Skill
> 🎯 **目标**：选准交互模型 + 定义核心场景 + 设计上下文协议，避免做成“能聊天但没价值”的鸡肋。
> **何时启用**：做 Agent/Copilot 产品时必须；传统 Web/App 项目可跳过。
### Phase 0.1: 交互模型选型
三选一:
| 交互模型 | 适用 | 上下文感知 | 落地难度 |
|---|---|---|---|
| **IM 机器人** | 跨系统查询 / 简单提醒 | 从零理解,需大量追问 | 低 |
| **内嵌后台 Copilot** | 配置 / 操作 / 复杂表单 | 页面即上下文,意图识别易 | 中 |
| **独立工具** | 专业工具场景 | 自定义上下文 | 高 |
**一句话规则**:有现成后台就做内嵌 Copilot,没后台就做 IM 或独立。
**🚧 门禁**:
- ✅ 交互模型唯一确定
- ❌ "都做" / "看情况切换" → 一个产品先定一个模型
### Phase 0.2: 核心场景设计
每个场景必须完整描述 3 要素:
1. **谁**:用户画像(角色 + 经验水平 + 使用频率)
2. **什么时候做什么**:触发时机和具体动作
3. **为什么用 Agent 而不是原有方式**:Agent 带来的价值
**场景模板**:
```markdown
## 场景 1: {场景名}
**用户画像**: {角色}, {经验水平}, {使用频率}
**触发时机**: {具体触发场景}
**具体动作**:
- 用户: {用户输入}
- Agent: {Agent 自动执行的步骤}
**Agent 带来的价值**: {具体提效数据,如"10 分钟→1 分钟"}
**不做什么(YAGNI)**: {明确砍掉的}
```
**场景数量控制**:P0 必做 1 个,P1 跟进 1-2 个,超过 3 个砍。
**🚧 门禁**:
- ✅ 至少 1 个完整场景(3 要素齐全)
- ✅ 有"不做什么"清单
- ❌ 场景 > 3 个 → 砍
- ❌ "所有用户都能用" → 必须画像具体
### Phase 0.3: 上下文设计(PageContext 协议)
Agent 必须拿到的上下文,决定意图识别复杂度:
```typescript
PageContext {
page_type: schedule | coupon | resource_slot | campaign | ...
filters: 当前筛选条件(键值对)
selected_items: 当前选中的行(可选)
form_state: 如果有打开的表单,当前表单状态(可选)
user_locale: 用户界面语言
user_timezone: 用户本地时区
target_country: 目标市场国家
target_region: 目标市场区域
currency: 当前币种
}
```
| 上下文丰富度 | 意图识别难度 | 追问次数 |
|---|---|---|
| 零上下文(IM 机器人) | 高 | 5-10 次 |
| 页面级上下文(内嵌) | 低 | 0-2 次 |
| 选中级上下文(内嵌 + 选中) | 极低 | 0 次 |
**关键**:页面/选中/筛选即上下文。用户说"排春促",Agent 已知"西班牙 / 未来时段 / 筛选空"。
**🚧 门禁**:
- ✅ PageContext 字段清单完整
- ✅ 核心场景的追问清单明确
- ❌ "Agent 自己猜" → 必须明确上下文来源
### 产出物
1. 交互模型决策 + 决策矩阵
2. 1-3 个核心场景(完整故事线)
3. PageContext 协议字段清单
4. 每个场景的追问清单
---
## Stage 1: 三步对话法（默认启用）
> 来源:socratic-dialogue Skill
> 🎯 **目标**:在任何产出前,用苏格拉底→第一性→奥卡姆三步引导,避免 AI 写出"漂亮废话"。
### 核心铁律
> **别让 AI 直接开始写。** 上来就写 = 写一堆看起来合理但无锚点的内容。先用 3 步把问题拆清楚。
### 适用场景
任何从 0 到 1 的产出启动时:PRD、技术方案、Agent 设计、架构设计、分享文档、复盘报告、工作计划。
**不适用**:已有明确规范的执行型任务(如"按设计稿写前端"、"修这个 bug")。
---
### Step 1 苏格拉底(问真问题)
**给用户的指令**:
> 动笔前,我先请你回答 5 个问题。不用每题都完美,但至少要认真想过。
> 1. **真实目标**:你要解决的真正问题是什么?(不是"提升转化率"这种结果指标,是"用户/业务实际遇到的什么痛)
> 2. **不做什么**:这次**明确不做**的事情有哪些?(砍得越清楚,后面越不混乱)
> 3. **用户真实痛点**:用户遇到了什么具体场景?最好有 1-2 个真实故事
> 4. **成功衡量**:怎么算成功?(指标 + 目标值 + 衡量方式)
> 5. **失败接受标准**:什么情况你能接受失败/砍掉?(你的底线在哪)
**产出**:真实目标一句话 + 不做清单 + 用户痛点 + 成功/失败标准。
**🚧 门禁**:
- ✅ 5 个问题全部有明确答复(不能是"待定 / 看后面")
- ✅ **真实目标**不能是"提升 X%" 这种结果指标,必须是"用户/业务的 Y 问题"
- ❌ 用户说"你先列一个吧" → 不要替用户答,追问"我帮你列候选,但最终要你拍板"
---
### Step 2 第一性(拆到本质)
**给用户的指令**:
> 忘掉线上现在怎么做。从刚才定的**真实目标**倒推:
> - 要实现这个目标,**最少**需要几个必要条件?(建议 ≤3 个)
> - 每个条件现在满足多少?
> - 哪个条件是最大瓶颈?
**原则**:
- 条件必须是"必要"的,不能是"应该有"
- AI 提候选,**最终由用户拍板**
- 典型 trap:AI 会编"应该做个性化推荐"这种合理但非必要的条件
**产出**:1-3 个必要条件 → 这是未来产出物的骨架。
**🚧 门禁**:
- ✅ 必要条件 ≤ 3 条
- ✅ 每条都能回答"砍了它,真实目标还能达成吗?" → 答"不能"才是必要
- ❌ AI 自己定义必要条件,用户没拍板 → 退回
- ❌ 超过 3 条 → 大概率有非必要项,合并或砍
---
### Step 3 奥卡姆(砍到最简)
**给用户的指令**:
> 现在我们有了骨架。接下来每个模块/字段/交互,**都问一遍**:
> "砍掉这个,核心目标还能达成吗?能 → 砍。"
**执行方式**:
1. 列出所有当前计划包含的模块/功能/字段
2. 逐条提问:砍了会怎样?
3. 能砍的画叉,不能砍的标"核心"
4. **回头看一眼**:砍完后"必要条件"还全部满足吗?状态机闭环吗?
**典型收益**:某 B 端中台项目砍掉积分货币/补签卡/签到后数值/吸底栏二级 CTA → 篇幅 -30%,研发可实施度 +100%。
**🚧 门禁**:
- ✅ 每个模块都回答过"砍了会怎样"
- ✅ 砍完回头看过一眼,必要条件仍然满足
- ❌ 砍破坏了状态机闭环 → 退回,这个不能砍
- ❌ 一个都没砍 → 质疑:真的每个都必要吗?再过一遍
---
### 完整示例
**用户需求**:做个签到积分系统,提升用户活跃度。
**Step 1 苏格拉底**:
- 真实目标?→ 用户答:其实是想做一个状态自适应的社区入口,积分只是吸引器
- 不做什么?→ 用户答:不做复杂货币体系、不做社交分享
- 用户痛点?→ 用户答:新用户/活跃用户看到的入口一样,没有区分
- 成功衡量?→ 用户答:活跃用户入口点击率 +15%
- 失败标准?→ 用户答:如果活跃用户点击率没变化,就砍掉
**Step 2 第一性**:必要条件 3 条:位置不变 / 状态可判定 / 每个模块对每个状态有明确策略
**Step 3 奥卡姆**:砍掉积分货币、补签卡、签到后数值、吸底栏二级 CTA → 篇幅 -30%,PRD review 一次过。
### 产出物
1. 真实目标一句话
2. 1-3 个必要条件
3. 精简后的模块/功能清单
4. 明确的"不做"清单(YAGNI)
---
## Stage 2: PRD 产出（默认启用）
> 来源:pm-requirement Skill
> 🎯 **目标**:从"命题"到"能进 review 的 PRD v1.0",少 50% 返工。
### PM 的 3 大陷阱
1. **跳过苏格拉底直接动笔** -- AI 产出一堆漂亮废话
2. **继承逻辑不写清** -- 研发默认全部新建,估期翻倍
3. **"必须澄清"项自己推断** -- 核心规则建在假设上,review 阶段大返工
---
### Phase 2.0: 项目识别(入口分流)
判断场景类型,决定走完整流程还是轻量流程:
| 场景 | 判断依据 | 走法 |
|---|---|---|
| 🆕 0→1 新项目 | 没有已有系统、没有上期 PRD | 完整流程 |
| 🔄 迭代需求 | 有已有系统、有上期 PRD/版本索引 | 轻量流程 |
| 🔧 优化/修复 | 小改动、不涉及新功能模块 | 极简流程 |
**🚧 门禁**:
- ✅ 场景类型已确认
- ✅ 迭代场景下:项目版本索引已存在或已创建
- ✅ 迭代场景下:上期 PRD 链接/位置已确认
#### 迭代模式简化规则
| 物料类型 | 0→1 要求 | 迭代要求 |
|---|---|---|
| 参照物料 | 必须齐全 | 仅补本期新增功能相关的竞品/线上对比 |
| 数据分析 | 完整漏斗 | 仅补本期关注指标的数据现状 |
| 继承清单 | 从零列 | 从上期 PRD 自动生成 diff(新增/修改/废弃/不变) |
**迭代继承清单**:
```markdown
| 上期功能模块 | 本期决策 | 变更说明 |
|---|---|---|
| 优惠券创建 | 不变 | - |
| 优惠券分发 | 修改 | 加批次化能力 |
| - | 新增 | 多语言编辑器(本期新模块) |
```
#### 优化/修复模式(极简流程)
1. 确认改动内容(一句话描述)
2. 直接在原 PRD 文档追加/修改对应 7.N 章节
3. 更新版本索引(记录一行)
4. 不走三步对话、不走完整门禁
---
### Phase 2.1: 物料准备(质量决定上限)
**3 类物料**:
| # | 物料类型 | 内容 | 常见坑 |
|---|---|---|---|
| 1 | 参照物料 | 竞品截图 + 线上截图(带状态标签) | 竞品和"想做的"混在一起 |
| 2 | 数据分析报告 | 竞品信息架构 + 线上漏斗/状态差异 | 口径偷换(UV vs PV) |
| 3 | 线上知识库 | 功能逻辑 + 策略逻辑 + 继承清单 | 只写新功能不写继承 |
**操作**:问用户 3 类物料有哪几类 → 缺的列出来问怎么补 → 标注质量等级。
**🚧 门禁**:
- ✅ 3 类物料齐全(每类至少 1 份具体内容)
- ✅ 数据口径已对齐(显式说明"这里 UV" / "那里 PV")
- ✅ 继承清单已列好(继承/修改/不做三列)
**不接受的"完成"声明**:
- ❌ "物料后面补"
- ❌ "我都记在脑子里"
- ❌ "继承逻辑开发会知道"
#### 物料缺失时的补料方案
**物料 1(参照物料)缺失**:用 WebFetch/WebSearch 抓取竞品公开信息,自动分类打标签。需要用户给 3-5 个对标竞品名称 + 线上产品截图。
**物料 2(数据分析)缺失**:口径不对齐 → 列出所有"核心数据点",逐个标注 UV/PV/DAU/其他,冲突让用户选统一口径。
**物料 3(继承清单)缺失**:读取现有代码仓库总结已有功能,模板化输出三列。
**补料优先级**:P0 物料 3 → P1 物料 2 → P2 物料 1
---
### Phase 2.2: 三步对话拆解
> 复用 Stage 1 的三步对话法逻辑,这里不再重复。详见 Stage 1。
调用 Stage 1 完成后,产出真实目标 + 必要条件 + 精简方案。
**🚧 门禁**:
- ✅ 真实目标一句话
- ✅ 必要条件 ≤ 3 条
- ✅ 不做清单已列
- ✅ 已砍一轮,状态机仍闭环
---
### Phase 2.3: 产出 PRD v1.0(骨架 + 占位)
**📄 输出载体**:所有产出**优先飞书文档**(`doc_create`),降级写本地 `knowledge-base/product/`。
---
**PRD 章节按需裁剪**:
不是每个项目都需要全部章节。先跑「章节裁剪」再写内容:
| # | 章节 | 默认 | 何时需要 |
|---|------|------|----------|
| 0 | 文档元信息 | ✅ | 始终 |
| 1 | 执行摘要 | ✅ | 始终 |
| 2 | 项目背景与目标 | ✅ | 始终 |
| 3 | 用户故事 / 使用场景 | ✅ | 始终 |
| 4 | 信息架构 | ✅ | 默认含;纯后端项目可砍 |
| 5 | 业务流程图 | ✅ | 默认含;单角色简单流程可砍 |
| 6 | 数据规则 / 字段定义 | ⬜ | 涉及数据模型变更时 |
| 7 | 功能详述(7.N 五子章节) | ✅ | 始终 |
| 8 | 非功能需求(性能/安全/合规) | ⬜ | 有明确指标要求时 |
| 9 | 继承清单(已有逻辑 diff) | ⬜ | 迭代项目,非 0→1 |
| 10 | 设计约束 / 视觉规范 | ⬜ | 有设计稿或品牌规范时 |
| 11 | 第三方依赖 | ⬜ | 涉及外部系统/API 对接时 |
| 12 | 灰度 / 上线方案 | ⬜ | 大范围变更或高风险项目 |
| 13 | 数据埋点需求 | ⬜ | 需要数据验证效果时 |
| 14 | 变更记录 | ✅ | 始终 |
| 15 | 待确认项 | ✅ | 始终 |
**裁剪操作**:
1. 列出上表给用户勾选(默认已勾的 + 用户额外勾的)
2. 未选中的章节不写,不占篇幅
3. 飞书文档目录结构只包含选中的章节
**每个功能模块 7.N 五子章节**:
1. 系统侧规则
2. 状态流转
3. 边界处理
4. 异常处理
5. 明确不做
**R1-R6 硬规则**:
| 规则 | 自检 | 常见违反 |
|---|---|---|
| R1 禁止自造词 | 所有词都是通用语言或术语表已定义 | "抽屉收起态下插卡逻辑" |
| R2 边界条件显式 | 每模块覆盖 6 类边界 | "网络异常时展示兜底" |
| R3 前后端分离描述 | 分别描述用户侧行为和数据侧规则 | 混写"前端调 /api/xxx" |
| R4 状态机 6 列 | 含"禁止转换"列 | "支持多状态切换" |
| R5 数值 4 维 | 值+单位+区间+可配置性 | "长按触发选中" |
| R6 AI 可读 | Figma 链接配 Mermaid/文字描述 | 只贴 Figma 链接 |
**PRD 职责边界(What vs How)**:
| ❌ PRD 不写 | ✅ PRD 要写 |
|---|---|
| 接口设计(URL/字段名/请求格式) | 业务数据规则 |
| 数据库表结构 | 数据实体关系 |
| 技术选型建议 | 性能期望("用户可感知的,如 < 3 秒") |
| 前后端分工方案 | 用户侧行为 vs 系统侧规则的分别描述 |
| 数据流转实现方式 | 第三方系统依赖说明 |
**🚧 门禁**:
- ✅ 必保章节存在(0/1/2/3/7/14/15)
- ✅ 每个功能模块五子章节齐全
- ✅ 不含技术实现细节(接口/表结构/技术选型)
- ✅ 飞书文档已创建,章节结构清晰
- ❌ 含"大概 / 似乎 / 可能" → 给具体数值或标"待确认"
- ❌ 出现接口名/字段名/技术方案 → 删除,改为业务规则描述
---
### Phase 2.4: v2+ 迭代(收敛"待确认"到 0)
| 版本 | 关注点 |
|---|---|
| v1.0 | PRD 模板骨架完整,含占位 |
| v1.x | 业务流程 + 状态机 + 信息架构填实 |
| v2.x | 业务数据规则 + 异常路径 + 继承清单 |
| v3.0 | 所有"待确认"必须清零 |
| v3.x | review 反馈回填 |
**每次升版动作**:找出"待确认" → 谁能答?去问 → 替换为具体内容 → 更新变更记录。
**关键规则**:标"必须澄清"的项 → 业务拍板,不自行推断。
**🚧 门禁**:
- ✅ 版本已迭代到 v3.0+
- ✅ 全文"待确认/待补充/待法务"数量 = 0
- ✅ 变更记录完整
- ❌ 有未收敛的"待确认" → 不能进 review
### 产出物
1. PRD v3.x 终稿(飞书文档)
2. 变更记录(v1.0 → v3.x)
3. 物料清单
4. 教训沉淀(如有)
---
## Stage 3: 多角色 Review（默认启用）
> 来源:pm-review Skill
> 🎯 **目标**:PRD 从 v1.0 经 5 轮并行 review 收敛到 v3.x 终稿,每次反馈都闭环。
### 4 大陷阱
| 坑 | 后果 | 拦截机制 |
|---|---|---|
| 关键澄清项自行推断 | 核心规则建在假设上,返工 | 凡"必须澄清"一律业务拍板 |
| 技术 review 只看新功能 | 研发以为全部重写,估期翻倍 | v3.0 起必含"现有逻辑继承"章节 |
| 单端 review 过 ≠ 三端过 | 服务端/客户端/测试理解各异 | 三端必须联合 review,不能串行 |
| 设计 review 与技术 review 串行 | 设计改完高保真,技术说做不了 | 设计与技术必须并行 |
---
### Phase 3.1: 评审前准备
**检查清单**:
- [ ] PRD 已迭代到 v2.x
- [ ] 已产出低保真原型或 mermaid 流程图
- [ ] 评审日程安排(技术 3 端 + 设计,**必须并行**)
- [ ] 评审产物形式(飞书消息 + MD 澄清清单)
**组织方式**(一人多角色场景):由 Agent 分别扮演四端视角出具 review 意见。
**🚧 门禁**:
- ✅ PRD 版本 ≥ v2.0
- ✅ 评审会议已约
- ✅ 三端 + 设计同时启动,不允许串行
---
### Phase 3.2: 四端并行 Review
**复用已有 Agent 的专业能力,不用临时空白 sub-agent。** 每个视角的 review 由对应的专业 Agent 执行(review 模式),它们自带铁律 + 角色教训 + 专业 checklist。
**四端 Agent 调用映射**:
| 视角 | 审查重点 | Review 模式 prompt 要点 |
|---|---|---|
| **服务端** | 接口可行性、字段规范、状态机、错误码、数据模型 | 从接口可行性审 |
| **客户端** | 交互可实现性、组件复用、状态管理复杂度、技术风险 | 从前端实现审 |
| **测试** | 验收标准可执行性、边界覆盖、4 层测试能否设计 | 从可测试性审 |
| **设计** | 视觉一致性、信息架构、交互规范、响应式可行性 | 从视觉/信息架构审 |
**每个 Agent 的 prompt 模板**:
```
你现在是 review 模式,不是正式设计/编码模式。
审核对象:PRD v{X} 全文
产出:阻塞(P0) / 风险(P1) / 优化(P2) 分级意见列表
无需产出接口文档/技术方案/测试策略,只产出 review 意见。
```
**3 级分类**:
| 级别 | 含义 | 响应要求 |
|---|---|---|
| P0 阻塞 | 不解决无法开发 | 当轮必解决,解决后重跑 review |
| P1 风险 | 可开发但有后续 bug 风险 | 3 天内解决 |
| P2 优化 | 锦上添花 | 可延后或砍掉 |
**每轮 review 动作**:
1. 收集 Agent 反馈(四端并行产出,汇总合并)
2. 分级分类(P0 / P1 / P2)
3. 逐条响应(接受 / 拒绝 / 需澄清)
4. 更新 PRD 版本
5. 更新变更记录
6. **必须澄清项 → 业务方拍板**(不允许 PM 自己推断)
7. 未通过的视角 → 带修改后的 PRD 重新调用对应 Agent re-review
**⚠️ 关键规则:凡标"必须澄清"一律业务拍板**
- 不允许 PM 自己推断答案
- 列清单 + 责任人 + deadline,推业务方拍板
- 拍板后回写 PRD,标注决策来源
**🚧 门禁**(每轮):
- ✅ 所有反馈都有明确响应
- ✅ "必须澄清"项已推业务方
- ✅ PRD 版本已升级,变更记录已更新
- ❌ 有反馈被忽略 → 回去响应
---
### Phase 3.3: 通过确认
**确认标准**(每端独立确认):
- **服务端**:接口草案通过 + 继承原则落地 + 失败路径明确
- **客户端**:页面结构通过 + 交互可实现 + 依赖 API 已定
- **测试**:AC 矩阵完整 + 接口未定项 = 0 + 版本兼容明确
- **设计**:高保真覆盖所有 PRD 状态 + 设计稿 ↔ PRD 一致
**🚧 门禁**:
- ✅ 三端"必须澄清"= 0
- ✅ "条件通过"全部收敛
- ✅ PRD 版本 ≥ v3.0
- ✅ 全文"待确认"= 0
- ❌ 单端通过 ≠ 过闸,必须三端都过
### 产出物
1. 四端 review 反馈汇总(含分级)
2. PRD v3.x 终稿(所有反馈闭环)
3. review 决策记录
---
## Stage 4: Agent 交互设计（可选）
> 来源：agent-interaction Skill
> 🎯 **目标**：把 6 步对话确认压缩到 3 步，用户认知负担最小。
> **何时启用**：做 Agent/Copilot 产品时启用。
### 核心原则
> **三步确认链路**:自然语言输入 → 隐式校验 + 填表高亮 → 确认提交。
### Phase 4.1: 三步确认链路设计
#### 步骤 1: 自然语言输入
- Agent **自动获取当前页面上下文**(page_type / filters / selected / locale / timezone...)
- 结合上下文理解意图 + 提取参数
- **缺失参数才追问**(不要预防性追问)
**示例**:
```
用户在排期页面(已选:集群=欧洲, 国家=西班牙)
用户输入: "明天 8 点到 12 点排一个春促活动"
Agent 自动知道:
page_type = schedule(不用问)
country = 西班牙(从筛选条件)
日期 = 明天(从自然语言)
时段 = 8:00-12:00(从自然语言)
缺失: 活动素材 → 追问
```
#### 步骤 1.5: 隐式校验(Agent 后台自动跑)
| 校验项 | 说明 | 不通过处理 |
|---|---|---|
| 时区转换 | 本地时间转 UTC,检测 DST | 确认卡片标注双时区 + DST 告警 |
| 合规校验 | 按 Global → Region → Country 层级匹配 | 硬性规则拦截;软性规则标黄 |
| 文化日历 | 检查营销节点、禁忌、宗教敏感期 | 确认卡片显示提示或告警 |
| 排期冲突 | 检测同时段已有配置 | 冲突标红 |
#### 步骤 2: 参数确认卡片
**不是纯对话,是结构化卡片**。卡片内可嵌入下拉选择器、日期选择器等表单组件。
#### 步骤 3: 填表高亮 + 用户提交
**三色高亮系统**:
| 颜色 | 含义 |
|---|---|
| 浅蓝色 | AI 填写,用户未修改 |
| 浅黄色 | AI 填写,用户已修改(提醒 AI 改过) |
| 浅红色 | 校验不通过或冲突 |
**提交**:点击后台原有的提交按钮,走已有审核流程。
**🚧 门禁**:
- ✅ 三步每步都有明确设计
- ✅ 隐式校验 4 项覆盖
- ✅ 确认卡片是结构化非纯对话
- ❌ 超过 3 步确认 → 重新精简
### Phase 4.2: 交互状态机
```
空闲态(AI 面板收起)
│ 用户点击 AI 按钮
▼
对话态(AI 面板展开)
│ 用户输入 / 快捷动作 / 模板
▼
校验态(隐式: 时区+合规+文化日历+冲突检测)
│ 校验完成
▼
确认态(参数确认卡片+校验结果)
│ ├── 修改参数 → 留在确认态
│ ├── 取消 → 回到对话态
│ ├── 预览影响 → Dry Run → 回到确认态
│ └── 填入表单 ↓
▼
填表态(左侧表单高亮显示 AI 填写内容)
│ ├── 修改字段 → 高亮变黄
│ ├── 放弃 → 回到对话态
│ └── 点击提交 ↓
▼
完成态(提交结果+影响评估+模板保存建议)
│ 自动回到对话态
```
### Phase 4.3: 快捷工具设计
#### 上下文感知的快捷动作按钮
根据当前页面类型和选中状态,展示最可能的操作。按钮组**不由 LLM 动态生成**,而是按「页面类型 × 选中状态」做**前端规则映射**。
#### 配置模板系统
| 能力 | 说明 |
|---|---|
| 从历史操作生成 | 提交成功后 Agent 主动建议"保存为模板" |
| 变量化 | 日期、国家、素材作为可替换变量,其余参数锁定 |
| 可视化调用 | 点击 [从模板创建],展示模板卡片列表 |
| 团队共享 | 模板可在团队内共享 |
#### 多人协作感知
```
⚠️ @Maria 10分钟前刚给西班牙同时段配了另一个活动,是否冲突?
```
基于操作日志中的 operator + page_context 字段实现。
**🚧 门禁**:
- ✅ 至少 1 种快捷工具
- ✅ 快捷工具不依赖 LLM 动态生成
- ❌ "全靠 LLM 生成按钮" → 拒绝
### 产出物
1. 三步确认链路设计
2. 交互状态机(覆盖所有分支)
3. 快捷动作按钮方案
4. 配置模板系统设计
---
## Stage 5: 学习循环 + 分期规划（可选）
> 来源：agent-learning + agent-phasing Skill
> 🎯 **目标**：让 Agent "越用越准"，同时做好 P0-P3 分期规划。
> **何时启用**：Agent 产品需要长期迭代时启用。
### 5A: 学习循环设计
#### Phase 5A.1: 日志架构(P0 必做)
**日志数据结构**:
```
操作日志:
├── meta: operation_id / timestamp / operator / page_context / config_type
├── geo: region / country / city / timezone / locale / currency
├── interaction: user_input / input_type / agent_parse / agent_questions /
│ form_filled / user_modified / final_submitted
├── execution: api_calls / cross_system / validation_results / submit_status
├── compliance: rules_checked[] / rules_passed[] / rules_blocked[] / override_reason
├── localization: languages[] / currency / tax_rules_applied
├── calendar: nearby_events[] / cultural_flags[]
├── tags: ai_tags / human_tags(双周会后回填)
└── quality: accuracy_score / issues / lessons(双周会后回填)
```
**核心字段**:`user_modified`(记录 AI 填了什么、用户改成了什么--经验学习的核心数据源)
**P0 必做**:
- 日志字段规范定义
- 每次交互自动写入
- 操作编号体系(CFG-YYYYMMDD-NNN)
- 标签字段预留 + AI 自动打标
#### Phase 5A.2: AI 汇总报告机制
**报告运转节奏**:
```
日常: Agent 配置 → 自动写入日志
↓
定时(每双周): AI 汇总分析 → 生成总结报告 → 推送飞书
↓
双周会: 运营团队过报告 → 人工标注(哪些对、哪些错、哪些是规律)
↓
会后: 标注结果回喂 AI → 结合人工判断做经验沉淀
↓
沉淀经验更新 Agent 知识库 → 反哺日常配置 → 循环
```
**AI 总结报告 7 板块**:操作概览 / 准确率分析 / 高频修改 TOP 10 / 合规拦截统计 / 模板使用率 / AI 发现的模式 / 建议经验条目
**原则**:AI 先做脏活(汇总、归类、提假设),人类只做判断(确认、否决、补充)。
#### Phase 5A.3: 经验库三层架构
| 层次 | 规则层 Rules | 模式层 Patterns | 原始层 Raw Cases |
|---|---|---|---|
| 数量级 | 几十~几百条 | 几百~几千条 | 全量操作记录 |
| 性质 | 确定性规则 | 统计规律,需人工确认 | 事实记录 |
| 产生方式 | 双周会确认后升级 | AI 清洗日志后聚类 | 每次交互自动写入 |
| Agent 使用 | 实时加载/检索 | 不直接使用 | 不直接使用 |
**流转**:原始层 → AI 清洗聚类 → 模式层 → 双周会确认 → 规则层 → Agent 决策推荐
**关键**:只有向上流动,没有跳级。AI 不能从原始日志直接生成规则。
**地域维度**:Global → Region → Country → Cluster(继承 + 覆盖,就近优先)
**落地分级**:
- P1: flat 结构 + country 标签(几十条够用)
- P2: 引入层级继承(超过 200 条时)
**生命周期**:规则 3 个月未命中 → 标记"待复核";原始层超 6 个月 → 冷存储。
**🚧 门禁**:
- ✅ 三层结构清晰
- ✅ 流转规则明确(不能跳级)
- ✅ 生命周期管理
- ❌ "AI 直接改规则" → 必须经模式层 + 人工确认
---
### 5B: P0-P3 分期规划
#### P0(4 周):能用 + 有数据 + 不留架构债
| 功能 | 最小可用版本 | 不做什么 |
|---|---|---|
| 三步确认链路 | 单场景端到端 | 不做多场景 |
| PageContext 协议 | 定义接口 + 单页面实现 | 不做其他页面 |
| 时区双显 | 确认卡片展示本地+UTC | DST 只做简单提示 |
| Dry Run | 影响国家数 + 冲突列表 | 不做用户量预估 |
| 合规校验 | 框架 + 硬编码 3-5 条规则 | 不做完整规则库 |
| 日志 | 全字段落库 | 不做查询后台 |
| 快捷按钮 | 前端规则映射 | 不做 LLM 动态推荐 |
**P0 不能省的架构基座**:PageContext 协议定义完整 / 日志全字段落库 / 合规规则框架可扩展
#### P1(4 周):闭环跑起来 + 效率工具
| 功能 | 最小可用版本 |
|---|---|
| 经验库 | 一层 flat 结构 + country 标签 |
| AI 总结报告 | 按区域拆分的操作概览 + 高频修改 TOP 10 |
| 配置模板 | 从历史保存 + 可视化调用 + 变量替换 |
| 人工标注 | 双周会后在日志上打标 |
**P1 完成标志**:"使用→日志→汇总→标注→回喂"闭环真实运转。
#### P2(4 周):铺量 + 深水区
- 多场景扩展(3+ 配置场景接入)
- 合规规则库(法务团队主导梳理)
- 文化日历(只读展示未来 14 天营销节点)
- 经验库层级(条目 >200 时引入继承)
#### P3(未来):智能化
- 文化禁忌拦截 / 实时协作感知 / 影响评估引擎 / 操作回放 / 决策 Agent
**每阶段通用门禁**:
- ✅ 明确"做什么"和"**不做什么**"
- ✅ MVP 标准清晰
- ✅ 下阶段依赖本阶段架构(不是重做)
- ❌ "P0 先不要,P1 再加" → 拒绝
### 产出物
1. 日志数据结构定义
2. AI 汇总报告模板
3. 经验库三层架构设计
4. P0-P3 分期规划文档(含 MVP 清单 + 不做什么)
---
## 完整交付清单
流水线跑完后,产出以下交付物(标注 ✅ 的为默认启用 Stage 的产出):
| # | 交付物 | 产出阶段 | 载体 |
|---|--------|---------|------|
| 1 | 交互模型决策 | Stage 0(可选) | 飞书文档 / 本地 MD |
| 2 | 核心场景故事线 | Stage 0(可选) | 飞书文档 / 本地 MD |
| 3 | PageContext 协议 | Stage 0(可选) | 本地 MD |
| 4 | ✅ 三步对话产出(真实目标+必要条件+精简方案) | Stage 1 | 飞书消息 / 本地 MD |
| 5 | ✅ PRD v3.x 终稿 | Stage 2-3 | 飞书文档 |
| 6 | ✅ 变更记录 | Stage 2 | 飞书文档内维护 |
| 7 | ✅ 四端 Review 汇总 | Stage 3 | 本地 MD |
| 8 | Agent 交互链路设计 | Stage 4(可选) | 飞书文档 / 本地 MD |
| 9 | 交互状态机 | Stage 4(可选) | Mermaid / 本地 MD |
| 10 | 学习循环架构 | Stage 5(可选) | 本地 MD |
| 11 | P0-P3 分期规划 | Stage 5(可选) | 本地 MD |
---
## 常见卡点速查
| 卡点 | 解决 |
|------|------|
| 物料不够全 | 列补料清单,标明谁能给,定 deadline |
| 三步对话拆不出必要条件 | 目标本身模糊,回去找业务方对齐 |
| PRD 写着写着发散 | 每写完一章回头看必要条件还在不 |
| "待确认"一直清不掉 | 列清单 + 责任人 + deadline,强制推进 |
| 一端反复不过 | PRD 有结构性缺陷,回 Stage 2 补物料 |
| "必须澄清"业务方不响应 | 飞书群 @ + 邮件 + 会议三连,带 deadline |
| 一轮 review 反馈 > 20 条 | PRD 还没稳定,拆成多次小 review |
| 设计和技术 review 冲突 | 召开三方对齐会 |
---
## 来源与致谢
本 Skill 融合了以下 7 个核心 Skill 的完整逻辑:
| Skill | 定位 |
|-------|------|
| `agent-scenario` | Agent 场景定位 + PageContext 协议 |
| `socratic-dialogue` | 三步对话法(苏格拉底→第一性→奥卡姆) |
| `pm-requirement` | PRD 4 步产出流水线 |
| `pm-review` | 多角色四端并行 Review |
| `agent-interaction` | 三步确认链路 + 状态机 |
| `agent-learning` | 日志→AI 汇总→人工标注三层架构 |
| `agent-phasing` | P0-P3 分期规划 |
三步对话法源自企业内部 Agent 对话方法论实践,PRD 一次通过率从 ~40% 提升到 ~80%。
don't have the plugin yet? install it then click "run inline in claude" again.